Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

["Craig R. McClanahan" <Cr...@eng.sun.com>]

glenn@apache.org 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. 
With this
change, such beans will work in Tomcat but not when the app is moved to
a different container that *does* put JSP-generated servlets into a
package.

The previous behavior (Jasper-generated servlets go into a package)
avoided this, because it essentially disallowed non-packaged beans.
Therefore, I prefer it.

(Also, I seem to remember a discussion on the expert group for JSP 1.2
that non-packaged beans and generarted classes should be disallowed, but
I have not yet located any reference to this in the 1.2 spec.)

Craig

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Paul Speed <Pa...@metrixpoint.com>]

Glenn Nielsen wrote:
> 
> "Craig R. McClanahan" wrote:
> >
> > glenn@apache.org 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.
> > With this
> > change, such beans will work in Tomcat but not when the app is moved to
> > a different container that *does* put JSP-generated servlets into a
> > package.
> >
> > The previous behavior (Jasper-generated servlets go into a package)
> > avoided this, because it essentially disallowed non-packaged beans.
> > Therefore, I prefer it.
> >
> > (Also, I seem to remember a discussion on the expert group for JSP 1.2
> > that non-packaged beans and generarted classes should be disallowed, but
> > I have not yet located any reference to this in the 1.2 spec.)
> >
> 
> If you check the code for JasperLoader you will find that it requires
> all classes to be in a package, the only class that does not have to
> be in a package is the JSP page itself.
> 
> Regards,
> 
> Glenn
> 

	So, you can't load unpackaged classes from a JSP page?
Even if they are specifically imported?

	-Paul Speed

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[cm...@yahoo.com]

> > > The new jasper makes it very easy to find and view
> > > the java source for
> > > a translated jsp page, it is located in
> > > work/somehost/someapp/some/context/path/MyJSP.java.
> > >
> > 
> > Does it not seem logical to assign a package to the
> > MyJSP class based on all or part of the above path?
> > 
> > This may seem like esthetics, I suppose.  Not
> > something we should get stressed about.
> > 
> > What you've done is a great improvement over what was
> > there.  Does it work with tc 3.3?
> > 
> 
> It should work for tc 3.x, but I don't have the time to
> back port it.

Well, it works in tomcat 3.x for some time ( too long ago to remember,
it's part of the original JspInterceptor :-)

The scheme is slightly different, but the ideea is the 
same ( using simpler and predictible names for the 
generated classes ). 



-- 
Costin

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Glenn Nielsen <gl...@voyager.apg.more.net>]

Mel Martinez wrote:
> 
> --- Glenn Nielsen <gl...@voyager.apg.more.net> wrote:
> 
> > There is no need for all this complexity to generate
> > a package name
> > in the new Jasper.
> 
> Hmmm... compared to the gobbledy-gook that was being
> done before, I'd hardly call what I did complex.
> Aside from options, all it does is very simply asign
> the JSP page a package name based on it's directory
> hierarchy and place the .java and .class files in same
> - this is consistant with strict java naming
> convention.
> 
>  The way jasper now loads jsp
> > pages, each page is
> > completely isolated from all other pages.  Every jsp
> > page compiled
> > could be a class named "org.apache.jsp.MyJSP"
> > without
> > any concern whatsoever about conflicts because each
> > individual page
> > has its own class loader.
> 
> Ah, I see, you avoid file-level conflicts by placing
> the generated code into separate directory paths, even
> though the package names (currently) do not reflect
> the directory locations.  Yup, that should work,
> although i wouldn't say it is any less complex and I
> don't think it is consistent with standard java
> package/directory naming conventions.
> 
> > The new jasper makes it very easy to find and view
> > the java source for
> > a translated jsp page, it is located in
> > work/somehost/someapp/some/context/path/MyJSP.java.
> >
> 
> Does it not seem logical to assign a package to the
> MyJSP class based on all or part of the above path?
> 
> This may seem like esthetics, I suppose.  Not
> something we should get stressed about.
> 
> What you've done is a great improvement over what was
> there.  Does it work with tc 3.3?
> 

