> >
> > My understanding of the lib vs lib/ext split was based on
> > which jars had to be
> > in the system classpath vs the JBoss server MLet based class
> > loader.
>
> Excuse my ignorance, but why does the MLET stuff have its own class loader?
> Can things be added to a running jboss server dynamically, by dropping jars
> into the lib/ext area and configuring them through some interface?
>
The javax.management.loading.MLet class is a subclass of URLClassLoader and it is
installed as the org.jboss.Main.main thread's context class loader and becomes the
parent
ClassLoader of any other URLClassLoader created by JBoss. The
org.jboss.util.ClassPathExtension
can be used to add any directory or jars to the MLet ClassLoader and this is how
the contents of lib/ext is added. I don't see that it is dynamic in that new jars can
be
dropped into a dir and will be loaded by a running server. They will be loaded the next
time the server is restarted.
>
> > All of the jars in the
> > lib directory are in
> > the bin/run.jar manifest Class-Path.
> >
>
> What I propose to do is to change this - remove the Class-Path entry from
> the jar/manifest and put "add all jars from the lib directory into the
> classpath" code into the run.bat/run.sh scripts.
>
> I know its not using the jar as perhaps it could be - but it allows us to
> switch to alternate implementations more easily - especially the xml parser.
>
>
I don't see a problem with this, but only the jars in lib should be on the
system classpath. I had the impression from an earlier mail that you wanted
to put both lib and lib/ext jars in the system classpath.
