[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: AW: AW: AW: [sdo] New HelperProvider implementation
Hi Ron,
If OSGI doesn't deliberately set it to null, then what I am saying is that Thread.currentThread().getContextClassLoader() will probably never return null. The part that I don't understand is the AccessController.doPrivileged(), why is that necessary, I am sure Frank had something in mind, so maybe he can explain. Other than that, Frank's code does try the classloader used to load the SDOImplementation class, so that's fine, right? I am not sure about the system classloader though.
Radu
> -----Original Message-----
> From: Barack, Ron [mailto:ron.barack@sap.com]
> Sent: Monday, February 02, 2009 5:16 AM
> To: radu.preotiuc-pietro@oracle.com; Frank Budinsky;
> sdo@lists.oasis-open.org
> 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
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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]