On Tue, Nov 25, 2008 at 3:39 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > 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 Yes sure thats true - if the JNDI lookup returns a WorkManager you know the commonj classes must be available so can use some class that wraps it, if the jndi lookup returns null then you don't use the wrapper and don't need the commonj classes. There would be a compile dependency in some module to compile the wrapper but its an optional runtime dependency and as as commonj is provided by the container we'd never need to distribute the commonj interfaces. ...ant
