TimePeriod
to time
.Int.ecb.gesmescb.event.GESMESCBReader.setSource(String)
GESMESCBWriter
s using reflectionGESMESCBObject
sInterchangeEnd
and MessageEnd
implicitMetabase
GESMESCBEventSieve
s without filterThe better understood and better documented package
time
should over time replace the old
class util.TimePeriod
.
That package is also more in the spirit of Java since it
is based on interfaces.
The changes in this area will be implemented gradually and should not be very noticeable to the outside.
All components which pass around GESMESCBObjects will implement a dedicated interface. All will have a name and be connected according to instructions in the configuration file. Very flexible.
To allow users of the library to use own implementations of the classes like {@link Int.ecb.gesmescb.TimeSeries}, it could be discussed to replace these classes by equivalent interfaces. Of course the reference implementations would remain accessible, though possibly in a different package than {@link Int.ecb.gesmescb}.
Error reporting is a known weakness. The approach to use the logging mechanism for that is disputable. Also we may want to generate a set of error objects and error object formatters. This should make it easier to report errors in a more uniform way, perhaps even using multiple languages and localization.
ARRAY_CELL
isArrayCell
Java 1.4 contains packages for logging and preferences. When time has come, these should be used in place of {@link Int.ecb.logging} and {@link Int.ecb.prefs}, respectively.
setSource(String)
This method should on the one hand allow re-use of
GESMESCBReader
s and on the other hand give the
top level {@link Int.ecb.gesmescb.application.Loader} a uniform
possibility to govern the sources.
A similar method
{@link Int.ecb.gesmescb.event.GESMESCBWriter}.setDestination(String)
could also be thought of.
This is similar to the choice of a reader using the
{@link Int.ecb.gesmescb.application.Loader#prefs Loader preference}
dataReaderClass
.
A proposal would be to define properties
dataWriterClass.1
, dataWriterClass.2
, and so on.
The advantage is that if a user has written an own GESMESCBWriter
,
the Loader
application need not be recompiled to support it.
This has been implemented in the
{@link Int.ecb.gesmescb.application.BatchTextUI}!
At present, the {@link Int.ecb.gesmescb.semanticchecker.SemanticChecker},
when reporting errors, cannot indicate the Gesmes/TS line and pseudocolumn
where the error occurred. This information is available to the
{@link Int.ecb.gesmescb.edifact.EDIFACTReader} but is not transported
in GESMESCBObject
s. This makes it difficult in some cases
for a user to find the location of the error in the source file.
Typically, a {@link Int.ecb.gesmescb.TimeSeries} key is sufficient
though not convenient for an experienced user of Gesmes/TS-EDIFACT
to search in the EDIFACT source. However, locating errors in more complex
data formats like Gesmes/TS-XML or a database may require additional
information.
Therefore, each GESMESCBObject
should carry a reference
to its origin. The reference would probably use a placeholder-interface
with implementations for each type of input data and maybe
also different for different GESMESCBObject
classes
(because e.g. a {@link Int.ecb.gesmescb.MessageBegin} takes its
information from various positions in the Gesmes/TS-EDIFACT source.
These objects are a relict from the time when the {@link Int.ecb.gesmescb.event.GESMESCBWriter} did not have a {@link Int.ecb.gesmescb.event.GESMESCBWriter#close()} method. Nowadays, a call to this method conveys the information that the end has been reached.
An abstract class Metabase
with a factory method
to access the singleton will allow retrieval of structural definitions
from other than pre-loaded storage structures in memory.
It also goes well with the idea to configure the structural definitions source file/database in the config file rather than on the command line. Even loading from an application server via a URL is thinkable.
In connection with the new layout for the Metabase
,
the {@link Int.ecb.gesmescb.event.ThreadPump} will no longer need
to flush the queue after each message.
The current situation where the metabase acts as a normal listener is not compatible with multiple threads, because the metabase relies on internal status (particularly the current maintenance agency) which must not be changed between handle calls.
The current sieve can be configured to use one {@link Int.ecb.gesmescb.sieve.GESMESCBObjectFilter} to distinguish expected from unexpected objects. It acts as a handle for such a filter.
Unfortunately, it is not possible to configure more than one filter with a sieve. Also, the filter API is structurally very similar to the general event handler API defined in {@link Int.ecb.gesmescb.event.GESMESCBEventListener} and its sub-interfaces.
Therefore, it may simplify the overall API to use only the handler API and drop the filter. To overcome the limitation as to the number of filters, a configuration method similar to the {@link Int.ecb.gesmescb.application.BatchTextUI}'s writer configuration may be used.
The same approach could simplify the (package internal) API in the {@link Int.ecb.gesmescb.semanticchecker} by distributing various checks to different checker classes forming a sequence.