Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[jean-frederic clere]

"Craig R. McClanahan" wrote:
> 
> +1 for all, with an expansion on the last point.
> 
> Currently, Tomcat components all use the internal Logger APIs for logging
> both container event and error messages, as well as those from the web
> applications that are being run (i.e. calls to ServletContext.log()).
> What would people think of migrating the container components of the HEAD
> branch to use commons-logging, as well as having Coyote do that?

1+

> 
> The most interesting technical part of this is that multiple instances of
> many of the components (such as StandardContext) are used in a pretty much
> autonomous manner, and you might want to have different logging levels for
> different instances.  I think we can can deal with this by creating naming
> of the underlying loggers, but wanted to gauge opinions before putting
> together a proposal for that.
> 
> Craig
> 
> On Tue, 12 Mar 2002, Remy Maucherat wrote:
> 
> > Date: Tue, 12 Mar 2002 18:30:23 -0800
> > From: Remy Maucherat <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
> >
> > There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> > start with some limited changes at first. Most of these proposed changes are
> > Coyote-related (hence the subject of the message), and all involve some
> > refactoring / API additions.
> >
> > A) URI decoding refactoring. To avoid doing some URI decoding in many places
> > in the pipeline, a decodedURI field (with associated getter/setter) should
> > be added in the HttpRequest interface, and used in the Catalina pipeline.
> > This also has the advantage to guarantee that no double URI decoding occurs
> > (which can lead to URI-based security attacks).
> >
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > 
> >
> > B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> > connector, which has many shortcoming (slow performance on output, HTTP
> > handling limitations and extreme complexity). Initial tests results and
> > benchmarks with Coyote are extremely positive so far.
> >
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > 
> >
> > C) Add better lifecycle handling in the resources. A start method is needed
> > (which could be called 'allocate' to mirror the 'release' method), because
> > it is currently not possible to restart a stopped context. In the 4.0
> > branch, the patch introducing the 'release' method must either be reverted,
> > or these proposed changes must also be ported to 4.0.
> > Thanks to Jean-Francois Clere for the report and debugging of this problem.
> >
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > 
> >
> > D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> > be used for any new connector development. To make this more obvious, I'd
> > like to deprecate all classes in this package and subpackages. The binaries
> > will also be packaged in a separate JAR file (tentatively named
> > catalina-legacy.jar). This package will continue to be maintained on a case
> > by case basis. The facades will not be deprecated, and two new helper
> > objects will be introduced to handle the need for "fake" req/resp when
> > requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> > more details).
> >
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > 
> >
> > E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> > interface. Otherwise, the processor has no way to cleanly handle logging.
> > commons-logging is already used by other j-t-c components. At the moment,
> > the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> > needs to be improved. When I originally designed most of the base
> > interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> > yet another logging interface.
> >
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > 
> >
> > +1 for everything. Thanks for voting / commenting :)
> >
> > Remy
> >
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
> >
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: In memory session replication, reminder

[Remy Maucherat]

> >Also, sorry for not mentioning it before (I didn't really look at the
> >details, I have to admit ;-) Too busy :-(), but I have a problem with
JG's
> >license. Basically, I don't want to create any dependency to it,
> >and I don't
> >want JG to be part of the TC build process.
>
> it doesn't have to be, it can be as Jason explained, we can create hooks
and
> interfaces,
> that way the user/sys admin can choose which module to use for the comm,
be
> it JG, Spread or something else. You just say the word.
>
> >So sorry, but I'm not very interested in the contribution anymore. The
> >functionality is useful, obviously. Maybe you should distribute it as a
> >module for your project.
>
> sorry to hear that.
>
> Let me know if you change your mind, and want me to create the hooks and
> interfaces to allow you to plug in any messaging system. Also this way,
the
> TC build would not be dependent on any outside library.

That kind of design would be more interesting. I was probably too harsh in
my response; I just wanted to point out I made a mistake by being that
enthusiastic about it originally.

I think I'll create a 'cluster' component in j-t-c, as was suggested, and
move the existing cluster implementations there.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7107] - Classes missing from binary distribution

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7107

Classes missing from binary distribution

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-03-14 07:43 ---
I just double checked, and they are there (in bin/bootstrap.jar).

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Where can I find the spec to implement SSI on Jakarta Tomcat 4.0?

[Paul Speed]

Amy Roh wrote:
> 
> Mike Jette wrote:
> 
> > Where can I find the spec to implement Server-Side Include (SSI) on Jakarta
> > Tomcat 4.0?

Note: I'm pretty sure that Catalina 4.0.x only has a minimal support
for SSI.  I rewrote it all to include everything that Apache 
mod_include does (except the some perl or regex stuff, don't quite
remember) but I'm pretty sure those changes only exist in the HEAD
branch, ie: 4.x.  As far as I know, that stuff was never back-ported
and so is only available when using a nightly build or building from
source.

Also note: The older SSI can only serve one request at a time or
it will possibly mix output to the different clients.  This was
actually my original reasons for fixing the SSI servlet in Catalina
since it messes up nested includes too.  The other reason was that I 
needed conditionals.

-Paul Speed

> 
> There isn't an actual spec for SSI feature for Tomcat 4.0.  It follows the NCSA
> SSI rules same as the Apache documentation.  You need to uncomment SSI Servlet
> in web.xml.  And to use the SSI servlet, you also need to rename the
> $CATALINA_HOME/server/lib/servlets-ssi.renametojar file to
> $CATALINA_HOME/server/lib/servlets-ssi.jar
> 
> Amy
> 
> >
> >
> > If you can point me at a link I would really appreciate your help.
> > Is it that same as the Apache documentation?
> >
> > Thanks you.
> >
> > --
> > Michael E. Jette
> > Technology Partners, Inc.
> > 636-519-1221 ext. 104
> > 1-877-636-1331 ext. 104 (toll free)
> > www.tech-partners.com
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7107] New: - Classes missing from binary distribution

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7107

Classes missing from binary distribution

   Summary: Classes missing from binary distribution
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Installable Packages
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The missing classes are:
org.apache.catalina.loader.Extension
org.apache.catalina.loader.Reloader
org.apache.naming.JndiPermission

The classes are missing at least from jakarta-tomcat-4.0.3-LE-jdk14.zip

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/proposals/patches/tomcat33a JspInterceptor.java JavaGeneratorTool.java ContextManager.java

[larryi]

larryi  02/03/13 19:17:05

  Removed: proposals/patches/tomcat33a JspInterceptor.java
JavaGeneratorTool.java ContextManager.java
  Log:
  Remove extra sources used for Tomcat 3.3a

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Where can I find the spec to implement SSI on Jakarta Tomcat 4.0?

[Amy Roh]

Uma Munugala wrote:

> Hi
>I installed tomcat 4.0.3 and installation was successful.
> I tested examples they are working fine.
> I unzipped all my application files in a directory under webapps directory.
> when I tried to run my servlets, Iam getting error
> http status 404 servlet (Login) not found.
>
> can some body write to me step by step procedure what to do when I want to
> run an application (servlet).

You can refer to "Application Developer's Guide" -
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/appdev/index.html.  Hope you
find this useful.

Amy

