Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Dienstag, 19. Mai 2009 16:02
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] Groups - HelperContext Creation - Version 4 (HelperContextCreation-v4.zip) uploaded
Hi Ron,
1. I thought you said that you didn't think it was needed (I'm
not convinced it's needed myself), so in the interest of starting with as simple
a user API as possible, I took it out to start with, assuming that we can always
add it back if we convince ourselves it is needed. I don't
think we need SDO.getHelperContextFactory(implName,classLoader), but we
have a hard requirement for
HelperContextFactory.createHelperContext(id,classLoader), since a classloader is
necessary when deriving metadata through reflection.
2. The
need for Environment.setHelperContext() came about as the result of providing a
default Environment. If an implementation chooses to use the default Environment
impl, and simply provide the HCF, then in OSGi, the Environment will be in the
API bundle, while the HCF will be in the implementation bundle - hence the need
to be able to set it. If we don't provide a default Environment implementation,
then we don't need it. So, now we are adding things into the API to
support a default implementation? Sounds like another reason not to supply
a default implementation!
3. I didn't provide a default HCF
implementation, but rather a convenient (abstract) default base class.
Implementations can choose to not use it, but I just thought it was a useful
base class that implementation could use if they wanted to. If it's not helpful,
then I'm fine with removing it.
Again, unless there are very compelling reasons, I'm
against supplying
implementations, even if they can be overridden. We have enough work in the TC to
define interfaces!
4. Same as #3, I thought
it would be useful to provide a default impl. Implementations can
override/replace it if they want. If we want to remove it, that's fine with
me.
5. After looking at it, I wasn't sure that it made a big difference
one way or another. It seemed like a pretty clean separation, but I'm fine with
merging them too. I see Blaise's latest version has merged them, which also
looks good to me. I'm also OK with either.
Note
that there are a couple of subtle changes I made to the design:
a) HFC
constructor takes an Environment arguement. I think it's important that the HFC
register with the same Environment that constructed it. The passed in
Environment instance can also be used to get a ClassLoader with which to find
the HFC. I think there's some confusion here: there's only
one Environment, it's a singleton and available
over Environment.getInstance(). Don't forget, client's go over the
SDO class, which is basically a wrapper for Environment.getInstance(), so if
Environment.getInstance() doesn't match with the HelperContextFactory's
environment, we're screwed.
b) I added a
createHelperContext() method to HelperContextFactory that only takes an options
argument. In the JavaDoc I say that it will be provided with generated unique
ID. We discussed this method a couple of weeks ago.
Blaise's argument was 1) since UUID is now part of JSE, this
is simply a convenience method that saves the user very few keystrokes
and 2) that the user should always participate in the naming of his
(non-default) contexts. Personally, I'm OK either
way.
Thoughts?
Thanks,
Frank.
"Barack, Ron"
<ron.barack@sap.com>
05/18/2009 04:34 AM |
|
Hi Frank,
I'm pretty confused by some of
the changes that you've made.
1. Why have you removed the HelperContextFactory that take
ClassLoader as a parameter? To me, it is a very important functionality to be
able to specify the classpath in which to search for static SDOs. I'm OK with
removing Environment.getHCF(className, classLoader), but this is a very
different use case.
2. Environment.setHelperContextFactory() should be called
Environment.setDefaultHelperContextFactory(). But even with the name change, I
don't really see any use-case for this method and I consider it a very dangerous
API. Environment is a singleton, and by calling setHelperContextFactory we are
effectively opening the door to having side-effects between applications. This
seems unavoidable in the case of setEnvironment, but I'd be against adding such
an API without a very strong usecase.
3. Why have you added a default implementation of
HelperContextFactory? Under the premise that we should avoid delivering
implementations as much as possible, what use-case does having an additional
implementation here support. At least in my mental model, HCF is the entry point
to the implementation (as in, from this point on, everything is implementation
specific).
4. I
have the same comment regarding a having default implementation of Environment. Especially as it
controls the lifecycle of HelperContexts, the implementation of Environment is
something that goes right to core values. What benefit do we have when we define
default behavior here. Whenever we define default behavior, I think we are
creating expectations in anyone who is viewing the code. Effectively, defining
default behavior is the same as writing a SHOULD in the spec. Implementations
can override them, but the expected behavior is other. What was you motivation
for defining this default behavior?
5. I thought we had decided in last week's call to
combine ServiceResolver and Environment: this was the motivation to provide a
base implementation for environment. You provide a base implementation of
Environement witthout having performed the refactoring that actually motivated
it.
Best
Regards,
Ron
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Freitag, 15. Mai 2009 18:12
An: sdo@lists.oasis-open.org
Betreff: Re: AW: AW: [sdo] Groups - HelperContext Creation - Version 4 (HelperContextCreation-v4.zip) uploaded
Hi Guys,
I've taken a pass at the interfaces (see
attachment). I've only included, in the zip, the files that I changed. The rest
are the same as Blaise's last version.
The changes I made are as
follows:
- 1. moved class Resolvable to the "impl" package. Now only SDO
and HelperContextFactory are API. Everything else is SPI in the "impl"
package.
2. removed the ClassLoader argument from all the APIs
3. made Environment an abstract class (instead of interface)
4. added a default (abstract base class) implementation of HelperContextFactory
5. to support OSGi, and maximum configurability, added setEnvironement and setHelperContextFactory methods
6. a few other minor changes to the design (e.g., HelperContextFactory is constructed with an Environment passed to the constructor).
I'm wondering if we should also need to add a standard BundleActivator for OSGi?
Thanks,
Frank.
(See attached file: helpercontext.zip)
"Barack, Ron"
<ron.barack@sap.com>
05/13/2009 09:06 AM |
|
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
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:
- 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