On Wed, 11 Apr 2001, Greg Wilkins wrote:
> [EMAIL PROTECTED] wrote:
>
> > That's reasonably easy to do ( in 3.3 workspace the Log is just an
> > independent class ,with no dependency on tomcat internals - except that
> > it's in tomcat.util.log package ).
>
> The only hestiation I have with that, is packaging. It is likely that the
> tomcat.util.log class will be normally packaged in a tomcat.jar. If
> you start copying classes from jar to jar, then you can end up with duplicates
> and if people start sealing jars, everything breaks down.
I know.
Most utils should move to a "jakarta-commons-sandbox" package,
i.e. outside of tomcat tree ( but that'll be after tc3.3 is released ).
> > Not easy - unless URLClassLoader is used ( or per thread class loader ? ).
> > This is a big issue for JspServlet, also the work dir and reloading,
> > but are not big issues if "cooperating" jasper+containers.
>
> Except that URLClassLoader is probably more trouble than it is worth.
> It makes reloading difficult (I guess JSP checks the source anyway?) and
> the fact that most JVMs have a broken JarURLConnection that does not
> see modified jars makes this even worse!
Take a look at org.apache.tomcat.util.depend.* ( again, no dependency on
tomcat, except the name of the package ).
If reloading is enabled we just wrap URLClassLoader in a DependClassLoader
that delegates everything and records all the loaded .class files into
a DependManager. Then .class dependecies are treated the same as any other
dependecies ( web.xml, .jar files, etc ).
> As Mel said that he does not want to dive into the guts of jasper
> just yet, changing the jsp loaders is probably a bit much to ask for
> now.
Actually, loaders are the most important piece to fix, as it creates the
most problems and is the hardest to integrate. Manglers are the next.
( of course, the first step is to separate all things in packages and
find a good mechanism to plug them and check everything still works )
Costin