>
>
> Thanks
> Uma
>
> -Original Message-
> From: Amy Roh [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 13, 2002 5:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Where can I find the spec to implement SSI on Jakarta
> Tomcat 4.0?
>
> Mike Jette wrote:
>
> > Where can I find the spec to implement Server-Side Include (SSI) on
> Jakarta
> > Tomcat 4.0?
>
> There isn't an actual spec for SSI feature for Tomcat 4.0.  It follows the
> NCSA
> SSI rules same as the Apache documentation.  You need to uncomment SSI
> Servlet
> in web.xml.  And to use the SSI servlet, you also need to rename the
> $CATALINA_HOME/server/lib/servlets-ssi.renametojar file to
> $CATALINA_HOME/server/lib/servlets-ssi.jar
>
> Amy
>
> >
> >
> > If you can point me at a link I would really appreciate your help.
> > Is it that same as the Apache documentation?
> >
> > Thanks you.
> >
> > --
> > Michael E. Jette
> > Technology Partners, Inc.
> > 636-519-1221 ext. 104
> > 1-877-636-1331 ext. 104 (toll free)
> > www.tech-partners.com
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Where can I find the spec to implement SSI on Jakarta Tomcat 4.0?

[Uma Munugala]

Hi 
   I installed tomcat 4.0.3 and installation was successful.
I tested examples they are working fine.
I unzipped all my application files in a directory under webapps directory.
when I tried to run my servlets, Iam getting error
http status 404 servlet (Login) not found.

can some body write to me step by step procedure what to do when I want to
run an application (servlet).




Thanks
Uma


-Original Message-
From: Amy Roh [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 5:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Where can I find the spec to implement SSI on Jakarta
Tomcat 4.0?


Mike Jette wrote:

> Where can I find the spec to implement Server-Side Include (SSI) on
Jakarta
> Tomcat 4.0?

There isn't an actual spec for SSI feature for Tomcat 4.0.  It follows the
NCSA
SSI rules same as the Apache documentation.  You need to uncomment SSI
Servlet
in web.xml.  And to use the SSI servlet, you also need to rename the
$CATALINA_HOME/server/lib/servlets-ssi.renametojar file to
$CATALINA_HOME/server/lib/servlets-ssi.jar

Amy

>
>
> If you can point me at a link I would really appreciate your help.
> Is it that same as the Apache documentation?
>
> Thanks you.
>
> --
> Michael E. Jette
> Technology Partners, Inc.
> 636-519-1221 ext. 104
> 1-877-636-1331 ext. 104 (toll free)
> www.tech-partners.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Where can I find the spec to implement SSI on Jakarta Tomcat 4.0?

[Amy Roh]

Mike Jette wrote:

> Where can I find the spec to implement Server-Side Include (SSI) on Jakarta
> Tomcat 4.0?

There isn't an actual spec for SSI feature for Tomcat 4.0.  It follows the NCSA
SSI rules same as the Apache documentation.  You need to uncomment SSI Servlet
in web.xml.  And to use the SSI servlet, you also need to rename the
$CATALINA_HOME/server/lib/servlets-ssi.renametojar file to
$CATALINA_HOME/server/lib/servlets-ssi.jar

Amy

>
>
> If you can point me at a link I would really appreciate your help.
> Is it that same as the Apache documentation?
>
> Thanks you.
>
> --
> Michael E. Jette
> Technology Partners, Inc.
> 636-519-1221 ext. 104
> 1-877-636-1331 ext. 104 (toll free)
> www.tech-partners.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Craig R. McClanahan]

On Wed, 13 Mar 2002, Craig R. McClanahan wrote:

>
> I think we can can deal with this by creating naming

Err, that was supposed to be "creative" naming ...

> of the underlying loggers, but wanted to gauge opinions before putting
> together a proposal for that.
>
> Craig
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Craig R. McClanahan]

+1 for all, with an expansion on the last point.

Currently, Tomcat components all use the internal Logger APIs for logging
both container event and error messages, as well as those from the web
applications that are being run (i.e. calls to ServletContext.log()).
What would people think of migrating the container components of the HEAD
branch to use commons-logging, as well as having Coyote do that?

The most interesting technical part of this is that multiple instances of
many of the components (such as StandardContext) are used in a pretty much
autonomous manner, and you might want to have different logging levels for
different instances.  I think we can can deal with this by creating naming
of the underlying loggers, but wanted to gauge opinions before putting
together a proposal for that.

Craig


On Tue, 12 Mar 2002, Remy Maucherat wrote:

> Date: Tue, 12 Mar 2002 18:30:23 -0800
> From: Remy Maucherat <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
>
> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> start with some limited changes at first. Most of these proposed changes are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
>
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
>
> 
> [ ] +1
> [ ] +0
> [ ] -1:
>
> 
>
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
>
> 
> [ ] +1
> [ ] +0
> [ ] -1:
>
> 
>
> C) Add better lifecycle handling in the resources. A start method is needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this problem.
>
> 
> [ ] +1
> [ ] +0
> [ ] -1:
>
> 
>
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
>
> 
> [ ] +1
> [ ] +0
> [ ] -1:
>
> 
>
> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> yet another logging interface.
>
> 
> [ ] +1
> [ ] +0
> [ ] -1:
>
> 
>
> +1 for everything. Thanks for voting / commenting :)
>
> Remy
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7102] - response.encodeURL() doesn't encode

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7102

response.encodeURL() doesn't encode

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 23:30 ---
I fixed this bug yesterday.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7102] New: - response.encodeURL() doesn't encode

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7102

response.encodeURL() doesn't encode

   Summary: response.encodeURL() doesn't encode
   Product: Tomcat 4
   Version: 4.0.4 Beta 1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If response.encodeURL() is called in a servlet called without cookies, it
still doesn't add the session ID. This can be demostrated with the "URL encoded"
link generated by the SessionExample sample in the examples app.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Newbie: Basic Question

[Patrick Luby]

Bhai,

The problem is that you have a '\' character at the end of %CATALINA_HOME%.
Instead of the following:

C:\Programs\jakarta-tomcat-4.0.3-src\dist\

set CATALINA_HOME to the following:

C:\Programs\jakarta-tomcat-4.0.3-src\dist

Patrick

Bhai wrote:
> 
> > > Hi,
> > >
> > > I have downloaded the tomcat source from TC web and have built it and
> also created a distribution. But on my Win2K machine when I do "catalina
> start" from the CATALINA_HOME\bin, it echoes the JAVA_HOME and CATALINA_HOME
> and the CATALINA_BASE, it appears to open a new command window, which it
> closes instantaneously. The port 8080 on my machine is not in use and
> looking at the task manager it does not appear that the java instance is
> running.
> > >
> > > Is there some other setting that I have to do other than setting the
> java home and catalina home in order to run the distribution/build. my
> catalina home is set to c:\...jakarta-tomcat-src\dist where ant created the
> distributables.
> > >
> > > Please point me in the right direction.
> > >
> > > Thanks.
> 
> > Bhai,
> >
> > It is hard to tell what is going on without capturing what is appearing in
> the
> > window that pops up. Try running "catalina run". This will keep all output
> in
> > the same window so that you can see the errors.
> >
> > Patrick
> 
> Hello Patrick,
> 
> That ran and I could see the output which I have pasted below.
> 
> C:\Programs\jakarta-tomcat-4.0.3-src\dist\bin>catalina run
> Using CATALINA_BASE:   C:\Programs\jakarta-tomcat-4.0.3-src\dist\
> Using CATALINA_HOME:   C:\Programs\jakarta-tomcat-4.0.3-src\dist\
> Using CATALINA_TMPDIR: C:\Programs\jakarta-tomcat-4.0.3-src\dist\\temp
> Using JAVA_HOME:   C:\j2sdk1.4.0
> Exception during startup processing
> java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
> at
> org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas
> sLoader.java:1127)
> at
> org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas
> sLoader.java:992)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:218)
> 
> It cannot find the catalina.class file that is present in the catalina.jar
> within the dist/servers/catalina.jar file. Can you help me out.
> 
> Thanks.
> 
> Bhai.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Newbie: Basic Question

