SDO INSTANCE fields

[Frank Budinsky <fr...@ca.ibm.com>]

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.

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.

Any advice or suggestions would be greatly appreciated.

Thanks,
Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: SDO INSTANCE fields

[Jeremy Boynes <jb...@apache.org>]

On Oct 18, 2006, at 3:16 PM, Frank Budinsky wrote:
<snip/>
>
> 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.
>
> Any advice or suggestions would be greatly appreciated.

As Jim pointed out, is this something SDO needs to do? Most of these  
problems go away if you make the application responsible for  
providing the TypeHelper to use (basically make it responsible for  
the SDo context). If the application wants to pass it around using  
parameters, a global, a ThreadLocal then it is free to do so.

As Raymond said, this is the approach taken by the JRE for normal  
deserialization. ObjectInputStream does not resolve classes using a  
custom classloader or even the TCCL - most code attempting  
deserialization needs to subclass and override resolveClass() to work  
correctly.

I would be very cautious about using the TCCL as well - this is how  
the current implementation is keying INSTANCE and we know that in non- 
trivial classloader environments this is problematic. I don't see why  
it would be needed in this scenario either. If you have a static SDO  
then the Type entry could contain the actual Class for the Type which  
would be sufficient to allow it to be instantiated.

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: SDO INSTANCE fields

[Jim Marino <jm...@myromatours.com>]

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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: SDO INSTANCE fields

[Raymond Feng <en...@gmail.com>]

Hi, Frank.

That's great news.

I think the issue is very similar as deserializing a java object which 
requires the java class to be available. In some cases, we have to subclass 
the ObjectInputStream to resolve the class by name (by default TCCL is not 
honored).

I think your proposal would work. Is 
HelperProvider.setThreadContextTypeHelper() a better method name?

A related question, is the spec going to define a way to link TypeHelpers, 
for example, TypeHelper1 will delegate to TypeHelper2?

Thanks,
Raymond

----- Original Message ----- 
From: "Frank Budinsky" <fr...@ca.ibm.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, October 18, 2006 3:16 PM
Subject: SDO INSTANCE fields


> 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.
>
> 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.
>
> Any advice or suggestions would be greatly appreciated.
>
> Thanks,
> Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org