cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] collapse ParanoidCocoonServlet into CocoonServlet itself?
Date Tue, 22 May 2001 12:59:32 GMT
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


Mime
View raw message