Hi again, Sometimes when you write down a question, the answer comes by itself.
I realised I didn't need to have those parameters to create commonJ threads in Camel. I have ported camel-commonj to the new ThreadPoolFactory interface and initial tests with WebSphere 7 works just fine. I have no complete test suite heavy concurrency and interruptions etc. but will start look into that as well. I am planning to submit a patch/branch to Prebens camel-commonj component for the latest Camel version. I have the Factory made as a camel component built and tested with maven. I believe more people can use this component. Even though there is not a lot of code, it is somewhat tricky to graps all concepts in both CommonJ, Java concurrency and the Camel interfaces. Sorry for submitting a question that turned out was no question at all. // Petter ________________________________________ Från: Petter Nordlander [petter.nordlan...@enfo.se] Skickat: den 1 januari 2013 21:49 Till: users@camel.apache.org Ämne: CommonJ ThreadPoolFactory interface question 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
