Re: Classloader

[Craig R. McClanahan]

Rob Shaw wrote:

> Given that I have 2 "contexts" defined (which I'm assuming
> each has thier own classloader).
>

That is correct.

>
> After making a request to the same servlet within each
> context, I'm witnessing the creation of seperate instances
> of the servlet per context, which I would expect, but
> I'm also witnessing the sharing of classes
> that have static members.
>
> Is this intentional, or is this a bug?
>

It depends on where the classes are loaded from.  The following details
are Tomcat-specific, but something similar is probably true for most
containers.

The web-app class loader that Tomcat creates for each web app will
delegate to the system class loader (i.e. the one that processes the
CLASSPATH) if a class is not found in "/WEB-INF/classes" or
"/WEB-INF/lib/*.jar".  In such a case, there will be only one copy of
such classes (because the system class loader is delegated to from each
web app), so statics are shared across web apps.

On the other hand, if you made a copy of the class underneath WEB-INF
for each web app, the statics would *not* be shared.

>
> According to Servlet 2.2 spec:
>
> > 4.6 Reloading Considerations
> >...
> > Therefore, when a Container Provider implements a class
> > reloading scheme for ease of development, they must ensure
> > that all servlets, and classes that they may use, are loaded
> > in the scope of a single class loader guaranteeing that the
> > application will behave as expected by the Developer.
> ...
>

In fact, there is an explicit documented restriction in Tomcat that it
only applies to classes found under WEB-INF -- class reloading for
things found on the system class path is not supported.

>
> Thanks,
> Rob.

Craig

RE: classloader

[Shapira, Yoav]

Hi,
I think it's a great goal and a great idea -- I look forward to seeing
progress on it ;)

Yoav Shapira
Millennium Research Informatics


>-Original Message-
>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache
>Sent: Friday, September 24, 2004 10:41 AM
>To: [EMAIL PROTECTED]
>Subject: classloader
>
>I had a small vacation, and managed to make some of the changes in the
>classloader/module area. I'm not completely done - but I want to
>eventually start checking in some of the code ( if nobody objects ).
>
>To avoid breaking anything, I started a new package (
>o.a.tomcat.util.loader ), and started with the existing classes, with
>small refactorings.
>
>- WebappClassLoader
>- Bootstrap
>- CatalinaProperties
>plus some extra classes to support jboss ( or m-let) style loading.
>
>I tried to remove all dependencies outside JDK1.4 - the package is
>very small, and I think it's ok to not use commons-logging or jmx in
>this area. Apache.naming and jmx functionality is added via hooks -
>after the server loader ( now "repository" ) is started.
>
>I think this will improve a bit the code structure - currently we have
a
>bit of a mess in how we select some classes in the bin/ jars.
>
>I'm not planning any change in the existing code - except adding few
>classes and code to allow the new loader to be used ( as an option )
>instead of the old one.
>
>My goal ( which is not yet completely done ) is to support "modules"
for
>connectors/interceptors/etc - with reloading and all the cool stuff,
and
>make this integrable with existing systems ( jboss, other jmx/mlet
based
>  applications, eclipse ). Instead of having the entire tomcat as one
>chunk of code ( plus all the depenencies ) integrated in one plugin, it
>should be possible to add a smaller subset and then have
>connectors/auth/etc as separate plugins.
>
>Please let me know if this is ok with you - I'll have another long trip
>in mid Oct. and I hope to get this done, but if there are problems with
>what I'm trying to do ( or conflicts with other plans ), I would
>appreciate feedback before I waste the time :-)
>
>Costin
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: classloader

[Remy Maucherat]

Costin Manolache wrote:
I had a small vacation, and managed to make some of the changes in the 
classloader/module area. I'm not completely done - but I want to 
eventually start checking in some of the code ( if nobody objects ).

To avoid breaking anything, I started a new package ( 
o.a.tomcat.util.loader ), and started with the existing classes, with 
small refactorings.

- WebappClassLoader
- Bootstrap
- CatalinaProperties
plus some extra classes to support jboss ( or m-let) style loading.
I tried to remove all dependencies outside JDK1.4 - the package is
very small, and I think it's ok to not use commons-logging or jmx in 
this area. Apache.naming and jmx functionality is added via hooks - 
after the server loader ( now "repository" ) is started.

I think this will improve a bit the code structure - currently we have 
a bit of a mess in how we select some classes in the bin/ jars.

I'm not planning any change in the existing code - except adding few 
classes and code to allow the new loader to be used ( as an option ) 
instead of the old one.