[Bhai]

> > Hi,
> >
> > I have downloaded the tomcat source from TC web and have built it and
also created a distribution. But on my Win2K machine when I do "catalina
start" from the CATALINA_HOME\bin, it echoes the JAVA_HOME and CATALINA_HOME
and the CATALINA_BASE, it appears to open a new command window, which it
closes instantaneously. The port 8080 on my machine is not in use and
looking at the task manager it does not appear that the java instance is
running.
> >
> > Is there some other setting that I have to do other than setting the
java home and catalina home in order to run the distribution/build. my
catalina home is set to c:\...jakarta-tomcat-src\dist where ant created the
distributables.
> >
> > Please point me in the right direction.
> >
> > Thanks.

> Bhai,
>
> It is hard to tell what is going on without capturing what is appearing in
the
> window that pops up. Try running "catalina run". This will keep all output
in
> the same window so that you can see the errors.
>
> Patrick

Hello Patrick,

That ran and I could see the output which I have pasted below.

C:\Programs\jakarta-tomcat-4.0.3-src\dist\bin>catalina run
Using CATALINA_BASE:   C:\Programs\jakarta-tomcat-4.0.3-src\dist\
Using CATALINA_HOME:   C:\Programs\jakarta-tomcat-4.0.3-src\dist\
Using CATALINA_TMPDIR: C:\Programs\jakarta-tomcat-4.0.3-src\dist\\temp
Using JAVA_HOME:   C:\j2sdk1.4.0
Exception during startup processing
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
at
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas
sLoader.java:1127)
at
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas
sLoader.java:992)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:218)


It cannot find the catalina.class file that is present in the catalina.jar
within the dist/servers/catalina.jar file. Can you help me out.

Thanks.

Bhai.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Newbie: Basic Question

[Patrick Luby]

Bhai,

It is hard to tell what is going on without capturing what is appearing in the
window that pops up. Try running "catalina run". This will keep all output in
the same window so that you can see the errors.

Patrick

Bhai wrote:
> 
> Hi,
> 
> I have downloaded the tomcat source from TC web and have built it and also created a 
>distribution. But on my Win2K machine when I do "catalina start" from the 
>CATALINA_HOME\bin, it echoes the JAVA_HOME and CATALINA_HOME and the CATALINA_BASE, 
>it appears to open a new command window, which it closes instantaneously. The port 
>8080 on my machine is not in use and looking at the task manager it does not appear 
>that the java instance is running.
> 
> Is there some other setting that I have to do other than setting the java home and 
>catalina home in order to run the distribution/build. my catalina home is set to 
>c:\...jakarta-tomcat-src\dist where ant created the distributables.
> 
> Please point me in the right direction.
> 
> Thanks.
> 
> Bhai

-- 
_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Newbie: Basic Question

[Bhai]

Hi,

I have downloaded the tomcat source from TC web and have built it and also created a 
distribution. But on my Win2K machine when I do "catalina start" from the 
CATALINA_HOME\bin, it echoes the JAVA_HOME and CATALINA_HOME and the CATALINA_BASE, it 
appears to open a new command window, which it closes instantaneously. The port 8080 
on my machine is not in use and looking at the task manager it does not appear that 
the java instance is running.

Is there some other setting that I have to do other than setting the java home and 
catalina home in order to run the distribution/build. my catalina home is set to 
c:\...jakarta-tomcat-src\dist where ant created the distributables.

Please point me in the right direction.

Thanks.

Bhai

RE: In memory session replication, reminder

[Filip Hanik]

>Also, sorry for not mentioning it before (I didn't really look at the
>details, I have to admit ;-) Too busy :-(), but I have a problem with JG's
>license. Basically, I don't want to create any dependency to it,
>and I don't
>want JG to be part of the TC build process.

it doesn't have to be, it can be as Jason explained, we can create hooks and
interfaces,
that way the user/sys admin can choose which module to use for the comm, be
it JG, Spread or something else. You just say the word.

>So sorry, but I'm not very interested in the contribution anymore. The
>functionality is useful, obviously. Maybe you should distribute it as a
>module for your project.

sorry to hear that.

Let me know if you change your mind, and want me to create the hooks and
interfaces to allow you to plug in any messaging system. Also this way, the
TC build would not be dependent on any outside library.

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: In memory session replication, reminder

[Remy Maucherat]

> >Well, apparently a lot of people would want that in j-t-c instead, and I
> >think they are right.
> >j-t-c/cluster should be a good name.
> >
> >Remy
>
> Hi Remy,
> j-t-c, that refers to Jakarta-tomcat-connectors right?
> If jtc is the connectors, from looking at my code, I'm not sure how this
> would be possible at all.
> Session replication isn't really related to the connectors, it is a part
of
> catalina, ie the underlying communication system is completely outside,
but
> the hook ins for session changes, doesn't that come from catalina? Because
> that is the code I wrote.

j-t-c is actually more jakarta-tomcat-modules. The idea started with
connectors (hence the name).

Also, sorry for not mentioning it before (I didn't really look at the
details, I have to admit ;-) Too busy :-(), but I have a problem with JG's
license. Basically, I don't want to create any dependency to it, and I don't
want JG to be part of the TC build process.

It's not that I hate the GPL (although for many server side projects, I do),
it's just that I don't want to mix licences if I can avoid it.

So sorry, but I'm not very interested in the contribution anymore. The
functionality is useful, obviously. Maybe you should distribute it as a
module for your project.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: In memory session replication, reminder

[Filip Hanik]

>Well, apparently a lot of people would want that in j-t-c instead, and I
>think they are right.
>j-t-c/cluster should be a good name.
>
>Remy

Hi Remy,
j-t-c, that refers to Jakarta-tomcat-connectors right?
If jtc is the connectors, from looking at my code, I'm not sure how this
would be possible at all.
Session replication isn't really related to the connectors, it is a part of
catalina, ie the underlying communication system is completely outside, but
the hook ins for session changes, doesn't that come from catalina? Because
that is the code I wrote.

looking at my code, please help me understand how this code would be outside
catalina?

thanks in advance
Filip



~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net

>-Original Message-
>From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, March 13, 2002 12:01 PM
>To: Tomcat Developers List
>Subject: Re: In memory session replication, reminder
>
>
>> >JavaGroups is cool since it is pure, multiplatform Java, although
>> >(from what I know) it cannot fall back to TCP when multicast isn't
>> >available,
>>
>> JavaGroups is cool, thanks :), and yes, it does support TCP. :))
>>
>> >What I'd like to do at some point is take Filip Hanik's TC4 session
>> >replication code (looking nice!) and make it switchable to use either
>> >Spread or JavaGroups, or other communication mechanisms for keeping the
>> >session data in sync. Pluggable messaging back-ends..
>>
>> I would fully support this, I think it is a great idea!
>>
>> >FWIW, I'd like to see the in-memory session replication code as part
>> >of TC4 itself, with a pluggable messaging layer API that allows
>> >a separate messaging system to be used.
>>
>> yes yes yes,
>> I would say make the hook ins and interfaces in catalina, and
>then you can
>> just plug in any messaging system you want.
>
>Well, apparently a lot of people would want that in j-t-c instead, and I
>think they are right.
>j-t-c/cluster should be a good name.
>
>Remy
>
>
>--
>To unsubscribe, e-mail:

For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin TreeControlTag.java

[craigmcc]

