On Tue, Nov 25, 2008 at 4:02 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > On Tue, Nov 25, 2008 at 3:46 PM, ant elder <[EMAIL PROTECTED]> wrote: > >> >> >> 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 >> >> >> > OK, but something needs to break the link with the commonj dependency. JNDI > may return a non null object e.g. > > Obect workManager = ctx.lookup("blah"); > wrapper.setWorkManager(workManager); > > So my point what how to get the "wrapper" without re-introducing a > dependency on commonj. There are of course ways and means but I was > specifically asking if you felt that the wrapper was a Tuscany extension or > something else. If not an extension then what did you have in mind? > Injecting an instance, string based classForName (would still need the > dependency at the OSGi bundle level so not ideal) etc. > > Simon > I think that will depend on what the scenario we want to support is - if its just for Tuscany in webapps and using the containers workmanager then the jndi lookup approach might be enough and use an optional dependency of core or in some other module (the 2.x equivalent of host-webapp perhaps), but if its to support a container thread pool with deep integration (which we don't support today) then it probably needs a new extension point. Going back to what i said earlier - i'd like to just remove the commonj dependency and do nothing about the extensibility for now until we have something that needs it. Right now we have no way of running Tuscany 2.x in any sort of container that supports jndi so the current code does nothing useful, there is no reason for the Tuscany thread pool impl to use the commonj WorkManager interfaces anyway, and when/if it comes up that we do need to support a plugable thread pool then we look at what the options are. I could raise a jira so this isn't forgotten if that would help? ...ant
