[PATCH]Tc3.3 Improvement to mod_jk.auto-conf

[Jim Rudnicki]

Attached is a diff to the class that writes the Apache config file.
I added code to write JkMount directives to include the servlet-mapping 's
from the web.xml files for each context.

I like/desire the functionality, but the implementation is a little cheap.

I did this by reparsing the web.xml's.  This is inefficient, because the
files were already parsed by the time execution reaches here.  But alas, I
wanted this feature now and didn't know if there was access to the mappings
from this task.

Jim

Index: ./src/share/org/apache/tomcat/task/ApacheConfig.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig
.java,v
retrieving revision 1.22
diff -r1.22 ApacheConfig.java
66a67,68
 import org.w3c.dom.*;
 import javax.xml.parsers.*;
202a205,218
   /* Get a factory and parser for reading
   the web.xml files.  One builder will be used for all the
   contexts as they are iterated below. */
   DocumentBuilderFactory docBuilderFactory =
DocumentBuilderFactory.newInstance();
   DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();
   try {
docBuilderFactory = DocumentBuilderFactory.newInstance();
docBuilder = docBuilderFactory.newDocumentBuilder();
   }
   catch (Exception x) {
docBuilderFactory = null;
docBuilder = null;
   }

288a305,366

 /* write servlet mappings */
 try {
 File fileWebInf = new File( docBase + File.separator +
"WEB-INF" + File.separator + "web.xml");
 if( (null!=docBuilder)  (fileWebInf.exists()) ) {
 Node ndTest;
 Element elMap;
 int i, n;
 int j, m;

 /* Parse file and retrieve all
 servlet-mapping tags */
 Document doc = docBuilder.parse(fileWebInf);
 NodeList nlMaps = doc.getElementsByTagName(
"servlet-mapping" );

 /* If there are any, walk the list and write
 a JkMount directive for each url-pattern. */
 n = nlMaps.getLength();
 if( n  0 ) {
 mod_jk.println("#" );
 mod_jk.println("# These lines create Apache
directives for the servlet mappings" );
 mod_jk.println("# contained in the file " +
fileWebInf.getAbsolutePath() );
 mod_jk.println("#" );
 i = 0;
 while( in ) {
 ndTest = nlMaps.item(i);
 if( ndTest instanceof Element ) {
 elMap = (Element)ndTest;
 NodeList nlUrls =
elMap.getElementsByTagName( "url-pattern" );
 /* The DTD says there must only be one, so
even if more
 than one was present, only the first is
processed */
 Node ndPattern =
nlUrls.item(0).getFirstChild();
 if( ndPattern.getNodeType() ==
Node.TEXT_NODE ) {
 /* The standard line terminator
problem presents itself here.
 The string from getNodeValue() may or
may not contain various
 /r and /n characters depending on
platform and editor used to
 create web.xml file.
 It would have been nice if
ndPattern.normalize() would have stripped
 off anything but the text, but it just
throws an exception.
 So, remove /r and /n from ends of
text.
 Also, ensure that the pattern starts
with a '/'.  Extension
 mappings (*.xyz) will not contain one.
Because the line will be
 a directive to Apache, the forward
slash will be appropriate
 on all platforms. */
 String s = ndPattern.getNodeValue();
 s = s.trim();
 if( s.charAt(0) != '/' ) {
 s = "/" + s;
 }
 mod_jk.println( "JkMount "+ path + s
+" ajp12" );
 }
 }
 i++;
 }
 }
 }
 }
 catch( Exception x ) {
 /* If anything goes wrong, just skip writing the mappings.
 The web.xml file was dealt with when the context was
created
 presumably errors where logged there. 

BugRat Report #563 has been filed.

[BugRat Mail System]

Bug report #563 has just been filed.

You can view the report at the following URL:

   http://znutar.cortexity.com/BugRatViewer/ShowReport/563

REPORT #563 Details.

Project: Tomcat
Category: Feature Requests
SubCategory: Enhancement
Class: feature
State: received
Priority: medium
Severity: serious
Confidence: public
Environment: 
   Release: 3.2, 4.0
   JVM Release: n.a.
   Operating System: n.a.
   OS Release: n.a.
   Platform: n.a.

Synopsis: 
Make JDBCRealm not a final class

Description:
The JDBCRealm is a cool feature and I have got it working alright. But I need to add 
an extra feature like storing the passwords encrypted in the database and not in clear 
text. Therefore I only need to override the authenticate method in the JDBCRealm class 
and add the encryption algorithm. But since the class is final I'm not allowed to do 
this and must therefore write a whole new class. If the Tomcat project is interested 
in the encryption realm I'm willing to submit/donate the code.

Title: 
BugRat Report #
563





BugRat Report #
563




Project:
Tomcat


Release:
3.2, 4.0




Category:
Feature Requests


SubCategory:
Enhancement




Class:
feature


State:
received




Priority:
medium


Severity:
serious




Confidence:
public





Submitter:
Allan Schweitz ([EMAIL PROTECTED])

Date Submitted:
Dec 10 2000, 04:25:07 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])


Synopsis:

Make JDBCRealm not a final class


 Environment: (jvm, os, osrel, platform)

n.a., n.a., n.a., n.a.



Additional Environment Description:

n.a.



Report Description:

The JDBCRealm is a cool feature and I have got it working alright. But I need to add an extra feature like storing the passwords encrypted in the database and not in clear text. Therefore I only need to override the authenticate method in the JDBCRealm class and add the encryption algorithm. But since the class is final I'm not allowed to do this and must therefore write a whole new class. If the Tomcat project is interested in the encryption realm I'm willing to submit/donate the code.



How To Reproduce:

null



Workaround:

null



View this report online...

Re: username and password for admin tomcat 3.2

[Andy]

peter duong wrote:

 hi,
 i tried to use admin function in tomcat but donot know the initial
 username and password. could you please help ?
 tia

I normally would not reply to this because its in the wrong list
(tomcat-dev as opposed to tomcat-user), but I feel it is enough of a
documentation error that the developers should consider doing something
about it.

I've not got tomcat here (only at work) so excuse any lack of precision
on filenames etc.   If you look at the something-or-other-users.xml file
under
[yourtomcatinstalldir]/conf you'll find a couple example users and
password and their roles.  Add one called "admin" give him a password of
your choosing and whatever other roles plus "admin".   (this part is not
documented anywhere that I could find easily, If I missed it appologize
in advance).   Then go to sever.xml  and change the admin context to be
"trusted".   Now the admin app should work.

-Andy


__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: [PROPOSAL] JSSI for Tomcat

[cmanolache]

Hi Hans,

 for servlet tags and NCSA SSI directives, I decided to port Apache 
 JSSI to Tomcat. Now it's basically done for TC 3.2, and the question is 
 what to do with it ;-)

 1) Make this a new Jakarta subproject, named jakarta-jssi.
The reason for this is that it's an optional module and it can
live its own life outside the container development.

+1  - but I would like more a "generic" name ( jakarta-jsse - java server
side extensions ). JSSI seems a small project and it may not be worth the
overhead of a top level modules. 

That will reduce the pressure on tomcat for developing feature-isms and
non-standard extensions, and will keep it more focused on strict
implementation of the servlet API. The extensions could be developed
independent of tomcat, and maybe will be reused in other containers. As an
additional benefit, people will not confuse "extensions" with
"standards" :-)


 2) Support only for TC 3.2 initially

+1

 3) Package structure (for TC 3.2 version)
In order to integrate with Tomcat's Context and ServletWrapper classes
(for servlet loading and execution), the JSSI classes should be in 
org.apache.tomcat.* packages, and at least one of them must be in the 
org.apache.tomcat.facade package specifically. Keeping basically the
original internal package structure but adjusted to Tomcat, I suggest
the following packages:
 
   org.apache.tomcat.facade
 One class (ServletTagHandler)
   org.apache.tomcat.ssi
 Main classes
   org.apache.tomcat.ssi.util
 SGMLTag
   org.apache.tomcat.ssi.io
 PositionReader

My preference would be org.apache.ssi ( no tomcat in package ).
Reason - other containers could use it. Tomcat is an implementation of the
servlet API, we should use the package only for that :-)

The facade class should be in a different directory ( something like
src/share, src/tomcat32_integration, src/jserc, ... ), and we should
help people to create code to integrate with other servlet containers.

One comment about the "facade" class - the plan is ( sometime in 3.3 ) to
"seal" the facade package. There are many security implications, the
facade is a critical component for tomcat's security. This shouldn't be 
a big problem, but an oportunity to learn and maybe provide better hooks
for applications like that :-)

Costin

BugRat Report #564 has been filed.

[BugRat Mail System]

Bug report #564 has just been filed.

You can view the report at the following URL:

   http://znutar.cortexity.com/BugRatViewer/ShowReport/564

REPORT #564 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.2
   JVM Release: 1.3
   Operating System: W2K
   OS Release: 1
   Platform: Intel PIII

Synopsis: 
startup .bat files use old paths

Description:
Tomcat 3.1 assumed the installation dir to be drive:\jakarta-tomcat. Accordingly, 
all .bat files had this hard coded. The default unzip dir was also this. With 3.2, it 
has changed to jakarta-tomcat-3.2 but the .bat files still use the jakarta-tomcat path.

Not really a bug but a show stopper definetly.

Title: 
BugRat Report #
564





BugRat Report #
564




Project:
Tomcat


Release:
3.2




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
Nasir Noor ([EMAIL PROTECTED])

Date Submitted:
Dec 10 2000, 11:35:54 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])


Synopsis:

startup .bat files use old paths


 Environment: (jvm, os, osrel, platform)

1.3, W2K, 1, Intel PIII



Additional Environment Description:





Report Description:

Tomcat 3.1 assumed the installation dir to be :\jakarta-tomcat. Accordingly, all .bat files had this hard coded. The default unzip dir was also this. With 3.2, it has changed to jakarta-tomcat-3.2 but the .bat files still use the jakarta-tomcat path.

Not really a bug but a show stopper definetly.



How To Reproduce:

null



Workaround:

null



View this report online...

Re: [PROPOSAL] JSSI for Tomcat

[Hans Bergsten]

[EMAIL PROTECTED] wrote:
 [...]
  1) Make this a new Jakarta subproject, named jakarta-jssi.
 The reason for this is that it's an optional module and it can
 live its own life outside the container development.
 
 +1  - but I would like more a "generic" name ( jakarta-jsse - java server
 side extensions ). JSSI seems a small project and it may not be worth the
 overhead of a top level modules.
 
 That will reduce the pressure on tomcat for developing feature-isms and
 non-standard extensions, and will keep it more focused on strict
 implementation of the servlet API. The extensions could be developed
 independent of tomcat, and maybe will be reused in other containers. As an
 additional benefit, people will not confuse "extensions" with
 "standards" :-)

That's a good idea, and jakarta-jsse is as good a name as any ;-)
This subproject could then be modeled after the jakarta-taglibs
project, with independent modules that have their own documentation,
can be downloaded separately, etc. (See the Jakarta-Taglibs web site
for details). I believe this project will be a good place for a
collection of Servlet 2.3 filters eventually. See more below for container 
integration.

  3) Package structure (for TC 3.2 version)
 In order to integrate with Tomcat's Context and ServletWrapper classes
 (for servlet loading and execution), the JSSI classes should be in
 org.apache.tomcat.* packages, and at least one of them must be in the
 org.apache.tomcat.facade package specifically. Keeping basically the
 original internal package structure but adjusted to Tomcat, I suggest
 the following packages:
 
org.apache.tomcat.facade
  One class (ServletTagHandler)
org.apache.tomcat.ssi
  Main classes
org.apache.tomcat.ssi.util
  SGMLTag
org.apache.tomcat.ssi.io
  PositionReader
 
 My preference would be org.apache.ssi ( no tomcat in package ).
 Reason - other containers could use it. Tomcat is an implementation of the
 servlet API, we should use the package only for that :-)

Okay, the current JSSI packages are:

  org.apache.java.io (one class, PositionReader)
  org.apache.java.util (one class, SGMLTag)
  org.apache.servlet.ssi (the rest)

Even though the "org.apache.java.*" classes are not directly tied to
JSSI, I have a feeling they are not all that useful for other projects.
And without a real "shared Java utils" package within Apache, it's a
pain to coordinate the development of shared code. I therefore suggest 
this structure initially instead:

  org.apache.ssi.io (one class, PositionReader)
  org.apache.ssi.util (one class, SGMLTag)
  org.apache.ssi.servlet (the rest)

For Servlet 2.3 containers, SSI can likely be implemented as a filter
instead. At that point, we can clean-up and move some of the classes 
from org.apache.ssi.servlet to a new package (org.apache.ssi.core),
and add the filter interface in a new package (org.apache.ssi.filter).


 The facade class should be in a different directory ( something like
 src/share, src/tomcat32_integration, src/jserc, ... ), and we should
 help people to create code to integrate with other servlet containers.

Okay, how about this: the packages above are stored in a directory
named ssi/src/share and the integration classes are stored in a
directory named ssi/integration/tomcat_3.2 (etc.), all within the
CVS repository for jakarta-jsse.

What's needed for integration is, first of all, an interface with
these methods:

  /**
   * Returns true if the named servlet is known by the context.
   */
  boolean isServletDefined(Servlet context, String servletName);

  /**
   * Adds the servlet class to the context, using the className
   * as the servlet name. After this call, a call to isServletDefined()
   * with className as servletName must return true. The initParams
   * must be used when the servlet is initialized.
   */
  void addServlet(String className, Hashtable initParams);

  /**
   * Calls the servlet's service() method with the specified
   * request and response object, loading and initializing the
   * servlet first if needed.
   */
  void executeServlet(ServletRequest req, ServletResponse res)
throws IOException, ServletException;
  
This interface can be called org.apache.ssi.integration.ServletExecutor
and live in the ssi/src/share part of the CVS repository.

Implementations of this interface for various containers live in
the ssi/integration part of the tree. For Tomcat 3.2, it's implemented
by a class in the org.apache.tomcat.facade package.

 One comment about the "facade" class - the plan is ( sometime in 3.3 ) to
 "seal" the facade package. There are many security implications, the
 facade is a critical component for tomcat's security. This shouldn't be
 a big problem, but an oportunity to learn and maybe provide better hooks
 for applications like that :-)

Would the above work even after you "sealed" the facade package? If not,
do you have a better suggestion?

Re: [PROPOSAL] JSSI for Tomcat

[Jeff Turner]

--
God made the integers; all else is the work of Man.
-- Kronecker

On Sun, 10 Dec 2000, Hans Bergsten wrote:

 [EMAIL PROTECTED] wrote:
  [...]
   1) Make this a new Jakarta subproject, named jakarta-jssi.
  The reason for this is that it's an optional module and it can
  live its own life outside the container development.
  
  +1  - but I would like more a "generic" name ( jakarta-jsse - java server
  side extensions ). JSSI seems a small project and it may not be worth the
  overhead of a top level modules.
  
  That will reduce the pressure on tomcat for developing feature-isms and
  non-standard extensions, and will keep it more focused on strict
  implementation of the servlet API. The extensions could be developed
  independent of tomcat, and maybe will be reused in other containers. As an
  additional benefit, people will not confuse "extensions" with
  "standards" :-)
 
 That's a good idea, and jakarta-jsse is as good a name as any ;-)

