cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morrison, John" <John.Morri...@uk.experian.com>
Subject RE: [C2] collapse ParanoidCocoonServlet into CocoonServlet itself ?
Date Tue, 22 May 2001 13:09:13 GMT
Could we not have a factory class which supplies CocoonServlet or
ParanoidCocoonServlet as required depending upon, say,
javax.servlet.ServletContext.getServerInfo (and Major/Minor versions?)?

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: 22 May 2001 2:00 pm
> To: cocoon-dev@xml.apache.org
> Subject: Re: [C2] collapse ParanoidCocoonServlet into CocoonServlet
> itself?
> 
> 
> Davanum Srinivas wrote:
> > 
> > Berin,
> > 
> > Shall i give it a shot (at merging both)? Three 
> environments that i have access to right now is
> > Tomcat 3.2, Tomcat 4.0 and ServletExec 3.1 (which 
> definitely has a broken class-loader).
> 
> The thing is, I don't want the extra classloader if it isn't 
> needed, there is alot of complexity
> already in the init parameters, so the separate classes 
> helped in that regard.
> 
> Remember the issues we had when you helped me get Cocoon 2 
> working with IBM WebSphere?  That
> has a seriously screwed up classloader.  Again, BEA WebLogic 
> 6.0 has some wierdness with it
> as well.
> 
> I am somewhat -1 on this approach, because it is going to 
> make CocoonServlet that much more
> difficult to maintain.  The whole reason for the separation 
> of the two classes is so that
> the complicated classloading code can be maintained separate 
> from the other code.
> 
> I am +1 if you want to attack the ClassLoader issue and 
> create one that loads from itself
> first, and then from it's parent if it has one.  That way the 
> ParanoidCocoonServlet might
> be able to use the Xerces Class without the XercesParser 
> hack.  If you can get that working,
> we can look at the complexities of merging the two.
> 
> Bottom line though, If we don't need the extra classpath 
> buffer, don't use it.
> 
> > 
> > Thanks,
> > dims
> > 
> > --- Berin Loritsch <bloritsch@apache.org> wrote:
> > > Davanum Srinivas wrote:
> > > >
> > > > Berin,
> > > > To enhance "Out of Box" Experience and reduce 
> frustration for beginners, can we collapse the
> > > two?
> > > > I don't see any performance hit because of the changes 
> (as parent class-loaders are always
> > > queried
> > > > first).
> > >
> > > Actually that is the whole problem.  We need to reverse 
> that approach for the
> > > ParanoidCocoonServlet.  In reality, we want to load 
> classes from the ClassLoader
> > > we instantiate, and if (only if) it isn't found, we go to 
> the parent classloader.
> > >
> > > I understand what you are saying, but they really are two 
> different animals.  If
> > > we always load the classes in our own classloader, then 
> we are subject to package
> > > sealing violation exceptions.
> > >
> > > I never have gotten around to writing the classloader 
> that operates opposite to
> > > the way Sun set them up.  Honestly, there are exceptions 
> to that rule where you
> > > don't want a ParentClassLoader to load first.
> > >
> > > 
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > 
> > =====
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Auctions - buy the things you want at great prices
> > http://auctions.yahoo.com/
> > 
> > 
> ---------------------------------------------------------------------
> > 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
> 


=======================================================================
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF

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


Mime
View raw message