On 6 Apr 2004, at 10:38, Werner Guttmann wrote:
This might sound a little bit off-topic, but are you sure that everything (Castor itself, dependent libraries, etc.) is loaded by the web app classloader ? And
more importantly, have you had a look at open bugs for Tomcat 5.x wrt to this issue ?
Everything is *not* loaded by the webapp classloader - that's exactly the point. :)
JDO is being loaded via JNDI off of the system-wide global JDNI context; it is not loaded or unloaded with the application. Both JDO and the database are configured as global resources available to all applications; the applications request a JDO object from JNDI, which is configured from Tomcat's server.xml.
Works great, except for this. :)
Yes, and no ... ;-). There's some, but I do not think they make it easy to trace anything. But it should be sufficiently easy to modify one of the expire()
calls to make a call to Cache.elements() and iterate over the returned Enumeration to see what's stuck in there. And putting this code in there shouldn't
make a difference performance-wise, as this method won't be called very often, anyhow.
The question is, is a field where an array is specified handled differently than an object without it? And when I blow away that object containing that field, does it also blow away the definition for the contents of that array?
When the new app comes in, it will request the JDO object retrieved from the global JNDI instance to configure itself off of the schema, which should trigger a reload of all information from that config for that JDO object. Something's sticking around. That's the problem. :)
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
