| XmlIngesterService implementation which delegates to XmlDigesterService.
This implementation goes through some pains to ensure that the types of
xml doc (determined by file name convention) are issued to the XmlDigesterService
in a pre-ordained order in an effort to avoid dependency problems. This implementation
is not responsible for knowing about the mappings between types and services, but
only the ordering of types, for the moment.
NOTE: when types are merged into a universal document, we need to decide how to handle
rollback if any specific type in that document fails, given that the current,
legacy implementation assumes that a given XmlDoc consists of one and only one type
and as such can be rolled back atomically. For instance, if universal doc now contains
types A, B, and C, and it invokes ServiceA, ServiceB, and ServiceC in succession on the
entire document, and ServiceB throws an exception attempting to parse B content...
is it sufficient to rollback only that entry, or do we rollback the whole document
and consider it "tainted"? (not to mention whether we should roll back the entire collection
of which the document is a part - for now we do NOT rollback a collection or workflow data doc,
but it is merely moved to a "problem" directory by the poller. the implementation does not yet
specifically note which document or type (and potentially eventually which entry) failed in the
collection or workflow data doc)
NOTE: this service must be invoked only after all other services have initialized
this should be the case since the LifeCycle is kicked off after contextInitialized,
which should occur after Spring is actually done initializing. But is it, considering
we are asynchronously initializing Spring? There is a 30 second built-in delay before
XmlPoller is first run, but suffice it to say there is a possible race condition.
See Also: edu.iu.uis.eden.batch.XmlIngesterService
See Also: edu.iu.uis.eden.batch.XmlDigesterServiceImpl
author:
Aaron Hamid (arh14 at cornell dot edu) |
