I've got the framework and initial application to complete and demo before next Wednesday, so I'm a little tight on time. Hopefully around the first of the July I'll some time to play around with this. In the meantime if anyone else can give it a go, please be sure to let everyone know.
Thanks. Jerry -----Original Message----- From: Joseph Barefoot [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:28 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession 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:[EMAIL PROTECTED]] > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
