On Oct 18, 2006, at 3:16 PM, Frank Budinsky wrote:
I'm sure some of you will be very to happy to hear that the SDO
spec group
is starting to consider removing the Helper INSTANCE fields and
coming up
with a design to properly handle SDO metadata scoping.
Yes, this is great news!
One of the questions that needs to be answered is how to pass a
TypeHelper
(metadata scope) to existing code that isn't IOC enabled. For
example, SDO
uses Java Serialization to pass DataObjects around. Here's a simple
example of a problem when we don't use a global TypeHelper.INSTANCE:
// get the TypeHelper for my current context
TypeHelper typeHelper = ...
// define the StockQuote type
typeHelper.define(...);
// get a/the DataFactory for the specified TypeHelper scope
DataFactory dataFactory = HelperProvider.getDataFactory(typeHelper);
// create an instance of the defined StockQuote type
DataObject quote = dataFactory.create(..., "StockQuote");
quote.set("companyName", "FlyByNightTechnology");
...
// serialize the quote
ObjectOutputStream out = new ObjectOutputStream(new
FileOutputStream("serializedQuote.xml"));
out.writeObject(quote);
...
// Later we want to read back the quote
ObjectInputStream in = new ObjectInputStream(new
FileInputStream("serializedQuote.xml"));
DataObject inQuote = (DataObject)in.readObject();
PROBLEM: how can the implementation of ObjectInputStream.readObject
() find
the metadata needed to create the StockQuote DataObject? It needs
to use
the typeHelper instance that has the quote metadata defined.
Does anybody have a suggestion for how this could be made to work. My
first thought was that we may need some way to set the default
TypeHelper
for a Thread. Maybe something like this:
HelperProvider.setThreadDefaultTypeHelper(Thread.currentThread(),
typeHelper);
or just:
HelperProvider.setCurrentThreadTypeHelper(typeHelper);
Does this make any sense? If this example used static SDOs, then
the TCCL
would also need to be able to load the actual Java implementation
class.
I think this may be problematic, particularly in managed
environments. Hibernate and JPA have a similar issue to deal with
when handling persistence contexts so it may be worth looking at what
they did. In those cases, they rely on the application maintaining a
reference to the scoped artifact. Basically, this means for managed
environments the runtime will maintain scoping for the application
while in non-managed environments, it is left to the application to
do so.
For SDO, if I follow, the TypeHelper would have to be passed to the
input stream. I'm assuming there would be some "initialization" class
for the SDO implementation (perhaps instantiated from a spec-defined
factory) and this would be responsible for loading the type system
when the application starts. It is likely to be fairly heavyweight so
an application could be told to maintain a reference to that, which
would provide the TypeHelper instance. It could also contain a method
to create input and output streams, making the passing of the type
helper instance transparent to the application. Also, I would provide
a mechanism for explicitly loading XSDs and other resources, and not
assume things can always be loaded from the TCCL.
This would also provide a hook for IoC containers to use SDO
infrastructure as well.
Jim
Any advice or suggestions would be greatly appreciated.
Thanks,
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
