Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep

sync4j.client.* (5)sync4j.framework.* (240)sync4j.server.* (18)sync4j.syncclient.* (18)
sync4j.test.* (4)sync4j.transport.* (9)

Package Samples:

sync4j.framework.transport.http: Application framework for building data synchronization clients and data synchronization servers  
sync4j.syncclient.spds.engine.recovery: This package contains the API to interface the synchronization engine with host applications.  
sync4j.syncclient.spds.engine: This package contains the Sync4j SyncClient Data Synchronization API  
sync4j.client.j2me: Contains the classes for the standalone sync4j client application.  
sync4j.server.syncbean.session: Stateful session EJB which handles data synchronization messages  
sync4j.framework.server.store: Base framework for building a data synchronization server  
sync4j.client
sync4j.framework.client
sync4j.framework.config
sync4j.framework.core.xml.jdom
sync4j.framework.core.xml.nanoxml
sync4j.framework.core.xml
sync4j.framework.core
sync4j.framework.database
sync4j.framework.dm
sync4j.framework.engine.source
sync4j.framework.engine
sync4j.framework.logging
sync4j.framework.protocol.v11
sync4j.framework.protocol

Classes:

IterateTask: This class is a Jakarta Ant custom task that repeatedly calls a target passing different values from a delimited string. For example: <project name="Test" default="main" basedir="."> <taskdef name="iterate" classname="sync4j.test.tools.ant.IterateTask"/> <target name="main"> <iterate target="hello" itemList="1,2,3" property="i" > </iterate> </target> <target name="hello"> <echo message="${i}" /> </target> </project> The above example will call the hello target three times, each time passing a value from the item list. In this case the ...
Sync4jStrategy: This class represents a synchronization process. The base concrete implementation of a synchronization strategy. It implements the ConcreteStrategy partecipant of the Strategy Pattern. The synchronization process is implemented in this class as follows: Given a set of sources A, B, C, D, etc, the synchronization process takes place between two sources at a time: A is first synchronzed with B, then AB with C, then ABC with D and so on. The synchronization process is divided in three phases: preparation, synchronization, finalization. These phases correspond to the methdos prepareSync, sync and endSync; ...
SyncStrategy: It defines the interface of a Synchronization Strategy object. It implements the Strategy partecipant of the Strategy Pattern. It is usually called by the synchronization engine when a syncronization action has to be performed. There are two types of synchronization process: slow and fast. Slow synchronization A slow synchronization is when the sources to be synchronized must be fully compared in order to reconstruct the right images of the data on both sources. The way the sets of items are compared is implementation specific and can vary from comparing just the key or the entire content of a ...
SyncManager: The SyncManager is the contact point between a host application and the synchronization engine. It is designed to hidden as much as possible the details of the synchronization logic, protocol, communication and so on; the simplest way to use it is to get an instance of the SyncManager and call its sync() method, as in the examples below: SyncManager syncManager = SyncManager.getSyncManager("test"); syncManager.sync(); SyncManager syncManager = SyncManager.getSyncManager("test", runtimeProperties); syncManager.sync(); getSyncManager() is a factory method that creates a new SyncManager bound to the ...
PostSyncML: This is a driver for running tests at the protocol level. It requires a directory structure like this: {test code} msg1.xml msg2.xml ... reference msg1.xml msg2.xml ... response msg1.xml msg2.xml ... test code is the code name of the test to be performed (i.e. WOSI0001); msg{N}.xml are the messages that the client has to send to the server. For each message sent, the response is stored in the response directory. The directory reference contains the expected response messages used by the comparison tool to identify the differences between the returned messages and the expected values. This class ...
SyncSource: A SyncSource is responsible for storing and retrieving SyncItem objects from/to an external data source. Note that the SyncSource interface makes no assumptions about the underlying data source or about how data are formatted: each concrete implementation will use its specific storage and formae. A SyncSource is not used directly by the host application, instead its methods are called by the synchronization engine during modifications analysis. The SyncSource methods are designed to perform an efficient synchronization process, letting the source selecting the changed items instead of doing more ...
SyncPackage: This is a base abstract class for classes that implement SyncML protocol packages. A SyncML package is composed of a SyncHeader and a SyncBody which follows the requirements that the protocol mandates. SyncPackage and its subclasses are designed to be used in two steps. First a SyncPackage is created and checked for validity and compliancy with the protocol. Than getResponse() can be used to get a response message for the given request. During the request validation process some information about the request message are cached into instance variables and used in getResponse() . Subclasses are required ...
JAASOfficer: This implementation of Officier uses JAAS for authentication and authorization. In order to use this implementation, remember to set the system property java.security.auth.login.config accordingly as specified in JAAS documentation or in the documentation of the application server in use. For example, in the case of the J2EE RI, in order to use the SimpleLoginModule delivered with the framework, the following lines have to be added to the file {J2EESDK_HOME}/lib/security/login.config : sync4j { sync4j.framework.security.jaas.SimpleLoginModule required required debug=true; } The security policy ...
SyncItem: SyncItem is the indivisible entity that can be exchanged in a synchronization process. It is similar to a sync4j.framework.core.Item , but this one is more generic, not related to any protocol. A SyncItem is uniquely identified by its SyncItemKey , whilst item data is stored in properties, which can be retrieved calling getProperty() , getProperties() and getPropertyValue() . Properties can be set by calling setProperties() , setProperty() and setPropertyValue() . A SyncItem is also associated with a state, which can be one of the values defined in SyncItemState . The following properties are standard ...
Sync4jHttpServlet: Receives the HTTP request and does session management. Session Management If the url contains a parameter {PARAM_SESSION_ID}={SESSION_ID}, the session id is used to lookup in the handlerCache if there is already a SyncHolder associated with the given session id it is used to process the incoming request. Otherwise (either if the session parameter is not specified or not cached handler is found), a new session id is created and a new SyncHolder object is instantiated and stored in the cache. The session id is created as followed: the first four bytes contains the IP address of the remote client ...
SyncEngine: A synchronization engine represents a mechanism used to drive the syncrhonization process. SyncEngine represents the Context partecipant of the Strategy pattern. It is a sort of factory and manager for the starategy object referenced by the property strategy (that implementing classes must provide). SyncEngine concentrate all the implementation specific information regarding strategies, sources, databases, services, etc. It is the point of contact between the synchronization, protocol and server services. When a synchronization process must take place, the SyncEngine will pass the control to the ...
PersistentStore: A PersistentStore is a class that stores objects in a persistent media such as a database. The work of saving and reading data to and from the store is delegated to the store() and read() methods that can take the appropriate actions based on the type of the object that has to be written or read. To store an object just call store(obj) . To read an object call read(obj). Note that those two methods return true if they know how to deal with the given object; that return value is not intended to be a success indicator. It just tells the caller that the PersistentStore knew how to process the given ...
SyncItem: SyncItem is the indivisible entity that can be exchanged in a synchronization process. It is similar to a sync4j.framework.core.Item , but this one is more generic, not related to any protocol. A SyncItem is uniquely identified by its SyncItemKey , whilst item data is stored in properties, which can be retrieved calling getProperty() , getProperties() and getPropertyValue() . Properties can be set by calling setProperties() , setProperty() and setPropertyValue() . A SyncItem is also associated with a state, which can be one of the values defined in SyncItemState . The following properties are considered ...
SyncBean: This is the session enterprise java bean that handles a synchronization request. It is designed to be a stateful session bean so that the state and the session management are on charge of the application server. This server accepts synchronization requests addressed to the hostname indicated by the configuration property pointed by {CONFIG_SERVER_URI} (see Sync4j.properties). SyncBean uses two environment properties: {ENV_ENGINE_FACTORY_NAME} points to the bean to be used as a factory for the synchronization engine {ENV_SERVER_CONFIG_URI} contains the URI of the server configuration. It can be ...
SimpleSessionHandler: This class represents the handler for a SyncML session. It coordinates and handles the packages and messages as dictated by the protocol. The entry point is processMessage() , which determines which message is expected and what processing has to be done (depending on the value of currentState ). If an error accours, the session goes to the state STATE_ERROR ; in this state no other messages but initialization can be performed. In the current implementation separate initialization is required. SessionHandler makes use of a SyncEngine for all tasks not related to the handling of the protocol. See ...
SessionManager: This implementation of a AbstractSessionManager stores and retrieves sessions to/from the file system. For each session is serialized under the directory pointed by sessionsPath in a file called {session_id}.session . This is a very simple implementation that allows many servers to access the same session repository. In fact, in a real deployment, we can have SyncML servers replicated for reliability and scalability purposes. In that case they must share the directory specified by sessionsPath . This class is not thread safe. It is supposed that an instance is not shared by multiple threads .
ClientConnectionImpl: A class for Http client connection. It assumes http-specific behavior, that means, it is not using StreamConnection but HttpConnection. Note: 1. A client can force HTTP 1.0 behavior by including the "Connection: close" header. In this behavior, the server closes the socket when it is done with the request. 2. For applications that make multiple round trip requests to the same server, you can achieve the best performance by taking advantage of the HTTP 1.1 persistent connections. This is particularly true if the requests are made over real wireless networks where the bandwidth is slow and the latency ...
SyncMLClient: This class is the http client handling the exchanges between a j2me client and a SyncML server, as located by an URL. The implementation synchronized the run method and introduced the wait method so as to enforce communicating one thread at a time upon user pressing "connect" button excessively. Also, we keep a single thread for communication all the time, instead of pressing Connect button each time. As a result, it saves the j2me device from sparing precious resource on creating a thread everytime. Courtesy of this article
PersistentStoreManager: This class represents the main persistent store of the Sync4j server. It handles everything related to saving and reading information to and from the database, delegating the work to other PersistentStore s if necessary. PersistentStoreManager can be configured with a list of PersistetStore s that are called in sequence until one of them can process the given object. This list is expressed in the form of the string array stores ; each string is the name of a bean (or a class) and is loaded by sync4j.framework.tools.beans.BeanFramework .
LazyInitBean: This interface models beans that supports or requires lazy initialization. When a bean is created, first of all the empty constructor is created and the the bean properties are set. It the initialization of the bean meeds that the properties have a proper value a init() method may be provided so that the caller has an opportunity to separately initialize the bean before using it. The described mechanism is used in BeanFactory when an instance of the bean is created. If the bean implements LazyInitBean after creating the bean the method init() is called.
Node: This class corresponds to &ltNode&gt element of the SyncML Device Management Tree and Description Framework DTD. Node is the representation of an instantiated object. Note that this element is recursive and that a Node with a Value tag must always terminate the recursion. It is possible for a Node to omit both the next recursive Node and a Value, this means that the hierarchy of Nodes continues elsewhere. This can be used to increase readability of very deep trees.
Configuration: Incapsulates all the configuration information about a Sync4jEngine . Configuration parameters are stored as properties in a Map structure. The key is the name of the parameter and it is strucured in dotted separated namespaces. The value of the parameter is the value of the key and can be of any type. Accessor methods are provided to get the value of the parameter in a particular type (such as String, int, double, boolean, ...). Access to getXXX() and setXXX() methods are synchronized.
SyncItemImpl: SyncItem is the indivisible entity that can be exchanged in a synchronization process. It is similar to an Item, but it doesn't contain any data, only status and addressing information. The idea is that a SyncItem represents status information about an item. Only if an item must be synchronized it needs also the real data. The SyncItemKey uniquely identifies the item into the server. Client keys must be translated into server keys before create a SyncItem .
ClientModifications: Represents a Client Modification package of the SyncML protocol. The class is designed to be used in two times. First a ClientModification is created and checked for validity and compliancy with the protocol. Than getResponse() can be used to get a response message for the given request. During the request validation process some information about the request message are cached into instance variables and used in getResponse() . Example: TO DO
SyncInitialization: Represents the Initialization package of the SyncML protocol. Example: SyncInitialization syncInit = new SyncInitialization(header, body); ... do something ... syncInit.setServerCapabilities(serverCapabilities); syncInit.setAuthorizedStatusCode(StatusCode.AUTHENTICATION_ACCEPTED); syncInit.setClientCapabilitiesStatusCode(StatusCode.OK); ... other initializations ... Message response = syncInit.getResponse();

Home | Contact Us | Privacy Policy | Terms of Service