; > From: Alex Fernández [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 30, 2001 2:49 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
> >
> >
> > Hi Steve!
> >
> > Steve Downey wrote:
>
On Fri, 30 Mar 2001, Mel Martinez wrote:
> I don't have the time to do much more than that! That
> Damn Day Job(tm) keeps getting in the way! :-)
Yea, believe me, I know what you mean, you're not the only one :-)
Costin
--- [EMAIL PROTECTED] wrote:
> On Fri, 30 Mar 2001, Mel Martinez wrote:
>
> > --- Steve Downey <[EMAIL PROTECTED]>
> wrote:
> >
> > I must admit to not being totally sure whether
> > co-opting the current 'Constants' and 'Options'
> class
> > families is the best naming for this, but they do
> >
On Fri, 30 Mar 2001, Mel Martinez wrote:
> --- Steve Downey <[EMAIL PROTECTED]> wrote:
>
> I must admit to not being totally sure whether
> co-opting the current 'Constants' and 'Options' class
> families is the best naming for this, but they do
> clearly indicate the difference in scope. I coul
--- Steve Downey <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> >
> > On Thu, 29 Mar 2001, Mel Martinez wrote:
> >
> > > activities that should be orthogonal. The only
> > > dependency should be that the Compiler is a
> consumer
> > > of the products of
mentation for a new
combination or style isn't that excessive.
> -Original Message-
> From: Alex Fernández [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 30, 2001 2:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Hi Steve!
Steve Downey wrote:
> Perhaps a Kit pattern is in order?
Wow, a Kit pattern. I never heard of that one (or never got that far in
the Patterns books :)
Is it a standard one? If so, I'll check it out later at home.
Un saludo,
Alex.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 29, 2001 3:04 PM
> To: [EMAIL PROTECTED]
> Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
>
>
> On Thu, 29 Mar 2001, Mel Martinez wrote:
>
&g
On Thu, 29 Mar 2001, Mel Martinez wrote:
> activities that should be orthogonal. The only
> dependency should be that the Compiler is a consumer
> of the products of the Mangler.
+1
> I think the problem starts with the idea to make a
> JspLoader that 'loads JSP files just as if they were
Jsp
--- Steve Downey <[EMAIL PROTECTED]> wrote:
>
> doing some static analysis, based on class use of
> other classes, it looks
> like this constellation of classes could easily be
> factored out into their
> own package:
>
> org.apache.jasper.compiler.Compiler
> org.apache.jasper.compiler.Mangler
On Thu, 29 Mar 2001, Steve Downey wrote:
> doing some static analysis, based on class use of other classes, it looks
> like this constellation of classes could easily be factored out into their
> own package:
>
> org.apache.jasper.compiler.Compiler
> org.apache.jasper.compiler.Mangler
> or
> -Original Message-
> From: Mel Martinez [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 6:41 PM
> To: [EMAIL PROTECTED]
> Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
>
>
> Wow! I go away for a day and there is some gr
On Wed, 28 Mar 2001, Matthew L Daniel wrote:
> > ( BTW, my interest is more in the jsp->java convertor area, I would be
> > interested to try a more customizable generator that would use XSL
> > templates, but that depends on a modularization and refactoring that would
>
> I remember back
m 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 A
On Wed, 28 Mar 2001, Matthew L Daniel wrote:
> > ( BTW, my interest is more in the jsp->java convertor area, I would be
> > interested to try a more customizable generator that would use XSL
> > templates, but that depends on a modularization and refactoring that would
>
> I remember back i
> ( BTW, my interest is more in the jsp->java convertor area, I would be
> interested to try a more customizable generator that would use XSL
> templates, but that depends on a modularization and refactoring that would
I remember back in the "old days" when the JSP spec actually contained a
ey <[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
inez
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 Propo
> -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:
>
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.
>
Yes - from my experience, this was the problem deploying Jasper in another
container.
Tim Julien
HP Middleware
-Original Message-
From: Steve Downey [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 28, 2001 11:33 AM
To: [EMAIL PROTECTED]
Subject: RE: TC3.3 Proposal: Refactoring
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> So far jasper has been one of the most stable pieces on
> tomcat ( most bugs
> I know about are related with the interfacing between jasper and the
> container ). And it has a huge potential for performance
>
On Tue, 27 Mar 2001, Craig R. McClanahan wrote:
> > The glass is half-full as well - because at least with
> > the servlet api it is _possible_ to implement those
> > services portably and thus provide a portable JSP
> > compiler.
> >
>
> When Tomcat 4.0 was created, one of the goals was to eli
On Tue, 27 Mar 2001, Mel Martinez wrote:
>
> The glass is half-full as well - because at least with
> the servlet api it is _possible_ to implement those
> services portably and thus provide a portable JSP
> compiler.
>
When Tomcat 4.0 was created, one of the goals was to eliminate all the
Jas
On Tue, 27 Mar 2001 [EMAIL PROTECTED] wrote:
> - initialization - how can you pass init parameters to the jsp ? This is
> one of the worst hacks and source of counteless problems ( AFAIK - I
> couldn't find any clean way to do that )
>From the application developer's perspective, you do this:
> > - JspServlet must manage the servlet lifecycle - the container can no
> > longer treat jsp-generate-servlets the same as regular servlets
> >
>
> This is a limitation of the servlet api and thus the
> lack of access to a consistent set of servlet engine
> features necessary for full servlet
--- [EMAIL PROTECTED] wrote:
> >
> > 1) I don't off-hand know of any other generalized
> way to make a portable JSP
> > compiler that can be plugged into any servlet 2.2
> engine other than as a
> > servlet. I'm not sure how that limits us
> feature-wise, other than the fact
> > that it adds a
>
> 1) I don't off-hand know of any other generalized way to make a portable JSP
> compiler that can be plugged into any servlet 2.2 engine other than as a
> servlet. I'm not sure how that limits us feature-wise, other than the fact
> that it adds a layer of indirection between the request on th
--- [EMAIL PROTECTED] wrote:
> Hi Mel,
>
> In my view, jasper is composed from at least 5 big
> components:
>
> 1. The jsp->java translator.
>
> 2. The java->class compiler
>
> 3. The Mangler ( managing name mappings )
>
> 4. Runtime - that should be completely independent
> of all other p
--- Glenn Nielsen <[EMAIL PROTECTED]> wrote:
> I have made some changes to the Jasper code in
> Tomcat 4 that
> you might want to look at.
>
I will definitely be looking at TC 4.
> 1. In general the Java SecurityManager
> implemenation in Tomcat 4
> and Jasper has significant improvements and
--- Steve Downey <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March 26, 2001 1:08 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: TC3.3 Proposal: Refactoring
On Mon, 26 Mar 2001, Steve Downey wrote:
> > 1. The jsp->java translator.
> >
> > 2. The java->class compiler
> >
> > 3. The Mangler ( managing name mappings )
> >
> > 4. Runtime - that should be completely independent of all
> > other pieces,
> > since jasper-generated servlets should run
> 1. In general the Java SecurityManager implemenation in Tomcat 4
> and Jasper has significant improvements and is much cleaner.
True. The SecurityManager in 3.3 is working fine for now ( Glenn is also
the main author for the 3.x sandboxing ), with all watchdog passing - but
a refactoring will
I have made some changes to the Jasper code in Tomcat 4 that
you might want to look at.
1. In general the Java SecurityManager implemenation in Tomcat 4
and Jasper has significant improvements and is much cleaner.
2. Jasper class loading is much simpler in the Tomcat 4 version.
It uses a singl
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 26, 2001 1:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
>
>
> Hi Mel,
>
> In my view, jasper i
Hi Mel,
In my view, jasper is composed from at least 5 big components:
1. The jsp->java translator.
2. The java->class compiler
3. The Mangler ( managing name mappings )
4. Runtime - that should be completely independent of all other pieces,
since jasper-generated servlets should run withou
As hinted at last week, I'd like to propose
refactoring some of the classes in Jasper to improve
the OO model a bit, make maintenance/extendability a
bit easier and hopefully help the performance a bit as
well for those of us using jasper as the JSP engine in
other servlet engines (other than tomc
37 matches
Mail list logo
