Re: JDBC-Session store

[Kief Morris]

Bip Thelin typed the following on 01:56 PM 3/26/2001 -0800
>According to the STATUS.html(which doesn't seem to be up to date) no one seems
>to have volunteered for the JDBC-Session store. If that is truly the case I
>would like to volunteer for that part.

Excellent! Let us know if you need any help.

Kief

Filters and Transfer-Encoding: chunked

[Robert Petersen]

I am facing a problem when useing a filter.  The problem is that the 
"Transfer-Encoding" header does not appear to be getting set.  In this case the filter 
is doing some simple xsl transformations and passing on the results to the response's 
output stream.  Unfortunatly because the content is not being chunked by Tomcat the 
socket just sits there open.

I'm not sure how tomcat knows to chunk the data.  When working with an unfiltered jsp 
page the data gets chunked as expected.  Does the filter need to do anything to 
"chunk" the data?

Thanks,
Robert Petersen

Re: [STATUS] Tomcat 3.2.2 beta 2

[Petr Jiricka]

Marc,

thanks many times for making this happen.

I would like to ask about the status of one particular issue. This is a long
outstanding issue whose one effect is that you can not serve files with file
names containing multibyte characters. I can still reproduce this problem in
3.2.2 b2. I talked to Costin about this some time ago, and from what I
understand, he thinks this problem is difficult to tackle in the 3.2 source
base, and that the solution is only possible in 3.3 and 4.0, so I don't much
hope that this can be fixed for 3.2.2 final. Either way, I think this should
be at least documented in the release notes.

To reproduce:
1) Create a file under the document base and name it so it contains
characters in a multibyte character set (Japanese, Korean, ...)
2) Type its URL into a web browser

I didn't see a bugzilla entry for this, should I create one ?

Costin, do you know anything about this issue ? Is my description accurate ?

Thanks

Petr


- Original Message -
From: "Marc Saegesser" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, March 24, 2001 12:02 AM
Subject: [STATUS] Tomcat 3.2.2 beta 2


> The tomcat_322_b2 tag is now available.  The binary and source
distributions
> have been uploaded.  I've got a couple more download tests to finish
before
> I update the website and send the announcement messages.
>
> If anyone has binaries that they want included in the distribution please
> send them to me and I'll add them to the download area.
>
> Thanks for everyone help getting this release wrapped up.
>

Listeners

[Kevin Jones]

Tomcat 4.0 stops configuring listeners if one of the listeners in the list
isn't present, should it carry on configuring the rest of the listeners it
finds? The spec is silent on this and it seems odd that if somebody (maybe
accidentally) deletes a listener class all other following listeners are not
configured (any listener preceding the missing listener would already have
been initialised).

I've also raised this as a bug,

Thanks,

Kevin

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez]

--- Steve Downey <[EMAIL PROTECTED]> wrote:
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March 26, 2001 1:08 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: TC3.3 Proposal: Refactoring
> org.apache.jasper.servlet
> > 
> > 
> > Hi Mel,
> > 
> > In my view, jasper is composed from at least 5 big
> components:
> > 
> > 1. The jsp->java translator. 
> > 
> > 2. The java->class compiler
> > 
> > 3. The Mangler ( managing name mappings )
> > 
> > 4. Runtime - that should be completely independent
> of all 
> > other pieces, 
> > since jasper-generated servlets should run without
> jasper ( as simple 
> > servlets ) 
> > 
> > 5. Interface with the serlvet container (
> JspServlet, 
> > JspInterceptor and
> > the associated classes). ( putting all other
> components togheter )
> > 
> 
> Layer 5 has to include the JspC/CommandLineXXX
> components, also. They have
> to provide an environment that looks to the rest of
> the JSP compiler like a
> web context, while actually interacting more closely
> with the filesystem. 
> 

I'm not going to make it a primary goal to fix JspC,
but I should be able to make the components reusable
so that a new version of JspC could be refactored to
use the same classes as this new version of
JspServlet. 

> Mangler needs some work, too. JspC and JspServlet
> have drifted in their
> implementations. The bane of code sharing by cut and
> paste.
> 

I will try to address this as well.

Mel

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

RE: [STATUS] Tomcat 3.2.2 beta 2

[Marc Saegesser]

Petr,

Bug 875 may be related to what your seeing.  I can duplicate this one.  Bug
463 looks like it might be the same problem.  Neither of these will be
addressed in Tomcat 3.2.2, but once that release is out the code freeze will
be lifted an we can work on addressing these and other issues.

I don't see a bug report about entering Japanese text in the URL.  Note that
RFD2396 doesn't support non-ASCII characters in URIs and also doesn't
specify what character encoding should be used for %HH escaped characters.
The Internationalization resources on the W3C site say that the preferred
encoding is UTF-8.  Can you verify that the Japanese characters you enter in
the URL are actually being correctly encoded in the HTTP request?

http://www.w3.org/International/O-URL-and-ident.html

Marc Saegesser

> -Original Message-
> From: Petr Jiricka [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2001 5:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [STATUS] Tomcat 3.2.2 beta 2
>
>
> Marc,
>
> thanks many times for making this happen.
>
> I would like to ask about the status of one particular issue.
> This is a long
> outstanding issue whose one effect is that you can not serve
> files with file
> names containing multibyte characters. I can still reproduce this
> problem in
> 3.2.2 b2. I talked to Costin about this some time ago, and from what I
> understand, he thinks this problem is difficult to tackle in the
> 3.2 source
> base, and that the solution is only possible in 3.3 and 4.0, so I
> don't much
> hope that this can be fixed for 3.2.2 final. Either way, I think
> this should
> be at least documented in the release notes.
>
> To reproduce:
> 1) Create a file under the document base and name it so it contains
> characters in a multibyte character set (Japanese, Korean, ...)
> 2) Type its URL into a web browser
>
> I didn't see a bugzilla entry for this, should I create one ?
>
> Costin, do you know anything about this issue ? Is my description
> accurate ?
>
> Thanks
>
> Petr
>
>
> - Original Message -
> From: "Marc Saegesser" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, March 24, 2001 12:02 AM
> Subject: [STATUS] Tomcat 3.2.2 beta 2
>
>
> > The tomcat_322_b2 tag is now available.  The binary and source
> distributions
> > have been uploaded.  I've got a couple more download tests to finish
> before
> > I update the website and send the announcement messages.
> >
> > If anyone has binaries that they want included in the
> distribution please
> > send them to me and I'll add them to the download area.
> >
> > Thanks for everyone help getting this release wrapped up.
> >

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez]

--- Glenn Nielsen <[EMAIL PROTECTED]> wrote:
> I have made some changes to the Jasper code in
> Tomcat 4 that
> you might want to look at.
> 

I will definitely be looking at TC 4.

> 1.  In general the Java SecurityManager
> implemenation in Tomcat 4
> and Jasper has significant improvements and is much
> cleaner.
> 

I copied some of this in my current implementation. 
Shoudn't be too hard to keep it in when I port.

> 2.  Jasper class loading is much simpler in the
> Tomcat 4 version.
> It uses a single URLClassLoader for each JSP page,
> this allowed
> me to simplify a great deal how Jasper handles
> generation of class
> and package names (no more need to do incremental
> .java and .class files).
> And it removed alot of overhead at both JSP
> translation and runtime
> when Jasper tries to figure out which incremental
> class file to use/check.
> This sped up JSP compiles by 33% and runtime
> execution by 25%.
> 

The refactoring I propose would indeed use one
class-loader per page.  My current implementation does
this leveraging a subclass of JasperLoader but I'll
explore using URLClassLoader.  I would need to make
sure that it is compatible with jdk1.1 (a tc3.3
requirement) so if I used URLClassLoader, I'd need to
provide a jdk1.1 replacement ala the way tomcat
startup does.  This actually should be pretty easy
since I'm getting the loader via a factory method.

> And before you ask, I just don't have the time to
> back port these
> changes in TC3.3.
> 

Don't worry - I totally understand this!  :-)

mel

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java

[Mel Martinez]

--- [EMAIL PROTECTED] wrote:
> > However, this does point to the need for default
> > behavior of tomcat session generation code (or any
> > interceptor or module code) in the absence of
> expected
> > configuration info in server.xml.
> 
> That's a good point, but I'm wondering how could it
> be implemented.
> The whole idea of modules is that each can be
> replaced with a better
> version ( for example a more secure or more
> efficient scheme to generate
> the ids ), so we can't just check for specific
> modules. 
> 
> Well, there is a solution ( I'm not sure how can we
> code it ) - have an
> automated way to run watchdog and sanity to validate
> the config files. If
> watchdog/sanity are passing  - then probably the
> config is valid :-)
> 

I'm not sure exactly the best way to do it here, since
I have not had the time to follow all the code
involved with session management.  However, I do know
that request.getSession() is a fundamental method of
the API that should NOT crash just because the
deployer has not specified a configuration option.  

The implementation of a specification should ALWAYS
supply a default behavior that either works gracefully
with default options OR fails gracefully while
informing the deployment engineer or developer about
the missing/incorrect configuration settings.

If SimpleSessionManager/ServletSession can not work
with a 'null' value for the Session ID, then it needs
to fail gracefully or it needs to supply a default id
generator.

Mel

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

Re: Cause found [was Re: How do I use a non-apache naming servicewith tomcat 4?]

[T. Park]

Craig,Remy,

downloading the latest nightly build resolved my problem... thanks!


...but only after I dropped that 'big everything' jar into the common/lib
folder.

So there seems to be a chicken & egg thing regarding what order certain
components need to be in
for the new tomcat to play with an alternative naming service.

My InstanceListener class goes into server/lib just fine, but the support
class (I.e. the one containing javax.naming) needs
to go in the common area.

Can you tell me why this would be? I know it's something to do with the new
classloading scheme
but I can't see why it would matter.

-Thom

"Craig R. McClanahan" wrote:

