Return-Path: 
 <cocoon-dev-return-13500-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 35637 invoked by uid 500); 18 May 2001 13:43:32 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 35608 invoked from network); 18 May 2001 13:43:28 -0000
From: "Matthew Langham" <mlangham@sundn.de>
To: <cocoon-dev@xml.apache.org>
Subject: AW: Restricting objectModel
Date: Fri, 18 May 2001 15:44:08 +0200
Message-ID: <MLEAJJEAAELCMLAIJNFIKEJGCEAA.mlangham@sundn.de>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <NEBBKBNHBMFHDJPKGCOBEEBDCKAA.vgritsenko@hns.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release
 5.0.5 |September
 22, 2000) at 18.05.2001 15:42:31,
	Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.5 |September
 22, 2000) at 18.05.2001 15:43:01,
	Serialize complete at 18.05.2001 15:43:01
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

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