At 19:19 08.02.00 , Robert Krüger wrote:
>>te that the above list is simplified but it demonstrates the general
>>principle. In reality it is a tree - not a list, and each
>>loader is a node. My recommendation is to put TunnelServlet at the
>>Servlet/Beans level (usually where it belongs) and
>>to
snip
>A class is *not* (common mistake) defined by name, but by name + loader.
>Lack of this knowledge is what leads to a lot of ClassCastException
>questions
>in various forums. The serializer does not have a problem finding the class,
>it simply does object.getClass(), the deserializer however
> >for magnus: it still behaves like that in 0.9.1g (you said that you'd
> >fixed several classloader bugs. if this is one, it's still there)
> >
No, this is not a bug, this is how classloader delegation works in a JVM.
I'll try expanding some on what Luke said:
A class is *not* (common mis
>ups, forgot to reply to the list.
>
>At 16:35 08.02.00 , you wrote:
>>Hi Robert,
>>
>>I'd get TunnelServlet out of the global classpath, and into a
>>different namespace that includes everything that it wants to accept
>>serialised objects for. If you need access from more namespaces, just
>>h
Hi Robert,
I'd get TunnelServlet out of the global classpath, and into a
different namespace that includes everything that it wants to accept
serialised objects for. If you need access from more namespaces, just
have a different copy of TunnelServlet for each namespace - Classes
are cheap.
P.S.,
Hi,
I ran into the following problem:
I have a servlet that reads serialized java objects from a POST request
called TunnelServlet which is in the global classpath of the server because
it's a general purpose utility. in addition to that I have a servlet
DomainAdminTunelServlet in a deploymen