> On Mon, 26 Mar 2001, T. Park wrote:
>
> > Hi Remy,
> >
> > I'm running  tomcat 4 beta 1.
> >
> > I'll download tonight's latest build and see how I fare with that.
> >
> > Thanks so much for the support!
> >
> > -Thom
> >
> > p.s. is there a b2 drop in the near future - I'm trying to focus my
> > integration efforts on the nearest milestone build.
> >
>
> There will be soon, but I've been notified that someone is working on a
> "real" patch for the sealing violation problems under JDK 1.3 JVMs.  I'd
> like to give him a chance to finish before cutting beta 2.
>
> Since I'm going to be at O'Reilly Java Conference for the remainder of
> this week (I'm speaking at 4:15 on Thursday about Web Application
> Architectures), the earliest possible time for a beta 2 release will be
> this weekend.
>
> In the mean time, working with a recent nightly build will save you the
> time it takes to deal with issues that have already been fixed (and there
> have been around 200 CVS commits on Tomcat 4.0 since beta 1).
>
> Craig

--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html

Re: Multi-byte character support.

[Thom Park]

Kazuhiro,

thank you for your reply,
I will investigate the possibility of using tomcat 3.2.b2 -
however
it is likely I will need to await 3.2.2 milestone before
considering it
as a release candidate.
-Thom

>Thom,
>
>From: "T. Park" <[EMAIL PROTECTED]>
>Subject: Multi-byte character support.
>Date: Mon, 26 Mar 2001 10:32:31 -0800
>Message-ID: <[EMAIL PROTECTED]>
>> Tomcat 3.2[.1] doesn't seem to like static html pages (or
servlets for
>> that matter) that offer multi-byte (non-latin) characters.
>
>Tomcat 3.2.2b2 has many i18n improvements. Would you use and
check
>3.2.2b3 if possible?
>
>Of cource, a few i18n problem (for example,
ServletRequest#getProperty
>method don't return value in Unicode) isn't resolved in 3.2.2.
But
>they will resolve them in 3.3 & 4.0.
>
>Kazuhiro Kazama ([EMAIL PROTECTED])NTT Network Innovation
Laboratories
>

Re: Tag pooling impl.

[Casey Lucas]

Hey Costin,

[EMAIL PROTECTED] wrote:
> 
> Hi Casey,
> 
> There is a small problem when building with jikes. The
> TagPoolInterceptor depends on jasper runtime, which depend on the servlet
> api - I think it should be moved into the facade ( for now ). We do need a
> serious refactoring of jasper - and that would clarify a lot of
> things. There is no problem with javac, since it doesn't use
> "strict" rules.
> 

Sorry about that.  I normally don't use jikes, but I should have at least
tested with it.

What platforms to most people test with before commiting code?  I mean
besides watchdog and such.  i.e.  jdk version, jdk vendor, os,
etc.?  Just curious.

> I'll do the move if you don't mind. I like the idea of having a general
> and facade-independent pool mechanism, but we can do that later.

I definately don't mind.  True a more general pooling mechanism would
probably be better.  Baby steps for me... just getting my feet wet. :)
Thanks for your help.

-Casey

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez]

--- [EMAIL PROTECTED] wrote:
> Hi Mel,
> 
> In my view, jasper is composed from at least 5 big
> components:
> 
> 1. The jsp->java translator. 
> 
> 2. The java->class compiler
> 
> 3. The Mangler ( managing name mappings )
> 
> 4. Runtime - that should be completely independent
> of all other pieces, 
> since jasper-generated servlets should run without
> jasper ( as simple 
> servlets ) 
> 
> 5. Interface with the serlvet container (
> JspServlet, JspInterceptor and
> the associated classes). ( putting all other
> components togheter )
> 
> My understanding is that your proposal is related
> with (5), and it seems
> it has the great property that it can be done as a
> proper refactoring -
> without chaning any functionality, just by providing
> better communication
> and code organization ( as the first stage ), and
> then by creating one
> module ( that will eventually replace JspServlet ).
> 

Yes, my main concern here is with (5) although I would also like to refactor
the mangler as well.

> Since this is my favorite "modus operandis" I can't
> say anything than a
> big +1...
> 
> There are few issues:
> 
> - Impact on 3.3 release cycle. I hate delaying it -
> it's clear we
> need another milestone, but I believe in the
> "release early and often"
> ( and on schedule :-). I tried very hard to decouple
> the components as
> much as possible, so development on any component
> shouldn't affect the
> overall release ( and the rest of the code ). 
> 
> That would be resolved by your proposal to use a
> separate package name -
> the new ( "in development mode" ) code can be
> developed in a proposal
> space and released separately and be included in a
> 3.3.1 for example. 
> 
> I think keeping "old, stable" code in paralel with
> "new,
> better" implementations and doing a gradual
> replacement is a very good
> strategy ( AJP1.1 -> AJP1.2 -> Ajp1.3 -> Ajp1.4,
> mod_jserv -> mod_jk ->
> mod_jk+webapp,  facade22 -> facade23, etc ).
> 

I'm agreeable with this strategy.  What package name should we use?  This
is primarily a 'replacement' of what is in org.apache.jasper.servlet.
Should we just name it "org.apache.jasper.servlet33"?  Suggestions?


 
> - Class loading and other interfacing problems. As I
> said many times, I
> don't think JspServlet is the right way to plug
> jasper in a container, but
> a richer interface exposing more of jasper. Having a
> working JspServlet
> for quick-plugin is great, but I think we should
> rather focus on keeping
> it just a small facade to a  better designed and
> more powerfull internal
> API.  
> 

1) I don't off-hand know of any other generalized way to make a portable JSP
compiler that can be plugged into any servlet 2.2 engine other than as a
servlet.  I'm not sure how that limits us feature-wise, other than the fact
that it adds a layer of indirection between the request on the container and
the actual ultimate jsp servlet.  A small performance price to pay for
portability.

2) One major point of the refactoring is to minimize the role that the
JspServlet plays.  In the model I'm advocating it only does a couple of
things: initializes jasper (i.e., creates the JspFactory) and maintain a
cache of JspPageHandlers to which it passes the requests.  Given this, the
same role could be played by other entry mechanisms.


> In any case, a refactoring can only help, and you
> have my +1 ( i.e. I
> think it's a good idea and I'll help !).
> 
> ( BTW, I'm looking into an alternative/experimental
> implementation for the
> jsp->java component, probably after 3.3 - as a
> standalone add-on
> module. I have few ideas - but I want to first do a
> prototype )
> 
> 

Dr. Mel Martinezmailto:[EMAIL PROTECTED]
Software Architect  phone:410-423-3931
G1440, Inc. http://www.g1440.com

Re: ajp13 and tomcat restart - next (final) release + AJ13 PROPOSAL

[Dan Milstein]

Henri,

1) Moving op->recoverable -- I looked more carefully, and you're right --
the uploadmode flag is guarding against the situation I was thinking about. 
So it's fine the way it was.  One (minor) naming note -- that flag gets set
if there is more than 8K of request data, which can happen due to a file
upload, but could also just happen normally (via a few big TEXTAREA's, for
instance).  So it's more large_request_mode, than upload_mode.  Just to
mention it...

2) Adding context/webapp load/unload.

Great idea, but...  One of the biggest problems with ajp13 right now is that
there is no general way for TC to send a message to the Web Server.  The
commands you're adding would need to be sent from Tomcat to Apache, but that
can only be done once Apache has forwarded a request to Tomcat and is
waiting for a response (and a user servlet has its hands on the connection
at that point).  So I'm not sure how to add the feature you're looking for. 
If we could add that, we could also have Tomcat inform the web server of a
general shutdown, so we could be more proactive about recycling TCP
connections.

-Dan

GOMEZ Henri wrote:
> 
> >Looks about ready for more general testing.  I like the new
> >ajp13_operation.  Two things:
> >
> > 1) l. 648 (op->recoverable = JK_FALSE).
> 
> I set op->recoverable to JK_FALSE just after
> detected upload mode (dropped var)
> 
> Find included the latest .c since I miss diff cmd
> under W2K rigth now.
> 
> Where could we put code in Ajp13Interceptor which
> could be informed of context load/unload ?
> 
> I'd like to add context/webapp load/unload
> à la mod_warp :)
> 
> will be new cmds in JK :
> 
> LOADEDCONTEXT + WEBAPP STRING
> #define JK_AJP13_LOADED_CONTEXT   (unsigned char)8
> 
> UNLOADEDCONTEXT + WEBAPP STRING
> #define JK_AJP13_UNLOADED_CONTEXT (unsigned char)9
> 
> Another proposal Strongest ACL
> (LOGIN + SECRET STRING + PROTOCOL SETS)
> #define JK_AJP13_LOGIN  (unsigned char)10
> 
> Comments ?
> 
>   
> Name: jk_ajp13_worker.c
>jk_ajp13_worker.cType: unspecified type (application/octet-stream)
> Encoding: quoted-printable

-- 

Dan Milstein // [EMAIL PROTECTED]

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cmanolache]

> 
> 1) I don't off-hand know of any other generalized way to make a portable JSP
> compiler that can be plugged into any servlet 2.2 engine other than as a
> servlet.  I'm not sure how that limits us feature-wise, other than the fact
> that it adds a layer of indirection between the request on the container and
> the actual ultimate jsp servlet.  A small performance price to pay for
> portability.

The only problem is that the price is much higher that that:

- JspServlet must manage the servlet lifecycle - the container can no
longer treat jsp-generate-servlets the same as regular servlets

- initialization - how can you pass init parameters to the jsp ? This is
one of the worst hacks and source of counteless problems ( AFAIK - I
couldn't find any clean way to do that )

- class loader problems - again, the JspServlet must duplicate and
override the class loading decisions of the container - other problems and
issues


My point is that the servlet abstraction may not provide enough API
support for what jasper need - in order to make it work you have to
duplicate services that should be ofered by containers ( class loading,
init, reloading, admin, etc ).

I don't want to discourage you from doing that - any refactoring will help
and we badly need that. I just want to give you an alternate view, based
on my experience - before you repeat mistakes we've already done :-)




> 2) One major point of the refactoring is to minimize the role that the
> JspServlet plays.  In the model I'm advocating it only does a couple of
> things: initializes jasper (i.e., creates the JspFactory) and maintain a
> cache of JspPageHandlers to which it passes the requests.  Given this, the
> same role could be played by other entry mechanisms.

+1 


Costin

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup StopTomcat.java

[costin]