It should work for tc 3.x, but I don't have the time to
back port it.

----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Mel Martinez <me...@yahoo.com>]

--- Glenn Nielsen <gl...@voyager.apg.more.net> wrote:

> There is no need for all this complexity to generate
> a package name
> in the new Jasper.

Hmmm... compared to the gobbledy-gook that was being
done before, I'd hardly call what I did complex. 
Aside from options, all it does is very simply asign
the JSP page a package name based on it's directory
hierarchy and place the .java and .class files in same
- this is consistant with strict java naming
convention.

 The way jasper now loads jsp
> pages, each page is
> completely isolated from all other pages.  Every jsp
> page compiled 
> could be a class named "org.apache.jsp.MyJSP"
> without
> any concern whatsoever about conflicts because each
> individual page
> has its own class loader. 

Ah, I see, you avoid file-level conflicts by placing
the generated code into separate directory paths, even
though the package names (currently) do not reflect
the directory locations.  Yup, that should work,
although i wouldn't say it is any less complex and I
don't think it is consistent with standard java
package/directory naming conventions.

> The new jasper makes it very easy to find and view
> the java source for
> a translated jsp page, it is located in 
> work/somehost/someapp/some/context/path/MyJSP.java.
> 

Does it not seem logical to assign a package to the
MyJSP class based on all or part of the above path?

This may seem like esthetics, I suppose.  Not
something we should get stressed about.

What you've done is a great improvement over what was
there.  Does it work with tc 3.3?

Mel


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Glenn Nielsen <gl...@voyager.apg.more.net>]

Mel Martinez wrote:
> 
> 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.
> 

There is no need for all this complexity to generate a package name
in the new Jasper.  The way jasper now loads jsp pages, each page is
completely isolated from all other pages.  Every jsp page compiled 
could be a class named "org.apache.jsp.MyJSP" without
any concern whatsoever about conflicts because each individual page
has its own class loader.  I will modify the current jasper class loader
to support putting the jsp pages in a package, but this is just to comply
with the JSP 1.2 spec.

All of the previous code in jasper to do all the package and class name
mangling was to overcome the limitations of how the Jasper class loader
for jsp pages was designed.

The new jasper makes it very easy to find and view the java source for
a translated jsp page, it is located in 
work/somehost/someapp/some/context/path/MyJSP.java.

Regards,

Glenn

----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Re: Tomcat Setup and configuration

[Mel Martinez <me...@yahoo.com>]

--- cmanolache@yahoo.com wrote:
> No, the overhead of using a servlet to invoke the 
> jsp page is significant ( at least in my tests 
> is shows a big difference ).
> 
> JspInterceptor does a simple thing - after the 
> jsp page is compiled to a servlet, the servlet 
> will be "registered" to tomcat ( as if it was
>  declared in web.xml ) and after that all 
> invocations to the jsp page are identical with
> invocations for servlets ( with one exception -
> jsp_precompile param must be read on each request 
> and if present, the request shouldn't be
> executed - that's the spec ).
> 

This almost implies some special behavior on the part
of the base HttpJspPage class (i.e. 'JspBase') used to
build the jsp servlet.  Is that so?  Is there any
problem for jsp pages that use the <%@page
extends=...> tag that don't extend
org.apache.jasper.runtime.JspBase but rather instead
(as per spec) simply implement
javax.servlet.jsp.HttpJspPage?

One of the things that really gripes me about the
WebLogic JSP servlet engine and JSP compiler is that
it has dependencies on the proprietary base class used
to generate JSP servlets. There are a lot of problems
with this so I hope that we don't send tomcat/jasper
down that road.

> 
> Try it yourself, send back the results :-)
> ( ab -n 10000 -c 80 http://localhost:8080/foo.jsp 
> with JspInterceptor in both modes ).
> 
> ( useJspServlet means JspInterceptor will do
> nothing,
> just return ).
> 
> ( of course, you can compare 3.3 with JspInterceptor
> with
> 3.2.1 without it - but there are other factors in
> that)
> 

It looks like I'll need to get the 3.3 version to try
this out! :-)