craigmcc02/03/13 12:09:55

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
TreeControlTag.java
  Log:
  Perform URL rewriting on the URL that is used to refresh the tree control.
  Without this, the admin webapp won't work with cookies turned off -- clicking
  any node of the tree would force you back to the login page.
  
  Submitted by:  Stephanie Bodoff 
  
  Revision  ChangesPath
  1.7   +7 -4  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java
  
  Index: TreeControlTag.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- TreeControlTag.java   18 Dec 2001 22:59:41 -  1.6
  +++ TreeControlTag.java   13 Mar 2002 20:09:55 -  1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java,v
 1.6 2001/12/18 22:59:41 amyroh Exp $
  - * $Revision: 1.6 $
  - * $Date: 2001/12/18 22:59:41 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TreeControlTag.java,v
 1.7 2002/03/13 20:09:55 craigmcc Exp $
  + * $Revision: 1.7 $
  + * $Date: 2002/03/13 20:09:55 $
*
* 
*
  @@ -104,7 +104,7 @@
* FIXME - Internationalize the exception messages!
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.6 $ $Date: 2001/12/18 22:59:41 $
  + * @version $Revision: 1.7 $ $Date: 2002/03/13 20:09:55 $
*/
   
   public class TreeControlTag extends TagSupport {
  @@ -400,6 +400,9 @@
   
   String updateTreeAction =
   replace(getAction(), "tree=${name}", "select=" + encodedNodeName);
  +updateTreeAction =
  +((HttpServletResponse) pageContext.getResponse()).
  +encodeURL(updateTreeAction);
   
   out.print("");
   if ((action != null) && !node.isLeaf()) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[remm]

remm02/03/13 12:02:20

  Modified:catalina/src/conf server.xml
  Log:
  - Make the new HTTP/1.1 connector the default connector. It will use the
URI normalization hack at the moment.
  
  Revision  ChangesPath
  1.55  +22 -18jakarta-tomcat-4.0/catalina/src/conf/server.xml
  
  Index: server.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- server.xml8 Mar 2002 05:35:46 -   1.54
  +++ server.xml13 Mar 2002 20:02:20 -  1.55
  @@ -84,28 +84,24 @@
IP address of the remote client.
   -->
   
  -
  -
  +
  +   acceptCount="10" debug="0" connectionTimeout="2"
  +   useURINormalizationHack="true" />
   
   
  -
  -
  -
   
   
   
  @@ -117,19 +113,27 @@
   
   
   
   
  -
  +
   
  +
  +
  +
   
   

Re: In memory session replication, reminder

[Remy Maucherat]

> >JavaGroups is cool since it is pure, multiplatform Java, although
> >(from what I know) it cannot fall back to TCP when multicast isn't
> >available,
>
> JavaGroups is cool, thanks :), and yes, it does support TCP. :))
>
> >What I'd like to do at some point is take Filip Hanik's TC4 session
> >replication code (looking nice!) and make it switchable to use either
> >Spread or JavaGroups, or other communication mechanisms for keeping the
> >session data in sync. Pluggable messaging back-ends..
>
> I would fully support this, I think it is a great idea!
>
> >FWIW, I'd like to see the in-memory session replication code as part
> >of TC4 itself, with a pluggable messaging layer API that allows
> >a separate messaging system to be used.
>
> yes yes yes,
> I would say make the hook ins and interfaces in catalina, and then you can
> just plug in any messaging system you want.

Well, apparently a lot of people would want that in j-t-c instead, and I
think they are right.
j-t-c/cluster should be a good name.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7096] - Incorrect reference to class

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7096

Incorrect reference to class





--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 19:53 ---
?
Could I get the "verbose" version of that report ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7096] New: - Incorrect reference to class

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7096

Incorrect reference to class

   Summary: Incorrect reference to class
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Catalina startup refers to org.w3c.dom.range.DocumentRange, while the actual 
path in xerces.jar is org.w3c.dom.ranges.DocumentRange.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: In memory session replication, reminder

[Filip Hanik]

>JavaGroups is cool since it is pure, multiplatform Java, although
>(from what I know) it cannot fall back to TCP when multicast isn't
>available,

JavaGroups is cool, thanks :), and yes, it does support TCP. :))

>What I'd like to do at some point is take Filip Hanik's TC4 session
>replication code (looking nice!) and make it switchable to use either
>Spread or JavaGroups, or other communication mechanisms for keeping the
>session data in sync. Pluggable messaging back-ends..

I would fully support this, I think it is a great idea!

>FWIW, I'd like to see the in-memory session replication code as part
>of TC4 itself, with a pluggable messaging layer API that allows
>a separate messaging system to be used.

yes yes yes,
I would say make the hook ins and interfaces in catalina, and then you can
just plug in any messaging system you want.

Remy, as I mentioned before, I more than willing to be the maintainer of
this code base, and work with people like Jason to get a pluggable messaging
system in there.
Right now we are only waiting for you and other Tomcat developers to make
the decision to move forward since I don't have commit privileges.

have a wonderful day.

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net

>-Original Message-
>From: Jason Brittain [mailto:[EMAIL PROTECTED]]
>Sent: Monday, March 11, 2002 6:01 PM
>To: Tomcat Developers List
>Subject: Re: In memory session replication, reminder
>
>
>GOMEZ Henri wrote:
>>>You can start with my doc, there are two references to
>>>JavaGroups in there
>>>http://www.filip.net/tomcat/tomcat-javagroups.html
>>>http://www.javagroups.com/
>>>
>>>
- Does it use multicast or others broadcast techniques ?

>>>Virtual Synchrony and Probabilistic broadcasting on top of IP
>>>Multicasting.
>>>see the docs
>>>
>>
>> Excellent stuff, something which could have its room in
>> jakarta !!!
>
>JavaGroups is cool since it is pure, multiplatform Java, although
>(from what I know) it cannot fall back to TCP when multicast isn't
>available, and the license could be "better"..  :)
>
>If you liked that, also have a look at Spread:
>
>http://www.spread.org/
>
>The messaging engine (daemon) isn't written in Java, but it's very
>fast and efficient, and runs on all the popular OSs.  The Java clients
>connect to it via TCP sockets, so the clients can be pure-Java.  The
>License is similar to the Apache license, and unlike JavaGroups the
>engine does know to fall back to using TCP unicast when multicast is
>not available.  It's been around for quite some time, too.
>

>
 But, if people decide that
>it's better suited to j-t-c, then that's okay (not quite as good, IMO),
>but I'd still like it to have a pluggable messaging layer API.
>
>Cheers.
>
>--
>Jason Brittain
><[EMAIL PROTECTED]>
>650-228-2644
>CollabNet http://www.collab.net
>
>
>--
>To unsubscribe, e-mail:

For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Patrick Luby]

Remy,

+1 for all.

Patrick

Remy Maucherat wrote:
> 
> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> start with some limited changes at first. Most of these proposed changes are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
> 
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> C) Add better lifecycle handling in the resources. A start method is needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this problem.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> yet another logging interface.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> +1 for everything. Thanks for voting / commenting :)
> 
> Remy
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties

[Larry Isaacs]

Hi David,

Yes, it is intentional.  Just "=" means append the properties to
java.policy.  "==" means replace java.policy, which is what we
want.

Thanks for the patches you have sent.  Sorry if it takes a while
before they are acted upon.

Cheers,
Larry

