tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Marius Garshol <lar...@garshol.priv.no>
Subject Re: Jasper optimizations
Date Tue, 28 Aug 2001 20:43:23 GMT

Hi there,

* cmanolache@yahoo.com
| 
| I'm working on it - probably next week I'll do another commit with
| the first part of the migration to SAX-based, which is the first
| step to add JSP1.2 features and cleans up even more.

Does this mean that you intend to completely separate parsing, tree
building, tree representation, and code generation, and to have a SAX
interface between the first two?

If so, I think that makes a lot of sense.

| We had many discussion on this, the visitor pattern is on the TODO
| list, as well as improving the modularity. There are some issues we
| don't agree on ( i.e. the use of XSLT to generate code, cocoon-style

Use XSLT to generate the code? I can see why you wouldn't want to do
that. 
 
| I would sugest jakarta-tomcat-jasper, the MAIN branch is frozen,
| it's very unlikely we'll do anything else in 3.3 jasper.

Uh, you'll have to go slowly here, I'm afraid. I'm not at all familiar
with the Tomcat sources.

So the MAIN branch in
jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/ is where
Jasper development is done right now?

| Jasper34 will be a module you can use to 'upgrade' jasper in 3.3.

Does this mean that there is a Jasper version somewhere else that goes
into Tomcat 3.3, and that the version I referred to above is what you
call Jasper34? Also, you plan to make this interface-compatible with
the Jasper in Tomcat 3.3?

* Lars Marius Garshol
|
|  - what do people think of my proposed solution? I know it is not
|    very nice, but as long as the code has to be generated from within
|    the current generators, which are called the way they are, I don't
|    see any better alternative.
 
* cmanolache@yahoo.com
|
| It seems some other people are working on that, 

Would these other people be Niko Schmuck? If so, he and I are working
in the same company, on the same project. If not, would be possible to
get in contact with them somehow, and find out what their plans are?

| I've got a sugestion to set all the constant fields when the tag is
| created ( including parent, etc) - that implies caching the whole
| tag set per page.

This is also what I had in mind, but as far as I can tell, it is not
exactly straightforward to make the current code generate variable
declarations in class scope for each tag, and then afterwards generate
the code that uses those variables.
 
| It makes sense - but it needs few more changes.

What changes? A redesign of the generator to use visitors? Or were you
thinking of something else?
 
* Lars Marius Garshol
|
|  - if I do make this change, what are the chances that it will be
|    accepted into the Jasper sources?
 
* cmanolache@yahoo.com
|
| For 3.3 - I don't think so.
| 
| For j-t-j/jasper34 - certainly.

OK, that's useful to know.

In that case I have an another question. I am working on a product
that needs to run with reasonable efficiency within Tomcat, and so I
need to a have a version of Tomcat where this runs fast enough by
October 1st.

What would you recommend that I do? Can I expect this optimization to
be in a stable version of Jasper 3.4 by then? Is there anything I can
do to make sure that it will be?

Also, where can I find the version of Jasper that is in Tomcat 3.3? In
the worst case I may have to add a temporary hack to that to make our
product perform.

* cmanolache@yahoo.com
|
| For j-t-c/jasper34: there is no such requirement for the compiler. I
| would like to keep the runtime 1.1 compatible - but if someone
| doesn't like that it's fine, we already added support for 'plugable'
| runtime.

No problem for me. I'm happy to write 1.1-compatible code as long as I
know that is a deliberate policy.

--Lars M.


Mime
View raw message