Thanks again, Costin.

mel

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

Re: Tomcat Setup and configuration

[cm...@yahoo.com]

> > status - there are 2 directories that can be set on
> > ContextManager,
> > one is "home" and the other one is "installDir". 
> > The env. variable is used to set home.
> 
> Where is this stuff documented?  There doesn't seem to
> be a DTD for server.xml.

It's still on the TODO list, but it'll happen only after we 
add the <ant> style config directives ( since that will
allow us to define all the attributes for JspInterceptor,
and different attributes for StaticInterceptor - each 
module has it's own properties ).

( same problems as in ant - user modules can't be coded
in the dtd ).

BTW, there is already code checked in that will read all
the .java code, and for all classes that extends BaseInterceptor
it'll extract the comments for the setters and generate 
a xml file. 

The .dtd generation can be easily automated ( the goal
is mostly to generate user documentation for modules
that is in sync with the real code )

> so you seem to be saying that one would set InstallDir
> -> TOMCAT_HOME and home -> APP_HOME.  I'll test that
> out.

Confusing, isn't it :-) ? 

( it's easy for me to criticize that - I wrote a lot of this 
code, so I'm not at risk to offend anyone else :-)

> These issues directly affect configuration management
> and are critical for managing complex deployments.  I
> don't think enough people take this area seriously
> enough (code features now, worry about deployment
> later!).

IMHO the biggest problem is that people deploying 
tomcat are not providing enough feedback and 
are not contributing back code or documentation.

Yes, we had requests for this kind of configuration
( with separate install and user dir ), and the 
intial code has been written way ago. I tried 
to do it as good as I could - but I can't guess 
what's easy and what isn't from a deployment 
perspective.

> Why exactly would it be 'much' slower?  Does that
> presume that a custom JspServlet would be inherently
> slower or that the default
> org.apache.jasper.runtime.JspServlet is somehow
> accellerated by something JspInterceptor does?

No, the overhead of using a servlet to invoke the 
jsp page is significant ( at least in my tests 
is shows a big difference ).

JspInterceptor does a simple thing - after the 
jsp page is compiled to a servlet, the servlet 
will be "registered" to tomcat ( as if it was
 declared in web.xml ) and after that all 
invocations to the jsp page are identical with
invocations for servlets ( with one exception -
jsp_precompile param must be read on each request 
and if present, the request shouldn't be
executed - that's the spec ).

( reloading is also done in the same way, using 
DependManager ).


> replacement and pre-load it in the CLASSPATH) would
> that be 'much slower' (even though it should not
> require setting the 'useJspServlet' tag since it would
> appear to be the regular default class)?  Just curious
> about your statement.

Try it yourself, send back the results :-)
( ab -n 10000 -c 80 http://localhost:8080/foo.jsp 
with JspInterceptor in both modes ).

( useJspServlet means JspInterceptor will do nothing,
just return ).

( of course, you can compare 3.3 with JspInterceptor with
3.2.1 without it - but there are other factors in that)

( as developer I do this kind of tests quite often 
to track if the changes are affecting the performance,
and everyone should do it once in a while )


> processing servlet (or any default servlet) with no
> more work than changing a line in a configuration
> file.  It sounds like 3.3 brings this ease in the
> JspInterceptor.

Well, it is possible in 3.2 also, but you need 
a special module that will set the jsp implementation.

It's not hard to do, but it's not there by default.
( I sent to the list one that changed jasper settings,
you just need to add few lines to change jasper with 
a different one). The module will do nothing else,
just alter some settings - you add it to server.xml.


> I'm pretty intimate with the Jasper API, but still
> learning the Tomcat API.  I'm still working on
> understanding how the Connector and Interceptor
> patterns are implemented.

A good news - in 3.3 there is no Connector API :-)
( the Connector is just a regular module )

( well, we are still far away from the rafinaments 
in Apache 2.0 where even the threads are managed by a 
plugable module - but the model for modularization
is close )


-- 
Costin

Re: Tomcat Setup and configuration

[Mel Martinez <me...@yahoo.com>]

