[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: AW: AW: [sdo] New HelperProvider implementation
Hi Radu,
I don't believe I said OSGi sets it to null. OSGi doesn't set it at all. Not sure what the reference to the parent thread is supposed to mean; I assume OSGi isn't setting it there, either.
I found a nice discussion of the problem (and workarounds in Equinox) here: http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements
Which contains a good, brief description of the problem:
"The OSGi Framework specification does not define what the context class loader should be set to and does not define when it should be switched. Part of the problem is the Framework is not always aware of when a component boundary is crossed."
The currentContext classloader is certainly the right thing to use in JavaEE, and all JEE components, such as web containers, ejb containers, etc. HelperProvider.class.getClassLoader() is probably OK in OSGi, at least when the implementation and interface are part of the same bundle, as foreseen by OSGi. Should be OK for standalone clients, too. One could also fall back to ClassLoader.getSystemClassLoader(), incase the implementation is still not found. All I'm saying is we should try all three, and not give up (or throw a NPE) when there is no current context classloader.
Ron
-----Ursprüngliche Nachricht-----
Von: Radu Preotiuc-Pietro [mailto:radu.preotiuc-pietro@oracle.com]
Gesendet: Freitag, 30. Januar 2009 21:13
An: Barack, Ron; Frank Budinsky; sdo@lists.oasis-open.org
Betreff: RE: AW: AW: [sdo] New HelperProvider implementation
Hi Ron,
Do you know for a fact that OSGI sets the threadContextClassloader to null (I don't know if it is possible to set it to null, never tried)? If not set, it defaults to the parent thread's context CL.
Radu
> -----Original Message-----
> From: Barack, Ron [mailto:ron.barack@sap.com]
> Sent: Tuesday, January 27, 2009 5:36 AM
> To: Frank Budinsky; sdo@lists.oasis-open.org
> Subject: AW: AW: [sdo] New HelperProvider implementation
>
> Hi Frank, Everyone,
>
> I'm worried that the call to
> Thread.currentContext.getClassLoader, or at least the
> assumption that it returns a non-null value, is an implicit
> dependency on JEE. On OSGi and on clients we cannot assume
> that this threadlocal is set.
>
> For OSGi, we probably want the bundle classloader in this
> position, but I'm not sure how to get it without introducing
> a dependency on OSGi.
>
> Ron
>
>
> -----Ursprüngliche Nachricht-----
> Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Gesendet: Freitag, 23. Januar 2009 17:08
> An: sdo@lists.oasis-open.org
> Betreff: Re: AW: [sdo] New HelperProvider implementation
>
> Hi Guys,
>
> Since we'd like to get rid of all the INSTANCE fields for
> SDO-96, I was thinking that all the static getXXXHelper()
> methods in HelperProvider should also go. Once we remove all
> this, I think we're not left with much interesting content in
> HelperProvider, so I think that maybe we should just
> deprecate the entire class HelperProvider, and replace it
> with a clean new API. I've attached my first pass at this,
> class SDOImplementation. I've deprecated HelperProvider, but
> made it a subclass of SDOImplementation, for backward
> compatibility. Comments welcome.
>
> Thanks,
> Frank.
>
>
>
>
>
>
>
> Frank Budinsky/Toronto/IBM@IBMCA
> 01/13/2009 10:51 AM
>
> To
> sdo@lists.oasis-open.org
> cc
>
> Subject
> Re: AW: [sdo] New HelperProvider implementation
>
>
>
>
>
>
> Hi Ron,
>
> Thanks for looking at it. You're right that is is a partial
> resolution to SDO-96. My thinking was that SDO-96 is one of
> the issues that we can resolve in the virtual F2F, but I
> wanted to get some starting material for
>
> discussion on the table before that. I think there are
> several aspects to the issue that we'll want to discuss in detail.
>
> One thing that I definitely had intended this class to do,
> but forgot, was
>
> to allow more that one impl/service to be located. I've
> attached a slightly modified version here.
>
>
>
> Thanks,
> Frank.
>
>
>
>
> "Barack, Ron" <ron.barack@sap.com>
> 01/13/2009 10:01 AM
>
> To
> Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
> cc
>
> Subject
> AW: [sdo] New HelperProvider implementation
>
>
>
>
>
>
> Hi Frank,
>
> I'm guessing that this is a partial resolution to SDO-96, is
> that right?
> If not, what is the issue that is being addressed here.
>
> I think holding the information in a file in meta-inf is OK,
> certainly an
> improvement over what we have now, but in order to handle the
> bootstrapping problem, I think we need some additional options. The
> problem with having things in a file in meta-inf is that it
> doesn't really
>
> change the situation about having only one SDO on the
> classpath, which the
>
> user always gets, no matter what.
>
> A lot of systems allow specifying the implementation class
> through the
> API... InitialContext is a famous example of this. Others allow
> configuration through system properties ("-D"s). I think SDO
> should allow
>
> for all 3 configuration options, with the API given highest priority,
> System properties second, the mechanism which you provide
> third, and the
> fallback solution should be the fixed class name constant, as
> you have
> given it.
>
> Best Regards,
> Ron
>
>
> -----Ursprüngliche Nachricht-----
> Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Gesendet: Montag, 12. Januar 2009 22:57
> An: sdo@lists.oasis-open.org
> Betreff: [sdo] New HelperProvider implementation
>
> Hi Guys,
>
> Attached is a proposed new implementation for class
> HelperProvider. The
> advantages of this impl are:
>
> 1. It allows SDO implementations be registered as a Java
> Service Provider
> -
> http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
> %20Provider
> 2. Implementations should not need to replace this impl, but instead
> simply plug in an subclass with necessary overrides.
> 3. I believe it's backward compatible with the previous version.
>
> Please take a look at this impl, and let me know what you
> think. Maybe we
> can discuss in tomorrow's call?
>
> Thanks,
> Frank.
>
>
> ---------------------------------------------------------------------
> 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_workgr
oups.php
>
>
> [attachment "HelperProvider.java" deleted by Frank
> Budinsky/Toronto/IBM]
> ---------------------------------------------------------------------
> 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_workgr
oups.php
>
> ---------------------------------------------------------------------
> 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]