cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: What are the XSP design goals?
Date Fri, 02 Jun 2000 19:12:21 GMT
Stefano Mazzocchi wrote:
> 
> Berin Loritsch wrote:
> >
> > Mike Engelhart wrote:
> >
> > > on 6/2/00 7:44 AM, Berin Loritsch at bloritsch@infoplanning.com wrote:
> > >
> > > > One of the biggest usability goals of Cocoon should be that
> > > > it is completely reload-able like a true servlet should be.
> > > > If these design goals cannot be met in this manner, than support
> > > > for XSP should be separated into a separate package that
> > > > would have to be installed in the classpath, allowing the rest
> > > > of cocoon to operate normally.
> > > One thing though - compiled XSP are NOT servlets at all.   They just have
> > > access to the request/response object but I don't think that makes them
> > > servlets. Also XSP are reloadable by definition. If you change the XSP
> > > source file, it is recompiled and reloaded by Cocoon.
> > >
> > > Mike
> >
> > My main point and major complaint is that Cocoon itself is no longer
> > able to act as a servlet because of the current implementation of XSP.
> > I was not trying to imply that XSP was a servlet.  I was trying to give
> > some possibilities that might make it so that I don't have to modify the
> > Tomcat/WebLogic/WebSphere/Insert your servlet engine $(%*#$
> > classpath.  I want to be able to drop a WAR file or directory in the
> > webapps folder and have XSP and everything else work normally.
> 
> Hmmmm...
> 
> > As long as I can get along without XSP (fat chance) then Cocoon will
> > behave like a good servlet should.  I was impressed with how easy
> > it was compared to C1.7.x--with the ugly exception that XSP forces
> > me to perform the classpath *HACK*.
> 
> ok
> 
> > I'm sure there is a way that we can have compiled pages and let Cocoon
> > behave like a good little servlet should.
> 
> I'm sure we can. This might reflect on other functionalities we are
> missing, though.
> 
> > Otherwise we should stop
> > frontin' and make this a complete App Server with EJB and the like
> > built in.  >I don't see this as part of what Cocoon is or even should do<
> 
> oh god...
> 
> > Don't get me wrong--C2 rocks, and so does XSP.  I want this thing
> > to rock everyone's world.  I want this project to be so good and so
> > compelling that it would be completely obvious that in order to
> > plunk down money for an inferior framework would be ludicrous
> > to even Dilbert's boss.
> 
> :)
> 
> > Unfortunately, this sticky point is going to give ammunition to anybody
> > who is trying to protect their own pet project saying, "see Cocoon isn't
> > a real servlet...."
> 
> see, Cocoon isn't a real servlet :)
> 
> Well, that's basically true, anyway.
> 
> > <important-disclaimer>
> > Do not take the above paragraph to mean anything against what is
> > already in Cocoon.  Do not take offense at the content--I am merely
> > making a point.
> > </important-disclaimer>
> 
> Sure, no problem..
> 
> > The current version of XSP in C2 still has carried over some design
> > constraints from C1.7.x that I think should be done away with.
> 
> Ok, the main constraint is Java 1.1, if we remove that, all classloading
> problems are instantly removed and we can have our own beautiful
> classloader with all fancy strings attached.
> 
> If not, there is no way out: you have to modify your classpaht.
> 
> > I am
> > trying, as best I can to help C2 blow the socks off of everybody who
> > has used C1.  Those of you who spend a fair amount of time in the
> > Cocoon-users list *know* that one of the sticky points is setting up
> > C1 correctly with XYZ servlet engine.  There is always the problem
> > of where to stick the jars and which classpath to set, and the inevitable
> > issues with classpath ordering and the multiple XML parsers out there.
> 
> The installation procedure should be improved, I'm totally with you on
> that. "how" is the real issue.
> 
> > We have the potential to be able to aleviate 9 out of 10 questions by
> > making C2 behave as a servlet.  I want to be able to upgrade from
> > C2.0 to C2.1 without restarting my web server.
> 
> Oh, shit, that's a nasty one :)
> 
> > Am I making any sense here?
> 
> Sure you are.
> 
> Here are my reasoning:
> 
> 1) this project voted to keep C2's core Java 1.1 compatible and allow
> components to require Java 1.2. So, it's XSP a core component?
> 
> 2) C2 core would greatly benefit from requiring Java 1.2 (to be entirely
> honest, I love Java 1.3 Proxies, but we can go along without them)
> 
> 3) Tomcat-next will require Java 1.2 since Servlet 2.3 will require it
> directly from the spec.
> 
> 4) The only reason for being Java 1.1 compatible is lack of a good BSD
> JVM (which is also recognized as most voted Java bug on the bugparade)
> 
> If we aim for Java 1.2 and Servlet 2.2 everything becomes incredibly
> simple and all stupid hacks go away.
> 
> So, what the hell, I propose we take this direction.

I'm on the side to have a simple installation in a servlet 2.2 container
(war file and everything in WEB-INF/lib). I also think XSP is a core
component. But to achieve both I vote +1 for Java 1.2

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message