hi John;
> No, the spec doesn't mandate anything - it's up to the application
> server implementation (a "quality of implementation feature"). With J2EE
> app servers there is typically one ClassLoader per container (or
> archive) even with multiple containers per Server VM. Decent
> application servers should remove all references to a container (or
> archive's) ClassLoader when the container is removed from the server.
> How this is done is vendor specific since server/container management
> is outside the scope of the spec.
thanks - so it's vendor specific; ...one thing I've had in
mind was the effect of this on such things like the static
class initializers with `sideeffects' -- so I have to be
careful about this (under a setting/server which does
class-unloading aggressively/fine-grained) I guess...
> What you can rely on is the fact that the classes & resources loaded to
> support J2EE modules running in one container should never be visible to
> different J2EE modules running in another container in the same VM.
> What you will also find is that several Servlet/JSP implementations
> (such as Tomcat) have the ability to reload JSP/Servlet class files from
> disk if the class has changed between client invocations in order to
> allow web developers to quickly test changes to their web components.
> However, such behaviour is configurable and is usually disabled for
> production systems as it imposes a signigicant performance hit.
well, when on Tomcat I was actually using this but never
really have cared about it :p, now it started to interest
me; I'll take a look...
thank you again!
kenji
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
