Hi Felix 2014-12-08 14:34 GMT+01:00 Felix Meschberger <fmesc...@adobe.com>:
> > > > * The J2E programming model discourages the creation of threads; instead > > one is supposed to use the threadpools of the application server. This is > > important in appservers like Websphere AS, where the succesfull lookup of > > JNDI resources is directly bound to the fact, that the thread, which > tries > > it, comes from a Websphere thread pool. > > Yes, that *is* a problem. And I am not sure whether we can easily solve > this. Except by not deploying as a web application. For example in > WebSphere with Liberty Profile, Sling could be deployed directly into > WebSphere’s OSGi framework and thus directly access the JNDI resources > through the OSGi JNDI service. > And that's the problem I have, and the reason for my proposal :-) > > Interestingly the actual problem of reading JNDI resources during startup > — looking up a JNDI DataSource to be used for an Oak Microkernel - is > harder to solve: This thread is the Felix Framework Startlevel service > thread which is also created with new Thread and not with some thread > pooling. > > (Yet, it is important to note, that the framework is not able to start if > the Startlevel thread could not be retrieved) > Hm, if we're talking about about appservers support: in the launchpad we also create a number of threads; most specifically the Sling Notifier thread and the OSGI Installer thread. Both of them are involved in the startup of the bundles and services. > WDYT? > > I think it basically is an ok idea, which we might want to follow-up upon. > Yet, we would not fully solve the problem, since some of the threads > created are outside of the control of Sling, particularly the Startlevel > thread used by the framework. > For the moment I would be happy, if we could migrate the threads created by Sling. The Felix threads are a different story. > > Yet, there’s JSR 236 (Concurrency Utilities for J2EE). Maybe we should > look into this ? Unfortunately its only part of J2EE 7 so your favourite > blend of App Server might not actually support it. > "favourite blend of App servers" ... You owe me a beer now :-) Can we split the application specific parts into own bundles and provide a JSR236 compliant code, plus a simple version with its own threadpool. -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
