OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: AW: [sdo] New HelperProvider implementation


Hi Frank,

It's easy enough to use the correct HelperContext/Implementation for 
serialization.  The problem is finding one for deserialization.  Using 
SDOImplementation.getInstance().getDefault() context is better than 
HelperProvider.getDefaultContext(), but not perfect.

I've been experimenting with mechanisms of passing HelperContext info as 
part of the serialized content, but haven't been able to come up with 
anything worth proposing to the group.

Does resolvable need to be implementation dependent?  Wouldn't it make 
serializing between SDO implementations easier if we all used the same 
implementation of Resolvable?

-Blaise

Frank Budinsky wrote:
> Hi Blaise,
>
> You are right. Sorry I missed that. It means that by default we use the 
> default context of the default implementation, instead of just the default 
> context of the one and only implementation previously. I think that we 
> also need to look at how we can allow other implementations to be used. 
> Maybe we should provide more constructors for ExternalizableDelegator, 
> where you can pass in an implementation.
>
>   public ExternalizableDelegator()
>   {
>     this(SDOImplementation.getInstance());
>   }
>
>   public ExternalizableDelegator(Object target)
>   {
>     this(SDOImplementation.getInstance(), target);
>   }
>
>   public ExternalizableDelegator(SDOImplementation impl)
>   {
>     delegate = impl.resolvable();
>   }
>
>   public ExternalizableDelegator(SDOImplementation impl, Object target)
>   {
>     delegate = impl.resolvable(target);
>   }
>
> Frank.
>
>
>
>
> Blaise Doughan <blaise.doughan@oracle.com> 
> 02/06/2009 10:36 AM
>
> To
> Frank Budinsky/Toronto/IBM@IBMCA
> cc
> sdo@lists.oasis-open.org
> Subject
> Re: AW: [sdo] New HelperProvider implementation
>
>
>
>
>
>
> Hi Frank,
>
> Along with your proposed changes the following would be required to 
> ExternalizableDelegator (also attached).
>
>   public ExternalizableDelegator()
>   {
>     delegate = SDOImplementation.getInstance().resolvable();
>   }
>
>   public ExternalizableDelegator(Object target)
>   {
>     delegate = SDOImplementation.getInstance().resolvable(target);
>   }
>
>
> I think in general this means that the HelperContext used for 
> deserialization will become:
>     SDOImplementation.getInstance().getDefaultContext();
>
> As opposed to:
>     HelperProvider.getDefaultContext();
>
> -Blaise
>
>
>
> Frank Budinsky wrote: 
> Hi Guys,
>
> Since we'd like to get rid of all the INSTANCE fields for SDO-96, I was 
> thinking that all the static getXXXHelper() methods in HelperProvider 
> should also go. Once we remove all this, I think we're not left with much 
> interesting content in HelperProvider, so I think that maybe we should 
> just deprecate the entire class HelperProvider, and replace it with a 
> clean new API. I've attached my first pass at this, class 
> SDOImplementation. I've deprecated HelperProvider, but made it a subclass 
> of SDOImplementation, for backward compatibility. Comments welcome.
>
> Thanks,
> Frank.
>
>
>
>
>
>
>
> Frank Budinsky/Toronto/IBM@IBMCA 
> 01/13/2009 10:51 AM
>
> To
> sdo@lists.oasis-open.org
> cc
>
> Subject
> Re: AW: [sdo] New HelperProvider implementation
>
>
>
>
>
>
> Hi Ron, 
>
> Thanks for looking at it. You're right that is is a partial resolution to 
> SDO-96. My thinking was that SDO-96 is one of the issues that we can 
> resolve in the virtual F2F, but I wanted to get some starting material for 
>
>
> discussion on the table before that. I think there are several aspects to 
> the issue that we'll want to discuss in detail. 
>
> One thing that I definitely had intended this class to do, but forgot, was 
>
>
> to allow more that one impl/service to be located. I've attached a 
> slightly modified version here.
>
>
>
> Thanks,
> Frank.
>
>
>
>
> "Barack, Ron" <ron.barack@sap.com> 
> 01/13/2009 10:01 AM
>
> To
> Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
> cc
>
> Subject
> AW: [sdo] New HelperProvider implementation
>
>
>
>
>
>
> Hi Frank,
>
> I'm guessing that this is a partial resolution to SDO-96, is that right? 
> If not, what is the issue that is being addressed here.
>
> I think holding the information in a file in meta-inf is OK, certainly an 
> improvement over what we have now, but in order to handle the 
> bootstrapping problem, I think we need some additional options.  The 
> problem with having things in a file in meta-inf is that it doesn't really 
>
>
> change the situation about having only one SDO on the classpath, which the 
>
>
> user always gets, no matter what.
>
> A lot of systems allow specifying the implementation class through the 
> API... InitialContext is a famous example of this.  Others allow 
> configuration through system properties ("-D"s).  I think SDO should allow 
>
>
> for all 3 configuration options, with the API given highest priority, 
> System properties second, the mechanism which you provide third, and the 
> fallback solution should be the fixed class name constant, as you have 
> given it.
>
> Best Regards,
> Ron
>
>
> -----Ursprüngliche Nachricht-----
> Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
> Gesendet: Montag, 12. Januar 2009 22:57
> An: sdo@lists.oasis-open.org
> Betreff: [sdo] New HelperProvider implementation
>
> Hi Guys,
>
> Attached is a proposed new implementation for class HelperProvider. The 
> advantages of this impl are:
>
> 1. It allows SDO implementations be registered as a Java Service Provider 
> - 
> http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider
> 2. Implementations should not need to replace this impl, but instead 
> simply plug in an subclass with necessary overrides.
> 3. I believe it's backward compatible with the previous version.
>
> Please take a look at this impl, and let me know what you think. Maybe we 
> can discuss in tomorrow's call?
>
> Thanks,
> Frank.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
> [attachment "HelperProvider.java" deleted by Frank Budinsky/Toronto/IBM] 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>  
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php /**
>  * <copyright>
>  *
>  * Service Data Objects
>  * Version 2.1.1
>  * Licensed Materials
>  *
>  * (c) Copyright BEA Systems, Inc., International Business Machines 
> Corporation, 
>  * Oracle Corporation, Primeton Technologies Ltd., Rogue Wave Software, 
> SAP AG., 
>  * Software AG., Sun Microsystems, Sybase Inc., Xcalia, Zend Technologies, 
>
>  * 2005-2008. All rights reserved.
>  *
>  * </copyright>
>  * 
>  */
>
> package commonj.sdo.impl;
>
> import java.io.Externalizable;
> import java.io.IOException;
> import java.io.ObjectInput;
> import java.io.ObjectOutput;
> import java.io.ObjectStreamException;
>
> /**
>  * Delegates DataObject serialization while ensuring implementation 
> independent 
>  * java.io.Serialization.  An implementation of DataObject
>  * returns an ExternalizableDelegator from its writeReplace() method.
>  * 
>  * The root DataObject is the object returned from do.getRootObject() 
> where
>  *   do is the DataObject being serialized in a 
> java.io.ObjectOutputStream.
>  *   When do.getContainer() == null then do is a root object.
>  * 
>  * The byte format for each DataObject in the stream is:
>  * [0] [path] [root]   // when do is not a root object
>  * [1] [rootXML]       // when do is a root object
>  * 
>  * where:
>  * [0] is the byte 0, serialized using writeByte(0).
>  * [1] is the byte 1, serialized using writeByte(1).
>  * 
>  * [path] is an SDO path expression from the root DataObject to the 
> serialized 
>  *          DataObject such that root.getDataObject(path) == do.
>  *          Serialized using writeUTF(path).
>  * 
>  * [root] is the root object serialized using writeObject(root).
>  * 
>  * [rootXML] is the GZip of the XML serialization of the root DataObject.
>  *          The XML serialization is the same as 
>  *          XMLHelper.INSTANCE.save(root, "commonj.sdo", "dataObject", 
> stream);
>  *          where stream is a GZIPOutputStream, length is the number of 
> bytes 
>  *          in the stream, and bytes are the contents of the stream.
>  *          Serialized using writeInt(length), write(bytes).
>  *
>  */
> public class ExternalizableDelegator implements Externalizable
> {
>   public interface Resolvable extends Externalizable
>   {
>     Object readResolve() throws ObjectStreamException;
>   }
>  
>   static final long serialVersionUID = 1;
>   transient Resolvable delegate;
>  
>   public ExternalizableDelegator()
>   {
>     delegate = SDOImplementation.getInstance().resolvable();
>   }
>
>   public ExternalizableDelegator(Object target)
>   {
>     delegate = SDOImplementation.getInstance().resolvable(target);
>   }
>
>   public void writeExternal(ObjectOutput out) throws IOException
>   {
>     delegate.writeExternal(out);
>   }
>
>   public void readExternal(ObjectInput in) throws IOException, 
> ClassNotFoundException
>   {
>     delegate.readExternal(in);
>   }
>
>   public Object readResolve() throws ObjectStreamException
>   {
>     return delegate.readResolve();
>   }
> }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>   


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]