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] Groups - HelperContext Creation - Version 4 (HelperContextCreation-v4.zip) uploaded


Hi Ron,

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:
7C3EF93EEBC6EB4A8B4470853DE86566AA8C6B@dewdfe18.wdf.sap.corp" type="cite">
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]