From: "David E Jones" <[email protected]>
On Feb 16, 2011, at 12:51 AM, Jacques Le Roux wrote:
Hi,
Reading this sentence in https://cwiki.apache.org/confluence/display/OFBTECH/Service+Engine+Guide <<Services which are used in
different applications can be defined only once by creating Global Service Definition files or services specific to an
application can be restricted and available only to that application.>> and considering
https://issues.apache.org/jira/browse/OFBIZ-865, I wonder 2 things
1. Should we not remove the reference to Global Service Definition since it's never used OOTB, and a bit confusing since anyway
services defined by components are also reacheable outside those components?
This is backwards. The global service definitions are ALWAYS used in the OOTB
code, not never.
a. Corollary: should we not remove the resource-loader element from
serviceengine.xml since it's broken for more than 3 years?
In what way is it broken?
Oops forget it, I read https://issues.apache.org/jira/browse/OFBIZ-865 too fast, it's only if you put <resource-loader> in root
element <service-config>. Now it has been moved into <service-engine>, this is clear in service-config.xsd. BTW should we close
OFBIZ-865?
What I understand from xml definitions (did not look into code): OOTB we only define <resource-loader> in ofbiz-component files and
this is referred by <service-resource> in the same file and defines thus Global Service Definition, right? If it's right I'd like to
put some words there to clarify our current OOTB most use.
2. Is it still possible to restrict services to an application, and if yes how? Else I will remove the whole sentence, it's just
confusing.
Yes, it is possible, but not used much. A WEB-INF directory can have a services.xml file in it, etc, etc. I'd recommend not
starting to remove that unless you plan to really get into it.
Thanks I wil ltry to explain that in a sentence also.
However, if we did that it would solve some issues with the service dispatcher, and we could move to a model of having one
dispatcher per delegator (instead of per webapp, plus per delegator for other things, plus funny special ones scattered around
with fixed names that cause problems with multiple delegators).
I have not planned to touch at the framework, but yes why not?
Thanks
Jacques
-David