--- cmanolache@yahoo.com wrote:
> 
> Ok, this is a clear example of what's wrong with the
> current
> status - there are 2 directories that can be set on
> ContextManager,
> one is "home" and the other one is "installDir". 
> The env. variable is used to set home.

Where is this stuff documented?  There doesn't seem to
be a DTD for server.xml.

> 
> If one is set and the other not - both share the
> same value.
> 
> InstallDir is the one used for jar files ( and all
> "shared" files ).
> home is supposed to be used for the local instance.
> 
> ( the model is again a shared installation -
> /usr/local or /opt/tomcat
> and each user having it's own config and set of
> applications ).
> 

so you seem to be saying that one would set InstallDir
-> TOMCAT_HOME and home -> APP_HOME.  I'll test that
out.


> By using explicit paths we can accomodate more use
> cases and be 
> very clear about what goes where.

yup.

> > Down the road an include mechanism would be a good
> 
> No need, it's already done ( and in 3.2 too ).

Luv it.  Thanks for pointing that out.


> One of the goals for 3.3 release is to have all
> those
> small things that makes configuration easy ( as 
> usability enhancements ).
> 

These issues directly affect configuration management
and are critical for managing complex deployments.  I
don't think enough people take this area seriously
enough (code features now, worry about deployment
later!).

> 
> > Q2: More importantly, I'm still left with:  How do
> I
> > configure the use of a different servlet to handle
> > *.jsp requests?
> 
> In 3.3 - in JspInterceptor you have "useJspServlet"
> and
> "jspServlet" that allows you to specify it on a
> global
> level ( or per context ! ).
> 
> This is strongly discuraged - as it'll be much
> slower than
> using JspInterceptor's optimizations. 
> 

Why exactly would it be 'much' slower?  Does that
presume that a custom JspServlet would be inherently
slower or that the default
org.apache.jasper.runtime.JspServlet is somehow
accellerated by something JspInterceptor does?

Hypothetical:  If I were to modify
org.apache.jasper.runtime.JspServlet (or make a
replacement and pre-load it in the CLASSPATH) would
that be 'much slower' (even though it should not
require setting the 'useJspServlet' tag since it would
appear to be the regular default class)?  Just curious
about your statement.

> If your jsp processor does something special, you
> can 
> bundle it with your application and use the web.xml
> ( from WEB-INF ) to set it. Then your app will work
> on any container the way you expect.
> 

This may be suitable for some situations, but I have
other situations where I need to have complete control
over what JSP compiler is used by the servlet engine. 
This sort of configuration (specifying what servlet to
route a request to) is easy with JServ, WebLogic
Server and other servlet engines.  I'm not sure why it
shouldn't be just as simple on Tomcat.  Especially
since fundamentally Jasper is a standalone servlet
package that runs fine on other servlet engines than
Tomcat.  One should be able to plug-in a different JSP
processing servlet (or any default servlet) with no
more work than changing a line in a configuration
file.  It sounds like 3.3 brings this ease in the
JspInterceptor.

I'm pretty intimate with the Jasper API, but still
learning the Tomcat API.  I'm still working on
understanding how the Connector and Interceptor
patterns are implemented.

Thanks again for the help.

Cheers,

mel


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

Re: Tomcat Setup and configuration

[cm...@yahoo.com]

> > In 3.3, the logs are corectly set relative to
> > TOMCAT_HOME.

> and should be implicitely written to paths relative to
> the application 'home', not into TOMCAT_HOME.   This
> is simple OO partitioning of responsibilities.

Ok, this is a clear example of what's wrong with the current
status - there are 2 directories that can be set on ContextManager,
one is "home" and the other one is "installDir". 
The env. variable is used to set home.

If one is set and the other not - both share the same value.

InstallDir is the one used for jar files ( and all "shared" files ).
home is supposed to be used for the local instance.

