Greg,
I am writing the jasper34 refactoring proposal. I am
late on getting it checked in because I have been
distracted by other issues (job hunting, for one). I
am nearly ready to submit it though. It is currently
in the form of a UML class model generated with
Together. I will submit it in html form inside the
tomcat 3.3 proposals directory for review.
The design philosophy used is to create a 'toolkit' of
factory and accessor methods for creating and
accessing services required by Jasper adapter
implementations such as JspServlet, JspC and
JspInterceptor.
The base toolkit class, JasperToolkit has one main
static method : createToolkit(..) that allows an
implementation to retrieve an instance of the desired
toolkit subclass. It then uses the instance methods
of the retrieved toolkit to access the desired
services. The base JasperToolkit class is being
written to support a common pattern by which all of
the common service implementations can easily be
specified via configuration properties. A subclass,
specific to a particular implementation of Jasper can
override any or all of the factories to allow
specification of the service implementations using
runtime information such as init-params or whatever.
Importantly subclasses can also extend the toolkit to
provide methods for services that are particular to
that jasper implementation. And finally, subclasses
can apply optimization and life-cycle management of
service objects as appropriate for the particular
implementation.
While it took me that big, long paragraph to explain
it, it is actually quite simple to use and extend.
This is just an abstract factory, after all.
The 'common' services, that might potentially need to
be overridden by a particular adapter, that I've
identified to include in the base JasperToolkit so far
are:
toolkit -- the toolkit subclass used
jspfactory -- the JspFactory implementation
pagehandler -- handles the page life cycle
requesthandler - handles the request life cycle
jspcompiler -- compiles the .jsp to .java
javacompiler -- compiles the .java to .class
jspmangler -- calculates class, package & file
names
modificationchecker -- checks whether to recompile
cache -- provides object caching for performance
Thus, all of the above can be easily re-implemented
and replaced, providing easy customization of Jasper.
To use this toolkit facade, a jasper adapter needs to
be rewritten to access these services through the
toolkit. This is done quite simply like so:
JspServletToolkit tk = (JspServletToolkit)
JasperToolkit.createToolkit("JspServlet");
// ....
JspMangler mangler =
tk.getJspMangler(jspUri,outputDir);
String javafile = mangler.getJavaFileName();
// ...etc...
I will be supplying a new version of JspServlet to use
this as a first cut. One extention that the
JspServlet will provide is a factory for generating
appropriate class loaders (something not needed by all
implementations) and to use init-params to specify
service implemenations during run-time. This will all
be done 'separately but in parallel' to the current
JspServlet implementation so as to not break anything.
The model specifically stays away from modifications
to Jasper's parser/compiler behavior because this
effort is about refactoring the adapters first.
It sounds like you would like to include the XML
parser in the list of 'replaceable' parts. I had not
thought to try to address that (yet) because that gets
into the internals of the jasper compiler itself (none
of the above does). This model will easily support
the idea of adding a factory for that service and then
rewriting the jasper compiler to retrieve the XML
parser via the toolkit, so I don't see any problem
with adding that. However, it requires a bit of
diligence to derive the appropriate interface or
facade for that service and I don't want to put any
time into that just yet. Once I get the proposal
submitted, and folks have had a chance to understand
the pattern, I would welcome any suggestions on
additional services to add, whether to the base
toolkit or whether they belong only in subclass
toolkits.
Regarding the issue of whether Jasper should re-parse
the web.xml file: This gets to the heart of why we
need this refactoring. In the case of running Jasper
inside Tomcat, we can easily factor in the fact that
the servlet engine has already read the web.xml file
and implement an adapter to leverage that info in our
use of Jasper. That is done with JspInterceptor.
However, for those of us using Jasper as a stand-alone
jsp compiler inside other servlet engines (via
JspServlet), the problem is that the Servlet API
provides no way to carry that information across to
JspServlet in a standard way, reliable when using
other servlet engines. Further, it is not clear that
the JspC implementation of Jasper even NEEDS web.xml
information. Thus, it is clear that another useful
service to abstract through the toolkit is going to be
the access to the web.xml info. Done properly, this
service could be provided by a Tomcat-supplied object
when running within tomcat, but implemented standalone
when running in some other container. This will be
one of the next services we will try to abstract into
the toolkit model. It seems obvious that it relies on
XML, though so it may be useful to solve the XML
service refactoring first, though.
Regarding Logging: This one might be pretty easy to
decouple through the toolkit. I'll look into it.
The beauty of this is it should be pretty easy to add
services to the toolkit (or to a subclass) one at a
time and then gradually adopt useage in the actual
adapter implementation.
I hope this is helpful.
Mel
Dr. Mel Martinez
Senior Software Architect
G1440, Inc., http://www.g1440.com
[EMAIL PROTECTED]
--- Greg Wilkins <[EMAIL PROTECTED]> wrote:
> Costin,
>
> [EMAIL PROTECTED] wrote:
>
> >...
> > The end result will be a more portable jasper -
> that will be usable in
> > multiple containers with minimal pain ( and with
> enough hooks to allow the
> > container to provide specific features and
> optimizations ).
>
> 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?
>
>
> > It is not an easy project - and it would be great
> to get help, feedback
> > and sugestions from jetty developers.
>
> Ok - I'll give brief over view of the changes and
> ideas that we have at the
> moment.
>
> The first change we made was to provide a logging
> facade class, so that the
> link with tomcat logging could be broken. Jasper
> code makes logging calls
> on a Jasper class, which we have implemented to call
> the Jetty logging
> facility. This probably should be generalized so
> that a dynamically
> selected logging facade can be configured for JSP.
>
> Secondly we replaced the XML parsing with our own
> wrappers for a JAXP
> parser. As Jetty is targetted for small memory
> footprint systems, we
> wish to avoid DOM as it is too heavy weight when you
> consider it is often
> only used only to read a config file (once loaded,
> the DOM classes stay
> in memory). I think a generic jasper should
> probably only assume a JAXP
> parser in the environment and then only use the SAX
> elements of it.
>
> Another concern I have is that I don't think that
> jasper should be parsing
> the web.xml file itself. Consider an deployment in
> an EJB container that
> uses JSP, the web.xml may be parsed 3 times, once by
> the EJB container looking
> for ejb-ref tags, once by the servlet container and
> then finally by the
> JspServlet. I think Jasper should be written to
> allow a deployer to push
> this configuration into it. Initially it would have
> to have it's own pusher that
> did parse the web.xml file, but eventually it would
> be good to make a proposal
> to the servlet spec guys to come up with an API to
> allow a servlet container
> to export the parts of the web.xml it does not know
> how to handle.
>
> For example - the jetty/jboss integration module
> under development now registers
> for callbacks when the container parses ejb-ref
> tags.
>
> 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.
>
> Finally I also have a few half formed ideas of how
> to improve the generation of
> web.xml fragments by the pre-compiler, so that it
> pays better attention
> to existing jsp mappings in the existing web.xml.
>
> Is there a jasper specific mailing list that we can
> tune into to monitor
> your jasper efforts? or is it just the general
> tomcat dev mailing list?
> If nobody steps forward to help maintain
> jetty-jasper (I call it jesper :-)
> and transition to the new portable version, then it
> would be good to have
> a focused mailing list to monitor and contribute to.
>
> And just to end on a positive note... our users that
> have switched from our
> older versions to our jasper based version have
> reported positive
> feedback with regards to performance and stability.
>
>
> regards
>
>
> >
> > On Mon, 9 Apr 2001, Greg Wilkins wrote:
> >
> >
> >> The Jetty project is in need of a Jasper
> maintainer for it's cut of the
> >> Jasper JSP engine.
> >>
> >> Jetty is a opensource java HTTP server and
> servlet container (see http://jetty.mortbay.com
> >> or http://sourceforge.net/projects/jetty) It is
> intended to be small, fast, yet fully functional.
> >>
> >> For JSP handling, we have taken a branch of the
> jasper code. The branch was required
> >> as we need to decouple the logging and XML
> parsing from tomcat. However, this branch
> >> is now a little bit of an orphan and requires a
> maintainer to :
> >>
> >> + Keep it up to date with the latest jasper
> development.
> >>
> >> + Cleanup the current jetty integration -
> specially with regards to
> >> classloading, logging and XML parsing.
> >>
> >> + Feedback changes and suggestions that may
> make jasper more portable
> >> between servlet containers (this may require
> removal of Jetty dependancies
> >> that were added in place of tomcat ones).
> >>
> >> + Testing of the integration using watchdog.
> >>
> >> + Planning and executing the upgrade of Jetty
> from servlet 2.2 and JSP1.1 to
> >> 2.3/1.2.
> >>
> >> Anybody who can help with some or all of this
> will be warmly welcomed to the
> >> Jetty project.
> >>
> >> I'm not subscribed to tomcat-dev, so can
> responses be directed to
> >> [EMAIL PROTECTED] or
> [EMAIL PROTECTED]
> >>
> >> regards
> >>
> >
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~>
> > Secure your servers with 128-bit SSL encryption!
> > Grab your copy of VeriSign's FREE Guide,
> > "Securing Your Web site for Business." Get it now!
> >
>
http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/CxaWlB/TM
> >
>
---------------------------------------------------------------------_->
> >
> > For the latest information about Jetty, please see
> http://jetty.mortbay.
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
