Home Docs Changes To-do End Users FAQs Getting Started Developers JCL RI Sample Code JavaDOC References |  |
jpos.config/loader (JCL) - FAQ
The following is a set of frequently asked questions about the JCL: What is it? Why does it exist and who maintains it? Is the JCL 2.0 compatible with the JCL 1.2? What are the required properties for the JCL 2.0? What do I need to do to move my services to the JCL 2.0? What about multi-vendor support and configuration? What happens to Sun's JPS (aka JDDK, JSD/JSL)? What do I need to use it? Who is using it now? What is the "simple" reference implementation? What JVM has it been tested on? Is it 100% pure Java? Any legal stuff I need to know? 1. What is it? Why does it exist? and who maintains it? The jpos.config/loader (JCL) is a simple binding API (configuration/loading) API for the JavaPOS services. It exist to allow the JavaPOS controls to bind to the JavaPOS service in a manner independent of the actual configuration mechanism. In other words, the API defines an abstract API with a reference implementation and allows third parties to create their own implementation. It is currently maintained by IBM and the JavaPOS technical committee. 2. Is the JCL 2.0 compatible with the JCL 1.2? The JCL 2.0 is compatible with JCL 1.2. Services that used the JCL 1.2 should just work with the JCL 2.0. See FAQ4 for details on what to do to build your services. 3. What are the required properties for the JCL 2.0? The JCL requires few properties. They are the same as the JCL 1.2 (all properties names are defined in the jpos.config.JposEntry and jpos.config.JposEntryConst interfaces. Required Properties
Name | Description
logicalName | Unique value and defines the name that will be used when doing the open() call on the control instance
serviceInstanceFactoryClass | The class name of the class that implements the JposServiceInstanceFactory interface. This class is used to create the service.
serviceClass | This is the fully qualified Java class name for the service the this entry is defining
NOTE: these required properties have always been part of the JCL. New JCL 2.0 Standard Properties (required for XML populator and editor) The following properties are standard properties required for using the JCL XML populator. Of course you can define your own populator that does not need these properties but we recommend using them anyway.
Name | Description
deviceCategory | This is the device category of the service that the entry describes. This should be one of the different device categories defined by the JavaPOS specification (capitalization IMPORTANT). e.g. CashDrawer, POSPrinter, ...
jposVersion | The JavaPOS version of the service described by this entry. e.g. 1.5
vendorName | The vendor name of the service
vendorURL | The vendor URL
productName | The product name that the service under description is part of
productDescription | Some description of that product
productURL | Any specific URL for that product
deviceBus | The device bus or connectivity. One of: RS232, RS485, USB, Proprietary or Unknown
RS232 Properties The following are properties for defining and RS232 service. These are required if you use the JCL editor to configure your devices. NOTE: the property names and values are defined in the jpos.config.JposEntryConst interface.
Name | Description
portName | The RS232 port name
baudRate | The baud rate. e.g. 1400
dataBits | The data bits. One of: 4, 5, 6, 7 or 8
parity | The parity value. e.g. None
stopBits | The stop bits. One of: 1.1.5 or 2
flowControl | The flow control. One of: Xon/Xoff, Hardware or None.
4. What do I need to do to move my services to the JCL 2.0? Make sure that your services implement the jpos.loader.JposServiceInstance interface. In the current 1.5 release of the JavaPOS controls the jpos.services.BaseService does not extend that interface, therefore your services classes need to (directly or indirectly) implement both interfaces. See the com.xyz.jpos.LineDisplayService for an example. Also See the JCL Sample section of this document for details. Also you need to configure entries for your services. The easiest mean to define this is via the JposEntryEditor. Please see the Getting Started section of this document for details. See also FAQ3 for details on required properties. NOTE: if you defined your own jpos.config.JposRegPopulator you will need to add a few methods to the class that implements this interface as more methods were added in the JCL 2.0 release. 5. What about multi-vendor support and configuration? One of the key new features of JCL 2.0 is the support for multiple vendor configuration. This is accomplished by allowing the JCL to load entries of more than one jpos.config.JposRegPopulator (or populator). Multi-Populator Support The old way of defining populator takes precedence over the new multi-populator. This is to maintain backward compatibility. To define one or many populator you do as usual and extract the jpos.properties file and edit it (you can also use the JposEntryEditor to do this, see the Getting Started section of this document for details). Add the following properties: jpos.config.populator.class.X = <class-name-of-populator> jpos.config.populator.file.X = <file name to load populator with> Where X == 0, 1, 2, ... When X == 0 this indicates the "default" populator that is used for all orphan entries (that is entries added to the registry w/o specifying a popualtor) Once the modified jpos.properties is added to the jcl.jar file or jpos15.jar then the JCL registry will be populated using the different defined populators. 6. What happens to Sun's JPS (aka JDDK, JSD/JSL)? As of the JavaPOS NY-2K meeting in January 2000, Sun have decided to endorse the JCL for JavaPOS in favor of the JPS. For details see the JavaPOS web site for Sun's official position. 7. What do I need to use it? You will need the JavaPOS controls 1.4a or later, the JCL JAR files and an understanding on how to configure your services. Please see the Getting Started section of this document for more information. 8. Who is using it now? As of January 2000, all the JavaPOS technical committee members have pledge to support the JCL with their JavaPOS services. 9. What is the "simple" reference implementation? The "simple" reference implementation is a pure Java implementation of the JCL. It stands as a very robust yet simple implementation of the JCL and also as an example implementation that third parties can use as a starting point to create their own implementations. See the JCL RI page for more details. 10. What JVM has it been tested on? The JCL 2.0.0 requires Java 2. It has been tested successfully under the following:
JVM | Platform(s) |
IBM's JDK 1.3 | Linux and Win32 |
IBM's JDK 1.2 | IBM's 4690-OS |
Sun's JDK 1.3 | Win32 |
NOTE: the JCL is written all in Java and should run on all compliant Java2 JVM. 11. Is it 100% pure Java? The JCL is all written in Java. PS We have not tried to pass the 100% pure Java tests but we may in the future and do not see any reason why we should not be able to pass that test. 12. Any legal stuff I need to know? The JCL is an "open source" API that is currently maintained by IBM and the JavaPOS committee. See the current header of each of the Java files for more info on the legality issues.
Last modified by EMM on 03/07/2001 12:17 AM