If I may be the first to throw cold water on that name..  JSSE already
stands for Java Secure Socket Extension
(http://java.sun.com/products/jsse/), which is necessary for Tomcat's SSL
support. Just imagine the confusion..  ;)
 
[snip]

--Jeff

 Hans
 -- 
 Hans Bergsten [EMAIL PROTECTED]
 Gefion Software   http://www.gefionsoftware.com
 Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
 

Re: [PROPOSAL] JSSI for Tomcat

[Hans Bergsten]

Jeff Turner wrote:
  [...]
  That's a good idea, and jakarta-jsse is as good a name as any ;-)
 
 If I may be the first to throw cold water on that name..  JSSE already
 stands for Java Secure Socket Extension
 (http://java.sun.com/products/jsse/), which is necessary for Tomcat's SSL
 support. Just imagine the confusion..  ;)

I realized that as soon as I hit the Send button, and was just waiting
for someone to react ;-) So how about jakarta-containerexts? I'm open
to other suggestions, but let's not get too hung up on the name thing
please.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm JDBCRealm.java

[craigmcc]

craigmcc00/12/10 15:35:33

  Modified:catalina/src/share/org/apache/catalina/realm JDBCRealm.java
  Log:
  Make JDBCRealm non-final so that it can be conveniently subclassed.
  
  Submitted by: Allan Schweitz [EMAIL PROTECTED]
  PR: BugRat Bug Report #563 (Feature Request)
  
  Revision  ChangesPath
  1.4   +1 -1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java
  
  Index: JDBCRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JDBCRealm.java2000/10/21 01:25:41 1.3
  +++ JDBCRealm.java2000/12/10 23:35:32 1.4
  @@ -97,7 +97,7 @@
