On Tue, Nov 25, 2008 at 3:23 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Tue, Nov 25, 2008 at 3:13 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> >> >> 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 >> > > I think we should leave a new extension point till we actually need it, and > as we don't have any webapp integration right now thats not yet. An > alternative to a new extension point could be similar to the jndi lookup > approach thats done now with the addition of an adapter wrapping the commonj > WorkManager so that it can be used with the Tuscany WorkScheduler interface. > > ...ant > > The part I'm missing though is that if you are going to wrap commonj.WorkManager the wrapper still has a dependency on that interface so the placement of the wrapper is important. Simon
