[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE 154: HelperContext Creation
Hi Blaise,
I have a few early comments on the proposed
API.
1. Am I correct that Resolvable will not
serialize non-closed data graphs, but will instead throw a "GraphNotClosed"
exception when attempting to serialize the root element? If
so, do you think Resolveable should also serialize non-closed
graphs? I believe some sort of envelope with orphanHolder properties was
under discussion here.
2. Right now, the implementation can only be set
through the API. Why not provide the same mechanisms here as you use to
set the HelperContextFactory? It seems like unless the user (as opposed to
the vendor) does something, he is stuck with the DefaultImplementation.
And this implementation is certainly not generally suitible. For instance,
the defaultHelperContext (as I read it) is a static (shades of INSTANCE), and,
furthermore, using WeakRefs to the HelperContexts in the map may also not be
appropriate. (Use case here: I serialize an object, and want do
deserialize it latter, in the mean time I don't necessarily have references to
the HelperContext). Bottom line, I think DefaultImplementation is too
specific to be delivered in the API. By making Implementation
pluggable, like HelperContextFactory, we can get out of delivering an
implementation as part of the API.
3. As discussed in the meeting, "Implementation"
is a terrible name. "SDOManager" maybe?
4. The user currently has to put in the effort to
provide an ID, otherwise he gets an unregistered context. It could be,
though, that he wants a registered context but doesn't care what the ID is ...
he just cares that it is unique, so that he can deserialize against it,
later. OK, he can always use java.util.UUID, but purely from a usability
standpoint, it might be better to add a method that calls UUID for
him.
5. I think there should be a standard way to look
up the "default" HelperContext based on the classpath and whatever else is
needed to separate applications. Something like
getDefaultHelperContext(ClassLoader,Properties).
In
general, support for standard serialization has added another level of
complexity to the API, and I'm wondering if the use-case really justifies
it. Handling passivation/activation bounces doesn't need any
standardization. The cross vendor use-case within the same VM is better
served by the API that will be part of SDO 158. That
leaves cross vendor RMI calls. In my opinion, the win here isn't very big
over using XML/ WebServices.
Best
Regards,
Ron
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] Gesendet: Dienstag, 7. April 2009 17:37 An: Fuhwei Lwo Cc: sdo@lists.oasis-open.org Betreff: Re: [sdo] Groups - HelperContext Creation - Version 3 (HelperContextCreation-v3.zip) uploaded In the latest proposal there are actually two plug-in points that can be configured:
Fuhwei Lwo wrote: OF47D67EB4.B2BCD6F0-ON88257591.00523EE5-88257591.0053E81B@us.ibm.com type="cite"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]