* @author Carson McDonald
*/
   
  -public final class JDBCRealm 
  +public class JDBCRealm 
   extends RealmBase {
   
   
  
  
  

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request JDBCRealm.java

[craigmcc]

craigmcc00/12/10 15:36:45

  Modified:src/share/org/apache/tomcat/request Tag: tomcat_32
JDBCRealm.java
  Log:
  Make JDBCRealm not final so that it can be conveniently subclassed.
  
  Submitted by: Allan Schweitz [EMAIL PROTECTED]
  PR: BugRat Bug Report #563 (Feature Request)
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.9.2.4   +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/request/JDBCRealm.java
  
  Index: JDBCRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/JDBCRealm.java,v
  retrieving revision 1.9.2.3
  retrieving revision 1.9.2.4
  diff -u -r1.9.2.3 -r1.9.2.4
  --- JDBCRealm.java2000/12/04 18:47:07 1.9.2.3
  +++ JDBCRealm.java2000/12/10 23:36:45 1.9.2.4
  @@ -92,7 +92,7 @@
*
*/
   
  -public final class JDBCRealm extends BaseInterceptor {
  +public class JDBCRealm extends BaseInterceptor {
   
   
   ContextManager cm;
  
  
  

Re: [PROPOSAL] JSSI for Tomcat

[cmanolache]

 
 Even though the "org.apache.java.*" classes are not directly tied to
 JSSI, I have a feeling they are not all that useful for other projects.
 And without a real "shared Java utils" package within Apache, it's a
 pain to coordinate the development of shared code. I therefore suggest 
 this structure initially instead:

That's another issue, and I kept asking for such a thing for a long time.
Having a common package for utilities that are independent of a particular
project is one of my biggest wishes ( for next year - Christmas is too
close :-). 

Most of the code in org.apache.tomcat.util ( and most of tomcat3.3 ) is
organized as a set of container-independent, general purpose utils (
optimized for server side use, but without any dependency on tomcat ) and
a simple set of tomcat-specific interfaces.

I am working on a better organization ( to reduce namespace polution in
tomcat.util), but there are many great tools in org.apache.java from the
JServ project, and few great tools in xerces - all those should be
organized under the same hierarchy, with a build system that would allow
projects to pick what they need.

Ok, too much discutions off-topic - I wouldn't mind if you keep the
org.apache.java.* ( and maybe import some more ), instead of
org.apache.ssi.util :-)
 
 What's needed for integration is, first of all, an interface with
 these methods:
 
   boolean isServletDefined(Servlet context, String servletName);
   void addServlet(String className, Hashtable initParams);
   void executeServlet(ServletRequest req, ServletResponse res)

 This interface can be called org.apache.ssi.integration.ServletExecutor
 and live in the ssi/src/share part of the CVS repository.

 Implementations of this interface for various containers live in
 the ssi/integration part of the tree. For Tomcat 3.2, it's implemented
 by a class in the org.apache.tomcat.facade package.

If that's all I think we don't need any change in tomcat core, and it
should work for both 3.2 and 3.3 ( in the form of an interceptor ).

I'll take a look and try to convert your code to a normal interceptor (
since this is the best way to extend tomcat3.x ). It would be a great test
for the model. ( we may need an additional notification/hook for
"addServlet" - if this is the case we'll need different code for 3.2/3.3 )


  One comment about the "facade" class - the plan is ( sometime in 3.3 ) to
  "seal" the facade package. There are many security implications, the
  facade is a critical component for tomcat's security. This shouldn't be
  a big problem, but an oportunity to learn and maybe provide better hooks
  for applications like that :-)
 
 Would the above work even after you "sealed" the facade package? If not,
 do you have a better suggestion?

For 3.2 - the package is not sealed, no problem. I think Interceptor
should be the best way to extend tomcat and integrate other components
with tomcat - if the provided hooks are not enough it's a great chance to
add what's needed. 

"Sealed" is an attribute in the Manifest of a .jar file, and it means ( if
the container uses a "standard" class loader, what we do ) that classes in
that particular package can't be defined in any other jar ( or classpath
directory ). It's great to insure that "package" protection is effective.

