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., hope you're being careful -- servers accepting arbitrary java
objects could be the next-generation internet security hole. :-)
P.P.S., the reason that writeObject works is that even though the
classes don't exist in the caller's namespace, they are still a part
of the objects that are being called in the runtime. When readObject()
gets called, it needs to find the classes somewhere to make the
objects.
My 2 cents,
Luke
Robert Kr�ger <[EMAIL PROTECTED]> writes:
> 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 deployment jar file that extends TunnelServlet
> that uses its serialization capabilities. the classes of the serialized
> objects are known to the DomainAdminTunnelServlet because they are in the
> same deployment jar file. however the readObject call in TunnelServlet
> fails with a ClassNotFoundException (Stacktrace below) if I don't put the
> classes of the serialized objects into the global server classpath which is
> definitely something I don't want to do. Am I doing something wrong here or
> should this work? The strange thing is that writeObject calls to the
> servlet's response output stream work OK.
>
> The setup in short again:
>
> TunnelServlet (loaded via server classpath) delegates calls to extending
> classes via reflection
> DomainAdminTunnelServlet extends TunnelServlet (loaded via deployed jar file)
> UnitData (implements Serializable and is read from servlet input stream,
> loaded via the same jar file as DomainAdminTunnelServlet)
>
> Any thoughts on that?
>
> thanks,
>
> robert
>
> P.S.: here's the stacktrace:
> com.signal7.procurement.struct.administration.UnitData is in the same jar
> file as the servlet
>
> java.lang.ClassNotFoundException: com.signal7.procurement.struct.administra
> tion.UnitData
> at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:981
> )
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
> at java.io.ObjectInputStream.inputArray(ObjectInputStream.java:951)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:357)
> at java.io.ObjectInputStream.inputClassFields(ObjectInputStream.jav
> a:1831)
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.ja
> va:502)
> at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:116
> 6)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:232)
> at com.signal7.httptunnel.TunnelServlet.service(TunnelServlet.java:
> 81)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:324)
> at cv.kt(JAX)
> at cv.forward(JAX)
> at c4.mu(JAX)
> at c.run(JAX)
>
> (-) Robert Kr�ger
> (-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
> (-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
> (-) Tel: 06151 665401, Fax: 06151 665373
> (-) [EMAIL PROTECTED], www.signal7.de