( the model is again a shared installation - /usr/local or /opt/tomcat
and each user having it's own config and set of applications ).

That's just a particular use case, and even for that it's too complex.

By using explicit paths we can accomodate more use cases and be 
very clear about what goes where.


> Down the road an include mechanism would be a good
> idea to add as well (i.e. add a server.xml element
> <server-include> which could take a path (or even a
> URL) to an external config file that could be imported

No need, it's already done ( and in 3.2 too ).
( I have no idea who did it - it's not me, and I was 
quite surprised to find it there :-)

Any file named server-foo.xml will be read and used 
as addition to server.xml. 

In 3.3 you can use <serverXmlReader> to read additional
files in arbitrary locations.

Part of the current proposal is to formalize that 
and use explicit directives for what gets read.

> > module - and you'll be able to set the location to
> > anything you want
> > ( or any other properties that affect its behavior )
> 
> Is this available in the current 3.3 milestone or
> nightly builds?

The first milestone will happen soon, it's only in 
the nightly builds and it's not yet completed ( 
i.e. some of the paths are now configurable, but
not all and not in all modules ). 

One of the goals for 3.3 release is to have all those
small things that makes configuration easy ( as 
usability enhancements ).



> Q1: Why does it say in the documentation that
> conf/web.xml is used as a default?  Needs to be
> corrected.

I agree. 

> Q2: More importantly, I'm still left with:  How do I
> configure the use of a different servlet to handle
> *.jsp requests?

In 3.3 - in JspInterceptor you have "useJspServlet" and
"jspServlet" that allows you to specify it on a global
level ( or per context ! ).

This is strongly discuraged - as it'll be much slower than
using JspInterceptor's optimizations. 

If your jsp processor does something special, you can 
bundle it with your application and use the web.xml
( from WEB-INF ) to set it. Then your app will work
on any container the way you expect.

> Okay, so it sounds like I need to reconfigure the
> StaticInterceptor module.  And I would do this... how?
>  Is this possible on 3.2.1 or do I need to go to 3.3
> for this?  Could someone point me in the right
> direction here?

Again - you can do it in a portable way ( using web.xml
in your application ) or tomcat-specific, by replacing 
StaticInterceptor.


Costin

Re: Tomcat Setup and configuration

[Mel Martinez <me...@yahoo.com>]

Costin - Thanks a ton for your reply.  Very helpful.

--- cmanolache@yahoo.com wrote:
> The intention ( in tc3.3 ) is to make all the
> configurations "explicit",
> instead of using conventions like "webapps will be
> in home, libs in
> install, etc". 
> 

This sound great.  I am a big proponent of explicit
configuration (with implicit defaults, of course).

> 
> For issue #1, it's a bug - logs are "special" in 3.2
> and they were not 
> made relative to the home. The workaround is to use
> explicit paths.
> 
> In 3.3, the logs are corectly set relative to
> TOMCAT_HOME.
> 

Shouldn't they be by default set relative to the
application home?  I.E. if we have one install of
tomcat on the system, (TOMCAT_HOME =
/opt/local/tomcat) and we have two different
applications on the box (using, perhaps different
ports) with different server.xml files and
ContextManager 'home' attributes), the log output
should be consider 'of the application' in each case
and should be implicitely written to paths relative to
the application 'home', not into TOMCAT_HOME.   This
is simple OO partitioning of responsibilities.


> If nobody objects to the config changes I'll also
> add the ant-style syntax
> for ${properties}, so you'll have more flexibility.

No objection.  Sounds like a good idea.  The
${property} syntax is consistent with the Security
Manager policy file format as well.  I've implemented
it in my own application's configuration file scheme.

Down the road an include mechanism would be a good
idea to add as well (i.e. add a server.xml element
<server-include> which could take a path (or even a
URL) to an external config file that could be imported
into the DOM).  Having built this sort of thing
before, I realize this not trivial (recursion,
protocol for conflict resolution, etc.) but the value
is high.

> 
> Issue #2 ( conf dir ) - again, in 3.3 most if this
> is configurable via 
> individual module options. For example the
> apache.conf is generated by a 
> module - and you'll be able to set the location to
> anything you want
> ( or any other properties that affect its behavior )

Is this available in the current 3.3 milestone or
nightly builds?

