Seems like webSiteId would be the best parameter to pass into the service: - It would be populated automatically for services executed from request events - WebSite already stores URLs and other site specific data - Services being called from services where the parent service isn't carrying the data required should really be refactored. Service groups are also a useful mechanism for chained services where all services share a common context but only take what they need.
Also, database configuration is always preferable over properties files IMO. Regards Scott On 27/07/2012, at 5:14 PM, Jacques Le Roux wrote: > The local dispatcher name must not match the webapp name. It just has to > exist in the web.xlm of the webapp. > > Consider this use case, you have *many* webapps. They all share a set of > properties and the values of these properties differ by webapp (hosts, urls, > tokens, timeouts, boolean values, etc.). A simple mechanism is then to have a > properties file by webapp, named after the local dispatcher name, and you > have a very *pramatic* way (think production, properties files in version > system agains contents in DB for instance) to dynamically adapt those values > in function of the webapp context. BTW, if you would pass this value as a > service data you would still need to know in which webapp you are running. > How would you decide that when calling a service in a service where you have > no direct access to request or session? Of course you could still use > ServletContext.getInitParameter(), but then things get complicated, why > complicate them since there is already a valid mechanism? > > I don't care it it goes away for this *specific case* because it will be > still easy for me to re-add it. Actually I'd then even generalise to avoid to > have to pass the local dispatcher name to async called services called sync > services in a webapp. I'd then use the same mechanism than is used to > automatically pass the default/current userlogin for instance. > > I was just warning *everybody* that it might not be a great idea to remove a > feature that's not broken. For which reasons BTW? Is it blocking/breaking > something? > > Also did you read this comment > https://cwiki.apache.org/confluence/display/OFBTECH/Service+Engine+Guide#ServiceEngineGuide-ServiceDispatcher > ? > <<However, applications may be running in different threads than the actual > ServiceDispatcher, so it is left to the LocalDispatcher to keep a > DispatchContext which among other things keeps a reference to the > applications classloader.>> > > Hope I clarified > > Jacques > > From: "Scott Gray" <[email protected]> >> 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 >>>>>>> >>>>>> >>
