On Tue, Nov 25, 2008 at 2:50 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Tue, Nov 25, 2008 at 2:33 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> >> >> On Tue, Nov 25, 2008 at 2:09 PM, ant elder <[EMAIL PROTECTED]> wrote: >> >>> This has come up on the dev list before IIRC and i don't remember any >>> objections so just an fyi that i plan to do this, see >>> TUSCANY-2688<https://issues.apache.org/jira/browse/TUSCANY-2688> >>> >>> ...ant >>> >> >> Hi Ant >> >> What is the alternative to the commonj stuff. I notice that there is a >> JNDI lookup for the key "java:comp/env/wm/TuscanyWorkManager". I can't see >> this is actually used anywhere by us b.t.w. But if it were whoever were >> writing the thread pool manager would need an interface to write to >> >> Simon >> > > We have a WorkScheduler interface in core-spi so if its need to plug > alternative implementations in we can use/enhance that. The jnid look up is > to make it possible to plug in an appserver workmanager when running > Tuscany embedded in a webapp running in an appserver that supports a commonj > workmanager, i don't know of anyone using this though and its not documented > anywhere how to do that. > > If we want to do something like that when we bring up the webapp support i > think it would better to have an adapter to enable a commonj workmanager be > used with the Tuscany WorkScheduler instead having the Tuscany WorkScheduler > implementation be a commonj WorkManager implementation. How does that sound? > > ...ant I think if we didn't already have the WorkScheduler interface I would be pushing against us inventing our own. However as we do have one already it does present an opportunity to get rid of a dependency from the minimal build. If we go this route I assume you are thinking of a new extension point to plug in the shim to provide integration with a container? Simon
