Mel,
Regarding the names and the scope of the changes.
If we are going to do some refactoring ( and that's going to require
work and testing anyway), then we should do it on a slightly broader
scope, not only local to the servlet interface.
Instead of org.apache.jasper.servlet33, I would suggest something like
org.apache.jasperX.*, and have separate packages for the different
components that we identify ( see my proposal for 5 components - some of
them like the java->class compiler or even the mangler are
general-purpose for any scripting system and could even be part of the
an util package ).
What would be really great is to coordinate this with someone on jasper4.0
side - we should be able to share most components, except probably few
classes in the JSP generator ( and of course the runtime - which
implements security and is heavily dependent on jsp1.2 ).
Most of the parser and generator is identical, and I think we would all
benefit by sharing as much as is possible.
In other words - it would be great to try to make this proposal not
limited to jasper33 servlet, but a jasper7.3 ( 4.0 + 3.3 ) proposal,
refactoring and combining the 2 ( now divergent ) versions ( while keeping
and increasing the ability to have alternative implementations for all
components - like the runtime and some of the generator ).
Of course, it's your choice - I will support a limited refactoring if
that's what you want, but I think we should at least try to combine our
efforts and re-unite ( at least ) jasper. Then all the optimizations (
like tag pooling ) and fixes and the sandboxing will be common for most
part, with clear container-specific modules ( that would also prove and
show how other containers can use jasper ),
Costin
On Wed, 28 Mar 2001, Mel Martinez wrote:
> Wow! I go away for a day and there is some great
> discussion on this thread!
>
> I've saved everybody's comments and will incorporate
> them into the proposal, which I will be working on
> tonight to formalize. When I've got it ready for
> review, I will put a proposal doc and any related
> files in html form into
> .../jakarta-tomcat/proposals/tomcat33/
>
> >From the discussion I think it is safe to say that the
> goals of this refactoring are:
>
> 1) focused primarily with cleaning up the object model
> of the org.apache.jasper.servlet package (i.e.
> JspServlet) so that we can reduce coupling between
> JspServlet and the core of Jasper.
>
> 2) we will try to increase separation between the
> JspServlet entry point into jasper from the various
> life-cycle services (class loading, mangling,
> compiling, etc) to make those services both
> replaceable for JspServlet and also reusable for
> alternate entry points, such as JspC or
> JspInterceptor.
>
> 3) we will try to clarify classpath and init-params
> configuration issues.
>
> 4) despite all this, we will strive to improve
> performance by reducing the call stack and by
> utilizing caching where possible.
>
> 5) fix more bugs than we introduce.
>
> I should have a first-draft class diagram and probably
> initial java code ready for the proposal tonight or
> early tomorrow.
>
> I tentatively propose to introduce the changes through
> the package name 'org.apache.jasper.servlet33', unless
> anyone objects AND has a better package name. :-)
>
> Cheers,
>
> Dr. Mel Martinez
> G1440, Inc.
>
>
> --- Steve Downey <[EMAIL PROTECTED]> wrote:
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, March 28, 2001 3:46 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: TC3.3 Proposal: Refactoring
> > org.apache.jasper.servlet
> > >
> > >
> > > On Wed, 28 Mar 2001, Steve Downey wrote:
> > >
> > > > The second most common cause of bugs in Jasper
> > is confusion
> > > over when to use
> > > > File.separator and when to use '/'. It's hard to
> > keep track
> > > of, since Jasper
> > > > does deal with both files and URIs. And the File
> > methods are used to
> > > > regularize some URIs.
> > > >
> > > > Another reason to refactor.
> > >
> > > I would say this is also part of interfacing the
> > jasper with the
> > > container, and not core to the jsp parser and
> > jsp->java
> > > convertor ( which
> > > in my opinion represents the "core" of jasper ).
> > >
> > > There is the problem of importing jsps ( and few
> > other cases
> > > where files
> > > are needed), but again that's related with the API
> > that is
> > > needed to plug
> > > jasper into a ( cooperating ) container.
> > >
> > <SNIP>
> >
> > ... importing jsp text, determining the file to
> > write java to, finding tag
> > library descriptors, finding the directory to direct
> > the java compiler to
> > write class files to...
> >
> > Files are inherent, at least as long as javac
> > insists on having files. I
> > would love to be able to compile a stream, or array
> > of streams, but that's
> > not happening near term.
> >
> > Almost everything else uses URI's to refer to
> > things. So, for the most part,
> > jasper should not be looking at, or using, files.
> > Streams, yes, as in
> > getResourceAsStream, but mostly not Files. Most
> > current uses of File are
> > wrong, and other parts of Jasper try to compensate.
> >
> > Actually, I don't think that importing needs Files.
> > It should be able to use
> > getResourceAsStream. That may need to work with
> > Files, but that's something
> > that the container deals with, not Jasper.
> >
> >
> > <><><><><><><><><><><><><><><><><><><><><>This
> > electronic mail transmission
> > may contain confidential information and is intended
> > only for the person(s)
> > named. Any use, copying or disclosure by any other
> > person is strictly
> > prohibited. If you have received this transmission
> > in error, please notify
> > the sender via e-mail.
> <><><><><><><><><><><><><><><><><><><><><>
>
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/?.refer=text
>
