Re: [Vote] JetSpeed joins the party?

[James Todd <ja...@eng.sun.com>]

Pierpaolo Fumagalli wrote:
> 
> James Todd wrote:
> >
> > in tomcat land i'd like to see the use of any one
> > parser over another to be pluggable ... with the
> > option of using projectX amongst others. if we do
> > this correctly, it should be trivial to perform
> > performance tests and the community at large will
> > benefit as they'll be able to plug in their favorite
> > lib of choice.
> >
> > should be pretty trivial.
> >
> (this should really be discussed in jakarta general)...
> 
> Can you please explain? My knowledge of the english language is not so
> deep :-)

sure. servlet 2.2 requires WEB-INF/web.xml based deployment
descriptors. the current ri (tomcat) uses ProjectX as the
parser and, optionally, a validator. within the servlet side
of tomcat, ProjectX is referenced by two files. it should be
fairly easy to create an abstraction layer by which the parsing
and/or validating of the xml data is independent of the actual xml
parsing/validating implementation, through delegation or
some such strategy.

if we get to this point it will be trivial to drop in one
parser and run the app to compare the results of a similiar
run against another parser. if we want to evaluate another
parser implemenation for performance, compliance, fixes or
other reasons it should be easy to reconfigure and rerun the
app.

as systems grow, this sort of abstraction will help
aggregated projects take advantage of the latest/greatest
features of any subsystem without necessarily being
held hostage to one implementation over the other.

that's how i see it anyways.

hope this helps,

- james

> 
>         Pier
> --
> Pierpaolo Fumagalli - IBM Center for Java Technologies
> <ma...@us.ibm.com>   <ma...@apache.org>
> ======================================================
> IBM Notes ID:  Pierpaolo Fumagalli/Cupertino/IBM@IBMUS
> Telephone: +1 (408) 777-5838 - IBM Tieline #: 240-5838
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org