No offense but it sounds to me like you're using a hack in place of a proper solution and are now concerned that it might go away? Can you provide a use case example for where a service might need to know which webapp it was called from? Service data is supposed to be supplied via the context, just because the dispatcher name happens to (but has never been required to) match the webapp name doesn't make it a good solution.
Regards Scott On 27/07/2012, at 8:27 AM, Jacques Le Roux wrote: > The requirement is to be able to recognize in which webapp a service is > called. If it's not called in the context of a webapp then it's another > problematic. Notably if it's called as a job, where then the webapp is always > webtools. I will not consider this aspect for now (then you need another way > to know in which context the service is supposed to be called, but nevermind, > not the issue at hand). I just would like to be sure that inside a service, > using DispatchContext.getName() you can still return the name of the > localDispatcher which is currently defined in the web.xml file of the webapp. > Of course if another smarter mechanism is able to do so, I'd see no problems. > Else I would consider this a major regression and would really like to know > what are the reasons behind, apart refactoring satisfaction (I know this > feeling)... When it's not broken don't fix it... > > Jacques > > From: "Adrian Crum" <[email protected]> >> That seems to be an odd requirement. What if the service call didn't >> originate from a webapp? >> >> -Adrian >> >> On 7/26/2012 3:11 PM, Jacques Le Roux wrote: >>> I did not have the time to read all the thread... I find useful to be able >>> to read the local dispatcher name from DispatchContext in >>> services to know from which webapp the service was called (webtools being a >>> specific case, for instance when you run services >>> from there...) >>> >>> HTH >>> >>> Jacques >>> >>> From: "Adrian Crum" <[email protected]> >>>> I think this has something to do with each application being a separate >>>> web application (in a J2EE sense), but I'm just guessing. >>>> There seems to be a reason you would need some services local to (or >>>> restricted to) a web application, but I don't know what the >>>> reason is. >>>> >>>> -Adrian >>>> >>>> On 7/26/2012 1:32 PM, Jacopo Cappellato wrote: >>>>> On Jul 26, 2012, at 11:51 AM, Jacopo Cappellato wrote: >>>>> >>>>>> * but the main question is: considering the layout described above, what >>>>>> is the purpose/goal of having several instances of >>>>>> LocalDispatcher with different names? Shouldn't we simply create one >>>>>> instance per delegator? >>>>> As a side note, this change(after the recent refactoring) should be >>>>> rather easy to implement; in fact it will be a matter of >>>>> changing the signature of the >>>>> >>>>> LocalDispatcher dispatcher = ServiceContainer.getLocalDispatcher(String >>>>> dispatcherName, Delegator delegator); >>>>> >>>>> into: >>>>> >>>>> LocalDispatcher dispatcher = >>>>> ServiceContainer.getLocalDispatcher(Delegator delegator); >>>>> >>>>> and we will no more have to add the dispatcher name to the web.xml file >>>>> of all the web applications, for example: >>>>> >>>>> <context-param> >>>>> <param-name>localDispatcherName</param-name> >>>>> <param-value>webtools</param-value> >>>>> <description>A unique name used to identify/recognize the local >>>>> dispatcher for the Service Engine</description> >>>>> </context-param> >>>>> >>>>> Kind regards, >>>>> >>>>> Jacopo >>>>> >>>>
