Hi Frank,
I think this post is related to mine:
We had a few "non-serializable" objects stored in session in TC 5.0.28 but
after migrating the app TC 5.5.9 is throwing
"java.lang.IllegalArgumentException: setAttribute: Non-serializable
attribute."
...when we try to put a non-serializable in the session. We are using a JSTL
recommended form like:
(...)
javax.servlet.jsp.jstl.fmt.LocalizationContext lc =
new javax.servlet.jsp.jstl.fmt.LocalizationContext(bundle);
javax.servlet.jsp.jstl.core.Config.set(session,
javax.servlet.jsp.jstl.core.Config.FMT_LOCALIZATION_CONTEXT,lc);
(...)
Do you know about any changes related to that in TC 5.5.x?
Thank you!
Paulo
-----Mensagem original-----
De: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 27 de abril de 2005 12:59
Para: Tomcat Users List
Assunto: Re: Nervous about Sessions ...
There *technically* isn't any requirement that things you store in
session be serializable. However, since some app servers use databases
or file systems to persist session information, and that many times is
implemented using serialization, and since serializable is usually (if
not always) necessary in a clustered environment to replicate the
session between nodes, you probably do for all intents and purposes only
want to store serializable objects in session, just to "future-proof"
your app.
Yes, you can store simple java types, and no, you do not *have* to use
beans (although I think this is generally considered a best practice in
most cases). If you do use beans though, you will probably want to make
sure you only use serializable types in the bean, or mark them transient
as Viorel mentioned, as per the point made in the first paragraph above.
But again, there's nothing that says you have to do any of this... if
you KNOW you are only going to run on a single server and if you KNOW
your app server is only storing session in memory, there is nothing that
says any object you put in session, on it's own or by virtue of members
it contains, must be serializable.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
David Whitehurst wrote:
> If I use the "session" to store things, 1. Can I use simple java types?
> 2. Do I have to use Java Beans (extends serializable)?
>
> David Whitehurst
>
> Viorel Dragomir wrote:
>
>> Yes.
>> But you can set some attributes of the objects as [ transient ] to not
>> be serialized. So you don't have to make all objects in the package
>> serializable.
>>
>>
>>
>>
>> Viorel Dragomir
>>
>> .
>> ..
>> -------------------------------------------------------------------
>>
>>
>>
>> ----- Original Message ----- From: David Whitehurst To:
>> tomcat-user@jakarta.apache.org Sent: Wednesday, April 27, 2005 11:31
>> Subject: Nervous about Sessions ...
>>
>>
>> Long ago a multi-client, multi-Oracle application was written using
>> Struts. Recently, we had a 4 in 22,000 record data integrity issue.
>> I found one client implementation that used prepared statements but
>> the primary key was being used e.g. "update mytable set a= ?, b=?
>> where pri_key = " + pkey + " ' "; ...whoa! I said, called the
>> developer and we had a talk.
>>
>> Then, I also found that where we use a HashMap object it is not
>> synchronized. I suspect that was the data problem, i.e. two records
>> saved by two different people, and the data was the same for the
>> different records in the same Oracle second.
>>
>> I'm looking for comments about the use of this HashMap on "requests"
>> but I'm also nervous now where I use Strings in the "session" e.g. a
>> clientname, username, etc. My concern started when I read the posts
>> about the non-serializable objects in the session. Do all java
>> objects placed in the session have to be serializable?
>> Thanks,
>>
>> David L. Whitehurst
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
