![]()
End Users Developers
|
The following is a set of frequently asked questions about the JCL:
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
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.
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.
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. 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. 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:
NOTE: the JCL is written all in Java and should run on all compliant Java2 JVM. 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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |