Hi Eric
The main reason for the WSO2 ESB distribution to be an exploded WAR is
because for a standalone deployment, we start up an embedded Tomcat
server, and for a deployment on any other JEE server, we simply deploy
the "same" distribution. This allows us to ensure to a great extent that
the WAR deployment will work on other JEE servers, since we infact do
the same for the standalone version by deploying to the embedded Tomcat.
This is the reason for the tomcat/conf and this has no direct
configuration on the ESB rules.
I started reviewing the code and found several places which would cause
problems. Right now what I described would not work at all.....
...........
Maybe a few others as well...
Sources which would need to be changed in Synapse-land:
I could not identify a single place. The code looks quite flexible,
using either the system properties instead of init parameters or loading
everything from the classpath.
Having a system property like "ESB_CONFIG_DIR" for most cases it would
be sufficient to define only this and saving the need to define
server.xml, synapse.xml, and axis2.xml. If those are specified, the
defaults could be overridden.
What do you think?
We are generally going to drop use of system properties as much as
possible in future, but may keep core properties for backwards
compatibility. This is because System properties generally creates
issues at deployment time..
However, I am fully open to evaluating suggestions for improvement, and
if we could capture a proposal as an enhancement request on our JIRA, we
will certainly look at the posibilities
asankha
--
Asankha C. Perera
WSO2 - http://wso2.org
http://esbmagic.blogspot.com
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