> 
> 
> Regarding Issue #3  - the web.xml is not used in
> tomcat3.2, 
> and will not be used in tomcat3.3. All the server
> config
> is done using server.xml ( and the new context.xml )
> files.
> 

That sounds great.  At least I now know what is (not)
going on!  :-)

Q1: Why does it say in the documentation that
conf/web.xml is used as a default?  Needs to be
corrected.

Q2: More importantly, I'm still left with:  How do I
configure the use of a different servlet to handle
*.jsp requests?


 
> Server.xml sets server behavior. For example, the 
> conversion between .jsp and java is a server
> property. 
> The static interceptor is a server property.
> Everything 
> that is not defined in the web.dtd belongs in
> server.xml,
> and it's specific to tomcat. What is defined in
> web.dtd
> and the spec belongs to WEB-INF/web.xml. 
> 

Okay, so it sounds like I need to reconfigure the
StaticInterceptor module.  And I would do this... how?
 Is this possible on 3.2.1 or do I need to go to 3.3
for this?  Could someone point me in the right
direction here?

Thanks again for your help.

Mel


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

Re: Tomcat Setup and configuration

[cm...@yahoo.com]

The intention ( in tc3.3 ) is to make all the configurations "explicit",
instead of using conventions like "webapps will be in home, libs in
install, etc". 

Even in 3.2 we tried to allow a shared installation dir and multiple 
work dirs ( i.e. you have one tomcat installed in /opt/tomcat, and each
user can run it with it's port and webapps ). This is not a "supported" 
feature - i.e. it's not very well tested or documented.

For issue #1, it's a bug - logs are "special" in 3.2 and they were not 
made relative to the home. The workaround is to use explicit paths.

In 3.3, the logs are corectly set relative to TOMCAT_HOME.

If nobody objects to the config changes I'll also add the ant-style syntax
for ${properties}, so you'll have more flexibility. Nacho started 
a nice idea in the loggers ( adding a ${TIMESTMAP} ), and I plan to add
other pre-defined properties (like configdir, context home, context
workdir ). 

Again - the current mechanism is indeed a bit confusing and complex, and 
making it explicit will be a big step forward ( i.e. all paths will use
${tomcat.home}/logs/mylog.log )


> better, wouldn't it be nice to be able to set that at
> the command-line with a an option?  That would make it

That's something I work on, but it's lower priority. ( better command line
support )

Issue #2 ( conf dir ) - again, in 3.3 most if this is configurable via 
individual module options. For example the apache.conf is generated by a 
module - and you'll be able to set the location to anything you want
( or any other properties that affect its behavior )

Henri proposed to make it simple to use Linux-style hierarchy ( with 
all logs in /var/log, configs in /etc/tomcat, webapps in /var/tomcat,
etc). Apache also have a "layout" option. 

Regarding Issue #3  - the web.xml is not used in tomcat3.2, 
and will not be used in tomcat3.3. All the server config
is done using server.xml ( and the new context.xml ) files.

There shouldn't be any overlap between web.xml and sever.xml,
any setting that is part of web.xml should be part of 
the web application's WEB-INF to make sure the app is 
portable ( if you rely on any tomcat-specific default, 
your app will work only on tomcat).

Server.xml sets server behavior. For example, the 
conversion between .jsp and java is a server property. 
The static interceptor is a server property. Everything 
that is not defined in the web.dtd belongs in server.xml,
and it's specific to tomcat. What is defined in web.dtd
and the spec belongs to WEB-INF/web.xml. 

> At this point, I try making a variety of changes to
> the web.xml file, including registering my servlet

Web.xml is not read - it's just a template you can
use for your applications. 


Costin

Tomcat Setup and configuration

[Mel Martinez <me...@yahoo.com>]

I realize that this is probably a 'tomcat-user'
question, but since my intention is towards dev
efforts, I hope no one minds my posting it here.  If
necessary I'll post it to the users list.  I've run
into 3 issues described below.  Of them, #3 is the
most important to me and I really need to get it
resolved rapidly.  Hopefully in all cases I'm just
being an idiot and someone here can nudge me with the
obvious answers. :-)

