[J2EE] Probleem met Non-serializable attribute in sessie

[Verwijderd]

Ik heb een vreemd probleem... ik ben bezig met de implementatie van PayPal en hierbij is een heel mooi voorbeeld geleverd dat werkt met JSP pagina's.

Vanwege verschillende redenen gebruik ik geen JSP pagina's in mijn applicaties maar Servlets. Hierbij loop ik echter tegen een vreemd probleem:

In het voorbeeld wordt het volgende gedaan in de JSP pagina (getest en werkt ook prima):

CallerServices caller = new CallerServices();
session.setAttribute("pp_caller", caller);


Er wordt dus een object geinstantieerd (doet er even niet toe wat voor object) en in de sessie opgeslagen. Dit werkt allemaal uitstekend, op de andere JSP pagina's kan ik dit object ook gewoon weer ophalen.

Nu wil ik dit niet in de JSP pagina doen maar in de servlet, ik doe het volgende in de doPost methode van de servlet: (ook in de doGet wil het niet trouwens)

HttpSession session = req.getSession(false);

CallerServices caller = new CallerServices();
session.setAttribute("pp_caller", caller);


Vervolgens krijg ik de volgende foutmelding:
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute
at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1255)
at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1233)
at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:129)
at TestServlet.doPost(TestServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Unknown Source)

Het verschil zit hem in het feit dat ik hier even zelf het session attribuut ophaal, in de JSP pagina is deze variabele standaard beschikbaar (hoe deze is geinstantieerd heb ik nog niet kunnen vinden).

Ik begrijp dat een Non-serializable object niet in de sessie gezet kan worden maar het punt is dat het in de JSP pagina (wat naar mijn weten eigenlijk gewoon een servlet is) wel perfect werkt.

Iemand een suggestie?

[momania]

Kan me niet voorstellen dat je _precies_ hetzelfde doet, aangezien een jsp uiteindelijk ook maar een servlet is

Die CallerServices class implementeerd echt Serializable?

[Verwijderd]

Dat is een beetje lastig om te bevestigen aangezien ik niet de source heb van die klasse... maar omdat het in een JSP pagina geen problemen geeft kan ik daar vanuit gaan (ook in de PayPal voorbeelden wordt het zo gedaan en het werkt uitstekend)

Maar inderdaad... ik snap ook echt niet wat het probleem kan zijn omdat ik dus echt precies hetzelfde doe... alleen haal ik in dit geval zelf de session op, das het enigste verschil dat ik kan ontdekken. Raar maar waar (anders had dit topic hier nooit geweest ).

Ik heb mijn code al zo gestript dat hij alleen het stukje dat ik laat zien in mijn start post uitvoert (dus alleen dat caller object op de sessie zetten) en in dezelfde applicatie gaat het dus wel perfect in een JSP pagina en niet in de Servlet

[Y0ur1]

momania schreef op dinsdag 13 maart 2007 @ 22:00:
Kan me niet voorstellen dat je _precies_ hetzelfde doet, aangezien een jsp uiteindelijk ook maar een servlet is

Die CallerServices class implementeerd echt Serializable?

Volgens deze api niet: http://www.jerrythedog.co...vices/CallerServices.html .

[Verwijderd]

Ik ben er nog een tijdje mee aan het experimenteren geweest en ik vind het echt vaag dat het de ene keer wel lukt (dat object in de sessie zetten) en in een ander project niet

Maargoed, ik heb nu zelf een klasse gemaakt die wel serializable implementeert, daarin sla ik dan dat caller object op.

[Verwijderd]

Ik heb het probleem gevonden... in de web.xml stond het volgende:

<distributable/>

Zogauw je dit weghaalt krijg je geen ClusteringNotSupportedException (van Tomcat volgens mij) meer en dan kan ik gewoon dat object in de sessie zetten.

[coenbijlsma]

Volgens mij is dat wel een oplossing, maar niet de oplossing. Je objecten moeten namelijk alleen maar Serializable zijn omdat je dan in een geclusterde JVM-omgeving kunt werken (al is het wel goed om je Objecten Serializable te maken voor het geval dat..).

Als je je non-serializable object in een serializable object zet maakt dat niets uit. Je Serializable kan dan wel naar een outputstream, maar je non-serializable-in-die-klasse-opgeslagen-object niet

Bottom-line: Het werkt nu omdat je je objecten alleen maar binnen dezelfde JVM kunt hebben omdat je die <distributable/> weg hebt gehaald. De ClusterinNotSupportedException komt dus ook daar vandaan