[EMAIL PROTECTED] wrote:
> On Tue, 10 Apr 2001, Greg Wilkins wrote:
>> Excellent - That sounds much easier for us to keep in sync with.
>> Still, it would be good to have a maintainer to step forward and help
>> us with the transition.... It may be good for somebody on the development
>> team to have another servlet container to test against?
>
> Greg, I was hoping for the reverse - have jetty developers help with
> jasper refactoring.
We don't have anybody on jetty that has really got into the internals
of jasper, so we are not in the best position to be actual contributors.
However as this refactoring is exactly what we are looking for, the Jetty
developers may well be your number one alpha testers!
> I will download the code and take a look anyway - the part I'm interested
> in is allowing jasper to take advantage of servlet container
> features ( and avoid double mapping and buffering, do better reloading,
> etc), and looking at other containers can only help.
Remember our branch is an orphan child. So our changes may indicate
requirements, but may not represent the best approach :-)
> This is a very interesting ( and not easy ) project - we are still in the
> planning stage, and getting people with experience in other containers
> will help us a lot ( and I'm sure the end result will be much better ).
I think we will try to use the refactored jasper both as a servlet and
potenitally as a Jetty HttpHandler (our own extension component), so we should
give it a good shake down.
> That's reasonably easy to do ( in 3.3 workspace the Log is just an
> independent class ,with no dependency on tomcat internals - except that
> it's in tomcat.util.log package ).
The only hestiation I have with that, is packaging. It is likely that the
tomcat.util.log class will be normally packaged in a tomcat.jar. If
you start copying classes from jar to jar, then you can end up with duplicates
and if people start sealing jars, everything breaks down.
So to my way of thinking, using one class - even an interface - from another
jar, may as well be a dependancy on every class in that jar.
I would prefer if the jasper toolkit described it's own logging interface
as part of the toolkit - the default implementation could be the tomcat log.
Furthermore, I think that the jasper log service API may need to be richer
than a standard log API. One of the most common complaints we get with
JSP is that it either show too much or not enough details when something
goes wrong. It may be that the logging API should distinguish between
exceptions and errors coming from the generation process from those
from the running of the JSPs. Normally this would not be a problem,
but I think that jasper sometimes hides the real exception from the
servlet container (which should log it as any other servlet exception).
A custom jasper logging API should allow different classes of logs
to be identified and customized for JSPs. How these are mapped to
the underlying log mechanism is installation specific.
> What I was thinking is slightly different - i.e. use a Event/Listener
> model for notifications ( that would completely decouple jasper from the
> logger, and would allow some nice tricks ).
That would also do the trick. We're listening....
> Replacing DOM with SAX would be great, and making it a separate component
> would be even better ( the container may provide the information without
> requiring a second parsing ).
>
> For small footprint I was thinking ( for tc3.3 ) to generate a serialized
> version of web.xml, that would allow an embedded tomcat to work without
> requiring a parser ( assuming pre-compiled jsps ).
>
> Do you have this working ? Can you contribute it (back) to jasper ?
For now we have tied the jesper XML parsing to our own XmlParser wrapper
for JAXP parsers. It has it's own mini dom light document structure and it
allows extra ContentHandlers to register interest in particular tags, so
they are called back while the main parsing is within the scope of that tag.
This is all very Jetty specific and really is the mechanism that we would
use within our own implementation of the jasper xml toolkit component that
provides web.xml content.
>
>> The classloading configuration is a bit ugly. I'm not sure how this
>> can be cleaned up, but currently in Jetty we have hard coded detection of the
>> JspServlet so that the context classloader can be set as an InitParam. It
>> would be better jasper could do a better job of trying to locate the context
>> classloader itself.
>
>
> Not easy - unless URLClassLoader is used ( or per thread class loader ? ).
> This is a big issue for JspServlet, also the work dir and reloading,
> but are not big issues if "cooperating" jasper+containers.
Except that URLClassLoader is probably more trouble than it is worth.
It makes reloading difficult (I guess JSP checks the source anyway?) and
the fact that most JVMs have a broken JarURLConnection that does not
see modified jars makes this even worse!
As Mel said that he does not want to dive into the guts of jasper
just yet, changing the jsp loaders is probably a bit much to ask for
now.
However, at the very least the jasper toolkit should be able to
ask for the parent loader to use. Then implementations could either
take this from attributes or container specific mechanisms.
> tomcat-dev is the list we use ( for jasper, tomcat 3.3, tomcat4.0, flames,
> etc :-).
MMmmm I'll try to monitor this, mail filters allowing - but if there are
any jasper specific postings that you really would like feedback from jetty
developers on, please cross post to [EMAIL PROTECTED]
And finally - if there is anybody still listening who wants to help out and
learn more about Jasper. Jetty still need a jasper maintainer in the short
term. It could be the ideal way for somebody to skill up into contributing
to the real thing!
regards
