"Rickard �berg" wrote:
>
> Hey
>
> Sebastien Alborini wrote:
> > I am seeing some really weird things with the new conf directory
> > structure (conf/default instead of conf):
> >
> > - If I start jboss normally, ok.
> >
> > - If use the embeddedtomcatservice (uncommenting out in jboss.conf),
> > other services complain, they seem not to see jndi.properties anymore
> > (see log below).
> >
> > - If I then copy jndi.properties to the bin directory for example, all
> > runs fine.
> >
> > I don't see why EmbeddedTomcatService would hide this file from the
> > classpath, any ideas?
>
> Yes, I know what it is. "conf" was added in run.jar's Class-Path
> manifest header. That made it part of the app classloader. Now, since it
> is now more dynamic I added "conf/default" (exchange "default" with your
> conf name of course) to the MLet which is set as context classloader.
>
> Then there are two cases. If code gets loaded through the MLet (and all
> code SHOULD be) then they will be able to do
> getClass().getResource("/jndi.properties"). If not (i.e. they were
> loaded from global classpath), then they must do
> Thread.currentThread().getContextClassLoader().getResource("jndi.properties").
>
> Question: are the Tomcat classes added to the global classpath or as a
> real dynamically loaded MBean? AFAICT it is added to classpath, which is
> why they can't "see" conf/default. The solution would be to load Tomcat
> classes just as we load everything else: by doing an MBean reference in
> "conf" which points to the .jar files and the installed Tomcat's
> "CODEBASE".
Hi,
The problem is not that embeddedtomcatservice cannot see conf/default.
It is that embeddedtomcatservice *prevents* other services to see
conf/default (see the server trace).
However I have tried the suggestion in your other mail (copying tomcat
jars to lib/ext), I have also tried to add a classpathextension with
$TOMCAT_HOME/lib, I still get this weird behaviour.
Other ideas?
Sebastien
