[sdo] [SDO-96]: Deprecate static INSTANCE variables & improvebootstrapping to allow for coresident implementations

[Radu Preotiuc-Pietro <radup@bea.com>]

Andy Grove [21/Jun/07 11:58 AM] 
I'm in favour of deprecating these static INSTANCE variables but I don't
think we have yet addressed the issue of how SDO should be bootstrapped
so that multiple SDO implementations can co-exist.

For instance, another JIRA suggested adding
HelperProvider.getDefaultContext() but again this means that the first
implementation on the classpath will win.

Each vendor can already add their own proprietary SDOFactory class to
obtain a HelperContext but I would like to at least see this approach
explained in the specification even if the implementation is necessarily
vendor-specific.

Another possibility would be to allow users to specify a class name as a
system property or environment variable and have HelperProvider
instantiate that class rather than the hard-coded
commonj.sdo.impl.HelperProviderImpl.


Blaise Doughan [21/Jun/07 04:47 PM] 
A related problem that needs to be solved is the Java deserialization of
SDOs. When the spec specified method of serialization is used (XML) then
the only real option is to use XMLHelper.INSTANCE to do the
deserialization, since the appropriate context is not and can not be
known.


Andy Grove [21/Jun/07 05:12 PM] 
Perhaps we should only support Java serialization/deserialization via
methods on one of the helper classes. Perhaps we need a new JavaHelper
in the Java version of the spec.

e.g.

interface JavaHelper { void serialize(DataObject, OutputStream os);
DataObject deserialize(InputStream os); }

The JavaHelper would be created via HelperContext.getJavaHelper() and
would therefore know which context to use.

If the user attempts object deserialization outside ot this helper then
we could attempt to use the default context?


Frank Budinsky [21/Jun/07 08:47 PM] 
I had originally included a method in HelperContext to create a
scope-aware ObjectInputStream, but took it out for 2.1 at Ron's request.

ObjectInputStream createObjectInputStream(InputStream inputStream);

I'd propose adding it in 3.0 or even 2.1.1 if others agree.

In Tuscany we have such a method. It returns a simple subclass of
ObjectInputStream that records the context to use during
deserialization.

public class SDOObjectInputStream extends ObjectInputStream { 
private HelperContext helperContext;

public SDOObjectInputStream(InputStream in, HelperContext helperContext)
throws IOException { super(in); this.helperContext = helperContext; }

public HelperContext getHelperContext() { return helperContext; }
}


Ron Barack [22/Jun/07 01:49 PM] 
I'm not sure the solution here has to do with adding new methods to do
the deserialization. After all, when deserialization is done eg, by a
ejb container during reactivation of a passivated session bean, we will
not have a chance to tell the container which API to use.

I think a solution would need to be based on the ExternalizableDelegator
approach in chapter 6. We need to somehow serialize the HelperContext
along with the XML string, and the delegator's readResolve will call the
appropriate API, eg, calling the XMLHelper in the appropriate
HelperContext.

But of course the point of chapter 6 is to provide an interoperable
serialization format...and therefore, in this approach, or any approach,
we need an interoperable way of serializing the HelperContext. This is a
problem, in fact, for us, serializing the HelperContext at all is a big
problem (since it is based basically on the classpath). Perhaps it's
only necessary to store some kind of identifier for the HelperContext,
at leave it up to the system to resolve the identifier.

But I'm wondering how important interoperable serialization really is?
It's optional anyway. In the presence of multiple SDO implementations, a
more standard java.io.Serialization would actually be less problematic,
AFAICS.


Frank Budinsky [22/Jun/07 03:01 PM] 
Hi Ron,

Maybe I'm misunderstanding what you're trying to say, but passing a
HelperContext through the stream is not what's needed. A HelperContext
is simply a metadata visibility scope. Both the writer (sender) and
reader (receiver) of the stream are running in their own scopes. The
reciever isn't trying to deserialize in the senders scope, it's
deserializing in its own scope. All that we need is to provide a way for
a reciever to call ObjectInputStream.readObject() and have it execute in
the receiver's scope. Creating the ObjectInputStream with the
appropriate HelperContext, as we do in Tuscany, is the simplest way to
do that. The implementation of delegate.readExternal(in) - in chapter 6
- can then access the HelperContext from the ObjectInputStream and use
it to do the XML load. If the recieving scope isn't provided (i.e., if
the receiver simply called new ObjectInputStream() to create the stream)
then, as Blaise said, the default HelperContext will (must) be used.

Frank.


Ron Barack [22/Jun/07 03:15 PM] 
Maybe I'm just confused. I was trying to think how this would all work
in a passivation/ activation cycle. Should all references to SDOs be
transient? If not, anything SDO that is being held when eg the
HttpSession is passivated,will be serialized, and will be deserialized
again when the HttpSession is activated. Which HelperContext would be
used in this case?



Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.