cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vgritse...@hns.com>
Subject RE: Restricting objectModel
Date Fri, 18 May 2001 15:52:08 GMT
Carsten,

Do you use WL6.0 or WL6.0sp1?

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


Mime
View raw message