Hi, I am trying to do something I have neglected for some time now. That is to hook in a CommonJ (WebSphere AS) thread pool for core camel features (JMS and Servlet stuff is working is just fine but I like to have the async. core features in managed threads as well).
So I actually read up a bit on this one. I've been fiddling around with Mr Preben's tryout (https://github.com/pax95/camel-commonj) a bit. It looks pretty good although there is some final touch needed. However, in the new versions of Camel, the interface has changed from ExecutorServiceStrategy to ExecutorServiceManager, so camel-commonj has to be "ported" to the new interface. When starting, I realised that large portions of the code was shared with DefaultExecutorServiceStrategy (even though Prebens class derives from the Deafult class, private declarations prevents reuse to some extent). My approach is to try to do the implementation in the newer ThreadPoolFactory interface rather than to rewrite the entire ExecutorServiceManager interface. Actually, this is the documented approach. ThreadPoolFactory newCachedThreadPool(ThreadFactory threadFactory) newScheduledThreadPool(ThreadPoolProfile profile, ThreadFactory threadFactory) newThreadPool(ThreadPoolProfile profile, ThreadFactory threadFactory) Now to my question. The agrument to these methods I need to implement is a ThreadFactory which essentially just have one method "Thread newThread(Runnable r)". A look in the source reviels that what's actually passed is an instance of a CamelThreadFactory configured with name, pattern and daemon flag. public CamelThreadFactory(String pattern, String name, boolean daemon) Those arguments is what I need to create the thread pool. I need to create the thread name, but that is a later problem which is easier to solve). The information is there, but not in any way reachable. If I could assume that only CamelThreadFactory was passed in this case (which I can assume in the current code base, at least), then in theory I could use some reflection hacking to get the private parameters, but that does not at all feel good. So, has anyone actually used the ThreadPoolFactory to jack in Camel threads into a Java EE thread pool/work manager before? Any hints how to come around the above "limits"? Any help at all is appreciated. Best Regards Petter Nordlander
