struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Barefoot" <jose...@hereuare.com>
Subject RE: Please help clarify or confirm -- HttpSession
Date Thu, 13 Jun 2002 19:27:36 GMT
Kevin wrote:
> It even says that the "shared" class loader exists for "classes and
> resources that you wish to share across ALL web applications".
>
> So as long as you've got a 2.3 compliant container and you can get the
> functionality you need from a static class, then this should work.

Thanks for the support Kevin, I was beginning to wonder if everyone thought
I was wacko for suggesting this. :)  I do realize that this isn't the most
robust or generic solution in the world, but it damn sure would be easy to
implement.

Jerry (or anyone else interested):  If you do test this out, could you
please post your conclusions back to the list?  This has been a very
interesting thread for me (having dealt with classloader craziness in the
past), so I'm curious if theory is backed by reality in this case.


peace,
Joe Barefoot

> -----Original Message-----
> From: Jerry Jalenak [mailto:Jerry.Jalenak@LABONE.com]
> Sent: Thursday, June 13, 2002 12:17 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Please help clarify or confirm -- HttpSession
>
>
> Damn, not yet ready to go to Tomcat 4.x.  Might be a good
> argument to start
> moving that direction.....  (:-)
>
> Thanks to everyone for their comments - it's given me plenty to
> think about.
>
> Jerry
>
> -----Original Message-----
> From: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
> Sent: Thursday, June 13, 2002 2:00 PM
> To: Struts Users Mailing List
> Subject: RE: Please help clarify or confirm -- HttpSession
>
>
>
>
> > > Second, having common
> > > directories on the two CLASSPATHS for the two webapps allows you to
> load
> > > CLASSES to create new objects, but not to share the objects once they
> are
> > > created.
>
> > True, but not what I suggested at all.  Two webapps sharing a common
> > CLASSPATH is far different from them having access to a common
> > (shared,parent) CLASSLOADER.  In the former two different classloaders
> are
> > loading the same class into two different "memory spaces", as you say.
> In
> > the latter, a parent classloader is loading a class into a
> "memory space"
> > accessible by either of the two child classloaders for the
> webapps.  So I
> > fail to see why a static class with static resources loaded by this
> parent
> > classloader will not enable objects to be shared between the two child
> > classloaders, so long as the objects themselves are also created from
> > classes loaded by the shared classloader.
> >
> > Note that I am also not claiming that this will 100% work, I just don't
> see
> > why it wouldn't.
>
> Sorry, misunderstood you.
>
> I'm not sure if this would work either, but I follow your logic.
> Seems like
> it would be easy to try. Just create a simple static class holding a
> counter and then hit two diff web apps that increment and display its
> value.
>
> Looking at:
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html it
> looks as it the Classloader Hierarchy in Tomcat 4.1 (per the Servlet Spec
> 2.3 sections 9.4 & 9.6) provides exactly this functionality.
>
> It even says that the "shared" class loader exists for "classes and
> resources that you wish to share across ALL web applications".
>
> So as long as you've got a 2.3 compliant container and you can get the
> functionality you need from a static class, then this should work.
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
> This transmission (and any information attached to it) may be
> confidential and is intended solely for the use of the individual
> or entity to which it is addressed. If you are not the intended
> recipient or the person responsible for delivering the
> transmission to the intended recipient, be advised that you have
> received this transmission in error and that any use,
> dissemination, forwarding, printing, or copying of this
> information is strictly prohibited. If you have received this
> transmission in error, please immediately notify LabOne at (800)388-4675.
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message