costin  01/03/27 12:27:42

  Modified:src/share/org/apache/tomcat/startup StopTomcat.java
  Log:
  A quick fix for StopTomcat - if the file is not found ( probably because
  we run from a different machine or tomcat was rebuilt ) but
  command-line params are present ( port for example ), we'll execute
  instead of throwing exception.( and ignore that ajp12.id is not found )
  
  Revision  ChangesPath
  1.7   +33 -27
jakarta-tomcat/src/share/org/apache/tomcat/startup/StopTomcat.java
  
  Index: StopTomcat.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/StopTomcat.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- StopTomcat.java   2001/03/25 21:53:16 1.6
  +++ StopTomcat.java   2001/03/27 20:27:41 1.7
  @@ -81,6 +81,8 @@
   String host=null;
   int port=-1;
   String secret;
  +// explicit command line params ( for port, host or secret )
  +boolean commandLineParams=false;
   
   public StopTomcat() 
   {
  @@ -135,35 +137,36 @@
   void stopTomcat() throws Exception {
String tchome=getTomcatHome();
   
  - if( secret==null ) {
  - try {
  - BufferedReader rd=new BufferedReader
  - ( new FileReader( tchome + "/conf/ajp12.id"));
  - String line=rd.readLine();
  -
  - if( port < 0 ) {
  - try {
  - port=Integer.parseInt( line );
  - } catch(NumberFormatException ex ) {
  - ex.printStackTrace();
  - }
  + // read TOMCAT_HOME/conf/ajp12.id unless command line params
  + // specify a port/host/secret
  + try {
  + BufferedReader rd=new BufferedReader
  + ( new FileReader( tchome + "/conf/ajp12.id"));
  + String line=rd.readLine();
  + 
  + if( port < 0 ) {
  + try {
  + port=Integer.parseInt( line );
  + } catch(NumberFormatException ex ) {
  + ex.printStackTrace();
}
  - 
  - line=rd.readLine();
  - if( host==null ) host=line;
  - line=rd.readLine();
  - if( secret==null ) secret=line;
  - if( "".equals( secret ) )
  - secret=null;
  - 
  - } catch( IOException ex ) {
  - //ex.printStackTrace();
  - System.out.println("Can't read " + tchome + "/conf/ajp12.id");
  - System.out.println(ex.toString());
  - return;
}
  + 
  + line=rd.readLine();
  + if( host==null ) host=line;
  + line=rd.readLine();
  + if( secret==null ) secret=line;
  + } catch( IOException ex ) {
  + //ex.printStackTrace();
  + System.out.println("Can't read " + tchome + "/conf/ajp12.id");
  + //  System.out.println(ex.toString());
  + if( ! commandLineParams )
  + return;
}
  - 
  +
  + if( "".equals( secret ) )
  + secret=null;
  + 
System.out.println("Stoping tomcat on " + host + ":" +port +" "
   + secret);
InetAddress address=null;
  @@ -257,6 +260,7 @@
}
if (arg.equals("-host") ) {
i++;
  + commandLineParams=true;
if (i < args.length)
host=args[i];
else
  @@ -264,6 +268,7 @@
}
if (arg.equals("-port") ) {
i++;
  + commandLineParams=true;
if (i < args.length)
port=Integer.parseInt( args[i] );
else
  @@ -271,7 +276,8 @@
}
if (arg.equals("-pass") ) {
i++;
  - if (i < args.length)
  + commandLineParams=true;
  + if (i < args.length) 
secret=args[i];
else
return false;
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml

[amyroh]

amyroh  01/03/27 12:34:01

  Modified:catalina/src/conf web.xml
  Log:
  Addition of SsiInvokerServlet definition and the mapping for SSI
  
  Revision  ChangesPath
  1.15  +27 -0 jakarta-tomcat-4.0/catalina/src/conf/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- web.xml   2001/03/14 22:36:36 1.14
  +++ web.xml   2001/03/27 20:34:00 1.15
  @@ -58,6 +58,27 @@
   4
 
   
  +  
  +  
  +ssi
  +org.apache.catalina.servlets.SsiInvokerServlet
  +
  +  
  +  debug
  +  0
  +
  +
  +  
  +  expires
  +  666
  +
  +
  +  
  +  buffered
  +  1
  +
  +5
  +  
   
 
 
  @@ -79,6 +100,12 @@
   *.jsp
 
   
  +  
  +  
  +ssi
  +*.shtml
  +  
  +  
 
 
   30
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi - New directory

[amyroh]

amyroh  01/03/27 12:34:28

  jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi - New directory

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets SsiInvokerServlet.java

[amyroh]

amyroh  01/03/27 12:36:50

  Added:   catalina/src/share/org/apache/catalina/servlets
SsiInvokerServlet.java
  Log:
  Servlet to process SSI requests
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java
  
  Index: SsiInvokerServlet.java
  ===
  /*
   * SsiInvokerServlet.java
   * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
 1.1 2001/03/27 20:36:50 amyroh Exp $
   * $Revision: 1.1 $
   * $Date: 2001/03/27 20:36:50 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */
  
  package org.apache.catalina.servlets;
  
  import java.io.IOException;
  import java.io.InputStream;
  import java.io.OutputStream;
  import java.io.BufferedInputStream;
  import java.io.ByteArrayOutputStream;
  import java.util.Date;
  import java.util.TimeZone;
  import java.util.Locale;
  import java.util.StringTokenizer;
  import java.text.SimpleDateFormat;
  import javax.servlet.ServletException;
  import javax.servlet.ServletContext;
  import javax.servlet.ServletOutputStream;
  import javax.servlet.http.HttpServlet;
  import javax.servlet.http.HttpServletRequest;
  import javax.servlet.http.HttpServletResponse;
  import javax.naming.directory.DirContext;
  import javax.naming.directory.Attribute;
  import javax.naming.directory.Attributes;
  import javax.naming.NamingException;
  import javax.naming.InitialContext;
  import org.apache.catalina.Globals;
  import org.apache.catalina.util.RequestUtil;
  import org.apache.catalina.util.ssi.SsiCommand;
  import org.apache.catalina.util.ssi.SsiMediator;
  import org.apache.catalina.util.ssi.ServletOutputStreamWrapper;
  import org.apache.naming.resources.Resource;
  import org.apache.naming.resources.ResourceAttributes;
  
  /**
   * Servlet to process SSI requests within a webpage.
   * Mapped to a path from within web.xml.
   *
   * @author Bip Thelin
   * @version $Revision: 1.1 $, $Date: 2001/03/27 20:36:50 $
   */
  public final class SsiInvokerServlet extends HttpServlet {
  /** Debug level for t

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi ResponseIncludeWrapper.java ServletOutputStreamWrapper.java SsiCommand.java SsiConfig.java SsiEcho.java SsiExec.java SsiFlastmod.java SsiFsize.java SsiInclude.java SsiMediator.java

[amyroh]

amyroh  01/03/27 12:38:01

  Added:   catalina/src/share/org/apache/catalina/util/ssi
ResponseIncludeWrapper.java
ServletOutputStreamWrapper.java SsiCommand.java
SsiConfig.java SsiEcho.java SsiExec.java
SsiFlastmod.java SsiFsize.java SsiInclude.java
SsiMediator.java
  Log:
  SSI feature util
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi/ResponseIncludeWrapper.java
  
  Index: ResponseIncludeWrapper.java
  ===
  /*
   * ResponseIncludeWrapper.java
   * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi/ResponseIncludeWrapper.java,v
 1.1 2001/03/27 20:38:00 amyroh Exp $
   * $Revision: 1.1 $
   * $Date: 2001/03/27 20:38:00 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */
  
  package org.apache.catalina.util.ssi;
  
  import java.io.OutputStream;
  import java.io.PrintWriter;
  import javax.servlet.ServletOutputStream;
  import javax.servlet.http.HttpServletResponse;
  import javax.servlet.http.HttpServletResponseWrapper;
  
  /**
   * @author Bip Thelin
   * @version $Revision: 1.1 $, $Date: 2001/03/27 20:38:00 $
   *
   */
  public final class ResponseIncludeWrapper
  extends HttpServletResponseWrapper {
  
  private ServletOutputStream _out;
  
  private boolean printwriter = false;
  
  private boolean outputstream = false;
  
  public ResponseIncludeWrapper(HttpServletResponse res,
  ServletOutputStream out) {
super(res);
this._out = out;
  }
  
  public PrintWriter getWriter()
throws java.io.IOException {
if(!outputstream) {
printwriter=true;
return (new PrintWriter(_out));
} else {
throw new IllegalStateException();
}
  }
  
  public ServletOutputStream getOutputStream()
throws java.io.IOException {
if(!printwriter) {
outputstream=true;
return _out;
} else {
t

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets SsiInvokerServlet.java

[amyroh]

amyroh  01/03/27 12:44:25

  Modified:catalina/src/share/org/apache/catalina/servlets
SsiInvokerServlet.java
  Log:
  Update submitted by Bip Thelin --
  "changed any dependencies on Craig's ResourceInfo class which I included as an 
Inline class.  This makes the code more streamlined and maintainable."
  
  Revision  ChangesPath
  1.2   +7 -161
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java
  
  Index: SsiInvokerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SsiInvokerServlet.java2001/03/27 20:36:50 1.1
  +++ SsiInvokerServlet.java2001/03/27 20:44:24 1.2
  @@ -1,8 +1,8 @@
   /*
* SsiInvokerServlet.java
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
 1.1 2001/03/27 20:36:50 amyroh Exp $
  - * $Revision: 1.1 $
  - * $Date: 2001/03/27 20:36:50 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
 1.2 2001/03/27 20:44:24 amyroh Exp $
  + * $Revision: 1.2 $
  + * $Date: 2001/03/27 20:44:24 $
*
* 
*
  @@ -69,6 +69,8 @@
   import java.io.OutputStream;
   import java.io.BufferedInputStream;
   import java.io.ByteArrayOutputStream;
  +import java.net.URL;
  +import java.net.URLConnection;
   import java.util.Date;
   import java.util.TimeZone;
   import java.util.Locale;
  @@ -90,15 +92,13 @@
   import org.apache.catalina.util.ssi.SsiCommand;
   import org.apache.catalina.util.ssi.SsiMediator;
   import org.apache.catalina.util.ssi.ServletOutputStreamWrapper;
  -import org.apache.naming.resources.Resource;
  -import org.apache.naming.resources.ResourceAttributes;
   
   /**
* Servlet to process SSI requests within a webpage.
* Mapped to a path from within web.xml.
*
* @author Bip Thelin
  - * @version $Revision: 1.1 $, $Date: 2001/03/27 20:36:50 $
  + * @version $Revision: 1.2 $, $Date: 2001/03/27 20:44:24 $
*/
   public final class SsiInvokerServlet extends HttpServlet {
   /** Debug level for this servlet. */
  @@ -113,17 +113,6 @@
   /** The Mediator object for the SsiCommands. */
   private static SsiMediator ssiMediator = null;
   
  -/** JNDI resources name. */
  -protected static final String RESOURCES_JNDI_NAME = "java:/comp/Resources";
  -
  -/** The set of SimpleDateFormat formats to use in getDateHeader(). */
  -protected static final SimpleDateFormat[] formats = {
  - new SimpleDateFormat("EEE, dd MMM  HH:mm:ss zzz", Locale.US),
  - new SimpleDateFormat("EE, dd-MMM-yy HH:mm:ss zzz", Locale.US),
  - new SimpleDateFormat("EEE  d HH:mm:ss ", Locale.US)
  -};
  -protected final static TimeZone gmtZone = TimeZone.getTimeZone("GMT");
  -
   /** The start pattern */
   private final static byte[] bStart = {
(byte)'<',(byte)'!',(byte)'-',(byte)'-',(byte)'#'
  @@ -134,11 +123,6 @@
(byte)'-',(byte)'-',(byte)'>'
   };
   
  -static {
  -formats[0].setTimeZone(gmtZone);
  -formats[1].setTimeZone(gmtZone);
  -formats[2].setTimeZone(gmtZone);
  -}
   //- Public methods.
   
   /**
  @@ -154,7 +138,6 @@
   ;
   }
   try {
  -// adapted from JSSI
   value = getServletConfig().getInitParameter("expires");
   expires = Long.valueOf(value);
   } catch (NumberFormatException e) {
  @@ -219,10 +202,9 @@
HttpServletResponse res)
throws IOException, ServletException {
   
  -DirContext resources = getResources();
   ServletContext servletContext = getServletContext();
   String path = getRelativePath(req);
  -ResourceInfo resourceInfo = new ResourceInfo(path, resources);
  + URL resource = servletContext.getResource(path);
   
   if (debug > 0)
   log("SsiInvokerServlet.requestHandler()\n" +
  @@ -239,7 +221,7 @@
   return;
   }
   
  - if (!resourceInfo.exists) {
  + if (resource==null) {
res.sendError(res.SC_NOT_FOUND, path);
return;
}
  @@ -250,12 +232,12 @@
   }
   
   OutputStream out = null;
  -InputStream resourceInputStream =
  - servletContext.getResourceAsStream(path);
  + URLConnection resourceInfo = resource.openConnection();
  +InputStream resourceInputStream = resourceInfo.getInputStream();
   
   InputStream in = new BufferedInputStream(resourceInputStream, 4096);
   ByteArrayOutputStream soonOut =
  - new By

SSI feature addition to tomcat4 by Bip Thelin

[Amy Roh]

Thanks to great work by Bip Thelin, SSI feature is now added to tomcat
4.  Stay tune for CGI/SSI exec command.

Amy

cvs commit: jakarta-tomcat/src/doc Tomcat-on-NetWare-HowTo.html

[marcsaeg]

marcsaeg01/03/27 13:29:30

  Added:   src/doc  Tag: tomcat_32 Tomcat-on-NetWare-HowTo.html
  Log:
  Adding new "how to" document for Tomcat on NetWare.
  
  Submitted by:Mike Anderson [[EMAIL PROTECTED]]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +348 -0jakarta-tomcat/src/doc/Attic/Tomcat-on-NetWare-HowTo.html
  
  
  
  

cvs commit: jakarta-tomcat/src/native/netscape Makefile.nw

[marcsaeg]

marcsaeg01/03/27 13:31:44

  Modified:src/native/apache1.3 Tag: tomcat_32 Makefile.nw
   src/native/jni_connect Tag: tomcat_32 Makefile.nw
   src/native/netscape Tag: tomcat_32 Makefile.nw
  Log:
  Updated makefiles for building connectors for the NetWare platform.
  
  Submitted by:  Mike Anderson [[EMAIL PROTECTED]]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.2   +40 -16jakarta-tomcat/src/native/apache1.3/Attic/Makefile.nw
  
  Index: Makefile.nw
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/apache1.3/Attic/Makefile.nw,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- Makefile.nw   2000/09/13 23:06:20 1.1.2.1
  +++ Makefile.nw   2001/03/27 21:31:44 1.1.2.2
  @@ -1,13 +1,36 @@
  +ifndef VERBOSE
   .SILENT:
  +endif
   
   NLM_NAME=mod_jk
  +
  +#
  +# Base environment
  +#
  +ifndef TOOLPATH
  +TOOLPATH = D:\Tools
  +endif
   
  -JDKPATH=k:\jdk\jdk-1_2_2
  -NOVELLNDK=r:\nwsdk
  -APACHE_HOME=d:\apache_1.3.12\src
  -WINSOCK_INCDIR=k:\ws295sdk\include
  -METROWERKSPATH=k:\mw\5.3
  +ifndef JDKPATH
  +JDKPATH=$(TOOLPATH)\jdk\jdk-1_2_2
  +endif
   
  +ifndef NOVELLNDK
  +NOVELLNDK=$(TOOLPATH)\nwsdk
  +endif
  +
  +ifndef APACHE_SRC
  +APACHE_SRC=d:\apache_1.3.17\src
  +endif
  +
  +ifndef METROWERKSPATH
  +METROWERKSPATH=$(TOOLPATH)\mw\5.3
  +endif
  +
  +ifndef WINSOCK_INCDIR
  +WINSOCK_INCDIR=$(NOVELLNDK)\include\winsock
  +endif
  +
   CC=$(METROWERKSPATH)\bin\mwccnlm
   LINK=$(METROWERKSPATH)\bin\mwldnlm
   
  @@ -43,7 +66,7 @@
@$(CC) $< -o=$(@F) @cc.opt

   cc.opt: Makefile.nw
  - -@del cc.opt 2> NUL
  + -@del cc.opt > NUL
@echo Generating $@
@echo -nosyspath -ext obj -c -align 1 -w nocmdline -bool on >> $@
   ifdef DEBUG
  @@ -56,16 +79,17 @@
@echo -I$(METROWERKSPATH)\include >> $@
@echo -I$(JDKPATH)\include >> $@
@echo -I$(JDKPATH)\include\netware >> $@
  - @echo -I$(APACHE_HOME)\include >> $@
  - @echo -I$(APACHE_HOME)\os\netware >> $@
  + @echo -I$(APACHE_SRC)\include >> $@
  + @echo -I$(APACHE_SRC)\os\netware >> $@
@echo -I$(WINSOCK_INCDIR) >> $@
@echo -DN_PLAT_NLM >> $@
@echo -DNETWARE >> $@
@echo -DXP_NETWARE >> $@
   
   link.opt: Makefile.nw
  - -@del link.opt 2> NUL
  - -@del link.def 2> NUL
  + -@del link.opt > NUL
  + -@del link.def > NUL
  + @echo Generating $@
@echo -warnings off >> $@
@echo -zerobss >> $@
@echo -desc "Apache 1.3 Plugin for Tomcat" >> $@
  @@ -91,13 +115,13 @@
@echo Import @$(NOVELLNDK)\imports\threads.imp >> link.def
@echo Import @$(NOVELLNDK)\imports\socklib.imp >> link.def
@echo Import @$(NOVELLNDK)\imports\ws2nlm.imp >> link.def
  - @echo Import @$(APACHE_HOME)\os\netware\ApacheCore.imp >> link.def
  + @echo Import @$(APACHE_SRC)\os\netware\ApacheCore.imp >> link.def
@echo Export jk_module >> link.def
   
   clean:
  - -@del *.obj 2> NUL
  - -@del *.map 2> NUL
  - -@del link.* 2> NUL
  - -@del cc.opt 2> NUL
  - -@del *.nlm 2> NUL
  + -@del *.obj > NUL
  + -@del *.map > NUL
  + -@del link.* > NUL
  + -@del cc.opt > NUL
  + -@del *.nlm > NUL

  
  
  
  No   revision
  
  
  No   revision
  
  
  1.1.2.2   +29 -11jakarta-tomcat/src/native/jni_connect/Attic/Makefile.nw
  
  Index: Makefile.nw
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/jni_connect/Attic/Makefile.nw,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- Makefile.nw   2000/09/13 23:06:28 1.1.2.1
  +++ Makefile.nw   2001/03/27 21:31:44 1.1.2.2
  @@ -1,11 +1,28 @@
  +ifndef VERBOSE
   .SILENT:
  +endif
   
   NLM_NAME=jni_conn
   
  -JDKPATH=k:\jdk\jdk-1_2_2
  -NOVELLNDK=r:\nwsdk
  -METROWERKSPATH=k:\mw\5.3
  +#
  +# Base environment
  +#
  +ifndef TOOLPATH
  +TOOLPATH = D:\Tools
  +endif
   
  +ifndef JDKPATH
  +JDKPATH=$(TOOLPATH)\jdk\jdk-1_2_2
  +endif
  +
  +ifndef NOVELLNDK
  +NOVELLNDK=$(TOOLPATH)\nwsdk
  +endif
  +
  +ifndef METROWERKSPATH
  +METROWERKSPATH=$(TOOLPATH)\mw\5.3
  +endif
  +
   CC=$(METROWERKSPATH)\bin\mwccnlm
   LINK=$(METROWERKSPATH)\bin\mwldnlm
   
  @@ -33,7 +50,7 @@

   
   cc.opt: Makefile.nw
  - -@del cc.opt 2> NUL
  + -@del cc.opt > NUL
@echo Generating $@
@echo -nosyspath -ext obj -c -align 1 -w nocmdline -bool on >> $@
   ifdef DEBUG
  @@ -51,8 +68,9 @@
@echo -DXP_NETWARE >> $@

   link.opt: Makefile.nw
  - -@del link.opt 2> NUL
  - -@del link.def 2> NUL
  + -@del link.opt > NUL
  + -@del link.def > NUL
  + @echo Generating $@
@echo -warnings off >> $@
@e

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez]

--- [EMAIL PROTECTED] wrote:
> > 
> > 1) I don't off-hand know of any other generalized
> way to make a portable JSP
> > compiler that can be plugged into any servlet 2.2
> engine other than as a
> > servlet.  I'm not sure how that limits us
> feature-wise, other than the fact
> > that it adds a layer of indirection between the
> request on the container and
> > the actual ultimate jsp servlet.  A small
> performance price to pay for
> > portability.
> 
> The only problem is that the price is much higher
> that that:
> 
> - JspServlet must manage the servlet lifecycle - the
> container can no
> longer treat jsp-generate-servlets the same as
> regular servlets
> 

This is a limitation of the servlet api and thus the
lack of access to a consistent set of servlet engine
features necessary for full servlet life-cycle
management that can be relied upon.  Besides, who said
that the container was guaranteed full-lifecycle
management of ANY servlet?  Any servlet could be
created/loaded dynamically and managed by some other
servlet without the container ever knowing about it
(assuming the SecurityManager allowed it, of course
:-).

> - initialization - how can you pass init parameters
> to the jsp ? This is
> one of the worst hacks and source of counteless
> problems ( AFAIK - I
> couldn't find any clean way to do that )
> 

How exactly do you solve this with JspInterceptor? 
The specification doesn't really seem to cover
init-params for individual JSP pages.  The JSP
container has no responsibility to provide
individualized init-params for JSP servlets, only to
invoke jspInit() prior to service().  In the absence
of a specified mechanism, it is the responsibility of
the JSP page author to initialize his page by
implementing the jspInit() method (from which he/she
can optionally load params from whereever he/she sees
fit).

In other words, this is not a limitation of
JspServlet, but rather a limitation of the JSP
specification.

> - class loader problems - again, the JspServlet must
> duplicate and
> override the class loading decisions of the
> container - other problems and
> issues
> 

This, again is more a limitation (or too much freedom)
in how servlet containers are implemented.

> 
> My point is that the servlet abstraction may not
> provide enough API
> support for what jasper need - in order to make it
> work you have to
> duplicate services that should be ofered by
> containers ( class loading,
> init, reloading, admin, etc ).
> 

The glass is half-full as well - because at least with
the servlet api it is _possible_ to implement those
services portably and thus provide a portable JSP
compiler.

And yes, it would be great if the JspServlet didn't
have to implement redundant container services, that
in no way really limits JspServlet's ability to
fullfill all JSP specification features.

And again - what is the alternative?  I can't write a
JspInterceptor solution for WebLogic or JRun.

> I don't want to discourage you from doing that - any
> refactoring will help
> and we badly need that. I just want to give you an
> alternate view, based
> on my experience - before you repeat mistakes we've
> already done :-)
> 

The mistakes aren't in using a servlet-based approach.
 This sort of feature (a plug-in to provid jsp
compilation and loading services to a web server) is
exactly what servlets are for.  This in itself in no
way limits what you can do with JSPs because all
features of the JSP spec should be attainable through
a servlet implementation.

This DOES limit the reliance Jasper can have on
value-added container features beyond the servlet API,
but hey, you have to draw the line somewhere.

The way to look at it is that a JspInterceptor-style
solution is a value-added feature of the tomcat
servlet engine.  That is a positive.  The portability
of JspServlet is also a positive.

Cheers,

Mel


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_util.c jk_util.h

[hgomez]

hgomez  01/03/27 13:58:26

  Modified:src/native/mod_jk/common jk_util.c jk_util.h
  Log:
  Add time stamp support in mod_jk.log
  
  Revision  ChangesPath
  1.5   +39 -5 jakarta-tomcat/src/native/mod_jk/common/jk_util.c
  
  Index: jk_util.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_util.c,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jk_util.c 2001/02/05 23:22:04 1.4
  +++ jk_util.c 2001/03/27 21:58:26 1.5
  @@ -55,8 +55,9 @@
   
   /***
* Description: Utility functions (mainly configuration)   *
  + * Author:  Henri Gomez <[EMAIL PROTECTED]>   *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.4 $   *
  + * Version: $Revision: 1.5 $   *
***/
   
   
  @@ -86,6 +87,7 @@
   #define DEFAULT_WORKER  JK_AJP12_WORKER_NAME
   #define WORKER_LIST_PROPERTY_NAME   ("worker.list")
   #define DEFAULT_LB_FACTOR   (1.0)
  +#define LOG_FORMAT   ("log_format")
   
   #define HUGE_BUFFER_SIZE (8*1024)
   #define LOG_LINE_SIZE(1024)
  @@ -95,6 +97,27 @@
   };
   typedef struct file_logger file_logger_t;
   
  +/* 
  + * define the log format, we're using by default the one from error.log 
  + *
  + * [Mon Mar 26 19:44:48 2001] [jk_uri_worker_map.c (155)]: Into 
jk_uri_worker_map_t::uri_worker_map_alloc
  + * log format used by apache in error.log
  + */
  +#ifndef JK_TIME_FORMAT 
  +#define JK_TIME_FORMAT "[%a %b %d %H:%M:%S %Y] "
  +#endif
  +
  +char * jk_log_fmt = JK_TIME_FORMAT;
  +
  +static void set_time_str(char * str, int len)
  +{
  + time_t  t = time(NULL);
  + struct tm   *tms;
  +
  + tms = localtime(&t);
  + strftime(str, len, jk_log_fmt, tms);
  +}
  +
   static int JK_METHOD log_to_file(jk_logger_t *l, 
int level,
const char *what)
  @@ -211,17 +234,23 @@
   if(f != file) {
   f++;
   }
  -   
  +
   #ifdef WIN32
  -used = _snprintf(buf, HUGE_BUFFER_SIZE, "[%s (%d)]: ", f, line);
  + set_time_str(buf, HUGE_BUFFER_SIZE);
  + used = strlen(buf);
  +used += _snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, line);   
 
   #elif defined(NETWARE) // until we get a snprintf function
   buf = (char *) malloc(HUGE_BUFFER_SIZE);
   if (NULL == buf)
  return -1;
   
  -used = sprintf(buf, "[%s (%d)]: ", f, line);
  + set_time_str(buf, HUGE_BUFFER_SIZE);
  + used = strlen(buf);
  +used += sprintf(&buf[used], " [%s (%d)]: ", f, line);
   #else 
  -used = snprintf(buf, HUGE_BUFFER_SIZE, "[%s (%d)]: ", f, line);
  + set_time_str(buf, HUGE_BUFFER_SIZE);
  + used = strlen(buf);
  +used += snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, line);

   #endif
   if(used < 0) {
   return 0; /* [V] not sure what to return... */
  @@ -363,6 +392,11 @@
   }
   
   return JK_FALSE;
  +}
  +
  +void jk_set_log_format(char * logformat)
  +{
  + jk_log_fmt = (logformat) ? logformat : JK_TIME_FORMAT;
   }
   
   double jk_get_lb_factor(jk_map_t *m, 
  
  
  
  1.3   +3 -1  jakarta-tomcat/src/native/mod_jk/common/jk_util.h
  
  Index: jk_util.h
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_util.h,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jk_util.h 2000/11/10 18:48:50 1.2
  +++ jk_util.h 2001/03/27 21:58:26 1.3
  @@ -56,7 +56,7 @@
   /***
* Description: Various utility functions  *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.2 $   *
  + * Version: $Revision: 1.3 $   *
***/
   #ifndef _JK_UTIL_H
   #define _JK_UTIL_H
  @@ -106,6 +106,8 @@
   int jk_get_worker_cache_size(jk_map_t *m, 
const char *wname,
int def);
  +
  +void jk_set_log_format(char *logformat);
   
   int jk_get_worker_list(jk_map_t *m,
  char ***list,
  
  
  

cvs commit: jakarta-tomcat/src/native/mod_jk/apache1.3 mod_jk.c

[hgomez]

hgomez  01/03/27 14:01:20

  Modified:src/native/mod_jk/apache1.3 mod_jk.c
  Log:
  Add support for timestamp in mod_jk.log
  New var is JkLogStampFormat and use strftime
  format ie : "[%a %b %d %H:%M:%S %Y] "
  nota the " " to make it a single param
  
  Revision  ChangesPath
  1.7   +11 -1 jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- mod_jk.c  2001/03/21 07:12:26 1.6
  +++ mod_jk.c  2001/03/27 22:01:18 1.7
  @@ -58,6 +58,7 @@
*  See ../common/jk_service.h for general mod_jk info *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
*  Dan Milstein <[EMAIL PROTECTED]>*
  + *  Henri Gomez <[EMAIL PROTECTED]>   *
* Version: $ $*
***/
   
  @@ -698,6 +699,14 @@
   }
   
   
  +static const char * jk_set_log_fmt(cmd_parms *cmd,
  +void *dummy,
  +char * log_format)
  +{
  + jk_set_log_format(log_format);
  + return NULL;
  +}
  +
   static const command_rec jk_cmds[] =
   {
   /*
  @@ -729,7 +738,8 @@
"Full path to the Jakarta Tomcat module log file"},
   {"JkLogLevel", jk_set_log_level, NULL, RSRC_CONF, TAKE1,
"The Jakarta Tomcat module log level, can be debug, info, error or emerg"},
  -
  +{"JkLogStampFormat", jk_set_log_fmt, NULL, RSRC_CONF, TAKE1,
  + "The Jakarta Tomcat module log format, follow strftime synthax"},
   /*
* Apache has multiple SSL modules (for example apache_ssl, stronghold
* IHS ...). Each of these can have a different SSL environment names
  
  
  

cvs commit: jakarta-tomcat/src/native/mod_jk/apache2.0 mod_jk.c

[hgomez]

hgomez  01/03/27 14:02:36

  Modified:src/native/mod_jk/apache2.0 mod_jk.c
  Log:
  Add support for timestamp in mod_jk.log
  New var is JkLogStampFormat and use strftime
  format ie : "[%a %b %d %H:%M:%S %Y] "
  nota the " " to make it a single param
  Also since Apache 2.0 alpha 15, ap_get_remote_host
  need another param
  
  Revision  ChangesPath
  1.10  +14 -4 jakarta-tomcat/src/native/mod_jk/apache2.0/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache2.0/mod_jk.c,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- mod_jk.c  2001/03/13 23:34:33 1.9
  +++ mod_jk.c  2001/03/27 22:02:34 1.10
  @@ -327,7 +327,7 @@
   
   s->protocol = r->protocol;
   s->remote_host  = (char *)ap_get_remote_host(r->connection,
  - r->per_dir_config,
  + r->per_dir_config, REMOTE_NAME,
   
  REMOTE_HOST);
   
   s->remote_host  = NULL_FOR_EMPTY(s->remote_host);
  @@ -448,7 +448,7 @@
   return NULL;
   }
   
  -static const char *jk_set_wroker_file(cmd_parms *cmd, 
  +static const char *jk_set_worker_file(cmd_parms *cmd, 
 void *dummy, 
 char *worker_file)
   {
  @@ -487,9 +487,17 @@
   return NULL;
   }
   
  +static const char * jk_set_log_fmt(cmd_parms *cmd,
  +   void *dummy,
  +   char * log_format)
  +{
  + jk_set_log_format(log_format);
  + return NULL;
  +}
  + 
   static const command_rec jk_cmds[] =
   {
  -{"JkWorkersFile", jk_set_wroker_file, NULL, RSRC_CONF, TAKE1,
  +{"JkWorkersFile", jk_set_worker_file, NULL, RSRC_CONF, TAKE1,
"the name of a worker file for the Jakarta servlet containers"},
   {"JkMount", jk_mount_context, NULL, RSRC_CONF, TAKE23,
"A mount point from a context to a Tomcat worker"},
  @@ -499,6 +507,8 @@
"Full path to the Jakarta Tomcat module log file"},
   {"JkLogLevel", jk_set_log_level, NULL, RSRC_CONF, TAKE1,
"The Jakarta Tomcat module log level, can be debug, info, error or emerg"},
  +{"JkLogStampFormat", jk_set_log_fmt, NULL, RSRC_CONF, TAKE1,
  + "The Jakarta Tomcat module log format, follow strftime synthax"},
   {NULL}
   };
   
  @@ -725,7 +735,7 @@
   
   if(map_alloc(&init_map)) {
   if(map_read_properties(init_map, conf->worker_file)) {
  - ap_add_version_component(pconf, 
"mod_jk");
  + ap_add_version_component(pconf, "mod_jk");
   if(wc_open(init_map, conf->log)) {
   return;
   }
  
  
  

jk_ajp13_worker.c

[GOMEZ Henri]

Could I commit the latest jk_ajp13_worker.c I send to list ?

It works fine for more than 1 week...

ajp1X protocol security

[Ian Kallen <[EMAIL PROTECTED]>]

I'm just recently getting more intimate with Tomcat's architecture and I'm
wondering what provisions and plans are in place for security in the
protocols btw http servers and the servlet engine.  What are the
vulnerabilities now and how are people using Tomcat in production
protecting themselves?  Firewalling access to ports 8007/8009?  Sorry if
this is a FAQ, I just didn't a clear definition of the status and the
future plans documented anywhere.

cheers,
-Ian

--
Ian Kallen <[EMAIL PROTECTED]> | AIM: iankallen

Re: jk_ajp13_worker.c

[Dan Milstein]

I would say go for it.  It's a hotly desired feature, so hopefully it will
see some good testing.

Nice work,
-Dan

GOMEZ Henri wrote:
> 
> Could I commit the latest jk_ajp13_worker.c I send to list ?
> 
> It works fine for more than 1 week...

-- 

Dan Milstein // [EMAIL PROTECTED]

RE: ajp1X protocol security

[GOMEZ Henri]

>I'm just recently getting more intimate with Tomcat's 
>architecture and I'm
>wondering what provisions and plans are in place for security in the
>protocols btw http servers and the servlet engine.  What are the
>vulnerabilities now and how are people using Tomcat in production
>protecting themselves?  Firewalling access to ports 8007/8009? 
> Sorry if
>this is a FAQ, I just didn't a clear definition of the status and the
>future plans documented anywhere.

Welcome you Covalent ;)

I proposed sometimes ago to add strongest ACL to ajp13 along
with many protocols add-ons.

ajp13 didn't use a login mechanism between Apache and TC.
Something to add. 

RE: jk_ajp13_worker.c

[GOMEZ Henri]

I commit NOW :-)

"Entre truands, les bénéfices, ça se partage, la réclusion, ça
s'additionne."
-- Michel Audiard
 

>-Original Message-
>From: Dan Milstein [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, March 28, 2001 12:28 AM
>To: [EMAIL PROTECTED]
>Subject: Re: jk_ajp13_worker.c
>
>
>I would say go for it.  It's a hotly desired feature, so 
>hopefully it will
>see some good testing.
>
>Nice work,
>-Dan
>
>GOMEZ Henri wrote:
>> 
>> Could I commit the latest jk_ajp13_worker.c I send to list ?
>> 
>> It works fine for more than 1 week...
>
>-- 
>
>Dan Milstein // [EMAIL PROTECTED]
>

cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_ajp13_worker.c

[hgomez]

hgomez  01/03/27 14:42:04

  Modified:src/native/mod_jk/common jk_ajp13_worker.c
  Log:
  The long awaited :) correction to tomcat restart problem.
  No need to restart apache now
  Will need a little adjustement, ie instead of 3
  fixed loop try to connect 2 * times the numbers of
  workers matching the requested URL (Dan ?)
  
  Revision  ChangesPath
  1.6   +224 -111  jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c
  
  Index: jk_ajp13_worker.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_ajp13_worker.c 2001/03/06 20:22:22 1.5
  +++ jk_ajp13_worker.c 2001/03/27 22:42:04 1.6
  @@ -54,10 +54,11 @@
*/
   
   /***
  - * Description: Bi-directional protocol.   *
  + * Description: Bi-directional protocol.   *
  + * Author:  Henri Gomez <[EMAIL PROTECTED]>   *
* Author:  Costin <[EMAIL PROTECTED]>  *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.5 $   *
  + * Version: $Revision: 1.6 $   *
***/
   
   #include "jk_pool.h"
  @@ -75,6 +76,9 @@
   #define JK_INTERNAL_ERROR   (-2)
   #define MAX_SEND_BODY_SZ(DEF_BUFFER_SZ - 6)
   
  +struct ajp13_operation;
  +typedef struct ajp13_operation ajp13_operation_t;
  +
   struct ajp13_endpoint;
   typedef struct ajp13_endpoint ajp13_endpoint_t;
   
  @@ -111,6 +115,18 @@
   unsigned left_bytes_to_send;
   };
   
  +/* 
  + * little struct to avoid multiples ptr passing
  + * this struct is ready to hold upload file fd
  + * to add upload persistant storage
  + */
  +struct ajp13_operation {
  + jk_msg_buf_t*request;   /* original request storage */
  + jk_msg_buf_t*reply; /* reply storage (chuncked by ajp13 */
  + int uploadfd;   /* future persistant storage id */
  + int recoverable;/* if exchange could be conducted on another 
TC */
  +};
  +
   static void reset_endpoint(ajp13_endpoint_t *ep)
   {
   ep->reuse = JK_FALSE; 
  @@ -343,6 +359,7 @@
len = 0;
}
   
  + /* the right place to add file storage for upload */
if(read_into_msg_buff(ep, r, msg, l, len)) {
r->content_read += len;
return JK_AJP13_HAS_RESPONSE;
  @@ -529,123 +546,219 @@
  "In jk_endpoint_t::done, NULL parameters\n");
   return JK_FALSE;
   }
  -
  -static int JK_METHOD service(jk_endpoint_t *e, 
  - jk_ws_service_t *s,
  - jk_logger_t *l,
  - int *is_recoverable_error)
  -{
  -jk_log(l, 
  -   JK_LOG_DEBUG, 
  -   "Into jk_endpoint_t::service\n");
   
  -if(e && e->endpoint_private && s && is_recoverable_error) {
  -ajp13_endpoint_t *p = e->endpoint_private;
  -jk_msg_buf_t *msg = jk_b_new(&(p->pool));
  +/*
  + * send request to Tomcat via Ajp13
  + * - first try to find reuseable socket
  + * - if no one available, try to connect
  + * - send request, but send must be see as asynchronous,
  + *   since send() call will return noerror about 95% of time
  + *   Hopefully we'll get more information on next read.
  + * 
  + * nb: reqmsg is the original request msg buffer
  + * repmsg is the reply msg buffer which could be scratched
  + */
  +static int send_request(jk_endpoint_t *e,
  + jk_ws_service_t *s,
  + jk_logger_t *l,
  + ajp13_endpoint_t *p,
  + ajp13_operation_t *op)
  +{
  + /*
  +  * First try to reuse open connections...
  + */
  + while((p->sd > 0) && !connection_tcp_send_message(p, op->request, l)) {
  + jk_log(l, JK_LOG_ERROR, "Error sending request try another pooled 
connection\n");
  + jk_close_socket(p->sd);
  + p->sd = -1;
  + reuse_connection(p, l);
  + }
  +
  + /*
  +  * If we failed to reuse a connection, try to reconnect.
  +  */
  + if(p->sd < 0) {
  + connect_to_tomcat(p, l);
  + if(p->sd >= 0) {
  + /*
  +  * After we are connected, each error that we are going to
  +  * have is probably unrecoverable
  +  */
  + op->recoverable = JK_FALSE;
  + if(!connection_t

RE: jk_ajp13_worker.c

[GOMEZ Henri]

What about my previous propositions on ajp13 extensions
which may became ajp14

"Entre truands, les bénéfices, ça se partage, la réclusion, ça
s'additionne."
-- Michel Audiard
 

>-Original Message-
>From: Dan Milstein [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, March 28, 2001 12:28 AM
>To: [EMAIL PROTECTED]
>Subject: Re: jk_ajp13_worker.c
>
>
>I would say go for it.  It's a hotly desired feature, so 
>hopefully it will
>see some good testing.
>
>Nice work,
>-Dan
>
>GOMEZ Henri wrote:
>> 
>> Could I commit the latest jk_ajp13_worker.c I send to list ?
>> 
>> It works fine for more than 1 week...
>
>-- 
>
>Dan Milstein // [EMAIL PROTECTED]
>

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cmanolache]

> > - JspServlet must manage the servlet lifecycle - the container can no
> > longer treat jsp-generate-servlets the same as regular servlets
> > 
> 
> This is a limitation of the servlet api and thus the
> lack of access to a consistent set of servlet engine
> features necessary for full servlet life-cycle
> management that can be relied upon.  Besides, who said
> that the container was guaranteed full-lifecycle
> management of ANY servlet?  Any servlet could be
> created/loaded dynamically and managed by some other
> servlet without the container ever knowing about it
> (assuming the SecurityManager allowed it, of course
> :-).


True, but a container can be smart ( and unload unused
servlets, provide nice monitoring, etc ). 


> > - initialization - how can you pass init parameters to the jsp ? This is
> > one of the worst hacks and source of counteless problems ( AFAIK - I
> > couldn't find any clean way to do that )
> > 
> 
> How exactly do you solve this with JspInterceptor?

A JSP is treated the same way as a servlet - it gets a 
ServletConfig with the right info from web.xml, etc.

There is no distinction between the way a regular servlet
is treated and a jasper-generated servlet.

 
> The specification doesn't really seem to cover
> init-params for individual JSP pages.  The JSP

??? 

/foo.jsp
foo..

AFAIK you should be able to define init params for jsps the same
as you do for servlets ( unless I'm missing something here).


> container has no responsibility to provide
> individualized init-params for JSP servlets, only to
> invoke jspInit() prior to service().  In the absence

I thought it does... Even tought that never worked 
very well :-) 


> The glass is half-full as well - because at least with
> the servlet api it is _possible_ to implement those
> services portably and thus provide a portable JSP
> compiler.

Almost everything is possible ( in a turing machine :-).
The problem is at what cost, and if that's the best 
solution. 


> And again - what is the alternative?  I can't write a
> JspInterceptor solution for WebLogic or JRun.

Unfortunately that's true - and it's a good reason to
have JspServlet. 

But if you have control over the servlet container ( 
for example using an internal extension mechanism -
like the interceptor in tc3 or valve in tc4 ) it would
be much better to use a rich API that allows full control
over jasper, and lets the container do what it is 
supposed to do - manage servlets.

> The mistakes aren't in using a servlet-based approach.
>  This sort of feature (a plug-in to provid jsp
> compilation and loading services to a web server) is
> exactly what servlets are for.  This in itself in no
> way limits what you can do with JSPs because all
> features of the JSP spec should be attainable through
> a servlet implementation.

I'm still looking for a solution to deal with the init-param
( except for re-parsing web.xml )

I'm not saying it's a mistake to have a servlet-based
approach, but that having a full API and letting the 
container manager servlets and jasper do the compilation
could be a better solution.


> The way to look at it is that a JspInterceptor-style
> solution is a value-added feature of the tomcat
> servlet engine.  That is a positive.  The portability
> of JspServlet is also a positive.

+1 

( and to my defense - I did the fixes to allow JspServlet
to be still be used in tomcat 3.3, for people who want
a slower jsp :-)

Mel, what I'm trying to explain is not that JspServlet is bad,
but that we need a refactoring to expose more if Jasper API
and cleanly separate the components - so we can use
JspServlet and interceptors ( or valves ).

A lot of the code in jasper is written with the assumption
that JspServlet is the entry point ( i.e. with workarounds 
and hacks for this case ) - and then we have JspC and JspInterceptor that
adds another round of hacks and workarounds. 

And it would help a lot to keep this in mind while doing the refactoring -
i.e. to distinguish between what's jasper's core functionality ( convert a
.jsp file to a java file ) and what's a hack and duplication of
container's functionality for JspServlet's use. 

For example JspLoader, some of the manglers, some of the JspEngine and
context. If we are going for a refactoring, it would be a good idea to
clean up and fix more than just JspServlet.


Costin 
 

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspParseEventListener.java

[horwat]

horwat  01/03/27 15:56:24

  Modified:jasper/src/share/org/apache/jasper/compiler
JspParseEventListener.java
  Log:
  Handle empty element case. This patch allows jasper to work with xerces-1.3.0
  
  Revision  ChangesPath
  1.23  +7 -5  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
  
  Index: JspParseEventListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- JspParseEventListener.java2001/02/04 01:05:13 1.22
  +++ JspParseEventListener.java2001/03/27 23:56:24 1.23
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.22 2001/02/04 01:05:13 glenn Exp $
  - * $Revision: 1.22 $
  - * $Date: 2001/02/04 01:05:13 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.23 2001/03/27 23:56:24 horwat Exp $
  + * $Revision: 1.23 $
  + * $Date: 2001/03/27 23:56:24 $
*
* 
*
  @@ -1097,8 +1097,10 @@
   public void handleJspCdata(Mark start, Mark stop, char[] data)
throws JasperException
   {
  - handleCharData(start, stop, data);
  -xo.append("jsp:cdata", null, data);
  + if (data != null) {
  + handleCharData(start, stop, data);
  +xo.append("jsp:cdata", null, data);
  + }
   }
   
   /**
  
  
  

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Craig R. McClanahan]

On Tue, 27 Mar 2001 [EMAIL PROTECTED] wrote:

> - initialization - how can you pass init parameters to the jsp ? This is
> one of the worst hacks and source of counteless problems ( AFAIK - I
> couldn't find any clean way to do that )

>From the application developer's perspective, you do this:


MyJspPageServlet
/path/to/myjsppage.jsp

name
value



The approach to implementing this in Catalina is also pretty ugly, but it
does work ...

Craig

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Craig R. McClanahan]

On Tue, 27 Mar 2001, Mel Martinez wrote:

> 
> The glass is half-full as well - because at least with
> the servlet api it is _possible_ to implement those
> services portably and thus provide a portable JSP
> compiler.
> 

When Tomcat 4.0 was created, one of the goals was to eliminate all the
Jasper dependencies on servlet container code (with the goal of a portable
JSP environment).  We were completely successful except for two
(initially) and now only one issue:  specifying a classpath for the Java
compiler.

In a JDK 1.1 environment, there is no portable solution to this
problem.  In JDK 1.2 or later, you can have a portable solution as long as
the web app classloader is a subclass of URLClassLoader (as it is in
Tomcat 4.0), because you can ask the URLClassLoader what it's repositories
are and therefore reconstruct a reasonable class path in most
circumstances.

The portability goal is definitely achievable in a Java2 world.

Craig

Re: JDBC-Session store

[Craig R. McClanahan]

On Tue, 27 Mar 2001, Kief Morris wrote:

> Bip Thelin typed the following on 01:56 PM 3/26/2001 -0800
> >According to the STATUS.html(which doesn't seem to be up to date) no one seems
> >to have volunteered for the JDBC-Session store. If that is truly the case I
> >would like to volunteer for that part.
> 
> Excellent! Let us know if you need any help.
> 
> Kief
> 
> 
Kief, a while back (when the work on PersistentManager was going on), the
need for a little refactoring work on Manager vs. StandardManager would be
useful.  Have you thought any more about what we should do here?

Craig

Re: Listeners

[Craig R. McClanahan]

On Tue, 27 Mar 2001, Kevin Jones wrote:

> Tomcat 4.0 stops configuring listeners if one of the listeners in the list
> isn't present, should it carry on configuring the rest of the listeners it
> finds? The spec is silent on this and it seems odd that if somebody (maybe
> accidentally) deletes a listener class all other following listeners are not
> configured (any listener preceding the missing listener would already have
> been initialised).
> 

Here's the rationale for this behavior (and the fact that Tomcat also
marks the app unavailable if it didn't initialize all the listeners and
filters successfully):

Let's say you are implementing user authentication yourself, and using
filters.  You specify connection information to a database in your filter
params, but mistype the password so that the connection cannot be
established, so your filter's init() method throws an exception.  If
Tomcat just logged this as a warning and went on deploying your app, it
would now be running with *no* authentication, potentially exposing
sensitive information.  Is that what you *really* want to have happen?

One might argue missing listeners would be less severe a risk than missing
filters, but IMHO that isn't the container's judgement to make -- the user
has an incomplete application deployed; better to make them go fix it
rather than trying to run only part of it.

> I've also raised this as a bug,
> 
> Thanks,
> 
> Kevin
> 
> 

Craig

Re: Cause found [was Re: How do I use a non-apache naming servicewith tomcat 4?]

[Craig R. McClanahan]

On Tue, 27 Mar 2001, T. Park wrote:

> Craig,Remy,
> 
> downloading the latest nightly build resolved my problem... thanks!
> 

Cool.

> 
> ...but only after I dropped that 'big everything' jar into the common/lib
> folder.
> 
> So there seems to be a chicken & egg thing regarding what order certain
> components need to be in
> for the new tomcat to play with an alternative naming service.
> 
> My InstanceListener class goes into server/lib just fine, but the support
> class (I.e. the one containing javax.naming) needs
> to go in the common area.
> 
> Can you tell me why this would be? I know it's something to do with the new
> classloading scheme
> but I can't see why it would matter.
> 

The reason something would need to be in "common" is if it needs to be
visible to both the Catalina classloader and a webapp class loader.  If
you consult the classloaders.html doc for Catalina, you will see that
this is the only configurable place that these two hierarchies meet.  It
sounds like there must be things in your "big everything" JAR that meet
that description.



> -Thom
> 

Craig

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseBase.java

[remm]

remm01/03/27 21:15:15

  Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseBase.java
  Log:
  - Fix for bug 1081.
  
  Revision  ChangesPath
  1.29  +6 -8  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
  
  Index: HttpResponseBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- HttpResponseBase.java 2001/03/14 02:17:21 1.28
  +++ HttpResponseBase.java 2001/03/28 05:15:14 1.29
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.28 2001/03/14 02:17:21 craigmcc Exp $
  - * $Revision: 1.28 $
  - * $Date: 2001/03/14 02:17:21 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.29 2001/03/28 05:15:14 remm Exp $
  + * $Revision: 1.29 $
  + * $Date: 2001/03/28 05:15:14 $
*
* 
*
  @@ -99,7 +99,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.28 $ $Date: 2001/03/14 02:17:21 $
  + * @version $Revision: 1.29 $ $Date: 2001/03/28 05:15:14 $
*/
   
   public class HttpResponseBase
  @@ -578,8 +578,8 @@
HttpServletRequest hreq = (HttpServletRequest) request.getRequest();
HttpSession session = hreq.getSession(false);
   
  - if ((session != null) && session.isNew() &&
  - getContext().getCookies()) {
  + if ((session != null) && session.isNew() && (getContext() != null) 
  +&& getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
   session.getId());
cookie.setMaxAge(-1);
  @@ -1044,8 +1044,6 @@
String absolute = toAbsolute(location);
setStatus(SC_MOVED_TEMPORARILY);
setHeader("Location", absolute);
  -//setContentLength(0);
  - //flushBuffer();
   
   }
   
  
  
  

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cmanolache]

On Tue, 27 Mar 2001, Craig R. McClanahan wrote:

> > The glass is half-full as well - because at least with
> > the servlet api it is _possible_ to implement those
> > services portably and thus provide a portable JSP
> > compiler.
> > 
> 
> When Tomcat 4.0 was created, one of the goals was to eliminate all the
> Jasper dependencies on servlet container code (with the goal of a portable
> JSP environment).  We were completely successful except for two
> (initially) and now only one issue:  specifying a classpath for the Java
> compiler.
> ...
> The portability goal is definitely achievable in a Java2 world.

The only problem is that maybe trying to make jasper independent of the
container is the wrong goal...

The price is ugly ( or at least complex ) and inefficient code ( not only
because of the overhead, but also because of the missed oportunities for
optimizations ).

A quick test is very simple - in 3.3 compare the speed of
running jsps via JspServlet and JspInterceptor. ( or with the JspServlet
in 4.0 if you think the 3.x JspServlet is bad ). 

I'm not saying that having a JSP implementation packaged as a servlet and
reimplementing functions of the servlet container is bad or impossible -
just that a solution where the container does servlet management and
jasper deals with converting jsps to servlets may result in cleaner code
and better performance. 

I don't remember reading anywhere in the JSP spec that jasper must be
implemented as a servlet, or that it must be independent of the servlet
container. And I don't think having a good design for jasper's API that
allows it to take advantage of the container would make it less portable -
and JspServlet can still be used to plug jasper in un-cooperating
containers. 

So far jasper has been one of the most stable pieces on tomcat ( most bugs
I know about are related with the interfacing between jasper and the
container ). And it has a huge potential for performance improvement - if
we do the right refactoring and provide the right internal APIs. 

Costin

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector ResponseBase.java

[remm]

remm01/03/27 21:35:25

  Modified:catalina/src/share/org/apache/catalina/connector
ResponseBase.java
  Log:
  - Fix for bug 453.
This has the potential to break stuff when using HTTP/1.1, although this is 
unlikely.
  
  Revision  ChangesPath
  1.11  +11 -5 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java
  
  Index: ResponseBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ResponseBase.java 2001/01/13 22:28:48 1.10
  +++ ResponseBase.java 2001/03/28 05:35:24 1.11
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
 1.10 2001/01/13 22:28:48 craigmcc Exp $
  - * $Revision: 1.10 $
  - * $Date: 2001/01/13 22:28:48 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
 1.11 2001/03/28 05:35:24 remm Exp $
  + * $Revision: 1.11 $
  + * $Date: 2001/03/28 05:35:24 $
*
* 
*
  @@ -88,7 +88,7 @@
* the connector-specific methods need to be implemented.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.10 $ $Date: 2001/01/13 22:28:48 $
  + * @version $Revision: 1.11 $ $Date: 2001/03/28 05:35:24 $
*/
   
   public abstract class ResponseBase
  @@ -464,7 +464,13 @@
   } catch (IOException e) {
   ;
   }
  -return (new PrintWriter(output));
  +try {
  +if (this.stream == null)
  +this.stream = createOutputStream();
  +} catch (IOException e) {
  +return null;
  +}
  +return (new PrintWriter(this.stream));
   
   } else {
   
  
  
  

RE: Listeners

[Kevin Jones]

> Here's the rationale for this behavior (and the fact that Tomcat also
> marks the app unavailable if it didn't initialize all the listeners and
> filters successfully):

But it doesn't, at least not in the latest nightly. I have a listener
configured and the class file is missing. Tomcat seems not to have
initialised any of the listeners but the application is still available.

> Let's say you are implementing user authentication yourself, and using
> filters.  You specify connection information to a database in your filter
> params, but mistype the password so that the connection cannot be
> established, so your filter's init() method throws an exception.  If
> Tomcat just logged this as a warning and went on deploying your app, it
> would now be running with *no* authentication, potentially exposing
> sensitive information.  Is that what you *really* want to have happen?
>
> One might argue missing listeners would be less severe a risk than missing
> filters, but IMHO that isn't the container's judgement to make -- the user
> has an incomplete application deployed; better to make them go fix it
> rather than trying to run only part of it.

But it is a judgement the container is making - In my app it doesn't matter
much if the filters/listeners are missing. I would argue that for listeners
the behaviour should be the same as for  servlets and that
the principle of least surprise would be applied. I would guess that
initially most listeners would be ported from load-on-startup servlets (mine
are), of one of those servlets was missing the application still started,
and the servlets still executed. Least surprise tells me that listeners
should behave the same way. Is there some way we could configure this in
server.xml or do you think that is overkill.

BTW should we also add a note in the spec. about this?

Kevin Jones
DevelopMentor
www.develop.com

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 28 March 2001 04:14
> To: Tomcat-Dev
> Subject: Re: Listeners
>
>
>
>
> On Tue, 27 Mar 2001, Kevin Jones wrote:
>
> > Tomcat 4.0 stops configuring listeners if one of the listeners
> in the list
> > isn't present, should it carry on configuring the rest of the
> listeners it
> > finds? The spec is silent on this and it seems odd that if
> somebody (maybe
> > accidentally) deletes a listener class all other following
> listeners are not
> > configured (any listener preceding the missing listener would
> already have
> > been initialised).
> >
>
> Here's the rationale for this behavior (and the fact that Tomcat also
> marks the app unavailable if it didn't initialize all the listeners and
> filters successfully):
>
> Let's say you are implementing user authentication yourself, and using
> filters.  You specify connection information to a database in your filter
> params, but mistype the password so that the connection cannot be
> established, so your filter's init() method throws an exception.  If
> Tomcat just logged this as a warning and went on deploying your app, it
> would now be running with *no* authentication, potentially exposing
> sensitive information.  Is that what you *really* want to have happen?
>
> One might argue missing listeners would be less severe a risk than missing
> filters, but IMHO that isn't the container's judgement to make -- the user
> has an incomplete application deployed; better to make them go fix it
> rather than trying to run only part of it.
>
> > I've also raised this as a bug,
> >
> > Thanks,
> >
> > Kevin
> >
> >
>
> Craig
>

FW: Tomcat 4 service

[Kevin Jones]

I posted this to tomcat-user with no response.

Does such a beast exist? If not I'll volunteer to port the Tomcat 3.2 code.
Just point me at it!

Kevin Jones
DevelopMentor
www.develop.com

> -Original Message-
> From: Kevin Jones [mailto:[EMAIL PROTECTED]]
> Sent: 27 March 2001 22:44
> To: Tomcat-User
> Subject: Tomcat 4 service
>
>
> I have tomcat 3.2 running as a service under W2K. I seem to remember that
> this wasn't available for Tomcat 4 (running it as a service that
> is), or is
> the code now available?
>
> Thanks,
>
> Kevin Jones
> DevelopMentor
> www.develop.com

Re: Multi-byte character support.

[Kazuhiro Kazama]

From: "Java Poop" <[EMAIL PROTECTED]>
Subject: Re: Multi-byte character support.
Date: Mon, 26 Mar 2001 22:33:36 -0800
Message-ID: <[EMAIL PROTECTED]>
> What are the il8n limitations in 3.2.1?

For example, there are the following limitations:

1, The getParameter method in ServletRequest class returns non-Unicode
strings.

If a HTTP GET or POST request is done by a HTML form, servlet can't
know its charset because the request don't have its charset
information.  The HTML 4.0 specification recommends to encode UTF-8
strings but most of systems don't do it.

Tomcat 3.2 treats parameters like their charset is ISO-8859-1. Other
servlet container may return Unicode strings by its own encoding
detection method but it is tricky and don't work under some situation.

For avoiding this problem, Servlet 2.3 API has setCharacterEncoding
method and Tomcat 4.0 based on it.

Because Tomcat 3.2 based on Servlet 2.2 API, we can't use this method.
But Costin will provide an extension module for Tomcat 3.3 (for
example, specify the default encoding per context).

2, A JSP content's encoding may not be recognized correctly.

This cause is a lack of a function to specify JSP content's encoding
(JSP output encoding is specified by contentType attribute of Page
directive).

JSP 1.2 has new pageEncoding attribute of Page directive. And a file
localization method, it is proposed by Arieh, may provide another
solution.
 
Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories

Re: Tomcat 4 service

[Arshad Mahmood]

I believe that the only change you require is to create a suitable
wrapper.properties, you should be able to use the existing
jk_nt_service.exe.

I had this working a few weeks ago but I tried my existing configuration on
the latest build and the service fails to startup. I am currently in the
process of trying to figure out what the issue is.

Regards,
Arshad

- Original Message -
From: "Kevin Jones" <[EMAIL PROTECTED]>
To: "Tomcat-Dev" <[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2001 7:52 AM
Subject: FW: Tomcat 4 service


> I posted this to tomcat-user with no response.
>
> Does such a beast exist? If not I'll volunteer to port the Tomcat 3.2
code.
> Just point me at it!
>
> Kevin Jones
> DevelopMentor
> www.develop.com
>
> > -Original Message-
> > From: Kevin Jones [mailto:[EMAIL PROTECTED]]
> > Sent: 27 March 2001 22:44
> > To: Tomcat-User
> > Subject: Tomcat 4 service
> >
> >
> > I have tomcat 3.2 running as a service under W2K. I seem to remember
that
> > this wasn't available for Tomcat 4 (running it as a service that
> > is), or is
> > the code now available?
> >
> > Thanks,
> >
> > Kevin Jones
> > DevelopMentor
> > www.develop.com
>