The package naming solution I've opt'ed for in my own
enhancement to Jasper (which I'll gladly share) is to
derive package names that are related to the location
of the jsp relative to the server context. This is
simple, flexible and should avoid collisions.
Some implementation details are:
Configurable properties (loaded at startup and
available through an extention of the Constants
class):
- default JSP_PACKAGE root (i.e. 'jsp_servlet')
- PACKAGE_PREFIX string (i.e. '_')
I've then created an extention of JspCompilerContext
that adds method for deriving fully-qualified class
names for the generated classes. Among these are
assertion methods that force conformance with java
naming conventions (allowed letters, disallowed
keywords, etc) as described in the Java Language
Specification. These two methods are:
public static String manglePackageName(String s) and
public static String mangleNameLetters(String s)
Using these utilities and the above configurable
properties I then have methods that actually derive
the package and file names I need given a Jsp File.
public static String buildPackageName(File file)
let <i>file</i> correspond to the path
"foo/somedir/myfile.jsp", JSP_PACKAGE="jsproot"
and PACKAGE_PREFIX="x". In that case the return
value would be "jsproot.xfoo.xsomedir".
public static String buildClassName(File file)
let <i>file</i> correspond to the path
"foo/somedir/myfile.jsp", JSP_PACKAGE="jsproot"
and PACKAGE_PREFIX="x". In that case the return
value would be "xmyfile".
public static String buildJavaFileName(
String srcDir, String clsName)
calculates the absolute filename for the .java
file corresponding to the class clsName residing
under the directory srcDir. For example if
srcDir = "/opt/myapp/work" and
clsName="jsproot.xfoo.xsomedir.myfile" then
this returns the string
"/opt/myapp/work/jsproot/xfoo/xsomedir/myfile.java"
public static String buildClassFileName(
String clsDir, String clsName)
like buildJavaFileName() except result would be:
"/opt/myapp/work/jsproot/xfoo/xsomedir/myfile.class"
These static methods are used by the JspContext
(which extends JspEngineContext) to derive the
instance methods:
public String getServletClassName()
public String getServletPackageName()
public String getFullJavaClassName()
public String getServletJavaFileName()
public String getServletClassFileName()
The result is that you have a lot of control over the
naming used by the generated classes. Further, the
resulting .java files are much easier to find and look
at when debugging.
This mangling scheme does not do any incrementing
because a new JspLoader is used each time a JSP gets
reloaded dynamically. This package also provides a
mechanism for recursively detecting changes to
statically included JSP files.
I would like to make this code available for
integration into the jasper scheme but I will need to
rename the packaging to something acceptable. As I
mentioned before, the whole thing is implemented as an
extension to Jasper, not a rewrite. Implementation
should be as simple as re-registering the server to
send *.jsp files to the JspServlet class in my
extended package. A simplest option would to simply
put the seven classes involved into a separate package
like "org.apache.jasper.jspx".
I've tested this thoroughly using the WebLogicServer
as the servlet engine (bypassing their JSP compiler)
and also New Atlanta's ServletExecDebugger. I am
still setting up using the Tomcat Servlet Engine to
try and test it there. I am having some unrelated
difficulties there and will make a separate post on
that.
I've been working so far by extending the Jasper API
as it exists in the tc 3.2.1 release. How mature is
the 4.0 build? Should I
I welcome queries on this code (I will share snippets
in lew of the whole thing for now, if necessary) and
suggestions on how to become more involved with the
Jasper effort. Like all of you, my time is very
tight, but this subject area is very important to my
projects so I'd like to be involved as much as
possible.
Cheers,
Dr. Mel Martinez
Senior Software Architect
G1440, Inc.
[EMAIL PROTECTED]
--- Glenn Nielsen <[EMAIL PROTECTED]> wrote:
> "Craig R. McClanahan" wrote:
> >
> > Glenn Nielsen wrote:
> >
> > > "Craig R. McClanahan" wrote:
> > > >
> > > > [EMAIL PROTECTED] wrote:
> > > >
> > > > > When Jasper is run in a servlet
> > > > > container it no longer puts the class
> files in a package, they are now
> > > > > in the default package.
> > > > >
> > > >
> > > > As was discussed earlier on TOMCAT-DEV, this
> is going to cause
> > > > portability problems for people who use beans
> that are not in packages.
> > That's true, but Steve Downey also found the spec
> reference I couldn't find (in
> > Section 8.2 of the JSP 1.2 Proposed Final Draft).
> The JSP page class is
> > required to be in a package for 1.2.
> >
<snip>
>
> Ok, I'm convinced thanks to Steve and Craig. I'll
> put compiled jsp pages
> in the package "org.apache.jsp" (JspC can still
> specify a package). I
> will have to make some changes to the Jasper class
> loader to support this.
>
> Regards,
>
> Glenn
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
