>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
>>have a different copy of TunnelServlet for each namespace - Classes
>>are cheap.
>
>have thought about that although I'm not quite sure if you're saying this
>is just a misunderstanding of mine or an orion bug that your approach is a
>workaround for?
>
>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)
>
>>P.S., hope you're being careful -- servers accepting arbitrary java
>>objects could be the next-generation internet security hole. :-)
>
>I'm aware of the implications (I hope ;-)
>
>>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.
>
>I'm not quite sure I fully understand that. let my try to recapture:
>writeObject only needs to know that the Object is of Serializable type
>(which they all are), readObject needs to call a constructor and therefor
>needs to have access to the class. is it something like that? any
>recommended reading on the topic?
>
>thanks,
>
>robert
>
>>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
(-) 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
