Hi Asankha,

> > You removed the classpath-entries for:
> > wrapper.java.classpath.10=webapp/WEB-INF/lib
> > wrapper.java.classpath.11=webapp/WEB-INF/lib/*.jar
> >
> This was done intentionally, as the WAR should not expect anything to
be
> loaded from the classpath, but get everything it needs from the WAR
> classloader.
Yes, I was pretty sure that this was done intentionally. :-)

> > But the service wrapper tries to instantiate the classes referenced
in
> > the log4j.properties.
> >
> > So it at least depends on wso2utils-1.2.jar and all its
dependencies.
> > Adding back the above two lines fixed that issue for me.
> >
> Can you check the latest ESB 1.7 branch (with Synapse 1.2).. I
couldn't
> reproduce this at all.. when starting the embedded Tomcat, we provide
a
> dummy log4j.properties for it to initialize, and that does not refer
to
> any other classes
I don't think this is an issue which has something to do with the
embedded tomcat. I have only seen this issue if I started the server
using the service wrapper. Did you use the service wrapper for your
tests?

Could it also be an issue with the way we are handling the config
locations?
We setup a cluster and put the content of tomcat/conf as well as
webapp/WEB-INF/classes/conf into ONE config directory in a shared
location and create only symlinks pointing to that directory.
This way it is much easier to handle configuration changes. Anyhow I
have to carefully "merge" the config files each time I setup a new
build. Basically I always take the new config files and add our changes
after diffing the changes. So it takes some time. Unfortunately I don't
have the time to install yet another build right now to test this.

Regards,
  Eric

_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev

Reply via email to