I think the changes will be too big to add before the 3.3 freeze. I like
your alternative and will start bashing the jsp->java files to get something
optimal before changing the jasper34 generator code. I'll let you know when
I have something that looks interesting so that it can be discussed
before taking the time to modify the generator code.
-casey
[EMAIL PROTECTED] wrote:
>
> Casey,
>
> We hope to freeze 3.3 for a release in the next weeks. If you feel the
> changes are reasonably small and will not create problems - you can still
> do it.
>
> What about:
>
> 1. We copy the code from 3.3 as it is in jasper34 area ( except that we
> rename the package ).
>
> 2. We make sure it builds and runs in 3.3 - with a minimal set of changes:
> - copy jasper34.jar in lib/container
> - edit server.xml and replace <JspInterceptor> with <JspInterceptor34 >
>
> 3. You can start making the optimizations, and I can start doing the
> refactoring, making sure we keep everything functional.
>
> 4. In time we can merge the changes from 4.0, add the new interfaces
> proposed by Mel, add a new generator and so on - while making sure the
> tests are passing and jasper is stable.
>
> This is unlikely to be finished before 3.3 is released, but we can make
> sure we keep passing all the test suites and we can release milestones of
> jasper34 for who needs the performance enhancements.
>
> When the code is ready we can make a 3.3.1 release and replace the old
> jasper ( and same for when ajp14 is ready ).
>
> What I tried in proposals/jasper34 is just wrong and against the basic
> ideas of "evolution" - and I realize that.
>
> Just give me 2 days, I need to finish with xalan ( we just had the 2.1.0
> release and I need to finish my work on it )
>
> Costin
>
> On Wed, 23 May 2001, Casey Lucas wrote:
>
> >
> > Costin & Craig,
> >
> > I agree with both of you. The optimizations that Craig mentioned are
> > exactly the ones that I was hoping to add. Yes, the least fun part
> > will probably be adding to the existing generator code. But, until a
> > new generating architecture is in place, I think it would be good to
> > go ahead and try to add the code to the existing jasper.
> >
> > When the next gen jasper gets a lot of momentum, we can add the
> > tag related optimizations to it.
> >
> > -casey
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > On Wed, 23 May 2001, Craig R. McClanahan wrote:
> > >
> > > > I know Costin loves evolutionary change :-), and it's certainly a valid
> > > > approach to Jasper.
> > > >
> > > > But there is also another approach we should consider - a green-field
> > > > recoding of at least some of the major components (conforming to an
> > > > agreed-upon overall architecture, of course).
> > >
> > > > NOTE: For most of the rest of the overall problem (the PageContext
> > > > implementation, how Jasper fits in with the servlet container, and so
> > > > on) evolution is probably a very reasonable strategy. On the compiler,
> > > > though, I'm not so sure.
> > >
> > > If we are talking about the compiler ( or code generator ): I partially
> > > agree, the current architecture will get a lot of pressure from more
> > > complex optimizations or tricks.
> > >
> > > But before we can even start to change the generator we need to do the
> > > initial refactoring and get the other components in order ( runtime, etc).
> > > We can also get some optimizations in, and use that to learn what's needed
> > > from a new generator architecture.
> > >
> > > I just don't think the new generator can happen in a 3.4 space - my goal
> > > is just to enable an effort to rewrite it, and gather as much information
> > > as possible about it's requirements.
> > >
> > > In any case - whatever happens in the current generator with regard to
> > > generated code will still be usefull for any new generator architecture.
> > > And if certain optimizations can't be done - that's even better, because
> > > it would help us understand what's needed.
> > >
> > > I had big hopes for an XSLT based generator, and I still think it may be a
> > > good way to implement the code generator - and I hope to hear other
> > > ideas.
> > >
> > > Costin
> >