> -Original Message-
> From: Schreibman, David [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, March 13, 2002 12:57 PM
> To: 'Tomcat Developers List'
> Subject: RE: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties
> 
> 
> Hi Larry,
> 
> Thanks for checking this in.  By the way, what's up with
> 
>-Djava.security.policy=="$(wrapper.tomcat_policy)"
> ?
> 
> Is the == intentional?
> 
> I had changed it to just = in the patch I submitted but I 
> noticed that you left it in.  Just curious and didn't want to 
> pass up the chance to learn something
> 
> Thanks,
> 
> -David
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 12, 2002 7:40 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties
> 
> 
> larryi  02/03/12 19:40:07
> 
>   Modified:src/etc/jk wrapper.properties
>   Log:
>   Added quotes around wrapper.javabin in the wrapper.cmd_line.
>   
>   Submitted by: David Schreibman
>   
>   Added wrapper.jvm.options and some documentation.
>   
>   Revision  ChangesPath
>   1.4   +24 -4 jakarta-tomcat/src/etc/jk/wrapper.properties
>   
>   Index: wrapper.properties
>   ===
>   RCS file: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v
>   retrieving revision 1.3
>   retrieving revision 1.4
>   diff -u -r1.3 -r1.4
>   --- wrapper.properties  13 Oct 2001 02:25:13 -  1.3
>   +++ wrapper.properties  13 Mar 2002 03:40:07 -  1.4
>   @@ -1,7 +1,7 @@
>#
>   -# $Header: 
> /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v 1.3 
> 2001/10/13 02:25:13 billbarker Exp $
>   -# $Revision: 1.3 $
>   -# $Date: 2001/10/13 02:25:13 $
>   +# $Header: 
> /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v 1.4 
> 2002/03/13 03:40:07 larryi Exp $
>   +# $Revision: 1.4 $
>   +# $Date: 2002/03/13 03:40:07 $
>#
>#
># jk_service.properties - a bootstrup file for the Tomcat 
> NT service.
>   @@ -100,17 +100,37 @@
># wrapper.shutdown_port tells the service the identity of 
> the port that 
># is used by AJP12/AJP13.
>#
>   +# Ajp12
>wrapper.shutdown_port=8007
>
>   +# Ajp13
>   +#wrapper.shutdown_port=8009
>   +
>#
># Can either be ajp12 or ajp13 depending on your configuration.
>#
>   +# Note: If you use ajp13, be sure to enable shutdown on 
> the Ajp13Connector.
>   +#   For Tomcat 3.3 add: shutDownEnable="true"
>   +#   For Tomcat 3.3.1 add: shutdownEnable="true" or
> shutDownEnable="true"
>   +#
>   +# Note: Use of a shutdown "secret" (i.e. password) is not 
> supported.
>   +#
># Default value is ajp12
>#
>wrapper.shutdown_protocol=ajp12
>
>#
>   +# JVM Options
>   +#
>   +# Useful Options:
>   +# -Xms256m= Initial heap size, modify for desired size
>   +# -Xmx256m= Maximum heap size, modify for desired size
>   +# -Xrs= Available in Jdk1.3.1 to avoid JVM 
> termination during
> logoff
>   +#
>   +wrapper.jvm.options=
>   +
>   +#
># This is the command line that is used to start Tomcat. 
> You can *add* extra
># parameters to it but you can not remove anything.
>#
>   -wrapper.cmd_line=$(wrapper.javabin)
> -Djava.security.policy=="$(wrapper.tomcat_policy)"
> -Dtomcat.home="$(wrapper.tomcat_home)" -classpath 
> $(wrapper.class_path)
> $(wrapper.startup_class) -config $(wrapper.server_xml) 
>   +wrapper.cmd_line="$(wrapper.javabin)" 
> $(wrapper.jvm.options) 
> -Djava.security.policy=="$(wrapper.tomcat_policy)"
> -Dtomcat.home="$(wrapper.tomcat_home)" -classpath 
> $(wrapper.class_path)
> $(wrapper.startup_class) -config $(wrapper.server_xml) 
>   
>   
>   
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties

[Edgar Knobloch]

Hi David,

there is a short explanation:
http://www.weblogic.com/docs51/techsupport/java12.html#security

Regards,
Edgar

> -Ursprüngliche Nachricht-
> Von: Schreibman, David [mailto:[EMAIL PROTECTED]]
> Betreff: RE: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties
> 
> 
> Hi Larry,
> 
> Thanks for checking this in.  By the way, what's up with
> 
>-Djava.security.policy=="$(wrapper.tomcat_policy)"
> ?
> 
> Is the == intentional?
> 
> I had changed it to just = in the patch I submitted but I 
> noticed that you
> left it in.  Just curious and didn't want to pass up the 
> chance to learn
> something
> 
> Thanks,
> 
> -David
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Remy Maucherat]

> On Tue, 12 Mar 2002, Remy Maucherat wrote:
>
> > Also, I'm about to add in the TC 4 adapter the code used in TC 4 to
prevent
> > some URL based attacks (with a flag allowing to disable the checks,
though,
> > as this may be useless in the HEAD branch after the proposed
refactoring).
> > However, I know that TC 3.3 has that kind of nomalization code also, so
> > maybe you should check to be sure you don't need it (maybe in 3.3 it's
not
> > part of the connector; I don't remember).
>
> No, the charset decoding is in DecodingInterceptor and is independent of
> connector.
>
> The connectors only deals with receiving/sending bytes, they have no idea
> about encodings or chars. The encoding may well be stored in the servlet
> session ( this is the only reliable way to deal with current browsers ),
> and in 2.3 it may be specified by the user.
>
> Having a 'decoded' field in the Request is very usefull, but computing it
> in the connector would be a mistake IMHO, as it'll potentially require
> access to higher layers.
>
> BTW, there is some decoding that may be required ( when Strings are
> still used ), but the real decoder will set the right charset and may
> reconvert.
>
> URL decoding is also included in the main decoder, but can be done
> in the connector.

Yes, I agree with that. I've just added the call to your URL decoding method
in the processor. No char decoding there (too many things are called the
same; it's confusing).

> > > > 
> > > > [X] +1 I'm guessing that Costin & Larry will have fits with this (TC
3.3
> > > currently has no dependencies on outside packages).  However, my
support
> > is
> > > only if it gets into o.a.c.Processor.   It shouldn't be a http11 only
> > issue.
> > > > [ ] +0
> > > > [ ] -1:
> > > >
> > > > 
> >
> > Yes, that's a good point. JK 2 is using commons-logging already, so I
think
> > the dependency on that component is inevitable no matter what. I'd
rather
> > live without it, but I'm very unhappy at the moment of having no logging
at
> > all inside the processor.
> > Yes, the get/setLogger will go in the Processor interface.
>
> Jk2 is using commons logging interfaces. Note that the model is based on
> pull, not push - so get/setLogger are not needed.

Ok, I'll look at the code, try to use commons-logging, and see if the
get/setLogger is really needed.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 6346] - Sun's Tag Libraries Tutorial examples do not work

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6346

Sun's Tag Libraries Tutorial examples do not work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 17:57 ---
The exmples use unnamed namespaces, and are therefore incompatible with the
servlets generated by 1.4 jasper.  Apparently, 1.4 jasper added a named
namespace (package org.apache.jsp) to the servlet class, and according to java
rule, the unnamed namespace is only in scope in another unnamed namespace.  The
javac errors is an enforcement to this rule.

I'll contact Sun to have these examples updated.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties

[Schreibman, David]

Hi Larry,

Thanks for checking this in.  By the way, what's up with

   -Djava.security.policy=="$(wrapper.tomcat_policy)"
?

Is the == intentional?

