Hi Ken
As part of OnDemandServer initialization (onInitialization()), the common
classloader is saved in the server's context [ServerContextImpl], for use
by other containers like the EJB and the web container. So could you use
ApplicationServer.getServerContext().getCommonClassLoader() to set as your
default ThreadContextClassLoader. [note the default TCC for the application
server is the Common ClassLoader - this is set in
ApplicationServer.onInitialization()]
HTH,
Thanks.
--Siva.
Lloyd L Chambers wrote:
> Ken,
>
> Kedar had previously suggested to me that Switch() would be good to remove.
>
> I can't claim that FeatureAvailability is the "standard mechanism", but
> I can say that in a discussion of V3, Jerome Dochez expressed his
> thought that it was a useful compliment to the module dependency graph,
> since it addresses a different sort of problem.
>
> Lloyd
>
> On Apr 27, 2007, at 5:02 PM, Ken Cavanaugh wrote:
>
>> Lloyd L Chambers wrote:
>>> I think it would be better to decouple from PEMain by using
>>> FeatureAvailability to expose the classloader.
>>>
>>> Here is one way to do it with FeatureAvailability, whose raison
>>> d^etre is to decouple dependencies, especially among multiple threads
>>> and/or unrelated packages.
>>>
>>> ...
>>> public PEMain() {
>>> // Set the context class loader
>>> _loader = getClass().getClassLoader();
>>> Thread.currentThread().setContextClassLoader(_loader);
>>> FeatureAvailability.getInstance().registerFeature(
>>> CONTEXT_CLASSLOADER_FEATURE, classloader ); ******
>>> AdminEventListenerRegistry.addShutdownEventListener(new
>>> Shutdown());
>>> _instance = this;
>>> }
>>>
>>> elsewhere:
>>> ...
>>> ClassLoader cl =
>>> FeatureAvailability.getInstance().waitForFeature( ******
>>> CONTEXT_CLASSLOADER_FEATURE, "<calling site description>" );
>>> ...
>>>
>>> You could use Switch.getSwitch(), but I think FeatureAvailability is
>>> better for a multi-threaded startup, and introduces no compile-time
>>> dependencies.
>>>
>>>
>> Multiple threads at startup is not an issue in this case, but I'll be
>> happy to use
>> FeatureAvailability if that is the standard mechanism to use for such
>> things.
>> Does this means that the Switch should be removed at some point?
>>
>> Thanks,
>>
>> Ken.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>