They told me that the spec will disallow it but I have no idea if that is
factual or not. It could just be their interpretation of the spec, from the
snipets I've seen it definetly says you shouldn't put Non Serializable
objects into the session but isn't very clear about putting them into the
PageContext under different scopes.
-Matt
-----Original Message-----
From: Punyansky, Alex [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 07, 2000 2:17 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Struts+Weblogic=Problems. Changes to struts?
Thanks Matt,
Does it mean that I need to modify Struts by removing support for
internationalization ( removing/replacing PropertiesResourceBundle from
MessageResources )?
Craig, are you planning to change Struts so that it complies with Servlet
2.3 ( making all attributes Serializable )?
Alex
-----Original Message-----
From: Matthew Heaton [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 07, 2000 2:14 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Struts+Weblogic=Problems
I posted my concerns on BEA's message board about Weblogic not allowing non
Serialized objects to be placed inside the PageContext are two of the
responses is below. I was basically told that the servlet 2.3 spec disallow
non serialized objects in the PageContext so built this into the current
release of Weblogic.
-Matt
----------------------------------------------------------------------------
--------------------
Matt,
In order for the reload-on-modify to work correctly, we have to assume that
any objects that go into servlet request, servlet context and HTTP session
are serializable. Otherwise, it's quite easy to get yourself into
ClassCastException situation.
WLS comes with reload-on-modify turned on out of the box. You can turn it
off by setting reload periods to -1 (never check). There are two separate
params for JSP and servlets. The one for JSPs is set in weblogic.xml
descriptor, the one for servlets is set in the console.
Thanks, -ruslan
Matt Heaton wrote:
> After many unsuccessful attempts at getting Struts to work on Weblogic
5.1, I decided with give it a try on Weblogic 6.0 Beta 2
>
> Everything seems to be deploying correct except for I get the following
error (which of course breaks everything):
>
> <Nov 30, 2000 1:19:37 PM PST> <Error> <HTTP>
<[WebAppServletContext(6802820,struts-example)] Cou
> ld not deserialize context attribute
> java.io.NotSerializableException: java.util.PropertyResourceBundle
> at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
> at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1841)
> at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
> at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
> at
weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:7
1)
> at
weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppServletCon
text.java
> :207)
> at
weblogic.servlet.jsp.PageContextImpl.getAttribute(PageContextImpl.java:164)
> at
org.apache.struts.taglib.bean.MessageTag.doStartTag(MessageTag.java:230)
> at jsp_servlet._index._jspService(_index.java:105)
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:208)
> at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:244)
> at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
ntext.jav
> a:1107)
> at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
:1482)
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
> >
>
> It appears that Weblogic requires any object that you use as a context
attribute on a JSP page must be serializable. I went through some of the
Struts source and it's trying to use objects which aren't serializable as
JSP page context attributes. This looks like it may be a shortcoming in the
JSP spec because it makes sense that to support to failover of sessions you
would need to be able to serialize the attributes since a the attributes of
a PageContext may have the scope of an entire session. > > -Matt
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 30, 2000 4:54 PM
To: [EMAIL PROTECTED]
Subject: Re: Struts+Weblogic=Problems but this time it looks like it's
Struts
Matthew Heaton wrote:
> The example application itself doesn't put non Serializable objects into
the
> Http session but all throughout the struts code non Serializable objects
are
> placed in the PageContext with a scopes of Application, Page, or Request.
> It appears that Weblogic 6.0 beta may be handling these as if they were
> placed with a Session context and disallowing non serializable objects.
> Whatever is going on it also appears WL is enforcing this rule in non when
> <distributable> is not set.
>
Yep. Looking more closely at the error message, it is complaining about a
non-Serializable *context* attribute, not a *session* attribute. I, like
others, jumped to the wrong conclusion there.
The spec provides no prohibitions on this -- only a warning that you cannot
use
a context attribute to share information globally in your application (the
way
that the example app does with its pseudo-database) in a distributed
environment.
Is there by chance some WebLogic specific configuration property you have
set
that makes it think this (or maybe all) applications should be treated as
distributable?
>
> -Matt
>
Craig
----------------------------------------------------------------------------
-------------
This looks similar to an issue that came up on the JSP newsgroup recently.
Below is the response I wrote there. Hope it helps. -- mark
In order to support reloading of jsps/classes in a webapp, we need to create
a new classloader. All stateful objects loaded from the old classloader
(such as things put into the session) need to be reloaded in the new
classloader. We try to preserve the state of the objects using
serialization. If the object isn't serializable, you are out of luck, and
the object is lost. The only other alternative in the case where we're
trying to support reloading is to allow a classcastexception to occur.
The only alternative in the current product is to turn off reloading,
setting jsp pageCheckSecs=-1 and ServletReloadCheckSecs=-1.
There is a thread on the servlet 2.3 mailing list where it looks like the
servlet 2.3 spec will have words to the effect that things put into the
session should be serializable if you want class reloading to work in the
container.
We suspect that this will be a fairly common problem, so we are trying to
find ways to avoid this in our implementation such as using a classloader
per jsp and handling this specific exception. Unfortunately, this will
probably not make it before GA.
The following is from the servlet 2.3 spec
------------------------------------------------------------------- "In
order to allow sessions to persist across class reloading within the
container, it is highly advised that you should implement the Serializable
interface. Otherwise, you risk the strong chance that the objects within
your session will not exist after the classloader has been reloaded."
--------------------------------------------------------------------