Costin



 

Re: [PROPOSAL] JSSI for Tomcat

[Hans Bergsten]

[EMAIL PROTECTED] wrote:
 [...]
 Ok, too much discutions off-topic - I wouldn't mind if you keep the
 org.apache.java.* ( and maybe import some more ), instead of
 org.apache.ssi.util :-)

Okay.

  What's needed for integration is, first of all, an interface with
  these methods:
 
boolean isServletDefined(Servlet context, String servletName);
void addServlet(String className, Hashtable initParams);
void executeServlet(ServletRequest req, ServletResponse res)
 
  This interface can be called org.apache.ssi.integration.ServletExecutor
  and live in the ssi/src/share part of the CVS repository.
 
  Implementations of this interface for various containers live in
  the ssi/integration part of the tree. For Tomcat 3.2, it's implemented
  by a class in the org.apache.tomcat.facade package.
 
 If that's all I think we don't need any change in tomcat core, and it
 should work for both 3.2 and 3.3 ( in the form of an interceptor ).
 
 I'll take a look and try to convert your code to a normal interceptor (
 since this is the best way to extend tomcat3.x ). It would be a great test
 for the model. ( we may need an additional notification/hook for
 "addServlet" - if this is the case we'll need different code for 3.2/3.3 )

Okay, I appreciate if you can take a look at it. I must admit I have not
looked at the interceptor stuff enough to see how it should be done. To
me, "interceptor" sounds like something that intercepts a specific request
and does something with it, not a component that can provide an interface
to non-request related internal functions. 

But maybe I'm missing something. Are you saying the whole SSI processing 
should be done as an interceptor instead of as a servlet? That may work, 
assuming an interceptor can do what the methods in the interface requires.
If so, it can be done as an interceptor for TC 3.x and as a Servlet 2.3 
filter for TC 4.x.

Let me also correct the interface API first so you know what to look at. I
missed the servletContext argument in two of the methods. This is how it
should look like:

  boolean isServletDefined(ServletContext context, String servletName);
  void addServlet(ServletContext context, String className, Hashtable
initParams);  
  void executeServlet(ServletContext context, ServletRequest req,
ServletResponse res);

  Would the above work even after you "sealed" the facade package? If not,
  do you have a better suggestion?
 
 For 3.2 - the package is not sealed, no problem. I think Interceptor
 should be the best way to extend tomcat and integrate other components
 with tomcat - if the provided hooks are not enough it's a great chance to
 add what's needed.
 
 "Sealed" is an attribute in the Manifest of a .jar file, and it means ( if
 the container uses a "standard" class loader, what we do ) that classes in
 that particular package can't be defined in any other jar ( or classpath
 directory ). It's great to insure that "package" protection is effective.