My goal ( which is not yet completely done ) is to support "modules" for
connectors/interceptors/etc - with reloading and all the cool stuff, 
and make this integrable with existing systems ( jboss, other jmx/mlet 
based  applications, eclipse ). Instead of having the entire tomcat as 
one chunk of code ( plus all the depenencies ) integrated in one 
plugin, it should be possible to add a smaller subset and then have 
connectors/auth/etc as separate plugins.

Please let me know if this is ok with you - I'll have another long 
trip in mid Oct. and I hope to get this done, but if there are 
problems with what I'm trying to do ( or conflicts with other plans ), 
I would appreciate feedback before I waste the time :-)
Ok. How "broken" is it ? ;) If it's not that broken, I think you should 
overwrite the existing code. Or you can keep it elsewhere (in utils) and 
work on it for the next branch.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: classloader status?

[Craig R. McClanahan]

OK, I've been playing with the scenario below ... and as far as I can tell,
session reloading works correctly.  To aid in experimentation, I've added some
instrumentation so that you can log debugging detail messages related to it.  The
attached log file is what I get when executing your steps below against Scarab
with the following server.xml entry:


  
  


As you can see from the log, the session attribute "turbine.user" is saved and
then reloaded, but nothing else.  What else would you expect to see here?

Craig


Jon Stevens wrote:

> Hi Craig, any status?
>
> Maybe you can point me at the right place to look?
>
> thanks,
>
> -jon
>
> --
> From: Jon Stevens <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Fri, 05 Jan 2001 21:37:41 -0800
> To: <[EMAIL PROTECTED]>
> Subject: Re: cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.html
>
> on 1/5/2001 8:52 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > That is not a provably correct assertion, given that it works on every test
> > case
> > I have concocted so far.
> >
> > Even if there is something in Turbine that makes it not work, that can be
> > dealt
> > with subsequent to b1.  It's not like this is the last release or anything
> > :-).
>
> Ok, I have found like 4 bugs in as many days and you still don't believe me
> on these things. :-)
>
> here we go again:
>
> #1. check out scarab
> #2. build it; start tomcat
> #3. goto: http://localhost:8080/scarab/servlet/scarab/template/Register.vm
> #4. hit "Register"
> #5. edit scarab/target/webapps/scarab/templates/Register.vm
> Add anywhere in the template:
> $data.getUser().setTemp("foo", "bar")
>
> #6. hit "Register"
> #7. touch
> scarab/target/webapps/scarab/WEB-INF/classes/org/tigris/scarab/actions/*.cla
> ss
> #7. change the above line to:
> $data.getUser().getTemp("foo")
> #8. hit "Register"
>
> Notice that you see the data you entered in #7. That is because Velocity
> wasn't able to introspect and find a result for "foo" because it doesn't
> exist in the session any longer.
>
> $data.getUser() returns an object that has been placed into the HttpSession
>
> This isn't Turbine that is broken as this same stuff worked fine in JServ
> and Tomcat 3.x. It is definitely Catalina.
>
> love,
>
> -jon
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


2001-01-10 18:50:49 StandardLoader[/scarab]: Reloading checks are enabled for this 
Context
2001-01-10 18:50:49 Manager[/scarab]: Starting
2001-01-10 18:50:49 Manager[/scarab]: Force random number initialization starting
2001-01-10 18:50:49 Manager[/scarab]: Seeding random number generator class 
java.security.SecureRandom
2001-01-10 18:50:49 Manager[/scarab]: Seeding of random number generator has been 
completed
2001-01-10 18:50:49 Manager[/scarab]: Getting message digest component for algorithm 
MD5
2001-01-10 18:50:49 Manager[/scarab]: Completed getting message digest component
2001-01-10 18:50:49 Manager[/scarab]: Force random number initialization completed
2001-01-10 18:50:50 ContextConfig[/scarab]: Added certificates -> request attribute 
Valve
2001-01-10 18:50:50 ContextConfig[/scarab]: Configured an authenticator for method 
BASIC
2001-01-10 18:50:51 Manager[/scarab]: Loading persisted sessions
2001-01-10 18:50:51 Manager[/scarab]: Loading persisted sessions from SESSIONS.ser
2001-01-10 18:50:51 Manager[/scarab]: No persisted data file found
2001-01-10 18:50:51 StandardWrapper[/scarab:default]: Loading container servlet default
2001-01-10 18:50:51 default: init
2001-01-10 18:50:51 StandardWrapper[/scarab:invoker]: Loading container servlet invoker
2001-01-10 18:50:51 invoker: init
2001-01-10 18:50:51 jsp: init
2001-01-10 18:51:35 scarab: init
2001-01-10 18:51:37 scarab: Turbine: init() Ready to Rumble!
2001-01-10 18:51:37 scarab: Turbine: doGet() Start Initializing Services!
2001-01-10 18:51:37 scarab: Turbine: doGet() Finish Initializing Services!
2001-01-10 18:56:08 StandardContext[/scarab]: Reloading this Context has started
2001-01-10 18:56:08 scarab: Turbine: Done shutting down!
2001-01-10 18:56:08 Manager[/scarab]: Unloading persisted sessions
2001-01-10 18:56:08 Manager[/scarab]: Saving persisted sessions to SESSIONS.ser
2001-01-10 18:56:08 Manager[/scarab]: Unloading 1 sessions
2001-01-10 18:56:08 Manager[/scarab]: writeObject() storing session 
F51410925838E0F5666257A405E4A200
2001-01-10 18:56:08 Manager[/scarab]:   storing attribute 'turbine.user' with value 
'org.apache.turbine.om.security.TurbineUser@8ebd435b'
2001-01-10 18:56:08 Manager[/scarab]: Expiring 1 persisted sessions
2001-01-10 18:56:08 Manager[/scarab]: Unloading complete
2001-01-10 18:56:08 Manager[/scarab]: Stopping
2001-01-10 18:5

Re: Classloader weirdities

[Remy Maucherat]

> Hi!
>
> I'm working on the JBoss plugin for Catalina, and everything is going
> well except for classloading. For some very obscure reason I can't get
> Catalina to pick up new classes. What the plugin does is to delegate to
> the EmbeddedManager MBean (which internally delegates to Embedded) on
> deploy. If the app has already been deployed it is first undeployed.
> But, the new classes just aren't picked up. For some strange reason it
> is using the last set of classes. What is going on!?! I'm using
> Tomcat4b7, since the latest Tomcat4b8 src'es doesn't seem to be working
> it all (not for me anyway).

What is not working with the latest sources ?

The message is quite vague, could I get more details ?

> Any ideas? Could this possible be related to this thread that I found in
> the archives:
> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg4.html

When reloading a context, the old classloader is dumped, and a new one is
created. Catalina doesn't internally keep any references on objects
instantiated by the old CL, but it's up to you to do the same.

At the time this message was posted we had some problems with references
which survived a reload (through the servlet context, mainly). Your problems
should be unrelated.

Remy

Re: Classloader weirdities

[Rickard Öberg]

Remy Maucherat wrote:
> What is not working with the latest sources ?

It is quite bizarre really. I am using the EmbeddedManager MBean, and
when I call "start" nothing happens. No listener is started. As a
side-effect I can't test much of anything. Going back to T4b7 makes it
work again.

> The message is quite vague, could I get more details ?

I will commit what I have now to JBoss CVS so you can try it out for
yourself.

> > Any ideas? Could this possible be related to this thread that I found in
> > the archives:
> > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg4.html
> 
> When reloading a context, the old classloader is dumped, and a new one is
> created. Catalina doesn't internally keep any references on objects
> instantiated by the old CL, but it's up to you to do the same.

Well, I assumed that that was the case, but that is not what is
happening. The old stuff is retained.

So, I will commit what I have now into the "contrib" JBoss CVS module
(/catalina subdirectory). Get it from there. Any help would be
appreciated.

regards,
  Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]

Re: Classloader weirdities

[Remy Maucherat]

> Remy Maucherat wrote:
> > What is not working with the latest sources ?
>
> It is quite bizarre really. I am using the EmbeddedManager MBean, and
> when I call "start" nothing happens. No listener is started. As a
> side-effect I can't test much of anything. Going back to T4b7 makes it
> work again.

If it really does nothing now and it was ok in b7, maybe it's also a
regression caused by a new feature Craig introduced (the new CATALINA_BASE
property). I had trouble with that and my service stuff.

I'll look into it.

> > The message is quite vague, could I get more details ?
>
> I will commit what I have now to JBoss CVS so you can try it out for
> yourself.

Ok.

> > > Any ideas? Could this possible be related to this thread that I found
in
> > > the archives:
> > >
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg4.html
> >
> > When reloading a context, the old classloader is dumped, and a new one
is
> > created. Catalina doesn't internally keep any references on objects
> > instantiated by the old CL, but it's up to you to do the same.
>
> Well, I assumed that that was the case, but that is not what is
> happening. The old stuff is retained.

Well, we do nothing more than unreferencing the old CL, clearing /
recreating the servlet context, and destroy / unload / load / init all
servlets and filters. So it's fully possible to have objects instatiated
from the old CL if you keep the references.

> So, I will commit what I have now into the "contrib" JBoss CVS module
> (/catalina subdirectory). Get it from there. Any help would be
> appreciated.

Ok.

Remy

Re: Classloader weirdities

[Rickard Öberg]

Remy Maucherat wrote:
> If it really does nothing now and it was ok in b7, maybe it's also a
> regression caused by a new feature Craig introduced (the new CATALINA_BASE
> property). I had trouble with that and my service stuff.

Sounds like a possible culprit yes.

> > I will commit what I have now to JBoss CVS so you can try it out for
> > yourself.
> 
> Ok.

I'll let you know when this is done.

> > Well, I assumed that that was the case, but that is not what is
> > happening. The old stuff is retained.
> 
> Well, we do nothing more than unreferencing the old CL, clearing /
> recreating the servlet context, and destroy / unload / load / init all
> servlets and filters. So it's fully possible to have objects instatiated
> from the old CL if you keep the references.

Well, I have no external stuff that keep the references. Or rather, I do
(the JMX MBeanServer), but these are not used and upon next deployment
they should not be used anyway since they'll be replaced with new ones.

/Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]

Re: ClassLoader priorities?

[Sriram N]

--- Deacon Marcus <[EMAIL PROTECTED]> wrote:
> Hi,
> Is it possible to override single classes in Tomcat by placing .class files
> in server/classes? If a .class exists both in /lib/.jar and
> /classes//.class which one is used?
> 

For Tomcat 4, the following priority list is followed:
/WEB-INF/classes of your web application 
/WEB-INF/lib/*.jar of your web application 
Bootstrap classes of your JVM 
System class loader classses (described above) 
$CATALINA_HOME/common/classes 
$CATALINA_HOME/common/lib/*.jar 
$CATALINA_HOME/classes 
$CATALINA_HOME/lib/*.jar 

Please refer to
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html, from
where I have pasted the list above.

> Greetings, deacon Marcus
> 
Sriram


__
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: ClassLoader problems

[Costin Manolache]

Once again - debugging it is close to impossible ( just like most 
classloader problems), but luckily I guessed how to fix it - just 
remove the "endorsed" property and it works again...

What "endorsed dirs" has to do with ActionHook - I don't know.

Costin

Costin Manolache wrote:

> Ok, that's another really strange JDK1.4 problem. I hate class loaders.
> 
> It works perfectly fine with JDK1.3 - but fails with JDK1.4.1.
> 
> Needless to say - tomcat-coyote is in lib, and if I enable -verbose:class
> it actually displays a line showing ActionHook is loaded - only to throw
> the exception few lines down.
> 
> Any idea ? I get this with 4.1 head and also with 5.0 ( but in 5.0 I may
> have a strange env - that's why I tested with a clean 4.1 head )
> 
> Java is 1.4.1_01-b01 on linux.
>  
> Costin
> 
> 
> The exception is:
> Using CATALINA_BASE:   /ws/41/dist
> Using CATALINA_HOME:   /ws/41/dist
> Using CATALINA_TMPDIR: /ws/41/dist/temp
> Using JAVA_HOME:   /usr/java/jdk14
> /usr/java/jdk14/bin/java
> -Djava.endorsed.dirs=/ws/41/dist/bin:/ws/41/dist/common/endorsed
> -classpath /usr/java/jdk14/lib/tools.jar:/ws/41/dist/bin/bootstrap.jar
> -Dcatalina.base=/ws/41/dist -Dcatalina.home=/ws/41/dist
> -Djava.io.tmpdir=/ws/41/dist/temp org.apache.catalina.startup.Bootstrap
> start
> Exception during startup processing
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 
> at
> 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 
> at
> 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
> Caused by: java.lang.NoClassDefFoundError: org/apache/coyote/ActionHook
> at java.lang.ClassLoader.findBootstrapClass(Native Method)
> at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:723)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
> 
> at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:941)
> 
> at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)
> 
> at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:941)
> 
> at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
> at java.lang.ClassLoader.defineClass0(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
> at
> 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:250) at
> java.net.URLClassLoader.access$100(URLClassLoader.java:54) at
> java.net.URLClassLoader$1.run(URLClassLoader.java:193) at
> java.security.AccessController.doPrivileged(Native Method) at
> java.net.URLClassLoader.findClass(URLClassLoader.java:186)
> 
> at
> 
org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:621)
> 
> at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:958)
> 
> at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:140)
> 
> at
> 
org.apache.coyote.tomcat4.CoyoteConnector.initialize(CoyoteConnector.java:1016)
> 
> at
> 
org.apache.catalina.core.StandardService.initialize(StandardService.java:579)
> 
> at
> 
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2246)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:511)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
> ... 5 more



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: classloader issues (ClassCastException on org.xml.sax.Parser)

[Ed Korthof]

On Wed, Jan 23, 2002 at 02:28:52AM -0800, Remy Maucherat wrote:
> > On Tue, Jan 22, 2002 at 06:14:18PM -0800, Remy Maucherat wrote:
> >
> > Do you mean you're spawning another process to do compilation?  I
> > thought that javac's core class had been fixed so that it'd be possible
> > to run it in a thread in an existing server ... for a number of reasons,
> > including performance and the awkwardness of spawning processes on
> > win32.  (I know there was talk about that years ago, when I last worked
> > on a page compilation system, but I don't know what happened with it.)
> 
> Jasper uses the javac API which doesn't spawn a process, but it still
> behaves the same way it does if you actually spawn a process.

You said the reason that we can't do what I suggested is that it would
"make JSPs behave differently from servlets" -- so I went to look at
Jasper to see how similar the behavior is right now, in terms of
classloading.  It looks like there's no guarantee at all about
consistency:

Jasper already assumes that the classpath for JSP compilation may be
different from that used in servlets.  There are a number of
inconsistencies, including at least the following:

1) jars accessed by URLs using protocols other than the file protocol
will be silently left out (JspEngineContext.java:155)

2) the order of classname resolution does not match the special logic in
WebappClassLoader, since the webapp classloader's jars aren't ever
preptended to the system classpath, they're always appended
(Compiler.java:233).  I haven't yet followed the logic all the way back
in terms of how the data gets into the context for use by JspServlet --
it is possible that the order is reversed somewhere else ... but if so,
the logic isn't in WebappClassLoader, which is the only class which will
know if delegation is true or false.  So I suspect it's not being done.

Note that #2 may mean that excluding the jars from the classpath to
Jasper might not be such a big deal, as the only reason for the
filtering of those jars in WebappClassloader is the fact that they could
override classes defined in their parent classloaders.

I can imagine that there may be other good reasons not to allow the
changes which I suggested, but AFAICT there's very little consistency
left to be preserved, when comparing classpath handling for JSP pages
and servlets.

> Also, you can't change the delegation and still be spec compliant. We could
> avoid implementing the requirement of preventing loading core libraries, if
> it turns out it's not implementable.

I don't mind configuring tomcat so that my install isn't spec compliant
(that's already possible, with the setDelgate toggle).  I tend to feel
as Daniel said -- the spec is broken.  But I can understand wanting to
build tomcat in such a way that it satisfies the spec as well as is
possible.

It is possible to be compliant with the specification, but I don't think
the current implementation is.  I can override classes in each of the
"protected" packages, so long as I take care to leave out the trigger
class, for which tomcat looks, in my .jar files -- so if it's tomcat's
job to avoid loading core libraries in the webapp classloaders, I don't
think it's doing it reliably.

Anyway -- one possibility would be to do filtering of .jars before
handing them to the JSP engine (much as it's being done now, thought it
might make more sense to read through the contents of the jars and look
for any classes which are in packages they're not allowed to be in), but
to do the kind of filtering which I described in my first message, in
loadClass.  And I'd suggest adding one or more toggles, to configure how
filtering is done.  (I'm not sure if one or two is appropriate because
I'm not sure if #2 -- up above -- should be fixed.)

thanks --

Ed

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Classloader when Tomcat is embedded + save

[Remy Maucherat]

Florent BENOIT wrote:
   Hello,

When we embed Tomcat in an application server, we have the following 
problem that we must "patch".
It would be good if in the Tomcat 5.x branch, this will be fixed.

The problem :

It's about the setClassPath() method of the class WebappLoader of the 
package org.apache.catalina.loader.

This is the following code :

   int layers = 0;
   int n = 0;
   while ((layers < 3) && (loader != null)) {
So, the classpath is set to 3 level.
When JOnAS is embedded, several URL Classloader can be parent 
classloader and not set to 3 levels.
So, for example if we have an application server classloader, ear 
classloader, ejb classloader, web classloader, etc.
The final classpath has some missing jars which can be found on a layer 
 >= 3.
So, please, if you can :
- remove this test on this value (only testing (loader != null) and we 
stop when it's not anymore an URLClassLoader
- or that we can configure this value by a system property or anything 
else.
It will make a better integration of the Tomcat product, without having 
to set the right classpath with the same method but without the number 3.
Well, I think in the complex cases, you should probably use 
StandardContext.setCompilerClasspath. I'm willing to remove that check, 
though.
Of course, it's good to remember that this code exists only because of 
the lack of a good in memory compiler. This could change.

Another request is if the save action to the server.xml file could not 
saved some configurable parameters.
For example, in a j2ee application server, some contexts are created at 
the runtime, but we don't want that these contexts will be stored on the 
server.xml as their path are sometimes dynamic, temporary, etc.
So if we could add/remove/configure the actions of the save() method, it 
would be great for a better integration.
That feature is thought out for standalone mode. It's hard to predict 
what are the components which should be saved, and which should not.
Now if you want to refactor the save-to-xml code to a separate class 
(and allow configuring that class, of course), then I'm waiting for your 
patch :)

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Classloader when Tomcat is embedded + save

[matthias.ernst]

> Of course, it's good to remember that this code exists only because of
> the lack of a good in memory compiler. This could change.

Class org.eclipse.jdt.internal.compiler.Compiler in combination with
org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler
provide a load-from-context-classloader compiler, independent of the
filesystem. The latter can be easily turned into an ant CompilerAdapter.

I've once briefly browsed the javac source, that one couldn't even easily
be adapted.

Matthias
-- 
Matthias Ernst
Software Engineer

CoreMedia - Smart Content Technology


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Classloader when Tomcat is embedded + save

[Florent BENOIT]

   Hi again,

Remy Maucherat wrote:
> Well, I think in the complex cases, you should probably use 
StandardContext.setCompilerClasspath. I'm willing to remove that check, 
though.
> Of course, it's good to remember that this code exists only because 
of the lack of a good in memory compiler. This could change.

Yes, I could use setCompilerClasspath() method, but, in order to 
retrieve the classpath (to give to setCompilerClasspath()), I have to 
use a similar method than setClassPath() of the class WebappLoader. So 
the code is duplicated only for changing the number of layer. So it 
would be great if the 3 is going to be removed.

If this value (3) is not removed, it could become a parameter like for 
setCompilerClasspath() on StandardContext.
StandardContext.setCompilerClassPathLayers(int layers). If it's null, it 
uses 3, else it uses the number which is set.
So, this value can be adjusted by the application server in different cases.
In ear case, this number will be greater than in a standalone war file 
as the number of classloader is increased.

But, it will result in the same case that if this 3 parameter is 
definitively removed because it will stop at the last URLClassloader found.

For the saving feature :
> That feature is thought out for standalone mode. It's hard to predict 
what are the components which should be saved, and which should not.
> Now if you want to refactor the save-to-xml code to a separate class 
(and allow configuring that class, of course), then I'm waiting for your 
patch :)

There is no problem for doing a contribution. But maybe I have to use 
the skippable mechanism already defined in StandardServer.
So, by adding a public method addSkippable(String classname) (and maybe 
a removeSkippable(String)) and by adding the isSkippable() mechanism in 
the storeContext like for storeListener()
I think that addSkippable(String classname) is better than 
setSkippables(string skippables) as we don't have to know the existing 
skippables.
These methods will not be called in standalone mode but can be useful in 
the embedded mode.
If you agree with this, I can propose a patch for the current catalina 
5.x cvs.

Regards,

Florent

Remy Maucherat wrote:

Florent BENOIT wrote:

   Hello,

When we embed Tomcat in an application server, we have the following 
problem that we must "patch".
It would be good if in the Tomcat 5.x branch, this will be fixed.

The problem :

It's about the setClassPath() method of the class WebappLoader of the 
package org.apache.catalina.loader.

This is the following code :

   int layers = 0;
   int n = 0;
   while ((layers < 3) && (loader != null)) {
So, the classpath is set to 3 level.
When JOnAS is embedded, several URL Classloader can be parent 
classloader and not set to 3 levels.
So, for example if we have an application server classloader, ear 
classloader, ejb classloader, web classloader, etc.
The final classpath has some missing jars which can be found on a 
layer  >= 3.
So, please, if you can :
- remove this test on this value (only testing (loader != null) and 
we stop when it's not anymore an URLClassLoader
- or that we can configure this value by a system property or 
anything else.
It will make a better integration of the Tomcat product, without 
having to set the right classpath with the same method but without 
the number 3.


Well, I think in the complex cases, you should probably use 
StandardContext.setCompilerClasspath. I'm willing to remove that 
check, though.
Of course, it's good to remember that this code exists only because of 
the lack of a good in memory compiler. This could change.

Another request is if the save action to the server.xml file could 
not saved some configurable parameters.
For example, in a j2ee application server, some contexts are created 
at the runtime, but we don't want that these contexts will be stored 
on the server.xml as their path are sometimes dynamic, temporary, etc.
So if we could add/remove/configure the actions of the save() method, 
it would be great for a better integration.


That feature is thought out for standalone mode. It's hard to predict 
what are the components which should be saved, and which should not.
Now if you want to refactor the save-to-xml code to a separate class 
(and allow configuring that class, of course), then I'm waiting for 
your patch :)

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Classloader when Tomcat is embedded + save

[Remy Maucherat]

Florent BENOIT wrote:

For the saving feature :
 > That feature is thought out for standalone mode. It's hard to predict 
what are the components which should be saved, and which should not.
 > Now if you want to refactor the save-to-xml code to a separate class 
(and allow configuring that class, of course), then I'm waiting for your 
patch :)

There is no problem for doing a contribution. But maybe I have to use 
the skippable mechanism already defined in StandardServer.
So, by adding a public method addSkippable(String classname) (and maybe 
a removeSkippable(String)) and by adding the isSkippable() mechanism in 
the storeContext like for storeListener()
I think that addSkippable(String classname) is better than 
setSkippables(string skippables) as we don't have to know the existing 
skippables.
These methods will not be called in standalone mode but can be useful in 
the embedded mode.
If you agree with this, I can propose a patch for the current catalina 
5.x cvs.
The implementation of the feature had little to do with the 
StandardServer class itself. It should really be a separate helper class 
(no more hacks, sorry ;-) ).

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Classloader when Tomcat is embedded + save

[Florent BENOIT]

Remy Maucherat wrote:
> The implementation of the feature had little to do with the 
StandardServer class itself.
> It should really be a separate helper class (no more hacks, sorry ;-) ).

Well, I can do the helper class, but I have some questions.
The helper class will be for the method storeConfig() or for 
storeServer() ? Because the name of the config file will remain the same 
name in the same place.
But it's true that the helper class must allow the best flexibility so 
it would be for storeConfig.

So, the Helper class can be on the form StoreConfigHelper with a 
constructor which take a Server Object.
so the storeConfig() method of StandardServer will call : 
storeConfigHelper.store(server)
All the stuff concerning exceptions, persistables, skippables could be 
in this helper class. Or it can be arguments for the constructor of the 
helper class.
StandardServer will also have a method for setting the helper class.
So there is a need of an interface. My next question is : Can we 
authorize the default StoreConfigHelper class to be extended and by 
allowing the fact that storeListener, storeContext, etc will be 
protected and not private.
Or if we have only choice by implementing a class of the 
StoreConfigHelper interface.

My last question is about the name and the package of these classes.
The helper class must go on the util package or stay in the core package.
The interface must go on root package where there are a lot of interfaces ?
Do you have advice for the name of these classes or architecture for 
this helper class.

Regards,

Florent

Florent BENOIT wrote:

For the saving feature :
 > That feature is thought out for standalone mode. It's hard to 
predict what are the components which should be saved, and which 
should not.
 > Now if you want to refactor the save-to-xml code to a separate 
class (and allow configuring that class, of course), then I'm waiting 
for your patch :)

There is no problem for doing a contribution. But maybe I have to use 
the skippable mechanism already defined in StandardServer.
So, by adding a public method addSkippable(String classname) (and 
maybe a removeSkippable(String)) and by adding the isSkippable() 
mechanism in the storeContext like for storeListener()
I think that addSkippable(String classname) is better than 
setSkippables(string skippables) as we don't have to know the 
existing skippables.
These methods will not be called in standalone mode but can be useful 
in the embedded mode.
If you agree with this, I can propose a patch for the current 
catalina 5.x cvs.


The implementation of the feature had little to do with the 
StandardServer class itself. It should really be a separate helper 
class (no more hacks, sorry ;-) ).

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Classloader issue with Embedded tomcat and WAR deployment

[Richard Unger]

I figured it out.  For the curious, I was specifying a loader for my root context, but 
that wasn't being propogated to any WAR files, only to servlets explicitly added to 
the root context at startup time.  I had to set the parent classloader on the host 
which was loading the WAR files.

Rich

> -Original Message-
> From: Richard Unger 
> Sent: Monday, April 01, 2002 4:36 PM
> To: '[EMAIL PROTECTED]'
> Subject: Classloader issue with Embedded tomcat and WAR deployment
> 
> 
> I'm making a tomcat 4.0.3 module for netbeans, and I'm 
> running into an odd problem with the 
> org.apache.catalina.loader.WebappClassLoader.
> 
> I'm utilizing the Embedded class to build my server, and I'm 
> using the HostConfig mechanism for rolling in WAR files.  I 
> have no trouble loading individual servlets, but when I start 
> the server with a WAR file in place, I get a 
> NoClassDefFoundError: javax/servlet/http/HttpServlet.  The 
> error is masked by a catch( Throwable t) clause in 
> HostConfig::deployApps, but when I explicitly print the stack 
> trace, it looks like:
> 
> java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet
> at java.lang.ClassLoader.defineClass0(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:493)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.
> java:111)
> at 
> org.apache.catalina.loader.WebappClassLoader.findClassInternal
> (WebappClassLoader.java:1631)
> at 
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappC
> lassLoader.java:926)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappC
> lassLoader.java:1360)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappC
> lassLoader.java:1243)
> at 
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardW
> rapper.java:865)
> at 
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.
> java:808)
> at 
> org.apache.catalina.core.StandardContext.loadOnStartup(Standar
> dContext.java:3266)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext
> .java:3395)
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.
> java:785)
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454)
> at 
> org.apache.catalina.core.StandardHost.install(StandardHost.java:723)
> at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:331)
> at 
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:398)
> at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConf
> ig.java:232)
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(L
> ifecycleSupport.java:156)
> at 
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131)
> 
> at 
> org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
> at 
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
> 
> at 
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
> at 
> org.apache.catalina.startup.Embedded.start(Embedded.java:957)
> at 
> org.netbeans.modules.httpserver.TomcatServer.start(Unknown Source)
> at 
> org.netbeans.modules.httpserver.HttpServerModule$1.run(Unknown Source)
> 
> 
> Delving into StandardWrapper line 865, I see the classloader 
> attempting to load the servlet residing in the WAR file.  
> This servlet extends HttpServlet, and that's where my error 
> is coming from.  However, if I stick in a line:
> 
> classLoader.loadClass("javax.servlet.http.HttpServlet")
> 
> before line 865, everything works fine.  I'm guessing this is 
> because HttpServlet gets loaded in an earlier run of 
> StandardWrapper::loadServlet() (like when the DefaultServlet 
> gets loaded).
> 
> Must I explicitly set the parent classloader for the 
> org.apache.catalina.loader.WebappLoader?  How?
> 
> 
> Rich
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Classloader problems. Tomcat won't load Xalan from WEB-INF/lib

[Craig R. McClanahan]

On 4 Aug 2001, burtonator wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> OK.
> 
> I running Tomcat under with Xalan under JDK 1.3.  I want to have
> Tomcat reload all my Xalan extensions when I recompile.
> 
> The only problem is that since the Tomcat core uses Xalan the system
> classloader is used and therefore when I recompile none of my new
> extension modifications are used.
> 
> OF course this normal behavior with the system classloader (
> sun.misc.Launcher$AppClassLoader ).  What I need to have happen is for
> Tomcat (when in a certain configuration) to ALWAYS use *it's*
> classloader even if a given class has been loaded by the system
> classloader.
> 
> Is this possible?  Can I have two classloaders in the same JVM with the same
> classes loaded from different locations?
> 
> Did that make sense?
> 
> I have tried to find more documentation on this but was unable to find any in
> the archives which helped.
> 

Tomcat 4 does what you are after.  It loads it's own XML parser from the
"$CATALINA_HOME/server/lib" directory, which won't interfere with use of
Xalan (or an XML parser) loaded in your web app.

There's a document describing Tomcat 4's internal class loading
architecture in the source distribution (accessible online via anonymous
CVS) at:

  catalina/docs/dev/classloaders.html


> Kevin
> 

Craig McClanahan


> - -- 
> Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
> Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 
> 
> My mind is glowing!
> 
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
> 
> iD8DBQE7bJMTAwM6xb2dfE0RApUfAJwMX9y2lPCcD+Y4KQPlvVbgc29zsgCePk82
> 3c4V4puKUnm4pO06BR0OzLk=
> =AVyy
> -END PGP SIGNATURE-
> 
>