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