Ah, got ya :-) 

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

cvs commit: jakarta-tomcat-4.0/catalina build.xml

[craigmcc]

craigmcc00/12/10 19:12:31

  Modified:catalina build.xml
  Log:
  Pick up the regular expressions package no matter what the JAR file name is.
  
  Revision  ChangesPath
  1.27  +3 -2  jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- build.xml 2000/12/07 05:15:08 1.26
  +++ build.xml 2000/12/11 03:12:30 1.27
  @@ -63,8 +63,9 @@
   copy file="${parser.jar}" 
tofile="${catalina.build}/server/${catalina.jaxp.parser.jar}" /
   !--   Catalina needs the regular expression library --
  -copy file="${regexp.jar}" 
  - tofile="${catalina.build}/server/regexp.jar"/
  +copy todir="${catalina.build}/server"
  +  fileset dir="${regexp.home}" includes="*.jar"/
  +/copy
   !--   Catalina needs the JSSE packages --
   !--
   copy file="${jcert.jar}" tofile="${catalina.build}/server/jcert.jar"/
  
  
  

Re: [PROPOSAL] JSSI for Tomcat

[cmanolache]

 Okay, I appreciate if you can take a look at it. I must admit I have not
 looked at the interceptor stuff enough to see how it should be done. To
 me, "interceptor" sounds like something that intercepts a specific request
 and does something with it, not a component that can provide an interface
 to non-request related internal functions. 

