Please have a look at the interface {@link Int.ecb.gesmescb.event.GESMESCBReader}. It specifies all functions that must be implemented. In fact, this interface extends the {@link Int.ecb.gesmescb.event.GESMESCBEventSource}, which defines operations for Listener connection and disconnection. However, this implies minimum additional coding if you extend the {@link Int.ecb.gesmescb.event.GESMESCBEventSourceAdapter} or if this is not possible by delegate to a {@link Int.ecb.gesmescb.event.GESMESCBEventSourceHelper}.
So there are mainly three things to implement. Each of these will be called once by the application:
run
has finished.
It should free all resources taken for reading which are not yet
freed. Of course you can choose to better directly free resources
at the end of run
.Just one more remark. You may want to also implement the
interface {@link Int.ecb.gesmescb.util.Named}. Names could be used
by more intelligent applications to address components.
This, however, does not imply much programming overhead.
You find one way of how to do it in
YourReader.java
.
The operation {@link Int.ecb.gesmescb.event.GESMESCBReader#run()}
generates all {@link Int.ecb.gesmescb.GESMESCBObject}s which represent
the input. In a loader-setup, these eventually reach the
{@link Int.ecb.gesmescb.event.GESMESCBEventListenerAdapter#handle()}
operation and are written to the
{@link Int.ecb.gesmescb.event.GESMESCBWriter}'s output destination.
In a checker-setup, they are normally not written, of course, but only checked.
There are three categories of GESMESCBObject
s:
The method run
that you write will generate and
dispatch a sequence of the above-mentioned objects in a timely order.
Such a sequence always starts with an
InterchangeBegin
and ends with an InterchangeEnd
.
Between these objects there can be one or more messages.
Each message starts with a MessageBegin
and ends
with a MessageEnd
. Enclosed between these there come
either structural definition objects or data objects, depending
on the type of message it is. A structural definition message
encloses first a sequence of CodeList
s, then
StatisticalConcept
s, and finally KeyFamily
objects.
A data message encloses first a sequence of TimeSeries
and then a sequence of Attribute
s.
Since recently, it is permitted to mix TimeSeries
and Attribute
s arbitrarily. This is less suited to
EDIFACT syntax, but better for OECD-style CSV and probably XML.
The {@link Int.ecb.gesmescb.edifact.EDIFACTWriter} can now
postpone writing of Attribute
s.
Other {@link Int.ecb.gesmescb.event.GESMESCBWriter}s must also
support mixed data sequences.
The package {@link Int.ecb.logging} tries to mimic a small subset of java.util.logging, which is not implemented on platforms earlier than Java 1.4. When Java 1.4 will be sufficiently widespread, the package could become obsolete.
Logging is typically configured via a configuration file.
Its location is determined by the system property
Int.ecb.logging.config.file
.
The logging configuration uses a tree-shaped model.
I.e. setting the log level
of a parent node {@link Int.ecb.logging.Logger}
also sets the child node Logger
s.
The log {@link Int.ecb.logging.Level}s
to be used when generating log messages are
{@link Int.ecb.logging.Level#SEVERE},
{@link Int.ecb.logging.Level#WARNING},
{@link Int.ecb.logging.Level#INFO},
{@link Int.ecb.logging.Level#CONFIG},
{@link Int.ecb.logging.Level#FINE},
{@link Int.ecb.logging.Level#FINER},
{@link Int.ecb.logging.Level#FINEST}.
The additional Levels
{@link Int.ecb.logging.Level#OFF}, {@link Int.ecb.logging.Level#ALL}
can be used to set the sensitivity of Logger
s.
There is a well-defined correspondence between the
Level
s and the
{@link Int.ecb.gesmescb.error.ErrorWatcher} severity codes
(which are so far mirrored by the
{@link Int.ecb.gesmescb.event.ErrorEvent} severity codes):
{@link Int.ecb.gesmescb.error.ErrorWatcher#FAILURE} and
{@link Int.ecb.gesmescb.error.ErrorWatcher#ERROR}
are SEVERE
,
{@link Int.ecb.gesmescb.error.ErrorWatcher#WARNING}
corresponds to a WARNING
,
and {@link Int.ecb.gesmescb.error.ErrorWatcher#OK}
(which is {@link Int.ecb.gesmescb.event.ErrorEvent#INFO})
corresponds to a INFO
.
Obviously, the semantic difference (internal/external problem)
between FAILURE
and ERROR
are not reflected in the logging API.
The finer log levels should be used according to the following proposed policy:
CONFIG
FINE
FINER
FINEST
Level
, particularly
forwarding of
{@link Int.ecb.gesmescb.GESMESCBObject}s.
Of course, these rules are not binding.
Particularly other activities, like opening and closing
files and databases could be logged with FINE
or even INFO
if central to the activity.
The package {@link Int.ecb.prefs} tries to mimic a small subset of java.util.prefs, which is not implemented on platforms earlier than Java 1.4. When Java 1.4 will be sufficiently widespread, the package could become obsolete.
Preferences are typically read from a configuration file.
Its location is determined by the system property
Int.ecb.prefs.config.file
.
The file is in the simple textual {@link java.util.Properties}
format.
Java allows to set properties also via the -D
parameter on the command line.
Many classes retrieve essential parameters from the configuration setup. Most importantly, reading sources and writing destinations can be set this way.