[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: AW: [sdo] Groups - HelperContext Creation - Version 4 (HelperContextCreation-v4.zip) uploaded
Hi Blaise,
I've been considering some of the points here. It
seems to me, the SDO.getHelperContextFactory(String,ClassLoader)
API is pretty useless.
If the client must give the implementation name and classloader, why
should he just lookup and instanciate the class himself? Won't this be
easier and more natural? And if he is creating the HelperContextFactory
himself, then he doesn't need the SDO class at all! I still don't really
get how expecting clients to know the implementation's classloader is really
going to help us in an OSGi world, where the client, the SDO API and the
implementation are all three distinct bundles. I think the API you
originally proposed, with just the name as the parameter, is more
approriate. In JEE the class should be on our current context classpath,
in JSE on the system classpath. On OSGi, I can image that the
Environment finds the named class in the ServiceRegistry. This would mean
that the bundle that contains the SDO implementation should expose the concrete
implementation of HelperContextFactory into the ServiceRegistry, which I think
is a reasonable thing for an OSGi integration to
do.
I
think ServiceResolver's approach to looking up the name of Environment's
implementation class in META-INF/services is similarly suitible to JEE and JSE
environments. It would also support the OSGi scenario where the API is
bundled with the implementation. To support OSGi environments with the API
in a seperate bundle, I think we should have something like
ServiceResolver.setEnvironment(). The bundle that is supplying the
implementation (of Environment) would simply call this method (it would
have to have a lower startLevel than any bundles that use SDO).
This
leaves us with the problem of how to find the implementation class for the
default HelperContextFactory. For JSE/JEE, I think the approach taken is
already good enough. For OSGi, I can think of several approaches.
The Environment can simply take the first service it finds that is registered as
supporting the HelperContextFactory interfaces, or it could be hard wired in the
Environment.
Best
Regard,
Ron
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] Gesendet: Freitag, 24. April 2009 16:47 An: Barack, Ron Cc: sdo@lists.oasis-open.org Betreff: Re: AW: [sdo] Groups - HelperContext Creation - Version 4 (HelperContextCreation-v4.zip) uploaded Thanks for the feedback, below are some of my thoughts. The latest drop (see below) contains fixes for points 2 & 3, if the group is in favour I'll create another drop with fixes for 1 & 5. I'll get back to you on item 4. http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/32234/HelperContextCreation-v5.zip 1. SDO.addHelperContext() vs. SDO.getEnvironment().addHelperContext() I'll go with which ever option the group decides on this point. Note, currently "getEnvironment()" is not a public API. 2. ServiceResolver().getContextClassLoader() Agreed, I have modified the API to fall back to ServiceResolver.class.getClassLoader(). 3. SDO.getHelperContextFactory(String,ClassLoader) Agreed, I have added the methods to both SDO and Environment. 4. Environment and OSGi I'll get back to you on this one. 5. Extra ServiceResolver Methods Originally I put these extra methods for resolving HelperContextFactories as a convenience. If the group decides we can remove them, this should let us put the logic right on the SDO class and remove ServiceResolver all together. -Blaise Barack, Ron wrote: Hi Blaise, I like the direction...I hope these comments don't come off as nitpicking... 1. I like the seperation of the API methods in SDO and the SPI methods in Environment. That being the case, do we still need SDO.addHelperContext()? This method should be called only from an implementation of HelperContextFactory, which I can only imagine will know his Environment, and even if he doesn't will be able to call ServiceResolver.getEnvironment() himself. 2. The method getContextClassLoader should fall back to the system classloader (or maybe to ServiceResolver.class.getClassLoader()). This will handle out-of-container (JavaSE) scenarios and cases where the security constrainst don't allow access to the currentContextClassLoader. 3. If choosing the implementation class of HelperContextFactory is part of the API (ie, is in the SDO class), then shouldn't the user also have a way of specifying the ClassLoader to be used to find the implementation? Don't we need an SDO.getHelperContextFactory(String,ClassLoader), which delegates to a corresponding method in Environment? 4. When resolving the Environment, only the ContextClassLoader is searched. Won't this lead to problems in the OSGi scenario where the API is in one bundle, the Environment in another (and possibly the implementation in a third). Or are you imagining the API bundle always containing an implementation of Environment? The singleton nature of SDO, ServiceResolver and Environment make this a hard problem to solve without complicating the API. 5. ServiceResolver contains methods for looking up the HelperContextFactory which are intended to be used by the implementation of Environment. But since we are no longer providing a default Environment, no one actually calls them. Will implementations of Environment be required to look up the HelperContextFactory in this way, or could you also imagine an implementation of Environment that is hard-wired to a particular implementation of HelperContextFactory? An implementation that is hardwired in this way could for instance know what options to set when creating a default HelperContext. Unless we want to start specifying the options that users may give to "createHelperContext"... Unless we require that all environments be pluggable with all HCFactories, we can remove these methods from ServiceResolver. Ron -----Ursprüngliche Nachricht----- Von: blaise.doughan@oracle.com [mailto:blaise.doughan@oracle.com] Gesendet: Mittwoch, 22. April 2009 21:23 An: sdo@lists.oasis-open.org Betreff: [sdo] Groups - HelperContext Creation - Version 4 (HelperContextCreation-v4.zip) uploaded Hello All, I have added the next revision of the SDO 3 API that makes the setting of Implementation (now Environment) pluggable. -Blaise -- Mr. Blaise Doughan The document revision named HelperContext Creation - Version 4 (HelperContextCreation-v4.zip) has been submitted by Mr. Blaise Doughan to the OASIS Service Data Objects (SDO) TC document repository. This document is revision #3 of HelperContextCreation.zip. Document Description: API Now Includes: - Implementation has been renamed to Environment - Environment is now set by means of a System property or service provider instead of an API on the SDO class. - A new class called ServiceResolver has been created to encapsulate the service lookup logic for both HelperContextFactory and Environment. View Document Details: http://www.oasis-open.org/committees/document.php?document_id=32204 Download Document: http://www.oasis-open.org/committees/download.php/32204/HelperContextCreation-v4.zip Revision: This document is revision #3 of HelperContextCreation.zip. The document details page referenced above will show the complete revision history. 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]