You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Daniel Dominik Holúbek <da...@gmail.com> on 2009/08/10 17:40:09 UTC
Problems with session after modifying code
Hello,i'm developing a webapp combining osgi (equinox) and wicket.
it works fine, except of this case:
let's say we've got two bundles - "core" and "chat".
the "chat" bundle depends on "core" bundle.
now, i've made some modifications to the "chat" bundle, exported it and
deployed it to osgi container, leaving the "core" bundle unchanged.
because i need the changes to be seen by the "core", i have to refresh it.
and here is the problem. when i now access the webapp, i get an exception
which says - MySession can not be cast to org.apache.wicket.Session.
i think the problem is that the old session, containing old classes (in some
Page store maybe? i'm still a newbie :)) is saved to disk before actually
refreshing core classes and then loaded again - but confliting with new,
freshly loaded classes.
the exception goes away and webapp loads correctly after i restart my
browser :)
so my question is: do you know about some workaround for this problem? the
best scenario would be that the Session will load correctly, but it's not
necessary - it can be dropped.
i know there's a lot of osgi, but i think this is a wicket problem - but
correct me if i'm mistaken. :)
thanks for your answers!
--
-danoh-
Re: Problems with session after modifying code
Posted by Daniel Dominik Holúbek <da...@gmail.com>.
This is the stack trace:
Servlet.service() for servlet equinoxbridgeservlet threw exception
java.lang.ClassCastException: sdb.ziwhat.megaweb.core.ZiwhatSession cannot
be cast to org.apache.wicket.Session at
org.apache.wicket.protocol.http.AbstractHttpSessionStore.lookup(AbstractHttpSessionStore.java:240)
at org.apache.wicket.Session.findOrCreate(Session.java:223) at
org.apache.wicket.Session.findOrCreate(Session.java:211) at
org.apache.wicket.Session.get(Session.java:250) at
org.apache.wicket.Application$1.onInstantiation(Application.java:276) at
org.apache.wicket.Application.notifyComponentInstantiationListeners(Application.java:974)
at org.apache.wicket.Component.<init>(Component.java:873) at
org.apache.wicket.MarkupContainer.<init>(MarkupContainer.java:105) at
org.apache.wicket.Page.<init>(Page.java:235) at
org.apache.wicket.markup.html.WebPage.<init>(WebPage.java:184) at
org.apache.wicket.markup.html.pages.ExceptionErrorPage.<init>(ExceptionErrorPage.java:55)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:163)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1302) at
org.apache.wicket.RequestCycle.steps(RequestCycle.java:1353) at
org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:355) at
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at
org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:91)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:110)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:60)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at
org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:115)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at
com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:380)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Is there a way to invalidate all sessions?
On Tue, Aug 11, 2009 at 1:27 PM, reiern70 <re...@gmail.com> wrote:
>
> Maybe invalidate the HTTP sessions? So, that users will have to log-in
> again.
>
> Can you post a stack trace of the error you get? I remember having
> "similar"
> class cast exceptions because OSGi class loading, but they all banished
> after using the buddy class loading of equinox... But maybe your problem is
> something different...
>
> Best,
>
> Ernesto
>
>
> Daniel Dominik Holúbek wrote:
> >
> > Ok,i've found out that i need to delete the JSESSIONID cookie after
> > refreshing bundles.
> > is there any way to do that programatically?
> >
> > thx
> >
> > On Mon, Aug 10, 2009 at 5:40 PM, Daniel Dominik Holúbek <
> > dankodomko@gmail.com> wrote:
> >
> >> Hello,i'm developing a webapp combining osgi (equinox) and wicket.
> >> it works fine, except of this case:
> >> let's say we've got two bundles - "core" and "chat".
> >> the "chat" bundle depends on "core" bundle.
> >> now, i've made some modifications to the "chat" bundle, exported it and
> >> deployed it to osgi container, leaving the "core" bundle unchanged.
> >> because i need the changes to be seen by the "core", i have to refresh
> >> it.
> >>
> >> and here is the problem. when i now access the webapp, i get an
> exception
> >> which says - MySession can not be cast to org.apache.wicket.Session.
> >> i think the problem is that the old session, containing old classes (in
> >> some Page store maybe? i'm still a newbie :)) is saved to disk before
> >> actually refreshing core classes and then loaded again - but confliting
> >> with
> >> new, freshly loaded classes.
> >> the exception goes away and webapp loads correctly after i restart my
> >> browser :)
> >>
> >> so my question is: do you know about some workaround for this problem?
> >> the
> >> best scenario would be that the Session will load correctly, but it's
> not
> >> necessary - it can be dropped.
> >>
> >> i know there's a lot of osgi, but i think this is a wicket problem - but
> >> correct me if i'm mistaken. :)
> >>
> >> thanks for your answers!
> >>
> >> --
> >> -danoh-
> >>
> >
> >
> >
> > --
> > -danoh-
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Problems-with-session-after-modifying-code-tp24902109p24915768.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
-danoh-
Re: Problems with session after modifying code
Posted by reiern70 <re...@gmail.com>.
Maybe invalidate the HTTP sessions? So, that users will have to log-in again.
Can you post a stack trace of the error you get? I remember having "similar"
class cast exceptions because OSGi class loading, but they all banished
after using the buddy class loading of equinox... But maybe your problem is
something different...
Best,
Ernesto
Daniel Dominik Holúbek wrote:
>
> Ok,i've found out that i need to delete the JSESSIONID cookie after
> refreshing bundles.
> is there any way to do that programatically?
>
> thx
>
> On Mon, Aug 10, 2009 at 5:40 PM, Daniel Dominik Holúbek <
> dankodomko@gmail.com> wrote:
>
>> Hello,i'm developing a webapp combining osgi (equinox) and wicket.
>> it works fine, except of this case:
>> let's say we've got two bundles - "core" and "chat".
>> the "chat" bundle depends on "core" bundle.
>> now, i've made some modifications to the "chat" bundle, exported it and
>> deployed it to osgi container, leaving the "core" bundle unchanged.
>> because i need the changes to be seen by the "core", i have to refresh
>> it.
>>
>> and here is the problem. when i now access the webapp, i get an exception
>> which says - MySession can not be cast to org.apache.wicket.Session.
>> i think the problem is that the old session, containing old classes (in
>> some Page store maybe? i'm still a newbie :)) is saved to disk before
>> actually refreshing core classes and then loaded again - but confliting
>> with
>> new, freshly loaded classes.
>> the exception goes away and webapp loads correctly after i restart my
>> browser :)
>>
>> so my question is: do you know about some workaround for this problem?
>> the
>> best scenario would be that the Session will load correctly, but it's not
>> necessary - it can be dropped.
>>
>> i know there's a lot of osgi, but i think this is a wicket problem - but
>> correct me if i'm mistaken. :)
>>
>> thanks for your answers!
>>
>> --
>> -danoh-
>>
>
>
>
> --
> -danoh-
>
>
--
View this message in context: http://www.nabble.com/Problems-with-session-after-modifying-code-tp24902109p24915768.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Problems with session after modifying code
Posted by Daniel Dominik Holúbek <da...@gmail.com>.
Ok,i've found out that i need to delete the JSESSIONID cookie after
refreshing bundles.
is there any way to do that programatically?
thx
On Mon, Aug 10, 2009 at 5:40 PM, Daniel Dominik Holúbek <
dankodomko@gmail.com> wrote:
> Hello,i'm developing a webapp combining osgi (equinox) and wicket.
> it works fine, except of this case:
> let's say we've got two bundles - "core" and "chat".
> the "chat" bundle depends on "core" bundle.
> now, i've made some modifications to the "chat" bundle, exported it and
> deployed it to osgi container, leaving the "core" bundle unchanged.
> because i need the changes to be seen by the "core", i have to refresh it.
>
> and here is the problem. when i now access the webapp, i get an exception
> which says - MySession can not be cast to org.apache.wicket.Session.
> i think the problem is that the old session, containing old classes (in
> some Page store maybe? i'm still a newbie :)) is saved to disk before
> actually refreshing core classes and then loaded again - but confliting with
> new, freshly loaded classes.
> the exception goes away and webapp loads correctly after i restart my
> browser :)
>
> so my question is: do you know about some workaround for this problem? the
> best scenario would be that the Session will load correctly, but it's not
> necessary - it can be dropped.
>
> i know there's a lot of osgi, but i think this is a wicket problem - but
> correct me if i'm mistaken. :)
>
> thanks for your answers!
>
> --
> -danoh-
>
--
-danoh-