cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: What are the XSP design goals?
Date Fri, 02 Jun 2000 16:23:29 GMT
Berin Loritsch wrote:
> Mike Engelhart wrote:
> > on 6/2/00 7:44 AM, Berin Loritsch at 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.

> 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*.

> 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.

Note for the *BSD folks: lowering the fever doesn't automatically cure
the disease.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message