Stuart Maclean wrote:
>
> My problem is that I cannot now cast object o to a local class type
> MyClass, since even though the fully qualified class names will match,
> the class instance as was added to the other context (using
> setAttribute( "foo", OBJ )) was itself loaded via a DIFFERENT class
> loader
>
The 2.3 spec mandates only that classes within a context
share a classloader, so the behavior you describe is intended
to be legal (going forward, at least...)
> Is there any way around this?
>
No way around the classloader thing, at least no way that
is guaranteed to always work. (Distributed webapps get a
context-per-jvm, so you'd run into problems there as well,
if it matters)
> On a related note, is there a better design here, where
> I want a resource to be accessible to distinct contexts.
>
There are some reasonably recent discussions in the archive.
Keywords like "singleton global" would probably be a good
start, and you can drill down from there. There is discussion
about making sure "global" classes are loaded by the system
classloader by putting them in the CLASSPATH, for example.
(If you can _get_ to the archive, the search function appears
to be either slow or offline again)
The correct answer also depends on if you ever intend to make
the webapp distributable...
-cks
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html