Re: LocalDipatcher vs ServiceDispatcher
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-namelocalDispatcherName/param-name param-valuewebtools/param-value descriptionA unique name used to identify/recognize the local dispatcher for the Service Engine/description /context-param Kind regards, Jacopo
Is it a good time to remove the debian folder?
... the removal will be documented, as usual, in the Attic page: https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Jacopo
Proposal: update service-config.xsd to reflect what is currently supported in OFBiz
I would like to updated the service-config.xsd file in the following way: Index: framework/service/dtd/service-config.xsd === --- framework/service/dtd/service-config.xsd(revision 1365888) +++ framework/service/dtd/service-config.xsd(working copy) @@ -22,7 +22,7 @@ xs:element name=service-config xs:complexType xs:sequence -xs:element minOccurs=1 maxOccurs=unbounded ref=service-engine/ +xs:element minOccurs=1 maxOccurs=1 ref=service-engine/ /xs:sequence /xs:complexType /xs:element @@ -39,7 +39,7 @@ xs:element minOccurs=0 maxOccurs=unbounded ref=global-services/ xs:element minOccurs=0 maxOccurs=unbounded ref=service-groups/ xs:element minOccurs=0 maxOccurs=unbounded ref=service-ecas/ -xs:element minOccurs=0 maxOccurs=unbounded ref=jms-service/ +xs:element minOccurs=0 maxOccurs=1 ref=jms-service/ /xs:sequence xs:attributeGroup ref=attlist.service-engine/ /xs:complexType The idea is that: 1) only one service-engine will be allowed; this is what is currently supported and all the service code is implemented with this assumption (static methods etc... that prevents the ability to define more than one service-config); also, it seems that no one really had the need to define more than one service configuration 2) zero or one jms-service element in the service-engine; again, this is what is currently supported; you still can define several servers (JMS Providers) within the jms-service element; I don't see a reason for defining more than one jms-service within the same service-engine configuration. Regards, Jacopo
Re: I need to retrieve a list from entity.
Hi Anurag, Please post your query on user mailing list. On Wed, Jul 25, 2012 at 7:57 PM, Anurag Walia walia.anu...@hotmail.comwrote: Hello All, I need you help. I need to retrieve a list from entity. Query like: select * from temp where name='ravi' OR name='anu'; I have tried this but not working: entity-and entity-name=temp list=tempList field-map field-name=name value=ravi/ field-map field-name=name value=anu/ /entity-and can you provide me some input from your side? Regards Anurag -- View this message in context: http://ofbiz.135035.n4.nabble.com/I-need-to-retrieve-a-list-from-entity-tp4635223.html Sent from the OFBiz - Dev mailing list archive at Nabble.com. -- Thanks Brajesh Patel Salmonllc.com http://bigfish.salmonllc.com/bfDemo.html skype: brajesh.patel11 Cell:- +91 8750709907
Re: LocalDipatcher vs ServiceDispatcher
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-namelocalDispatcherName/param-name param-valuewebtools/param-value descriptionA unique name used to identify/recognize the local dispatcher for the Service Engine/description /context-param Kind regards, Jacopo
Re: Proposal: update service-config.xsd to reflect what is currently supported in OFBiz
Hmmm... please ignore this for now, I need more time to study the code. Jacopo On Jul 26, 2012, at 2:39 PM, Jacopo Cappellato wrote: I would like to updated the service-config.xsd file in the following way: Index: framework/service/dtd/service-config.xsd === --- framework/service/dtd/service-config.xsd (revision 1365888) +++ framework/service/dtd/service-config.xsd (working copy) @@ -22,7 +22,7 @@ xs:element name=service-config xs:complexType xs:sequence -xs:element minOccurs=1 maxOccurs=unbounded ref=service-engine/ +xs:element minOccurs=1 maxOccurs=1 ref=service-engine/ /xs:sequence /xs:complexType /xs:element @@ -39,7 +39,7 @@ xs:element minOccurs=0 maxOccurs=unbounded ref=global-services/ xs:element minOccurs=0 maxOccurs=unbounded ref=service-groups/ xs:element minOccurs=0 maxOccurs=unbounded ref=service-ecas/ -xs:element minOccurs=0 maxOccurs=unbounded ref=jms-service/ +xs:element minOccurs=0 maxOccurs=1 ref=jms-service/ /xs:sequence xs:attributeGroup ref=attlist.service-engine/ /xs:complexType The idea is that: 1) only one service-engine will be allowed; this is what is currently supported and all the service code is implemented with this assumption (static methods etc... that prevents the ability to define more than one service-config); also, it seems that no one really had the need to define more than one service configuration 2) zero or one jms-service element in the service-engine; again, this is what is currently supported; you still can define several servers (JMS Providers) within the jms-service element; I don't see a reason for defining more than one jms-service within the same service-engine configuration. Regards, Jacopo
Re: LocalDipatcher vs ServiceDispatcher
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 adrian.c...@sandglass-software.com 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-namelocalDispatcherName/param-name param-valuewebtools/param-value descriptionA unique name used to identify/recognize the local dispatcher for the Service Engine/description /context-param Kind regards, Jacopo
What is the meaning of the code in JmsListenerFactory?
Hi all, could you please help me to understand the meaning of the code in JmsListenerFactory that deals with the initialization of listeners? I am confused and before I touch it I would like to be sure I am not missing anything. Specifically: 1) what is the purpose of the while block in the run() method? 2) under what circumstances the loadListener method could return a null object? or a listener that is not connected? Kind regards, Jacopo
Re: What is the meaning of the code in JmsListenerFactory?
On Jul 26, 2012, at 5:15 PM, Jacopo Cappellato wrote: Hi all, could you please help me to understand the meaning of the code in JmsListenerFactory that deals with the initialization of listeners? I am confused and before I touch it I would like to be sure I am not missing anything. Specifically: 1) what is the purpose of the while block in the run() method? 2) under what circumstances the loadListener method could return a null object? or a listener that is not connected? 3) why are we composing the serverKey concatenating server.jndi-server-name + server.jndi-name + server.topic-queue rather then the simpler jms-service.name + server.jndi-server-name? this latter form guarantees that the key is unique while the former doesn't. Kind regards, Jacopo
Re: LocalDipatcher vs ServiceDispatcher
On Jul 26, 2012, at 3:47 PM, Adrian Crum wrote: 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. This was actually an old feature that was available but never used in years, and I have excluded it in my recent refactoring (to make the code less complex, more efficient and thread safe); I guess that was part of an initial plan but then OFBiz evolved in a more component-centric rather than webapp-centric architecture and I doubt we will ever need that feature. Jacopo -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-namelocalDispatcherName/param-name param-valuewebtools/param-value descriptionA unique name used to identify/recognize the local dispatcher for the Service Engine/description /context-param Kind regards, Jacopo
Re: LocalDipatcher vs ServiceDispatcher
As long as no one else has a problem with it, I agree that we should eliminate the unused feature. -Adrian On 7/26/2012 5:25 PM, Jacopo Cappellato wrote: On Jul 26, 2012, at 3:47 PM, Adrian Crum wrote: 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. This was actually an old feature that was available but never used in years, and I have excluded it in my recent refactoring (to make the code less complex, more efficient and thread safe); I guess that was part of an initial plan but then OFBiz evolved in a more component-centric rather than webapp-centric architecture and I doubt we will ever need that feature. Jacopo -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-namelocalDispatcherName/param-name param-valuewebtools/param-value descriptionA unique name used to identify/recognize the local dispatcher for the Service Engine/description /context-param Kind regards, Jacopo
Re: LocalDipatcher vs ServiceDispatcher
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 adrian.c...@sandglass-software.com 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-namelocalDispatcherName/param-name param-valuewebtools/param-value descriptionA unique name used to identify/recognize the local dispatcher for the Service Engine/description /context-param Kind regards, Jacopo
Re: LocalDipatcher vs ServiceDispatcher
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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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-namelocalDispatcherName/param-name param-valuewebtools/param-value descriptionA unique name used to identify/recognize the local dispatcher for the Service Engine/description /context-param Kind regards, Jacopo
Re: LocalDipatcher vs ServiceDispatcher
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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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-namelocalDispatcherName/param-name param-valuewebtools/param-value descriptionA unique name used to identify/recognize the local dispatcher for the Service Engine/description /context-param Kind regards, Jacopo
reduction of entities in HR
we intend to reduce the number of entities in HR: EmplLeave EmplLeaveReasonType EmplLeaveType - workeffort+related-entities so it also appears on the calendar JobInterview JobInterviewType - communication event and related entities any comments or suggestions? Regards, Hans
Re: LocalDipatcher vs ServiceDispatcher
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 scott.g...@hotwaxmedia.com 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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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,
Re: svn commit: r1365895 - /ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/AbstractEngine.java
From: jaco...@apache.org
Author: jacopoc
Date: Thu Jul 26 07:03:46 2012
New Revision: 1365895
URL: http://svn.apache.org/viewvc?rev=1365895view=rev
Log:
Made locationMap thread safe using static initialization and immutability.
Modified:
ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/AbstractEngine.java
Modified:
ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/AbstractEngine.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/AbstractEngine.java?rev=1365895r1=1365894r2=1365895view=diff
==
---
ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/AbstractEngine.java
(original)
+++
ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/AbstractEngine.java
Thu Jul 26 07:03:46 2012
@@ -18,12 +18,12 @@
***/
package org.ofbiz.service.engine;
+import java.util.Collections;
+import java.util.HashMap;
import java.util.Map;
import java.util.List;
import java.util.Iterator;
-import javolution.util.FastMap;
-
import org.ofbiz.service.ServiceDispatcher;
import org.ofbiz.service.ModelService;
import org.ofbiz.service.GenericServiceException;
@@ -41,40 +41,38 @@ import org.w3c.dom.Element;
public abstract class AbstractEngine implements GenericEngine {
public static final String module = AbstractEngine.class.getName();
-protected static MapString, String locationMap = null;
+protected static final MapString, String locationMap =
createLocationMap();
protected ServiceDispatcher dispatcher = null;
protected AbstractEngine(ServiceDispatcher dispatcher) {
this.dispatcher = dispatcher;
-initLocations();
}
// creates the location alias map
-protected synchronized void initLocations() {
-if (locationMap == null) {
-locationMap = FastMap.newInstance();
-
-Element root = null;
-try {
-root = ServiceConfigUtil.getXmlRootElement();
-} catch (GenericConfigException e) {
-Debug.logError(e, module);
-}
+protected static MapString, String createLocationMap() {
+MapString, String tmpMap = new HashMapString, String();
+
+Element root = null;
+try {
+root = ServiceConfigUtil.getXmlRootElement();
+} catch (GenericConfigException e) {
+Debug.logError(e, module);
+}
-if (root != null) {
-List? extends Element locationElements =
UtilXml.childElementList(root, service-location);
-if (locationElements != null) {
-for (Element e: locationElements) {
-locationMap.put(e.getAttribute(name),
e.getAttribute(location));
-}
+if (root != null) {
+List? extends Element locationElements = UtilXml.childElementList(root,
service-location);
+if (locationElements != null) {
+for (Element e: locationElements) {
+tmpMap.put(e.getAttribute(name),
e.getAttribute(location));
}
}
-Debug.logInfo(Loaded Service Locations : + locationMap, module);
}
+Debug.logInfo(Loaded Service Locations: + tmpMap, module);
+return Collections.unmodifiableMap(tmpMap);
}
-// uses the lookup map to determin if the location has been aliased in
serviceconfig.xml
+// uses the lookup map to determine if the location has been aliased in
serviceconfig.xml
protected String getLocation(ModelService model) {
if (locationMap.containsKey(model.location)) {
return locationMap.get(model.location);
If serviceconfig.xml means serviceengine.xml here and location means
service-location, could we change the comment here? Else just
discard this comment (not enough time to digg in)
Jacques
Re: reduction of entities in HR
I don't understand the question. Are you proposing removing those entities? -Adrian On 7/27/2012 4:42 AM, Hans Bakker wrote: we intend to reduce the number of entities in HR: EmplLeave EmplLeaveReasonType EmplLeaveType - workeffort+related-entities so it also appears on the calendar JobInterview JobInterviewType - communication event and related entities any comments or suggestions? Regards, Hans