I had changed it to just = in the patch I submitted but I noticed that you
left it in.  Just curious and didn't want to pass up the chance to learn
something

Thanks,

-David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 7:40 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties


larryi  02/03/12 19:40:07

  Modified:src/etc/jk wrapper.properties
  Log:
  Added quotes around wrapper.javabin in the wrapper.cmd_line.
  
  Submitted by: David Schreibman
  
  Added wrapper.jvm.options and some documentation.
  
  Revision  ChangesPath
  1.4   +24 -4 jakarta-tomcat/src/etc/jk/wrapper.properties
  
  Index: wrapper.properties
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- wrapper.properties13 Oct 2001 02:25:13 -  1.3
  +++ wrapper.properties13 Mar 2002 03:40:07 -  1.4
  @@ -1,7 +1,7 @@
   #
  -# $Header: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v 1.3
2001/10/13 02:25:13 billbarker Exp $
  -# $Revision: 1.3 $
  -# $Date: 2001/10/13 02:25:13 $
  +# $Header: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v 1.4
2002/03/13 03:40:07 larryi Exp $
  +# $Revision: 1.4 $
  +# $Date: 2002/03/13 03:40:07 $
   #
   #
   # jk_service.properties - a bootstrup file for the Tomcat NT service.
  @@ -100,17 +100,37 @@
   # wrapper.shutdown_port tells the service the identity of the port that 
   # is used by AJP12/AJP13.
   #
  +# Ajp12
   wrapper.shutdown_port=8007
   
  +# Ajp13
  +#wrapper.shutdown_port=8009
  +
   #
   # Can either be ajp12 or ajp13 depending on your configuration.
   #
  +# Note: If you use ajp13, be sure to enable shutdown on the
Ajp13Connector.
  +#   For Tomcat 3.3 add: shutDownEnable="true"
  +#   For Tomcat 3.3.1 add: shutdownEnable="true" or
shutDownEnable="true"
  +#
  +# Note: Use of a shutdown "secret" (i.e. password) is not supported.
  +#
   # Default value is ajp12
   #
   wrapper.shutdown_protocol=ajp12
   
   #
  +# JVM Options
  +#
  +# Useful Options:
  +# -Xms256m= Initial heap size, modify for desired size
  +# -Xmx256m= Maximum heap size, modify for desired size
  +# -Xrs= Available in Jdk1.3.1 to avoid JVM termination during
logoff
  +#
  +wrapper.jvm.options=
  +
  +#
   # This is the command line that is used to start Tomcat. You can *add*
extra
   # parameters to it but you can not remove anything.
   #
  -wrapper.cmd_line=$(wrapper.javabin)
-Djava.security.policy=="$(wrapper.tomcat_policy)"
-Dtomcat.home="$(wrapper.tomcat_home)" -classpath $(wrapper.class_path)
$(wrapper.startup_class) -config $(wrapper.server_xml) 
  +wrapper.cmd_line="$(wrapper.javabin)" $(wrapper.jvm.options)
-Djava.security.policy=="$(wrapper.tomcat_policy)"
-Dtomcat.home="$(wrapper.tomcat_home)" -classpath $(wrapper.class_path)
$(wrapper.startup_class) -config $(wrapper.server_xml) 
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7090] - JSP Compilation generate \r\n (new line)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7090

JSP Compilation generate \r\n (new line)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 17:39 ---
When you created a file like that, the chars that are in that file is
'<', '%', '%', '>', and '\n', the added '\n' cannot be be removed, according to
the spec.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7082

Calling an RMI Server from a servlet produces stack trace





--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 17:39 ---
I thought it was a bug in the JDK, but I tried it in TC3.3 with a space in the 
path and it worked.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7093] - Results Getting Truncated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7093

Results Getting Truncated





--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 17:21 ---
This is a "WORKSFORME" unless you provide a test case. It is very likely that 
an exception occurs during the processing of your page. If the exception occurs 
after the page has been committed, the exception will be logged rather than 
being displayed (maybe we could change that policy in the future).

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7083] - Tomcat 4 ignores querystring parameters containing '=' characters.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7083

Tomcat 4 ignores querystring parameters containing '=' characters.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 17:18 ---
According to the HTTP spec, you have to %xx encode special character, and '=' 
is one of them.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7082

Calling an RMI Server from a servlet produces stack trace

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Normal



--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 17:16 ---
Well, the error strongly hints at the Sun RMI classes incorrectly dealing with 
spaces in the path. This should have an obvious workaround (install Tomcat in a 
path without spaces, as you would do on Unix). Fixing the bug could be complex. 
If you're really interested in having this fixed quickly, you should try to 
debug it further.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7093] New: - Results Getting Truncated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7093

Results Getting Truncated

   Summary: Results Getting Truncated
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am not sure whether this is a setting somewhere that I have missed, but I 
have a JSP that is returning around 32000 bytes and the result is consistantly 
getting cut off mid stream.  At first I assumed that this was a problem with 
the client because the content-length was not sent, but then I used a telent 
client and notice that it was getting cut off in the same spot.
I installed on linux from tomcat4-4.0.2-3.noarch.rpm

You can see the problem on my Tomcat 4 server if you execute the following post:

POST HTTP://demo2.cokinetic.com:80/quickbooks/paybills.jsp HTTP/1.1
Host: demo2.cokinetic.com
Content-Length: 0
Content-Type: application/x-www-form-urlencoded
Cookie: JSESSIONID=FEB661E15C20D9DBCE4925B45499F713

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

on EJB and tomcat4.0.3

[wzfg]

Hi,friend,
I tried to use tomcat 4.0.3 and JBoss 2.4.3 for using EJB, but got the 
following problems:
(JBoss works well)(Tomcat encountered the problem:)
...
getEJB,icx=javax.naming.InitialContext@7f0dde
getEJB,envCtx=org.apache.naming.NamingContext@101437
getEJB,Error getting CatalogEJB! Cannot create resource instance
javax.naming.NamingException: Cannot create resource instance
at 
org.apache.naming.factory.EjbFactory.getObjectInstance(EjbFactory.java:184)
at 
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at org.apache.naming.NamingContext.lookup(NamingContext.java:835)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:194)
at com.javabeans.Catalog.getEJB(Catalog.java:34)
at com.javabeans.Catalog.(Catalog.java:22)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:237)
at java.beans.Beans.instantiate(Beans.java:207)
at java.beans.Beans.instantiate(Beans.java:51)
at org.apache.jsp.browse$jsp._jspService(browse$jsp.java:138)
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at 
com.myservlet.DebugRequestFilter.doFilter(DebugRequestFilter.java:38)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1012)
at 
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107)
at java.lang.Thread.run(Thread.java:484)
Error using CatalogEJB (retrieving all)! null
...

my Server.xml as following:(I use ejb/ejb/CatalogEJB, if delete one ejb, 
I will get ejb not bound problem)
..
  
..

Then What should I do to solve the problem? I can not find any info. 
about tag  in Docs.

Thanks a lot.




--
To unsubscribe, e-

DO NOT REPLY [Bug 7092] New: - socket error while trying write to response.getOutputStream() with on servlet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7092

socket error while trying write to response.getOutputStream() with 
 on servlet

   Summary: socket error while trying write to
response.getOutputStream() with  on
servlet
   Product: Tomcat 4
   Version: 4.0 Beta 4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: HTTP/1.1 Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If servlet is secure and trys to do:

