I think this will be a good topic for tomorrows conference call.
HelperContextFactory Class or Interface
I believe whether HelperContextFactory is a class or interface will depend on what we decide to do about serialization. If once serialization is sorted out and HelperContextFactory works fine as an interface I'm ok with modifying this in the proposal.
ImplementationResolver and DefaultImplementationResolver
I have posted a new version of the API that moves these classes to the "commonj.sdo.impl" package as Frank suggested:
http://www.oasis-open.org/committees/download.php/31787/HelperContextCreation-v2.zip
Identifier
I think we all agree that the identifier is useful for deserialization. There are a couple of options:
- Serialization Includes the Identifier
With this option identifiers need to be unique in scope of the proposed SDO object. This means that two instances of HelperContextFactory could not use the same identifier to reference a HelperContext. The getHelperContext(String) method currently proposed for HelperContextFactory could be moved to the SDO object. The advantage of this approach is that if all SDO implementations share the same serialization format then you could serialize between different SDO implementations.
- Serialization Includes Identifier and Implementation
With this option the identifier and implementation string are included in the serialized message. This means that identifiers are unique at the HelperContextFactory level, but the same SDO implementation must be available on both the server and client side.
-Blaise
Barack, Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE865668F7BC0@dewdfe18.wdf.sap.corp" type="cite">Hi Frank, Blaise,Our implementation has a similar API for creating and managing HelperContexts, so I'd like to respond a little to the point 3 in Frank's email.For most users the call to HelperContextFactory.getDefaultContext() is the only HelperContextFactory method they will ever use. At least for us, this returns the HelpContext (lazilly created, of course) associated with the JEE application/ SCA contribution. This is what most users want and expect.We have an additional HelperContextFactory.create() method that takes no arguments. This creates a new HelperContext with a unique identifier. We have also extended the HelperContext interface, so that the identifier can be retreived. Perhaps the addition of such a method can help allieviate some of Frank's concerns.We have the very strong opinion, that managing the HelperContexts is something that we must require of SDO implementations. The main reason for requiring this is, as Frank points out, that it is necessary for java.io deserialization.In our API, the methods are "createOrGet" methods, so when the user (accidentially or intentially) reuses an identifier, he gets an existing HelperContext. I think having separate methods is much cleaner, and therefore I prefer Blaise's API. Having separate methods seems to imply that the (accidental) reuse of an identifier in a create method is a user error, and that the implemation should throw an exception.Best Regards,Ron
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Donnerstag, 19. März 2009 19:24
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] Groups - HelperContext Creation (HelperContextCreation.zip) uploaded
Hi Guys,
I have a few questions and concerns.
- Why is HelperContextFactory an abstract class instead of an interface?
- ImplementationResolver and DefaultImplementationResolver are not user APIs (they're SPIs), so I think they should be moved to the commonj.sdo.impl package, instead of being nested in class commonj.sdo.helper.SDO.
- Regarding the "identifier" argument on the HelperContextFactory.createHelperContext() methods, I'm not sure it's very user friendly. If a user writes an application and just wants to start with a new (clean) HelperContext, what value should be passed for the "identifier" argument? I think SDO definitely needs a standard API for creating HelperContexts, but I'm not so sure we need SDO to also manage HelperContexts. I wouldn't expect typical users, like the one I just described, would need to call the getHelperContext(identifier) method. If I remember correctly, it is intended to help solve the Java serialization (HelperContext lookup) problem, but I think we need a better explanation of what values would be used for identifiers. For example, what if there's already a HelperContext with the requested identifier when you call createHelperContext()? How can a simple user, like the one above, use this without needing to worry about what value to use for the identifier argument?
Thanks,
Frank.
"Barack, Ron" <ron.barack@sap.com>
"Barack, Ron" <ron.barack@sap.com>
03/19/2009 09:03 AM
To
<blaise.doughan@oracle.com>, <sdo@lists.oasis-open.org>
cc
Subject
AW: [sdo] Groups - HelperContext Creation (HelperContextCreation.zip) uploaded
Hi Blaise,
We've reviewed this API, and it looks good to us. I'm going to put this as the first discussion point on this week's agenda.
Ron
-----Ursprüngliche Nachricht-----
Von: blaise.doughan@oracle.com [mailto:blaise.doughan@oracle.com]
Gesendet: Montag, 2. März 2009 17:11
An: sdo@lists.oasis-open.org
Betreff: [sdo] Groups - HelperContext Creation (HelperContextCreation.zip) uploaded
Hello All,
I have added a zip file to the documents page containing a modified set of
SDO 3.0 classes that contain APIs to create and look up instances of
HelperContext. These are based on the results of the virtual face to face
discussion that was held on February 19, 2009.
-Blaise
-- Mr. Blaise Doughan
The document named HelperContext Creation (HelperContextCreation.zip) has
been submitted by Mr. Blaise Doughan to the OASIS Service Data Objects
(SDO) TC document repository.
Document Description:
An updated set of SDO APIs based on the Helper Context Creation discussion
that occured during the virtual SDO Face to Face on February 19, 2009.
The APIs include:
- SDO (New Class) for obtaining HelperContextFactory objects from multiple
vendors.
- HelperContextFactory (New Class) for obtaining instances of
HelperContext. APIs are provided to create and access HelperContexts by a
unique identified.
- HelperProviderImpl (Deprecated & Modified), now delegates calls to
SDO and HelperContextFactory.
- Helper classes (Modified) the INSTANCE variables are now deprecated.
View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=31485
Download Document:
http://www.oasis-open.org/committees/download.php/31485/HelperContextCreation.zip
PLEASE NOTE: If the above links do not work for you, your email application
may be breaking the link into two pieces. You may be able to copy and paste
the entire link address into the address field of your web browser.
-OASIS Open Administration
---------------------------------------------------------------------
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