Yes, the documentation of tomcat3 is very bad... 

"Interceptor" is (or tries to be ) equivalent with an Apache
module. Almost all of the tomcat's functionality ( parsing URLs, maps,
authentication, class loaders, reloading, error handling - in 3.3,
configuration, etc) is implemented in "modules" or "interceptors". 
In 3.3 we also implement server connectors ( HTTP, AJP ) as Interceptor -
again mirroring a bit Apache ( and MPM ).

The interceptor is a collection of hooks / notifications - for everything
that happens in tomcat and for every functionality that is needed we have
a hook, and people can define a module that will use that hook to
implement the functionality in a particular way. 

In theory ( and what happens in Apache, IIS, NES ) all extensions should
be implementable as modules ( + the core == a small set of classes
representing common server objects ). JSSI is a good test case - from what
I read I think we forgot one hook ( to notify when a new servlet is
defined/added to the server - so that the JSSIInterceptor can implement
isServletDefined ).

Note that isServletDefined can be implemented either as a call to a
component that manages servlets, or by maintaining a private
structure (hashtable). The second choice is very important because it
doesn't force a particular data structure for modules - the core can
only use JDK1.1 tools, while a module can use JDK1.2 collections or
specialized structures. 

Costin

I'm interesting in this project

[Qi Xiaobin]