I'm having trouble figuring out how to setup Tomcat in
the following particular manner:

I've installed Tomcat 3.2.1 into /opt/local/tomcat and
have set TOMCAT_HOME=/opt/local/tomcat.  However I
have a need to keep my actual application completely
separate from the above installation.  (This is not an
unusual idea: keep all application-specific data,
scripts and configuration independent of the COTS
installation).  My application is thus, for example,
installed in APP_HOME=/opt/demo.  I've created a
server.xml file for the application and I start tomcat
using the option "-f /opt/demo/conf/server.xml".  So
far so good.

Issue#1:
The comments in the server.xml file say that by
setting the "home" attribute to the <ContextManager>
element, that "...webapps/, work/ and log/tomcat_logs/
will be relative to this...".  So I set this attribute
to home="/opt/demo".  However, because the tc_log,
servlet_log and JASPER_log are all defined outside the
scope of the <ContextManager>, I soon find that by
default, tomcat still writes it's logs back to
TOMCAT_HOME/logs/*.  There does not seem to be a
single attribute in server.xml that can tell tomcat to
route all Logger output to have a different root
directory (i.e., I'd prefer to write to
APP_HOME/logs/*).  So I am forced to edit the 'path'
attribute of every Logger element to have an absolute
path like so : path="/opt/demo/logs/tomcat.log".

Q: Wouldn't it be easier to have a 'home' attribute on
the <Server> element that would be used as the base
for all relative paths in nested elements (i.e.
<Logger>, <ContextManager>, <Context>, etc.)  And even
better, wouldn't it be nice to be able to set that at
the command-line with a an option?  That would make it
much easier to reuse server.xml settings across
multiple deployments.  Basically, I think tomcat needs
to have the ability to clearly separate the
TOMCAT_HOME installation from the configuration and
data for a particular application.  Not doing so is
kind of like assuming that every user wants to store
all his MS Word documents into C:/Program
Files/Microsoft/Word/documents/ (or wherever the MS
Word application is installed).

Issue#2
Having set the <ContextManager home="/opt/demo" ...>
attribute, Tomcat does seem to be finding the work and
webapps directories correctly.  And it also seems to
create certain output, such as the
"tomcat-apache.conf"  file correctly inside the
"/opt/demo/conf/" directory.

Q: While there are attributes (workDir, path) for
changing the names used for the scratch directory and
the location of a webapp context, there seems no way
to change the name or location used for the conf/
directory.  It is 'fixed' as relative to the home
path.  Since configuration data is often deployment
specific, I would greatly appreciate the ability to
direct tomcat to use a particular directory for conf
(for example if I need to deploy to both linux and nt
I might want to specify APP_HOME/conf/linux/ for one
and APP_HOME/conf/nt/ for the other.).  If this
capability already exists, could someone please
explain to me how to invoke it?


At any rate, given the above, I am now able to run
tomcat and launch, compile and run JSPs using the
default jasper JspServlet.  I am also able to invoke
classes I've included in the CLASSPATH just fine.  I
still have some issue with referencing classes with
the default JasperLoader but I think this is because
the ClassPath pulled from the init-params is not set. 
I'm not to worried about that one.

Issue#3:
The documentation in the "Tomcat - A Minimalistic
User's Guide" says: "Tomcat lets the user define
default web.xml values for all context by putting a
default web.xml file in the conf directory.".  This
sounds reasonable, as there needs to be some global
registration of such servlets as, for example, the
JspServlet.  So, I promptly placed a copy of web.xml
in my APP_HOME/conf directory and edited it to change
the servlet class used for JSPs.   I first tried doing
this by simply replacing:

    <servlet>
        <servlet-name>
            jsp
        </servlet-name>
        <servlet-class>
            org.apache.jasper.runtime.JspServlet
        </servlet-class>
        ....
    </servlet>

with:

    <servlet>
        <servlet-name>
            jsp
        </servlet-name>
        <servlet-class>
            com.my.package.JspServlet
        </servlet-class>
        ....
    </servlet>


At this point, I would expect that tomcat would send
all *.jsp requests to the 'jsp' servlet which should
use my class as indicated above for servlet.  However,
it does not.

At this point, I try making a variety of changes to
the web.xml file, including registering my servlet
class under a different name, changing url pattern
servlet mappings and none of them seem to have any
affect!  I also tried putting the web.xml file into
TOMCAT_HOME/conf instead, but that too does not seem
to have any affect.

Q: How do I get Tomcat to recognize the changes I make
to the default web.xml file?  Basically, I need to be
able to change the servlet class used for *.jsp.

Question #3 above is the most important to me.

If anyone can help me out here, I would greatly
appreciate it.  Am I running into bugs already fixed
in Tomcat 3.3 or 4.0?  I will move to one of those
builds if necessary, but that is not a preferred path
because I don't like to tell my customers I'm
deploying them with experimental code!  :-)

Thanks,

Dr. Mel Martinez
Senior Software Architect
G1440, Inc.
melaquias@yahoo.com




__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Mel Martinez <me...@yahoo.com>]

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.
melaquias@yahoo.com

--- Glenn Nielsen <gl...@voyager.apg.more.net> wrote:
> "Craig R. McClanahan" wrote:
> > 
> > Glenn Nielsen wrote:
> > 
> > > "Craig R. McClanahan" wrote:
> > > >
> > > > glenn@apache.org 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/

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Glenn Nielsen <gl...@voyager.apg.more.net>]

"Craig R. McClanahan" wrote:
> 
> Glenn Nielsen wrote:
> 
> > "Craig R. McClanahan" wrote:
> > >
> > > glenn@apache.org 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.
> > > With this
> > > change, such beans will work in Tomcat but not when the app is moved to
> > > a different container that *does* put JSP-generated servlets into a
> > > package.
> > >
> > > The previous behavior (Jasper-generated servlets go into a package)
> > > avoided this, because it essentially disallowed non-packaged beans.
> > > Therefore, I prefer it.
> > >
> > > (Also, I seem to remember a discussion on the expert group for JSP 1.2
> > > that non-packaged beans and generarted classes should be disallowed, but
> > > I have not yet located any reference to this in the 1.2 spec.)
> > >
> >
> > If you check the code for JasperLoader you will find that it requires
> > all classes to be in a package, the only class that does not have to
> > be in a package is the JSP page itself.
> >
> 
> 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.
> 

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

----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Glenn Nielsen wrote:

> "Craig R. McClanahan" wrote:
> >
> > glenn@apache.org 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.
> > With this
> > change, such beans will work in Tomcat but not when the app is moved to
> > a different container that *does* put JSP-generated servlets into a
> > package.
> >
> > The previous behavior (Jasper-generated servlets go into a package)
> > avoided this, because it essentially disallowed non-packaged beans.
> > Therefore, I prefer it.
> >
> > (Also, I seem to remember a discussion on the expert group for JSP 1.2
> > that non-packaged beans and generarted classes should be disallowed, but
> > I have not yet located any reference to this in the 1.2 spec.)
> >
>
> If you check the code for JasperLoader you will find that it requires
> all classes to be in a package, the only class that does not have to
> be in a package is the JSP page itself.
>

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.

>
> Regards,
>
> Glenn
>

Craig

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Glenn Nielsen <gl...@voyager.apg.more.net>]

"Craig R. McClanahan" wrote:
> 
> glenn@apache.org 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.
> With this
> change, such beans will work in Tomcat but not when the app is moved to
> a different container that *does* put JSP-generated servlets into a
> package.
> 
> The previous behavior (Jasper-generated servlets go into a package)
> avoided this, because it essentially disallowed non-packaged beans.
> Therefore, I prefer it.
> 
> (Also, I seem to remember a discussion on the expert group for JSP 1.2
> that non-packaged beans and generarted classes should be disallowed, but
> I have not yet located any reference to this in the 1.2 spec.)
> 

If you check the code for JasperLoader you will find that it requires
all classes to be in a package, the only class that does not have to
be in a package is the JSP page itself.

Regards,

Glenn

----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------