if (fromFile.exists() && !fromFile.isDirectory()) {
byte[] buf = new byte[100*1024];
//Set header and mime type
String mimetype = downloadConfig.getServletContext().getMimeType( 
fileName );
response.setContentType( (mimetype != null) ? 
mimetype : "application/octet-stream" );
response.setContentLength( (int)fromFile.length() );
response.setHeader( "Content-Disposition", "attachment; 
filename=\"" + request.getParameter("file") + "\"" );
BufferedInputStream bufIS = new BufferedInputStream(new 
FileInputStream(fromFile),1024*1024);
int byteRead;
ServletOutputStream out = response.getOutputStream();
while( (bufIS != null) && (byteRead = bufIS.read(buf,0,100*1024)) !
= -1) {
  out.write(buf,0,byteRead);
}
bufIS.close();
out.flush();
out.close();

than output is ok only first time. Any other attempt to do it arise the socket 
error and put in log file:

2002-03-13 17:47:02 [org.apache.catalina.connector.warp.WarpConnector] Error 
accepting requests
java.net.SocketException: socket closed
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:468)
at java.net.ServerSocket.implAccept(ServerSocket.java:243)
at java.net.ServerSocket.accept(ServerSocket.java:222)
at org.apache.catalina.connector.warp.WarpConnector.run
(WarpConnector.java:590)
at java.lang.Thread.run(Thread.java:484)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[costinm]

On Tue, 12 Mar 2002, Remy Maucherat wrote:

> Also, I'm about to add in the TC 4 adapter the code used in TC 4 to prevent
> some URL based attacks (with a flag allowing to disable the checks, though,
> as this may be useless in the HEAD branch after the proposed refactoring).
> However, I know that TC 3.3 has that kind of nomalization code also, so
> maybe you should check to be sure you don't need it (maybe in 3.3 it's not
> part of the connector; I don't remember).

No, the charset decoding is in DecodingInterceptor and is independent of 
connector. 

The connectors only deals with receiving/sending bytes, they have no idea 
about encodings or chars. The encoding may well be stored in the servlet 
session ( this is the only reliable way to deal with current browsers ),
and in 2.3 it may be specified by the user.

Having a 'decoded' field in the Request is very usefull, but computing it
in the connector would be a mistake IMHO, as it'll potentially require
access to higher layers.

BTW, there is some decoding that may be required ( when Strings are 
still used ), but the real decoder will set the right charset and may
reconvert.

URL decoding is also included in the main decoder, but can be done
in the connector.  


> > > 
> > > [X] +1 I'm guessing that Costin & Larry will have fits with this (TC 3.3
> > currently has no dependencies on outside packages).  However, my support
> is
> > only if it gets into o.a.c.Processor.   It shouldn't be a http11 only
> issue.
> > > [ ] +0
> > > [ ] -1:
> > >
> > > 
> 
> Yes, that's a good point. JK 2 is using commons-logging already, so I think
> the dependency on that component is inevitable no matter what. I'd rather
> live without it, but I'm very unhappy at the moment of having no logging at
> all inside the processor.
> Yes, the get/setLogger will go in the Processor interface.

Jk2 is using commons logging interfaces. Note that the model is based on 
pull, not push - so get/setLogger are not needed. 

The main benefits over current 3.3 logging - it allows much finer 
granularity for logging/info and already supports log4j/jdk1.4.
My plan is to do a small performance test on QLog vs. log4j/1.4,
and if the results are positive ( QLog has few features, but is 
quite 'tuned' ) make QLogger implement commons logging. 

3.3 has no dependencies external to apache - jaxp is required
( but easy to replace the impl with a smaller one ), and 
each module may have its own dependencies (jk2->logging).

I do plan to add a dependency jk2->openjmx, at the moment it
seems the best way to provide runtime manageability of the 
connector and the recent changes in the C side are in this
direction ( i.e. jk2 will have a proxy/remote mbean that
will manage mod_jk ) 

The commons-logging 'core' is comparable in size and power
with tomcat.util.log, so I see no problem moving to 
a common log.

Costin 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7090] New: - JSP Compilation generate \r\n (new line)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7090

JSP Compilation generate \r\n (new line)

   Summary: JSP Compilation generate \r\n (new line)
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When you do (in the shell) this
_
$ echo "<%%>" > x.jsp
_
Tomcat compile x.jsp and the corresponding java result contains this line
out.write("\r\n");
it is a problem getting images from database when you use a JSP. This new line 
makes files be corrupted.

please help
Thanks a lot
alfonso

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7052] - Security manager not initialised or accessed properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7052

Security manager not initialised or accessed properly





--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 14:28 ---
A less clunky patch.  The private variable "securityManager" is unnecessary.

Keith

106d105
< private SecurityManager securityManager = null;
118d116
<   this.securityManager = System.getSecurityManager();
180c178
< securityManager.checkPackageAccess(name.substring(0,dot));
---
> System.getSecurityManager().checkPackageAccess
(name.substring(0,dot));

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD

[Larry Isaacs]

+0 for all.  Wish I had more time to help.

Larry

> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, March 12, 2002 9:30 PM
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
> 
> 
> There are many ways to take advantage of Coyote in Tomcat 4, 
> but I'd like to start with some limited changes at first. 
> Most of these proposed changes are Coyote-related (hence the 
> subject of the message), and all involve some refactoring / 
> API additions.
> 
> A) URI decoding refactoring. To avoid doing some URI decoding 
> in many places in the pipeline, a decodedURI field (with 
> associated getter/setter) should be added in the HttpRequest 
> interface, and used in the Catalina pipeline. This also has 
> the advantage to guarantee that no double URI decoding occurs 
> (which can lead to URI-based security attacks).
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, 
> replacing the old connector, which has many shortcoming (slow 
> performance on output, HTTP handling limitations and extreme 
> complexity). Initial tests results and benchmarks with Coyote 
> are extremely positive so far.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> C) Add better lifecycle handling in the resources. A start 
> method is needed (which could be called 'allocate' to mirror 
> the 'release' method), because it is currently not possible 
> to restart a stopped context. In the 4.0 branch, the patch 
> introducing the 'release' method must either be reverted, or 
> these proposed changes must also be ported to 4.0. Thanks to 
> Jean-Francois Clere for the report and debugging of this problem.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> D) Deprecate the o.a.catalina.connector package. This package 
> *SHOULD NOT* be used for any new connector development. To 
> make this more obvious, I'd like to deprecate all classes in 
> this package and subpackages. The binaries will also be 
> packaged in a separate JAR file (tentatively named 
> catalina-legacy.jar). This package will continue to be 
> maintained on a case by case basis. The facades will not be 
> deprecated, and two new helper objects will be introduced to 
> handle the need for "fake" req/resp when requesting a JSP 
> precompilation with a load-on-startup (see bug 4518 for more details).
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> E) Use commons-logging in Coyote, by adding a get/setLogger 
> on the Processor interface. Otherwise, the processor has no 
> way to cleanly handle logging. commons-logging is already 
> used by other j-t-c components. At the moment, the HTTP/1.1 
> processor "logs" problems as stack traces on the stderr; this 
> needs to be improved. When I originally designed most of the 
> base interfaces, commons-logging didn't exist yet, and I 
> didn't feel like adding yet another logging interface.
> 
> 
> [ ] +1
> [ ] +0
> [ ] -1:
> 
> 
> 
> +1 for everything. Thanks for voting / commenting :)
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7083] New: - Tomcat 4 ignores querystring parameters containing '=' characters.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7083

Tomcat 4 ignores querystring parameters containing '=' characters.

   Summary: Tomcat 4 ignores querystring parameters containing '='
characters.
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Previous Tomcat releases have allowed '=' characters in querystring parameters, 

