cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject RE: Restricting objectModel
Date Tue, 22 May 2001 05:13:56 GMT


On Mon, 21 May 2001, Vadim Gritsenko wrote:

> Carsten,
>
> I did try request attributes with <jsp:forward> - everything works fine for me;
> I went through the weblogic.servlet.internal.ServletRequestImpl and RequestAttributes
> (same package) - and, yes, there is check "instanceof Serializable", but no, all other
> attributes are also alowed (just stored in another Map).

I'm confused now. Is it possible for weblogic users to use
request.setAttribute without the need to make the objects put there
Serializable?

Giacomo

>
> PS My test is attached, run Test.jsp. If you can, please give me non-working test.
>
> Vadim
>
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > Sent: Monday, May 21, 2001 1:41
> > To: cocoon-dev@xml.apache.org
> > Subject: AW: Restricting objectModel
> >
> >
> > > Von: Vadim Gritsenko [mailto:vgritsenko@hns.com]
> > >
> > > Carsten,
> > >
> > > Do you use WL6.0 or WL6.0sp1?
> > >
> > WL6.0sp1
> >
> > Carsten
> >
> > > Vadim
> > >
> > > > -----Original Message-----
> > > > From: Matthew Langham [mailto:mlangham@sundn.de]
> > > > Sent: Friday, May 18, 2001 9:44
> > > > To: cocoon-dev@xml.apache.org
> > > > Subject: AW: Restricting objectModel
> > > >
> > > >
> > > > Vadim,
> > > >
> > > > >>
> > > > And about request attributes - that may be done for automatic failover
/
> > > > load
> > > > balancing - I'm not so sure why is this done this way...
> > > > <<
> > > > Carsten was only talking about the request attributes - not the
> > > session. The
> > > > serialization of request attributes seems to be a "feature" of
> > > Bea WLS 6.0
> > > > as we have not seen it on any other application server we have installed
> > > > onto.
> > > >
> > > > Matthew
> > > >
> > > > --
> > > > Open Source Group               sunShine - Lighting up e:Business
> > > > =================================================================
> > > > Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > > Tel: +49-5251-1581-30   [mlangham@sundn.de - http://www.sundn.de]
> > > > =================================================================
> > > >
> > > >
> > > > -----Ursprungliche Nachricht-----
> > > > Von: Vadim Gritsenko [mailto:vgritsenko@hns.com]
> > > > Gesendet: Freitag, 18. Mai 2001 15:28
> > > > An: cocoon-dev@xml.apache.org
> > > > Betreff: RE: Restricting objectModel
> > > >
> > > >
> > > > Carsten,
> > > >
> > > > </skip>
> > > >
> > > > > > > >
> > > > > > > I forget some important point:
> > > > > > > I know that the "correct" way of passing information should
not be
> > > > > > > the objectModel. You will tell me in your next email that
> > > I could use
> > > > > > > the session or the request object for this, right?
> > > > > >
> > > > > > Absolutely :)
> > > > > >
> > > > > > > The problem with this is that some servlet engines (like
> > > BEA WLS 6.0)
> > > > > > > requires that even the attributes of the request are serializable.
> > > > > >
> > > > > > Shit, is this a standard?
> > > > >
> > > > > Not sure about the standard, but BEA WLS 6.0 is known for exactly
this
> > > > > (there are discussions about this over on in the bea newsgroups.)
> > > > > Our tests did prove this.
> > > >
> > > > You do not need to perform any tests to confirm this: If you think about
> > > > running
> > > > your application in clustered environment and remember that
> > > serialization is
> > > > the
> > > > only way of replicating your session into backup server - than
> > > it would be
> > > > obvious
> > > > to you why it's done this way :)
> > > >
> > > > And about request attributes - that may be done for automatic failover
/
> > > > load
> > > > balancing - I'm not so sure why is this done this way...
> > > >
> > > > So, may be, you want your objects to be serializable to run
> > > well in cluster.
> > > >
> > > > Regards,
> > > > Vadim
> > > >
> > > >
> > > > > >
> > > > > > > And this prevents from putting anything into the request.
Now we
> > > > > > > could say: "Ok, that's a problem of the servlet engine
> > > but not ours"
> > > > > > > but this is of course no solution.
> > > > > > > If there are really many votes with "+1" for changing to
an avalon
> > > > > > > context I would vote "+10000" for a container object which
I can
> > > > > > > get from the context to put any objects into for the
> > > current request.
> > > > > >
> > > > > > Hmm..
> > > > > >
> > > > > >
> > > > > > Can I read in between your lines that you already us it that
way?
> > > > >
> > > > > Yes. And changing it would hit us hard.
> > > > >
> > > > >
> > > > > Carsten
> > > > >
> > > > > Open Source Group                        sunShine - b:Integrated
> > > > > ================================================================
> > > > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > > > www.sundn.de                          mailto: cziegeler@sundn.de
> > > > > ================================================================
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message