One thought:
Take a look at the AtStartup and LoadMBeanServer classes which are
used in their own threads from PEMain.main(). Similar threads can be
started later, say in PEMain.run().
You could kick off a similar thread to initialize a thread pool. You
could also (optionally) make the classloader and/or thread pool(s)
available via FeatureAvailability:
FeatureAvailability.getInstance().registerFeature
( CONTEXT_ClASSLOADER_FEATURE, classloader );
Later code can call FeatureAvailability.getInstance().waitForFeature
( CONTEXT_ClASSLOADER_FEATURE, ... ) and will block until it's ready.
I'm not sure that's the right solution here, but I thought I'd
mention it.
Lloyd
On Apr 27, 2007, at 11:46 AM, Ken Cavanaugh wrote:
> Lloyd L Chambers wrote:
>> Factor out the thread pool alone so that any client can use it,
>> not just the ORB? And initialize it in its own thread at startup
>> (always)?
>>
> No re-factoring needed in the ORB. The threadpool is independent
> of the ORB. It's just like any other utility
> class in appserv-rt.jar. In fact, several other parts of the app
> server share this same threadpool.
> However, the threadpool startup may need to be factored out of the
> ORBManager code. Right now,
> the threadpool is only initialized when the ORB is initialized, not
> at server startup time.
> But we certainly could move the threadpool initialization someplace
> else, where the
> context ClassLoader is guaranteed to be something that will be
> valid for the lifetime of
> the server VM.
>
> I don't know anything about app server startup, so I can't do this,
> but I'd be happy to work
> with someone to get this done.
>
> Thanks,
>
> Ken.