Hi,all:
   I'm very interesting in your work and want to distribute to this
project.
After downloaded the source codes from the web site, I find it is
difficult
to read them without something that describe the whole architecture. Would
you pls tell me where can I find the description about the whole
architecture about this project?

_

Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

[PATCH] charset line terminator (Re: My patches for Tomcat 3.2wrt mutlibyte characters)

[Kazuhiro Kazama]

From: Costin Manolache [EMAIL PROTECTED]
Subject: Re: My patches for Tomcat 3.2 wrt mutlibyte characters
Date: Wed, 6 Dec 2000 21:55:45 -0800 (PST)
Message-ID: [EMAIL PROTECTED]
 The least we can do is to detect if the encoding is 
 compatible with ASCII ( or UNICODE ) and use the
 getBytes() only if it isn't. The method has a big
 impact on all VMs - try it if you don't believe me.

If getBytes() is used only one time per one HTTP request, its overhead
may be acceptable.

PrintWriter class support a continuous conversion, but it has much
synchronization overhead, you know. In fact, I have tested a modified
ServletWriterFacade.java (reducing synchronization by method
overriding ... an adhoc approach), servlet output became much faster.

 This is a very delicate subject from the point of view
 of performance, and I spent a lot of time tunning
 tomcat - I would like to review any patch on encoding
 before it is commited.

I fixed the following problems.

1, "8859_1" isn't right charset name in MIME.
2, HTTP charset is a case insensitive.
3, getBytes() != getBytes("iso-8859-1")
(In fact, getBytes() is getBytes(CharToByteConverter.getDefault()))
4, HTTP line terminator is CRLF.

Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories

--- src/share/org/apache/tomcat/core/Constants.java.origMon Dec 11 14:28:06 
2000
+++ src/share/org/apache/tomcat/core/Constants.java Mon Dec 11 14:31:06 2000
@@ -120,7 +120,7 @@
 public static final String HTML = "text/html";
 
 public static final String DEFAULT_CONTENT_TYPE = "text/plain";
-public static final String DEFAULT_CHAR_ENCODING = "8859_1";
+public static final String DEFAULT_CHAR_ENCODING = "ISO-8859-1";
 
 
 // deprecated
--- src/share/org/apache/tomcat/facade/ServletOutputStreamFacade.java.orig  Mon 
Dec 11 12:05:47 2000
+++ src/share/org/apache/tomcat/facade/ServletOutputStreamFacade.java   Mon Dec 11 
+14:23:09 2000
@@ -127,16 +127,16 @@
if( !gotEnc ) {
enc = resA.getCharacterEncoding();
gotEnc=true;
-   if ( Constants.DEFAULT_CHAR_ENCODING.equals(enc) )
+   if ( Constants.DEFAULT_CHAR_ENCODING.equalsIgnoreCase(enc) )
enc=null;
}
if( enc==null) 
-   b=s.getBytes();
+   b=s.getBytes(Constants.DEFAULT_CHAR_ENCODING);
else 
try {
b=s.getBytes( enc );
} catch (java.io.UnsupportedEncodingException ex) {
-   b=s.getBytes();
+   b=s.getBytes(Constants.DEFAULT_CHAR_ENCODING);
enc=null;
} 

--- src/share/org/apache/tomcat/facade/ServletWriterFacade.java.origMon Dec 11 
12:43:55 2000
+++ src/share/org/apache/tomcat/facade/ServletWriterFacade.java Mon Dec 11 14:43:35 
+2000
@@ -103,6 +103,10 @@
if( ACCT ) out(); 
}
 
+public void println() {
+   super.print("\r\n");
+}
+
 public void println( String str ) {
if( ACCT ) in();
super.println( str );