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
>