--- [EMAIL PROTECTED] wrote:
> Hi Mel,
>
> As you know, we are on the same page on the main
> issue ( refactoring
> jasper), but there are few details... ( sorry for
> responding so late)
>
Don't be sorry - I'm going to take a day or to fully
respond to this and your other suggestions myself. I
am posting now to let you know I've got this post,
that I've read it, and that I have no problem with
just about everything you have to say below - if
anything, you are just proposing things I think I was
too shy to propose m'self. I will try to incorporate
the suggestions you make below over the weekend and
hopefully get a next phase in by monday. That version
should look a lot more assertive about some of the
statements you make below instead of simply implying
them.
I wish this was going faster but I've been dreadfully
busy lately, what with doing job interviews (and I'll
be traveling a bit this next week for more) and trying
to gracefully wrap up my current job so folk's still
like me long after I'm gone (documentation!!!!).
Also, I've had a bad NIC on my linux box at home
causing me no end of pain that I still haven't fully
resolved. Blah.. blah...
Some very brief comments:
> First, I think we need to agree on the goals :-)
> Your proposal is great,
> but I would like to make explicit the following ( at
> least ):
>
> - clean separation between runtime and compile time.
> This is important to
> resolve many class loader issues, to allow "real"
> self-contained wars (
> i.e. you include the runtime and jspc-compiled
> servlets - and that should
> run on any container without requiring the full
> jasper )
>
Agreed - this is a very important requirement, imho.
> - separated and pluggable code generator. This is
> very important for me,
> as I want to do some optimizations and try few ideas
> - and that shouldn't
> affect the stability of the main code. ( this is
> somehow included in the
> toolkig idea, but it's good to make it explicit ).
>
That's the whole idea of the toolkit - to make each
service a modular, separable piece. It would probably
be good to express that particular separation as a
particular goal of the refactoring.
> - "commons"-style components. Even if we'll use
> explicit interfaces for
> toolkit, we need to separate components as
> independent beans ( with
> setter/getter, and no/minimal inter-dependencies ).
> On top of this we can
> use the Toolkit or whatever internal interfaces are
> required by jasper.
>
I'll need to review the commons project to adopt any
standards that are in play there, but I don't see a
problem. This brings up some things I'll need to know
- I have code for some utilities that I can add to the
mix that are very powerful that have general usage
beyond just Jasper. These touch areas from io to
string handling to reflection and somethings I know
don't have equivalents already in the tomcat/jasper
codebase. How should we handle packaging such stuff?
I realize that the goal is to put generalized stuff
into the commons project, how do we leverage that from
Jasper? I.E. what exactly is the strategy for sharing
the commons stuff? Oh never mind - I'll go sit down
and do some reading.
> - Important. Merge of jasper40 and 33. It would be a
> waste of time to do
> this only for 3.3 or to re-implement jsp1.2 features
> later. We should
> think of this from start ( and it's not difficult -
> if we support separate
> runtime and generators ). That would require ( IMHO
> ) to start with 4.0
> and combine with 3.3.
>
I think this is a great idea. The codebase for Jasper
is not that different between 3.3 and 4.0. Might as
well do the refactoring just once.
> Long term, I am very interested in experiments with
> code generators ( like
> using XSLT, optimizations for buffers, etc ), so
> support for multiple
> generators ( with intial support for 2 - "classic"
> 1.1 and 1.2 ) is
> important.
>
> I do agree with the "toolkit" metaphor, in the sense
> of having multiple
> quasi-independent components. I think we should
> postpone adding the
> interfaces and the "Toolkit" classes until after the
> first round of
> refactoring - but that's not that important.
>
> If you agree with starting with jasper4 ( because
> it's more complex ), I
> can start doing an initial split in components.
>
I agree with using Jasper 4 code as the basis. What
I'd like is to first concentrate on making sure the
base set of services proposed represents a suitable
set of tools that are
1) comprehensive - cover all the bases needed by most
adapter implementations
2) cohesive - each service should be well-focused on
just particular thing
3) decoupled - there should be minimal or no
dependencies between services other than through the
abstractions released by the toolkits (i.e. the
interfaces)
The latter requires good interfaces or base abstract
classes to be built.
> I do have some experience with refactoring (
> tomcat3.0 -> 3.3 :-), and did
> few experiments with refactoring jasper ( but I'm
> still not happy with
> the result ).
>
>
I think the refactoring of tomcat 3->3.3 has taken tc3
a long ways. Jasper is seriously lagging and it is
time for it to catch up.
Later,
Mel
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
