Daniel Rall wrote: > Scott Brickner <[EMAIL PROTECTED]> writes: > > > "Different contexts" isn't necessarily the same as "different JVMs". > > I think that tomcat uses a single JVM instance for all of the > > webapps. They just use different classloaders to keep things from > > "accidentally" interfering with one another. This might be as simple > > as explicitly loading the common class through the system > > classloader. > > Scott B. is right on. What you want to do is implement the cache > based on some static field of a class placed in Tomcat's shared > classloader.
A colleage of mine came up with this, too. I was not aware of how the classes in Tomcat's lib directory where handled differently (from those in the webapp's lib directory). Using a different classloader is much easier than I originally thought it would be. > > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html > > This static field will reference the same object in both of your web > applications, and can point to your cache (using the singleton pattern > for this would work well). > > Scott W.'s suggestion of XML-RPC (very easy to implement) and Scott > B.'s suggestion JCS only work for certain use cases. If you're going > to be making lots of calls to these shared objects, you don't have the > right use case for these schemes. The number of calls should not really be a problem, but the data exchanged in those calls. I am getting Input- and OutputStreams from some of them, because I am using a selfmade virtual filesystem for storing/reading documents, images and other files + metadata. [btw I'd like to make that VFS open-source some day (probably LGPL), so if you ever hear of "Liland VFS"...] I will probably move the VFS into a standalone app (accessible via XML-RPC, RMI, webdav or some other suitable means of network transport), when scalability becomes an issue. > Another possiblity (mentioned for academic completeness) would be to > use Servlet API 2.3's RequestDispatcher interface and pass just the > data you need between web apps as they call each other internally. > This doesn't give you shared objects per say, but does provide you > with the data you need and opens up other sorts of possibilities > (likely not useful for your case). I looked at that possibility too and I have to agree: it's not really useful in my case. > > - Dan I have decided to write a class that simply provides access to it's internal hashtable via static put- and get-methods. I'll synchronize those methods to be (thread)safe and let tomcat load it from it's common/lib directory. That should solve my present (and possible future) object sharing problems. Thank you, Dan, for those suggestions! Thanks to all the others, who have replied! Edmund -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
