|
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 the JCL?
- Who is using it now?
- What is the "simple" reference implementation?
- What JVM has it been tested on?
- Will it work with J2ME?
- 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 as well as vendor independence. 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 jpos.loader.JposServiceInstanceFactory
interface. This class is provided by the service writer and used to create the service instances. |
serviceClass |
This is the fully qualified Java class name
for the service the this entry is defining. This class should implement one of the service category interfaces in jpos.services.<DevCat>Service1<n> where
<DevCat> == CashDrawer, LineDisplay, etc... and
<n> == 4a, 5, 6, 7, etc...
|
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, 1.6 etc... |
vendorName |
The vendor name of the service e.g. IBM Corp. |
vendorURL |
The vendor URL |
productName |
The product name that the service under
description is part of |
productDescription |
Some description of the product |
productURL |
Any specific URL for the product |
deviceBus |
The device bus or connectivity. One of:
RS232, RS485, USB, Proprietary or Unknown |
RS232 Properties
The following are properties for defining RS232 service. These
are required if you use the JCL editor to configure your devices. They were decided on by the JavaPOS committee.
NOTE: the property names and values are defined in the jpos.config.RS232Const
interface. This file contains constant for the names defined here as well as possible values.
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 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.
In addition, you need to configure entries for your services. The easiest
mean to define this is via the JposEntryEditor or by editing the sample jpos.xml file to add a JposEntry for the service in question that includes all required and vendor properties.
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 implement a few more methods to the
implmenting class since 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. That is if the jpos.config.regPopulatorClass is set then it will be used as the default populator.
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 for each populator:
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, ...
X == 0 indicates the "default" populator that is used
for all orphan entries (that is entries added to the registry w/o specifying a
populator)
Once the modified jpos/res/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 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 the JCL?
You will need the JavaPOS controls 1.4a or later, the JCL JAR files and an
understanding on how to configure your services.
Configuration of services is usualy specific to the service vendor, it involves setting the common properties and vendor defined properties names and values. Consult the service provider for details.
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 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 if they so desire.
See the JCL RI page for more details.
10. What JVM has it been tested on?
The JCL 2.1.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 and Linux |
|
Sun's JDK 1.4 |
Win32 |
|
NOTE: the JCL is written all in Java and should run on all compliant Java2 JVM.
11. Will it work with J2ME?
The JCL has been found to work with J2ME CDC using the foundation profile.
Depending on if your existing JavaPOS services work with J2ME, your mileage might vary.
12. 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 these tests.
13. Any legal stuff I need to know?
The JCL is an "open source" API that is currently maintained by IBM
and the JavaPOS committee. It is licensed under the
Common Public License or CPL which is an Apache like license, follow the
link for complete license terms.
Last Modified by EMM
on 10/20/02 8:34 PM |
|