e.g. ?id=12345&sig=12345==
would be read as 
id=12345
sig=12345==
Tomcat 4 reads the above as: 
id=12345
sig=null

Why the change in behaviour?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7082] New: - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7082

Calling an RMI Server from a servlet produces stack trace

   Summary: Calling an RMI Server from a servlet produces stack
trace
   Product: Tomcat 4
   Version: 4.0.4 Beta 1
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using jdk 1.4.0 and TC4.0.4b1 (haven't tried another jdk yet, but it works 
fine using TC3.3 and this jdk) and calling an RMI server produces the 
following stack trace:

java.rmi.ServerException: RemoteException occurred in server thread; nested 
exception is: 
java.rmi.UnmarshalException: error unmarshalling arguments; nested 
exception is: 
java.net.MalformedURLException: no protocol: Files/Apache
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:292)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages
(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run
(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:536)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer
(StreamRemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall
(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
at com.staffplanner.utils.rmi.StaffplannerRemoteImpl_Stub.executeTask
(Unknown Source)
at com.staffplanner.utils.rmi.RemoteController.execute
(RemoteController.java:76)
at com.staffplanner.utils.rmi.RemoteServer.callRemote
(RemoteServer.java:56)
at com.staffplanner.batchjobs.CrystalProcessServer.runCrystalReport
(CrystalProcessServer.java:15)
at 
com.staffplanner.pages.tradingweeks.TradingWeekScrollPage.processCustomRequests
(TradingWeekScrollPage.java:316)
at com.staffplanner.pages.base.ScrollPage.processFormSubmit
(ScrollPage.java:181)
at com.staffplanner.pages.base.ScrollPage.processPost
(ScrollPage.java:129)
at com.staffplanner.pages.base.StaffPlannerPage.doPost
(StaffPlannerPage.java:453)
at com.staffplanner.pages.base.ScrollPage.doPost(ScrollPage.java:118)
at com.staffplanner.servlets.StaffPlannerServlet.processRequest
(StaffPlannerServlet.java:227)
at com.staffplanner.base.ServletBase.doPost(ServletBase.java:74)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.access$0
(ApplicationFilterChain.java:197)
at org.apache.catalina.core.ApplicationFilterChain$1.run
(ApplicationFilterChain.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:172)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.CertificatesValve.invoke
(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2347)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valv

DO NOT REPLY [Bug 7080] New: - Interbase JDBCRealm - Bug # 5564 - Have a safe fix.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7080

Interbase JDBCRealm - Bug # 5564 - Have a safe fix.

   Summary: Interbase JDBCRealm - Bug # 5564 - Have a safe fix.
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On inspecting the code to JDBCReam.java, I made the following change to the method 
credentials().  The short of it is that the string should be tested to
see if null.  If it is null 
then the setNull() method should be called on prepared statement. Not calling the 
setNull() 
method can cause PreparedStatement setString() to fail for other JDBC drivers too.


protected PreparedStatement credentials(Connection dbConnection,
String username)

throws SQLException {

if (preparedCredentials == null) {
StringBuffer sb = new 
StringBuffer("SELECT ");
sb.append(userCredCol);
sb.append(" FROM ");

sb.append(userTable);
sb.append(" WHERE ");
sb.append(userNameCol);
sb.append(" = 
?");
preparedCredentials =
dbConnection.prepareStatement(sb.toString());
}

  
if ( username == null )
preparedCredentials.setNull(1,java.sql.Types.VARCHAR);

else
  preparedCredentials.setString(1, username);
return (preparedCredentials);


}

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7078] New: - Session created in https not valid for http

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7078

Session created in https not valid for http

   Summary: Session created in https not valid for http
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If you create a session during a http request, you can see it in a following 
https request, too.
If you create a session during a HTTPS request, you CAN'T SEE IT in a following 
http request!

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: JSP parsing bug?

[Alf Scherer]

All right :)

Thanks.

-Original Message-
From: Tomas Rokicki [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, March 12, 2002 8:05 PM
To: Tomcat Developers List
Subject: RE: JSP parsing bug?


This isn't a bug; this is according to spec.  The parsing
of the <%...%> is done first, independent of whatever bytes might be in
there.  Thus, your code looks to the JSP compiler like

A declaration consisting of
"

// <% comment "

Literal content consisting of
"

final static int SOME_INT = 0xF;

public void someMethod(){

}
%>
This page demonstrates a parsing bug"

So, I'd say, no bug.  Just a common misunderstanding.

-tom

-Original Message-
From: Alf Scherer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 10:53 AM
To: Tomcat Developers List
Subject: JSP parsing bug?


Hi,

I've discovered something that looks like a bug to me, although I'm not
sure whethter this should/can be classified as a bug. The following
behavour occurs when you put "<% %>"-JSP tags inside a java comment in a
JSP file. The code following the comment will be displayed on the page
when requesting the file.


You can try the following code snippet to see how it works out.

 snip 
<%!

// <% comment %> 

final static int SOME_INT = 0xF;

public void someMethod(){

}
%>
This page demonstrates a parsing bug
 snip 

Cya,
Alf


-
 Alf Scherer|
|
 CarrotMEDIA GmbH   |
 Saegewerkstr. 3| Q: What is a programmer?
 83395 Freilassing  | A: A bio-chemical machine, turning 
 Germany, EU|coffee into lines of code
- 


--
To unsubscribe, e-mail:

For additional commands, e-mail:




smime.p7s
Description: application/pkcs7-signature

Re: jk2: Config changes ( again )

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
> 
> On Tue, 12 Mar 2002, jean-frederic clere wrote:
> 
> > myworker1=
> > Would be the same as:
> > myworker1=ajp13://localhost:8009?lbfactor=0&debug=ERROR
> > (no load balancing and only log error messages).
> 
> 
> > How to describe AF_UNIX or shared memory (as transport but not protocol)?
> > myworker1=ajp13://file_name:afsocket?lbfactor=0&debug=ERROR
> > myworker1=ajp13://key_file:shm?lbfactor=0&debug=ERROR
> 
> Good question...
> 
> ajp13:aprChannel:/tmp/tomcat.socket?
> or
> apj13:channel.apr:/tmp/tomcat.socket?lbfactor=0...
> 
> ajp13:jniChannel?lbfactor=0&debug=0
> 
> If no channel is specified, default to the socket channel.
> ajp13:channel.socket://localhost:8009
> ajp13://localhost:8009
> 
> Ok, so the question is: which form ? The goal is to be intuitive, easy to
> type, easy to explain. It seems some hierarchical naming is the best way
> ( but which form ? ).
> 
> So far we have the following:
> 
> - separators do not matter ( syntactical sugar ) - . : / _ -
> - each 'name' is hierarchical
> - a name with a single component ( myworker1 ) defines an alias, for
> easier typing. The RHS will be the real name. Question: should it be
> alias.myworker1=ajp13:// ?

Why do we alias?

> 
> - The first part of the hierarchical name will identify the type.
> 
> - The second part of the hierarchical name be used by the constructor.
> For example, the ajp13 constructor will take the local part and interpret
> the first component as a channel name, then what's after ? as parameters.
> 
> What do we do about properties ? Are we going with 2 styles - a URL style
> and a workers.properties style ?

No... We should choose one.

> 
> In workers.properties style:
> 
> ajp13.[LOCAL_PART].port=8009
> ajp13.[LOCAL_PART].debug=0
> ajp13.[LOCAL_PART].lbfactor=1
> 
> More ideas ? Implementing this is not trivial, but I would hate to have to
> do it again.
> 
> Costin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: