[JK2] uriMap vhosts

[Mladen Turk]

Hi,

Seems we have some problems and conceptual misunderstandings regarding
vhosts.
I would like to clear that a bit cause it's a pretty big showstopper on
any beta.

My proposal is to lead some light to both configuration and code that
maps all that.

We need to things that will satisfy that.

1. Making some sort of _default_ mappings
These mappings are for every host on the server (both default and every
vhost).
There is no particular reason for that except that the
workers2.properties can be smaller.

2. Making vhost:port scheme
Using general vhost:* mapping no matter port number is and
Using vhost:port mappings for that particular combination.

If the hostname is provided than the mapping can only be done in the
following cases:

1. Exact hostname:port is found
2. Hostname:* is found
3. _default_ mapping has been found.

Now my question is are there any ideas how to differentiate the default
host and its mappings from the _default_ mappings for every host
(default and all the vhosts) in the w2.p.


MT.


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

RE: [JK2] uriMap vhosts

[Ignacio J. Ortega]

> De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> Enviado el: 23 de septiembre de 2002 9:06
> Para: [EMAIL PROTECTED]
> Asunto: [JK2] uriMap vhosts
> 
> 

Hola Mladen: 

I agree with the introduction including the new vhost:* form, FYI
uriEnv, when the host is not setted, responds that host is "*" :), the
interpretation about _default_ ( or Global i prefer ) mappings is
correct, and i know Costin did that this way because i asked so, map the
capabilities of isapi in jk..

> 
> Now my question is are there any ideas how to differentiate 
> the default
> host and its mappings from the _default_ mappings for every host
> (default and all the vhosts) in the w2.p.
> 
> 

There is no difference, if one needs to map a Java context to one the
alias of the default server, the only way to do it, is to think about
the default server, exactly as any other VS, it has a name ( well in
fact a namespace that includes localhost, any ip variation , the host
name and some more), and do explicit mappings with the name to which one
want to associate the Java Context, i see no problem with this..

Saludos ,
Ignacio J. Ortega


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

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

[remm]

remm2002/09/23 01:19:18

  Modified:catalina/src/share/org/apache/catalina/servlets
InvokerServlet.java
  Log:
  - Port patch.
  
  Revision  ChangesPath
  1.2   +11 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java
  
  Index: InvokerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- InvokerServlet.java   18 Jul 2002 16:47:40 -  1.1
  +++ InvokerServlet.java   23 Sep 2002 08:19:18 -  1.2
  @@ -320,6 +320,13 @@
   } else {
   pathInfo = "";
   }
  +
  +if (servletClass.startsWith("org.apache.catalina")) {
  +response.sendError(HttpServletResponse.SC_NOT_FOUND,
  +   inRequestURI);
  +return;
  +}
  +
   if (debug >= 1)
   log("Processing servlet '" + servletClass +
   "' with path info '" + pathInfo + "'");
  
  
  

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

cvs commit: jakarta-tomcat-4.0/lib tomcat-ajp.jar tomcat-coyote.jar tomcat-http11.jar tomcat-util.jar

[remm]

remm2002/09/23 01:23:25

  Modified:lib  Tag: tomcat_40_branch tomcat-ajp.jar
tomcat-coyote.jar tomcat-http11.jar tomcat-util.jar
  Log:
  - Update Coyote and AJP.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.11  +238 -261  jakarta-tomcat-4.0/lib/Attic/tomcat-ajp.jar
  
<>
  
  
  1.1.2.4   +198 -207  jakarta-tomcat-4.0/lib/Attic/tomcat-coyote.jar
  
<>
  
  
  1.1.2.4   +119 -144  jakarta-tomcat-4.0/lib/Attic/tomcat-http11.jar
  
<>
  
  
  1.1.2.10  +581 -534  jakarta-tomcat-4.0/lib/Attic/tomcat-util.jar
  
<>
  
  

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

RE: [JK2] uriMap vhosts

[Mladen Turk]

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> 
> 
> There is no difference, if one needs to map a Java context to 
> one the alias of the default server, the only way to do it, 
> is to think about the default server, exactly as any other 
> VS, it has a name ( well in fact a namespace that includes 
> localhost, any ip variation , the host name and some more), 
> and do explicit mappings with the name to which one want to 
> associate the Java Context, i see no problem with this..
> 

I don't think so.
The default serverer should be namless, cause it can have many aliases,
and the default port can vary. Also that way we could separate the
default and vhost settings.
We can do that using aliases.
So for the default we should assume that its name is *:*, meaning we can
map and the specific port too.

[uri:*]
alias=localhost
alias=127.0.0.1
alias=63.251.56.142
alias=www.apache.org
etc...

But what if I wish that nothing from the default host be the Global
mapping.
Right now all the default mappings are also the global ones, which is
definitely bad, and you may have some vhosts that you wish _not_ to be
mapped to TC at all, but they will, cause of global mappings.

The global mappings should IMO be marker as such, just to ease the
config, but in general it's a bad idea, and the only benefit is that it
promotes laziness ;).

Right now the i_r2 uses found_vhost/default which is very bad cause the
SSL connections will get mapped to the TC too, and perhaps I don't wish
to do that, but I cannot.

Using the upper mechanism I could be able to specify the

[uri:*:443]

And that will force the alias:443 mappings.

So:

1. Make the alias to work
2. Get rid of Global settings as such (but can be enabled if you put the
vhost as a alias to the default host)
3. Make the host:port parsing to work 



MT.


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

Re: mod_jk 1.2.0 release proposal

[Henri Gomez]

Bojan Smojver wrote:
> Sounds good (although I have to admit I haven't compiled mod_jk from CVS
> for a while).

Just take a look, cvs should be tagged tomorrow  ;)





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

cvs commit: jakarta-tomcat-connectors/jk build.xml

[hgomez]

hgomez  2002/09/23 03:04:24

  Modified:jk   build.xml
  Log:
  Remove unneeded stuff
  
  Revision  ChangesPath
  1.56  +0 -8  jakarta-tomcat-connectors/jk/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
  retrieving revision 1.55
  retrieving revision 1.56
  diff -u -r1.55 -r1.56
  --- build.xml 20 Sep 2002 21:34:18 -  1.55
  +++ build.xml 23 Sep 2002 10:04:24 -  1.56
  @@ -384,14 +384,6 @@
 
   
  
  -
  -  
  -
  -   
  -
  -  
  -
  -   
   
   
   
  
  
  

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

RE: [JK2] uriMap vhosts

[Ignacio J. Ortega]

> De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> Enviado el: 23 de septiembre de 2002 10:47
> > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> > 
> > 
> > There is no difference, if one needs to map a Java context to 
> > one the alias of the default server, the only way to do it, 
> > is to think about the default server, exactly as any other 
> > VS, it has a name ( well in fact a namespace that includes 
> > localhost, any ip variation , the host name and some more), 
> > and do explicit mappings with the name to which one want to 
> > associate the Java Context, i see no problem with this..
> > 
> 
> I don't think so.
> The default serverer should be namless, cause it can have 
> many aliases,
> and the default port can vary. Also that way we could separate the
> default and vhost settings.
> We can do that using aliases.
> So for the default we should assume that its name is *:*, 
> meaning we can
> map and the specific port too.
> 

Another case for language impedance? ;)..

The default host does have name, a namespace that includes everything
not explictely configured as a VS, in any port the server listens.. 



> [uri:*]
> alias=localhost
> alias=127.0.0.1
> alias=63.251.56.142
> alias=www.apache.org
> etc...
> 

Ok, this defines the namespaces served by Default..

> But what if I wish that nothing from the default host be the Global
> mapping.
> Right now all the default mappings are also the global ones, which is
> definitely bad, and you may have some vhosts that you wish _not_ to be
> mapped to TC at all, but they will, cause of global mappings.
> 

I dont think i understand you completely, but from my POV, it's
irrelevant, we do want Global mappings? i think so, this is the way
I_r.dll works right now, and we need to map such a functionality.

With my proposal, can you map concrete Java Context to any of the
aliases of default or all? yes we can..

> The global mappings should IMO be marker as such, just to ease the
> config, but in general it's a bad idea, and the only benefit 
> is that it
> promotes laziness ;).
> 

As said, global aliases are a reminiscent of jk's isapi, and lazyness in
some environments is not bad at all, think of mass VS hosting, do we
need to define a globally used Java context for every VS? we shouldn't

> Right now the i_r2 uses found_vhost/default which is very bad 
> cause the
> SSL connections will get mapped to the TC too, and perhaps I 
> don't wish
> to do that, but I cannot.
> 

I've lost the clue here, can you rephrase it?

Rigth now i_r2.dll ( as i_r.dll did) uses directly the Host header, i
agree that this is inherently insecure, i will change this to use, the
same that apche does, to use the host in the header, but the real port..
instead of directly the Host header.. are you talking about that?


> Using the upper mechanism I could be able to specify the
> 
> [uri:*:443]
> 
> And that will force the alias:443 mappings.
> 
> So:
> 
> 1. Make the alias to work

Ohh, never tried, are aliases buggy too? :))

In anycase i'm +1 in to have less bugs.. ;))

> 2. Get rid of Global settings as such (but can be enabled if 
> you put the
> vhost as a alias to the default host)

This makes life very complicated to old i_r users, neither it's the best
for a mass vhosting enviroment.. until a better solution, i'm -1 in
unsupport Global mappings..

> 3. Make the host:port parsing to work 

ok

> 
> 
> 
> MT.


Saludos ,
Ignacio J. Ortega


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

Re: [POLL] aprize jk2

[Costin Manolache]

Mladen Turk wrote:

> I would like to make a poll (something non-obligatory as a vote) about
> using apr/apr-util inside the jk2. The reason is quite simple, we have
> lots of extra code that we either duplicate or just mimic. Since the APR
> is already default for Apache2 and IIS, IMO there is no reason to keep
> and maintain the 'old pre-apr' code.
> 
> I would like to use the APR for every API supported. Meaning memory
> pools (we have a serious memory leak problem with i_r2 just using
> different pool), file i/o, etc...
> Of course that would mean switching to the apr socket too.
> 
> So...
> 
> 1. Keep the status quos
> 
> 2. Use the APR for memory pool management
> 
> 3. Use the APR for file i/o
> 
> 4. Use the APR for network i/o
> 
> 5. Use the APR for shared memory (never been able to use that without
> APR)
> 
> 6. Use the APR for threads (well, that's the only way to use it at all)
> 

+1 on using apr/apr-util - but I would preffer doing so for jk2.1.

Let's tag/branch the workspace as jk2.0, with the current code ( as beta 
level ), at the moment 4.1 is released. It is stable and works.
Imediately after we start on the main branch with the removal of the
old code, and use the APR version.

That was the original plan anyway (AFAIK). 

Costin



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

RE: [JK2] uriMap vhosts

[Costin Manolache]

My only requirement: make sure whatever we define as mapping in 
jk2 ( i.e. jk_map, etc ) works identically with the 
 in Apache.

IMO this is an important use case, with 

  JkSet 


( i.e. use the native apache mapper, bypassing jk_map). 
Jk_map should use mappings as close as possible to apache
( and differ only where the servlet spec forces it ).

Costin


Mladen Turk wrote:

> 
> 
>> -Original Message-
>> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
>> 
>> 
>> There is no difference, if one needs to map a Java context to
>> one the alias of the default server, the only way to do it,
>> is to think about the default server, exactly as any other
>> VS, it has a name ( well in fact a namespace that includes
>> localhost, any ip variation , the host name and some more),
>> and do explicit mappings with the name to which one want to
>> associate the Java Context, i see no problem with this..
>> 
> 
> I don't think so.
> The default serverer should be namless, cause it can have many aliases,
> and the default port can vary. Also that way we could separate the
> default and vhost settings.
> We can do that using aliases.
> So for the default we should assume that its name is *:*, meaning we can
> map and the specific port too.
> 
> [uri:*]
> alias=localhost
> alias=127.0.0.1
> alias=63.251.56.142
> alias=www.apache.org
> etc...
> 
> But what if I wish that nothing from the default host be the Global
> mapping.
> Right now all the default mappings are also the global ones, which is
> definitely bad, and you may have some vhosts that you wish _not_ to be
> mapped to TC at all, but they will, cause of global mappings.
> 
> The global mappings should IMO be marker as such, just to ease the
> config, but in general it's a bad idea, and the only benefit is that it
> promotes laziness ;).
> 
> Right now the i_r2 uses found_vhost/default which is very bad cause the
> SSL connections will get mapped to the TC too, and perhaps I don't wish
> to do that, but I cannot.
> 
> Using the upper mechanism I could be able to specify the
> 
> [uri:*:443]
> 
> And that will force the alias:443 mappings.
> 
> So:
> 
> 1. Make the alias to work
> 2. Get rid of Global settings as such (but can be enabled if you put the
> vhost as a alias to the default host)
> 3. Make the host:port parsing to work
> 
> 
> 
> MT.

-- 
Costin



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

RE: [JK2] uriMap vhosts

[Mladen Turk]

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> 
> Another case for language impedance? ;)..
>

Yes it seems :)
 
> 
> > But what if I wish that nothing from the default host be the Global
> > mapping.
> 
> I dont think i understand you completely, but from my POV, it's
> irrelevant, we do want Global mappings? i think so, this is the way
> I_r.dll works right now, and we need to map such a functionality.
>

You may have a VS that you wish NOT to map. But OK, then you have to
name that host withouth any mappings.


> > 1. Make the alias to work
> 
> Ohh, never tried, are aliases buggy too? :))
>

Don't know how that happened, but yes :-).

> 
> > 2. Get rid of Global settings as such (but can be enabled if 
> > you put the
> > vhost as a alias to the default host)
> 
> This makes life very complicated to old i_r users, neither 
> it's the best
> for a mass vhosting enviroment.. until a better solution, i'm -1 in
> unsupport Global mappings..
> 

OK, I can live with that for now :)

> > 3. Make the host:port parsing to work 
> 
> ok
> 

I'm working on that for some time, using also *:* parsing, meaning that
the default host will have the vhost name as "*", allowing mappings
either to that or to the NULL (allowing Global mappings). So intead of
NULL and separate table we'll use the "*" for a host name and only vhost
tables.
It will make the entire code lot easier to understand. Is that OK with
you?

Could you check the i_r2.dll if it can use the GetServerVariable
SERVER_NAME:SERVER_PORT perhaps?


MT.


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

RE: [POLL] aprize jk2

[Mladen Turk]

Hi, glad to see you rised from the death :)

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache
> Sent: Monday, September 23, 2002 12:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [POLL] aprize jk2
> 
> 
> +1 on using apr/apr-util - but I would preffer doing so for jk2.1.
> 

Yes that was my thought too.

> Let's tag/branch the workspace as jk2.0, with the current 
> code ( as beta 
> level ), at the moment 4.1 is released. It is stable and 
> works. Imediately after we start on the main branch with the 
> removal of the old code, and use the APR version.
> 
> That was the original plan anyway (AFAIK). 
> 

Two things:

1. vhosts doesn't behave very well right now (we are solving that) on
all platforms
2. BUG 12346 (sockets)
3. Release

MT.



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

Re: [JK2] uriMap vhosts

[Costin Manolache]

Mladen Turk wrote:
 
> 1. Making some sort of _default_ mappings
> These mappings are for every host on the server (both default and every
> vhost).
> There is no particular reason for that except that the
> workers2.properties can be smaller.
> 
> 2. Making vhost:port scheme
> Using general vhost:* mapping no matter port number is and
> Using vhost:port mappings for that particular combination.
> 
> If the hostname is provided than the mapping can only be done in the
> following cases:
> 
> 1. Exact hostname:port is found
> 2. Hostname:* is found
> 3. _default_ mapping has been found.
> 
> Now my question is are there any ideas how to differentiate the default
> host and its mappings from the _default_ mappings for every host
> (default and all the vhosts) in the w2.p.

We can have a 
[ default: ] 
section.

Or we can use 'global' settings ( attributes ).

Do you have any example use-case ? How would it translate to
a httpd.conf ?

Costin
 

> 
> 
> MT.

-- 
Costin



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

Re: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh

[Costin Manolache]

Bill Barker wrote:

> 
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 18, 2002 9:21 PM
> Subject: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh
> 
> 
>> billbarker2002/09/18 21:21:17
>>
>>   Modified:src/shell tomcat.bat tomcat.sh
>>   Log:
>>   Temporary stop-gap until I work out all of the ClassLoader issues.
>>
> 
> Ok, there are a couple of options here:
> 1) Add a Class-Path to the Manifest (and make a comment in the release
> notes for people using Java 1.1.x).
> 
> 2) Revert o.a.t.u.compat.* and o.a.t.u.depend.* to using System.err
> instead of c-l, since they are loaded in the System ClassLoader when
> running from the scripts.
> 
> 3) Re-implement the required methods from o.a.t.u.compat.* in
> o.a.t.startup.Main so that we can leave o.a.t.u.depend.* and
> o.a.t.u.compat.* out of the jar.
> 
> My personal choices are in order, 3-1-2.  However 1 is the easiest, and
> seems to be in the direction that the proposals are heading.
> 
> Opinions (Larry/Costin)?

I used to like a lot (1), however I've been bitten few times. I still
think it is a good solution, but with a lot of care.

(2) is very easy to implement, and can solve the problem.

The big question is: do we want to keep the very small/minimal parent
loader - with commons-logging-api in the container loader ? 
  
BTW, I'm not sure what was the original problem you are trying 
to solve. I have a lot of mail to sort through, I would apreciate 
some more context info :-)

-- 
Costin



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

RE: [POLL] aprize jk2

[Costin Manolache]

Mladen Turk wrote:

> Hi, glad to see you rised from the death :)

Unfortunately - it's back from vacation. Besides
getting in the right timezone, I have to get re-adjusted with
using a computer and reading mail... 


>> Let's tag/branch the workspace as jk2.0, with the current
>> code ( as beta
>> level ), at the moment 4.1 is released. It is stable and
>> works. Imediately after we start on the main branch with the
>> removal of the old code, and use the APR version.
>> 
>> That was the original plan anyway (AFAIK).
>> 
> 
> Two things:
> 
> 1. vhosts doesn't behave very well right now (we are solving that) on
> all platforms
> 2. BUG 12346 (sockets)
> 3. Release

That's 3 things :-)

For (1) - it works for me :-) ( using  ), and I did at
least once tested it with the 'normal' mapper, so it can't be 
very far. If you give me more context info on what's broken -
I can try help with the fix.

I'll look at 12346.

Costin



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

Re: mod_jk 1.2.0 release proposal

[Costin Manolache]

Henri Gomez wrote:

>>> - Tag JTC as mod_jk 1.2.0 and prepare tarball,
>>>   which will contains only :
>>>
>>>   jk/native
>>>   jk/docs   (generated from xdocs and without jk2 parts)
> 
> Do you agree to remove jk2 docs from jk release ?
> Just to avoid confusion...

+1 

We should add the first tag to jk2 and release at least a beta src tarball
when 4.1 is released, but jk1.2 will be release quality and is a different
story.


-- 
Costin



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

RE: [POLL] aprize jk2

[Mladen Turk]

 
> For (1) - it works for me :-) ( using  ), and I did 
> at least once tested it with the 'normal' mapper, so it can't be 
> very far. If you give me more context info on what's broken -
> I can try help with the fix.
> 

It's pretty close to finish, hopefully later this day.

> I'll look at 12346.
> 

Yet better solve it :).

MT.


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

Re: jk doc

[Costin Manolache]

I'm impressed. 

I think I should consider taking more vacation ! :-)

I'll review it and send comments ( or commit ) if I find 
anything.



Henri Gomez wrote:

> The JK doc is allready available for comments and revue at :
> 
> 
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/doc/
> 
> 
> Remember release will be next week.

-- 
Costin



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

Re: Problem with Tomcat 3.3.2-dev and classloader for JMX

[Costin Manolache]

Bill Barker wrote:

> 
> - Original Message -
> From: "Henri Gomez" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, September 19, 2002 4:25 AM
> Subject: Problem with Tomcat 3.3.2-dev and classloader for JMX
> 
> 
>> I've got a problem in loading MX4J and it's http adaptator.
>>
>> I initially put mx4j and mx4j-tools in lib/container,
>> next to crimson and xalan but at init time the ClassLoader
>> didn't find mx4j/mx4j-tools there.
>>
>> When I moved mx4j and mx4j-tools to lib/common, both are
>> found but http connector couldn't be loaded since it need
>> crimson and xalan which are in lib/container.
>>
>> How could I update MxInterceptor to make use of lib/container
>> CL and sus being able to put mx4j jars in lib/container ???
>>
> 
> What needs to happen is to split the j-t-c tomcat-util.jar into two jars
> (one for common and one for container/server).  I haven't had the time to
> inventory what is there and decide what should go in which jar.
> 
> Putting mx4j in common opens a major problem, since you make every webapp
> "trusted" that way.  It's clear that o.a.t.u.mx needs to go in container.
> It's the rest I'm not sure of.

Not sure I agree ( completely ).

In theory, jmx is a 'system' API, and we can expect it to be in 
common. J2EE has it, catalina has it, etc. So we need to make sure
it's security works and it is safe.

I agree - it is much 'safer' to keep in in container/. But there
are many cases where this is not possible.

For my tests - I put mx4j and mx4j-tools in commons, I never got 
it to work with them in container ( the current version of mx4j may 
work - it had some classloaders problems or I didn't use it the 
right way ).


Costin



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

-- 
Costin



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

DO NOT REPLY [Bug 12917] New: - The request dumper valve Error

[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=12917

The request dumper valve Error

   Summary: The request dumper valve Error
   Product: Tomcat 4
   Version: 4.1.10
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I Send java object (vectors) from applet to servlet. When I have enabled the 
request dumper my servlet fails to work. I have java.io.EOFException in servlet 
code line 2 at in.readObject();
When I disable log entry (in server.xml) it works fine.

Appletc Code:

URLConnection con = new URL(s).openConnection();   
con.setDoInput(true);
con.setDoOutput(true);
con.setUseCaches(false);
con.setDefaultUseCaches(false);
ObjectOutputStream os = new ObjectOutputStream(con.getOutputStream());
os.writeObject();
os.flush();
os.close();
ObjectInputStream is = new ObjectInputStream(con.getInputStream());
Object o = is.readObject();
is.close();

Servlet Code:
1: ObjectInputStream in = new ObjectInputStream
(httpServletRequest.getInputStream());
2: Object obj = in.readObject();
3: in.close();

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

DO NOT REPLY [Bug 12346] - Constant Refreshes crash "Framed" Web Applications in TOMCAT

[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=12346

Constant Refreshes crash "Framed"  Web Applications in TOMCAT





--- Additional Comments From [EMAIL PROTECTED]  2002-09-23 11:35 ---
I've seen this before - most likely related to socket reuse or
protocol ( ajp13 ) framing errors. I'll try to reproduce it ( need to
find a win machine first ). Does it happens on unix as well ? ( it should, the
ajp code is identical )

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

DO NOT REPLY [Bug 12918] New: - Status code missing with mod_webapp

[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=12918

Status code missing with mod_webapp

   Summary: Status code missing with mod_webapp
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Webapp
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is the output of a request through Apache 2.0.40+mod_webapp:

[root@kay /]# telnet webtest 80
Trying 53.212.1.210...
Connected to webtest.unix.debis.it.
Escape character is '^]'.
GET /examples/ HTTP/1.0

HTTP/1.1 OK
Date: Mon, 23 Sep 2002 09:13:18 GMT
Server: Apache/2.0.40 (Unix) DAV/2 mod_webapp/1.2.0-dev
Content-Type: text/html;charset=UTF-8
Content-Length: 1286
Connection: close

And the following is what I receive connecting directly to Tomcat:

[root@kay /]# telnet webtest 8080
Trying 53.212.1.210...
Connected to webtest.unix.debis.it.
Escape character is '^]'.
GET /examples/ HTTP/1.0

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Connection: close
Date: Mon, 23 Sep 2002 10:09:31 GMT
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)


In the first case, the status code, 200, is missing from response.
While the code is 200 this is not a problem, but when it becomes, say, 302, the 
browser cannot follow the redirection.
The same page is correctly served with Apache 1.3.26

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

Re: [POLL] aprize jk2

[Henri Gomez]

> +1 on using apr/apr-util - but I would preffer doing so for jk2.1.
> 
> Let's tag/branch the workspace as jk2.0, with the current code ( as beta 
> level ), at the moment 4.1 is released. It is stable and works.
> Imediately after we start on the main branch with the removal of the
> old code, and use the APR version.

+1 to put apr/apr-util in jk 2.1



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

Re: Problem with Tomcat 3.3.2-dev and classloader for JMX

[Henri Gomez]

> Not sure I agree ( completely ).
> 
> In theory, jmx is a 'system' API, and we can expect it to be in 
> common. J2EE has it, catalina has it, etc. So we need to make sure
> it's security works and it is safe.
> 
> I agree - it is much 'safer' to keep in in container/. But there
> are many cases where this is not possible.
> 
> For my tests - I put mx4j and mx4j-tools in commons, I never got 
> it to work with them in container ( the current version of mx4j may 
> work - it had some classloaders problems or I didn't use it the 
> right way ).

Hi Costin, hope you enjoy your vacations ;)

Ok, I does the same, ie put mx4j and mx4j-tools in common but
I've got a problem when trying to use mx4j http adaptor which
require TRAX (ie xalan). And we couldn't use any xalan jar here
since apps could want to use their own xalan isn't it ?

I send a dummy example, where the jtc code for MDynamicBean
was duplicated and moved in modules/config, ie next to MxInterceptor
and sus allowing us to have mx4j/mx4j-tools in container (next to 
bundled xalan).




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

Re: [POLL] aprize jk2

[Remy Maucherat]

Costin Manolache wrote:
> Mladen Turk wrote:
> 
> 
>>Hi, glad to see you rised from the death :)
> 
> 
> Unfortunately - it's back from vacation.

Welcome back anyway :)

> Besides
> getting in the right timezone, I have to get re-adjusted with
> using a computer and reading mail... 

That sucks ;-)

>>>Let's tag/branch the workspace as jk2.0, with the current
>>>code ( as beta
>>>level ), at the moment 4.1 is released. It is stable and
>>>works. Imediately after we start on the main branch with the
>>>removal of the old code, and use the APR version.
>>>
>>>That was the original plan anyway (AFAIK).
>>>
>>
>>Two things:
>>
>>1. vhosts doesn't behave very well right now (we are solving that) on
>>all platforms
>>2. BUG 12346 (sockets)
>>3. Release
> 
> 
> That's 3 things :-)
> 
> For (1) - it works for me :-) ( using  ), and I did at
> least once tested it with the 'normal' mapper, so it can't be 
> very far. If you give me more context info on what's broken -
> I can try help with the fix.
> 
> I'll look at 12346.

If confirmed, that would be a bug we would like to fix ASAP. 
Unfortunately, the next release (4.1.12) can't wait, so it'll have to be 
in 4.1.13.

Remy


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

BUG? ClassLoader doesn't find files in WEB-INF/classes

[Torsten Fohrer]

Hello,

we have some configuration files that lies directly under WEB-INF/classes
per ClassLoader.getResource.

It works fine with Tomcat 4.0.4, but doesn't find it in 4.1.10/1.

i.A. Torsten Fohrer

**
* DCSI AG* Tel.: +49 7131 155 88-0   *
* Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
* D-74076 Heilbronn  * [EMAIL PROTECTED]*
* GERMANY* http://www.dcsi.de*
** 

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

Re: Problem with Tomcat 3.3.2-dev and classloader for JMX

[Costin Manolache]

Henri Gomez wrote:

>> Not sure I agree ( completely ).
>> 
>> In theory, jmx is a 'system' API, and we can expect it to be in
>> common. J2EE has it, catalina has it, etc. So we need to make sure
>> it's security works and it is safe.
>> 
>> I agree - it is much 'safer' to keep in in container/. But there
>> are many cases where this is not possible.
>> 
>> For my tests - I put mx4j and mx4j-tools in commons, I never got
>> it to work with them in container ( the current version of mx4j may
>> work - it had some classloaders problems or I didn't use it the
>> right way ).
> 
> Hi Costin, hope you enjoy your vacations ;)
> 
> Ok, I does the same, ie put mx4j and mx4j-tools in common but
> I've got a problem when trying to use mx4j http adaptor which
> require TRAX (ie xalan). And we couldn't use any xalan jar here
> since apps could want to use their own xalan isn't it ?

With JDK1.4 - this is not possible anyway ( unless reverse loader
is used to load org.apache.xalan classes ). 

Just put xalan in common, it won't be worse :-) ( or use 1.4 )

The alternative is to put mx4j-tools in container and make sure
the right class loader is used ( i.e. explicitely pass the loader 
when constructing the mbean - I think it is possible ).
But I wouldn't waste time with that.


> I send a dummy example, where the jtc code for MDynamicBean
> was duplicated and moved in modules/config, ie next to MxInterceptor
> and sus allowing us to have mx4j/mx4j-tools in container (next to
> bundled xalan).

-- 
Costin



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

Re: Problem with Tomcat 3.3.2-dev and classloader for JMX

[Henri Gomez]

> With JDK1.4 - this is not possible anyway ( unless reverse loader
> is used to load org.apache.xalan classes ). 

Interesting point here, will it be possible when using jdk 1.4
to use a specific xalan at least for webapp ?

> Just put xalan in common, it won't be worse :-) ( or use 1.4 )

So we'll have to put xalan/xerces in commons ?

May be time to upgrade the build to xerces-j 2.1.0, xalan 2.4.0
and xml-commons 1.0 ?


> The alternative is to put mx4j-tools in container and make sure
> the right class loader is used ( i.e. explicitely pass the loader 
> when constructing the mbean - I think it is possible ).
> But I wouldn't waste time with that.

Ok, so you suggest to put jaxp + mx4j + mx4jtools in commons
and warn users that their apps will have to use the commons JAXP,
MX4J and MX4JTOOLS (since a webapp may also use mx4j for it's
own purposes ?)




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

removing old jtc/jk/docs

[Henri Gomez]

I'd like to remove the old jtc/jk/docs now that the xml based
is available.

Do you agree ?


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

Re: removing old jtc/jk/docs

[Glenn Nielsen]

Henri Gomez wrote:
> I'd like to remove the old jtc/jk/docs now that the xml based
> is available.
> 
> Do you agree ?
> 

+1, that can prevent someone like me from updating old outdated docs ;-)


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

Re: Problem with Tomcat 3.3.2-dev and classloader for JMX

[Costin Manolache]

Henri Gomez wrote:

>> With JDK1.4 - this is not possible anyway ( unless reverse loader
>> is used to load org.apache.xalan classes ).
> 
> Interesting point here, will it be possible when using jdk 1.4
> to use a specific xalan at least for webapp ?

It is certainly possible to use a different xslt ( saxon, etc ) - using
the normal jaxp discovery.

It should be possible to use a different version of xalan - if a 
non-delegating class loader is used ( since org.apache.xalan is in 
rt.jar ).

>> Just put xalan in common, it won't be worse :-) ( or use 1.4 )
> 
> So we'll have to put xalan/xerces in commons ?

It's easier.


> May be time to upgrade the build to xerces-j 2.1.0, xalan 2.4.0
> and xml-commons 1.0 ?

One important note: if JDK1.4 is used, there is a whole issue with 
'endorsed' system property. Cut&paste from catalina.sh is the best
solution, however I had some problems loading jni code from java
( with jdk1.4, if the endorsed property was set). Very strange, I
just worked around - but we may need to revisit.


>> The alternative is to put mx4j-tools in container and make sure
>> the right class loader is used ( i.e. explicitely pass the loader
>> when constructing the mbean - I think it is possible ).
>> But I wouldn't waste time with that.
> 
> Ok, so you suggest to put jaxp + mx4j + mx4jtools in commons
> and warn users that their apps will have to use the commons JAXP,
> MX4J and MX4JTOOLS (since a webapp may also use mx4j for it's
> own purposes ?)

If you just want to play with mx interceptor - that may be the
best ( at least short-term ) solution.

Right now there isn't very much support - we need to add more 
interesting info ( i.e. getters for status and config, etc - in 
various interceptors ).

What I'm interested most is the jk-level components.

I'll send some proposals this week - I have some ideas here. As soon
as 4.1 is released I'll start some discussions on the new coyote hooks
and the new 'notes', I have some interesting ideas.


-- 
Costin



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

Using a tomcat 4.0 connector with tomcat 4.1

[h . buerger]

Hi,

i have a connector working with tomcat 4.0 and want to use it with
tomcat 4.1. First problem was that the lifecycle interface had changed.
I could fix that in a way i can deploy on 4.0 and 4.1.

But i still crash with an exception:
java.lang.Exception: ManagedBean is not found with MyXyConnector
at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:225)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:359)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:716)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:690)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:329)
at
org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2184)
at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

I'm no JMX guru, what must i do to get rid of it?

Thanks
 Haug





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

[POLL] Tomcat 3.3.2 updates

[Henri Gomez]

Hi to all,

If you tracked the discussion about MxInterceptor and it's
use in Tomcat 3.3.2-dev you should know that we have some
modification to Tomcat 3.3.2 jars layout to be able to
use MxInterceptor :

1) mx4j and mx4j-tools should goes in lib/common

2) mx4j-tools HTTP adaptor require TRAX (xalan),
so we should put in common/lib JAXP+XML PARSER+TRANSFORMER,
and as such could use :

xerces-j2 2.1.0
xalan-j2 2.4.0
xml-commons-apis 1.0

Since these jars will be in lib/common, users won't be able
to use another one for it's own apps.

3) We'll have to remove JAXP/XML-PARSER for lib/container.


Thanks to give your opinion here.

[ ] 1. Don't care about MBeans, or do want to be able to have
different XML apis for apps and container, so keep the
current situation.

[ ] 2. MxInterceptor is really needed, ok to change the layout,
we'll warn users in Changelog / Readme

[ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to
have a copy of DynamicMBeanProxy from jtc/util located in
a location compatible with container/lib (to be in
container_util.jar we could copy it in org.apache.tomcat.util.mx)

[ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't
want to make the copy and could provide some code to avoid that.


Personally, I'd like solution 4 (but don't know how to), so I'll be 
pragmatic and retains 3.





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

[VOTE] [4.0.5] [4.1.12] Security releases

[Remy Maucherat]

A security vulnerability which affects all releases of Tomcat 4.x has 
been discovered.

It is proposed that new Tomcat 4.0.x and 4.1.x releases are made, at 
which time the exploit will be publicized. The security advisory will 
also include an easy workaround to protect existing Tomcat 
installations, so upgrading is not a necessity.

Tomcat 4.0.5 release


Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
- a bugfix to URL parsing
- the security fix


+1 [ ] Yes, I approve this release
-1 [ ] No, because:



Tomcat 4.1.12 Stable release


Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its 
release. Tomcat 4.1.11, on which the release is based, has recieved 
positive feedback so far. The list of changes is available in the 
release notes.
It is proposed that it recieves a Stable rating. The existing 4.1.10 
release will be retired.


+1 [ ] Yes, I approve this release
-1 [ ] No, because:



The proposed binaries for 4.0.5 and 4.1.12 are available at:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/

4.0.5 was packaged on my new computer (which I have been using for all 
the 4.1.x releases), and may contain unwanted changes over 4.0.4. Please 
let me know if there are problems.

Remy


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

Re: mod_jk 1.2.0 release proposal

[Bojan Smojver]

On Mon, 2002-09-23 at 20:04, Henri Gomez wrote:
> Bojan Smojver wrote:
> > Sounds good (although I have to admit I haven't compiled mod_jk from CVS
> > for a while).
> 
> Just take a look, cvs should be tagged tomorrow  ;)

I'll try...

Bojan


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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Henri Gomez]

> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
> - a bugfix to URL parsing
> - the security fix
> 
> 
> +1 [+1] Yes, I approve this release
> -1 [ ] No, because:
> 
> 

Which JTC should be used ?

> 
> Tomcat 4.1.12 Stable release
> 
> 
> Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its 
> release. Tomcat 4.1.11, on which the release is based, has recieved 
> positive feedback so far. The list of changes is available in the 
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10 
> release will be retired.
> 
> 
> +1 [+1] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> The proposed binaries for 4.0.5 and 4.1.12 are available at:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/
> 
> 4.0.5 was packaged on my new computer (which I have been using for all 
> the 4.1.x releases), and may contain unwanted changes over 4.0.4. Please 
> let me know if there are problems.


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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Glenn Nielsen]

Remy Maucherat wrote:
> A security vulnerability which affects all releases of Tomcat 4.x has 
> been discovered.
> 
> It is proposed that new Tomcat 4.0.x and 4.1.x releases are made, at 
> which time the exploit will be publicized. The security advisory will 
> also include an easy workaround to protect existing Tomcat 
> installations, so upgrading is not a necessity.
> 
> Tomcat 4.0.5 release
> 
> 
> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
> - a bugfix to URL parsing
> - the security fix
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> Tomcat 4.1.12 Stable release
> 
> 
> Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its 
> release. Tomcat 4.1.11, on which the release is based, has recieved 
> positive feedback so far. The list of changes is available in the 
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10 
> release will be retired.
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> The proposed binaries for 4.0.5 and 4.1.12 are available at:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/
> 
> 4.0.5 was packaged on my new computer (which I have been using for all 
> the 4.1.x releases), and may contain unwanted changes over 4.0.4. Please 
> let me know if there are problems.
> 
> Remy
> 
> 
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 




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

cvs commit: jakarta-tomcat-connectors/jk/xdocs index.xml

[hgomez]

hgomez  2002/09/23 07:59:39

  Modified:jk/xdocs index.xml
  Log:
  APR is Apache Portable Runtime, not Library (reported by Anthony Milbourne)
  
  Revision  ChangesPath
  1.10  +2 -2  jakarta-tomcat-connectors/jk/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/index.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- index.xml 20 Sep 2002 21:35:31 -  1.9
  +++ index.xml 23 Sep 2002 14:59:39 -  1.10
  @@ -108,7 +108,7 @@
   JK2 ;-))
   
   
  -The disadvantage is that it requires the Apache Portable Library
  +The disadvantage is that it requires the Apache Portable Runtime
   which is still only easily available via Apache 2.0 and that it didn't support
   webservers like IIS, NES/iPlanet or Domino.
   
  
  
  

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

Tomcat startup is slow

[Chenthil Kumaran I]

Hi,

I am using tomcat 4.0.4 it seems to be slower compared to
tomcat
3.3.x.  Is there any way i can speedup the tomcat initialization.
(I
have already costomised server.xml to my need)

I have one more doubt is there a way by which i can
confirm the
status of the of tomcat server.  ie, wether the startup is
complete or
inprogress.

Thanks in advance.

ick




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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Jean-Francois Arcand]

Remy Maucherat wrote:

> A security vulnerability which affects all releases of Tomcat 4.x has 
> been discovered.
>
> It is proposed that new Tomcat 4.0.x and 4.1.x releases are made, at 
> which time the exploit will be publicized. The security advisory will 
> also include an easy workaround to protect existing Tomcat 
> installations, so upgrading is not a necessity.
>
> Tomcat 4.0.5 release
> 
>
> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
> - a bugfix to URL parsing
> - the security fix
>
> 
> +1 [X ] Yes, I approve this release
> -1 [ ] No, because:
>
> 
>
> Tomcat 4.1.12 Stable release
> 
>
> Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its 
> release. Tomcat 4.1.11, on which the release is based, has recieved 
> positive feedback so far. The list of changes is available in the 
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10 
> release will be retired.
>
> 
> +1 [X ] Yes, I approve this release
> -1 [ ] No, because:
>
> 
>
> The proposed binaries for 4.0.5 and 4.1.12 are available at:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/
>
> 4.0.5 was packaged on my new computer (which I have been using for all 
> the 4.1.x releases), and may contain unwanted changes over 4.0.4. 
> Please let me know if there are problems.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
>


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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Remy Maucherat]

Henri Gomez wrote:
>> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
>> - a bugfix to URL parsing
>> - the security fix
>>
>> 
>> +1 [+1] Yes, I approve this release
>> -1 [ ] No, because:
>>
>> 
> 
> 
> Which JTC should be used ?

I bundled the latest JTC binaries for Coyote HTTP/1.1, and for AJP 1.3 
(although it has been fairly stable lately, and shouldn't introduce many 
changes over 4.0.4).

JK 2 is not included.

Remy


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

Re: BUG? ClassLoader doesn't find files in WEB-INF/classes

[Jun Inamori]

Hi,

> we have some configuration files that lies directly
> under WEB-INF/classes
> per ClassLoader.getResource.

Please try:
  ClassLoader cl=Thread.currentThread().getContextClassLoader();
  InputStream is=cl.getResourceAsStream("some.txt");

Happy Java programming!
---
Jun Inamori
OOP-Reserch
E-mail: [EMAIL PROTECTED]
URL:http://www.oop-reserch.com/

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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Patrick Luby]

Remy,

Here's my votes.

Patrick

Tomcat 4.0.5 release



+1 [X] Yes, I approve this release
-1 [ ] No, because:


Tomcat 4.1.12 Stable release



+1 [X] Yes, I approve this release
-1 [ ] No, because:



-- 

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: [VOTE] [4.0.5] [4.1.12] Security releases

[Henri Gomez]

Remy Maucherat wrote:
> Henri Gomez wrote:
> 
>>> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
>>> - a bugfix to URL parsing
>>> - the security fix
>>>
>>> 
>>> +1 [+1] Yes, I approve this release
>>> -1 [ ] No, because:
>>>
>>> 
>>
>>
>>
>> Which JTC should be used ?
> 
> 
> I bundled the latest JTC binaries for Coyote HTTP/1.1, and for AJP 1.3 
> (although it has been fairly stable lately, and shouldn't introduce many 
> changes over 4.0.4).

Ok, but you should also include the JTC source tarball isn't it ?



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

DO NOT REPLY [Bug 12926] New: - java.net.URLEncoder.encode problem with JDK 1.4.1

[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=12926

java.net.URLEncoder.encode problem with JDK 1.4.1

   Summary: java.net.URLEncoder.encode problem with JDK 1.4.1
   Product: Tomcat 4
   Version: 4.1.10
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I use tomcat 4.1.10 on Linux with the new JDK 1.4.1
I get org.apache.jasper.JasperException: Unable to compile class for JSP
for a JSP that does a  with a . The problem is that
javac doesn't find java.net.URLEncoder.encode for constructing the forwarding
URL. Since this method is marked as deprecated in the 1.4 Javadocs I assume that
it is no longer available in JDK 1.4.1. Is there a workaround I can use? You
might have already fixed that in a developemnt version of tomcat 4.1, but I
would like to use the stable release 4.1.10 if possible.

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

Re: [POLL] Tomcat 3.3.2 updates

[Costin Manolache]

Henri Gomez wrote:

> Hi to all,
> 
> If you tracked the discussion about MxInterceptor and it's
> use in Tomcat 3.3.2-dev you should know that we have some
> modification to Tomcat 3.3.2 jars layout to be able to
> use MxInterceptor :
> 
> 1) mx4j and mx4j-tools should goes in lib/common
> 
> 2) mx4j-tools HTTP adaptor require TRAX (xalan),
> so we should put in common/lib JAXP+XML PARSER+TRANSFORMER,
> and as such could use :
> 
> xerces-j2 2.1.0
> xalan-j2 2.4.0
> xml-commons-apis 1.0
> 
> Since these jars will be in lib/common, users won't be able
> to use another one for it's own apps.
> 
> 3) We'll have to remove JAXP/XML-PARSER for lib/container.
> 
> 
> Thanks to give your opinion here.
> 
> [+0] 1. Don't care about MBeans, or do want to be able to have
> different XML apis for apps and container, so keep the
> current situation.

I care about MBeans, but we can keep the current situation as 
stable and copy xerces, xalan, etc in common/ for mx experiments.

 
> [ ] 2. MxInterceptor is really needed, ok to change the layout,
> we'll warn users in Changelog / Readme

It is needed - for experiments and to enahance the module. Right
now it's not very usefull without ability to save and with the
limited visibility ( i.e. very few info is available ).

As we implement the proposed JNDI/JMX config ( for 5.0 - but will work
with any tomcat in the same way ) - MxInterceptor will become essential
( for 3.x ). However when we implement the new coyote hooks, if all goes
as planned ( and Interceptor/Valve will be particular cases of the new
hooks ) then MxInteceptor will not be needed.
 
> [ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to
> have a copy of DynamicMBeanProxy from jtc/util located in
> a location compatible with container/lib (to be in
> container_util.jar we could copy it in org.apache.tomcat.util.mx)

That's possible - but given 5.0 I think it would be waste of time. 



> [ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't
> want to make the copy and could provide some code to avoid that.

+1

Costin 

> 
> 
> Personally, I'd like solution 4 (but don't know how to), so I'll be
> pragmatic and retains 3.

-- 
Costin



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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Amy Roh]

> Tomcat 4.0.5 release
> 
> 
> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
> - a bugfix to URL parsing
> - the security fix
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> Tomcat 4.1.12 Stable release
> 
> 
> Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its 
> release. Tomcat 4.1.11, on which the release is based, has recieved 
> positive feedback so far. The list of changes is available in the 
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10 
> release will be retired.
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 

Amy




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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Costin Manolache]

Remy Maucherat wrote:

> A security vulnerability which affects all releases of Tomcat 4.x has
> been discovered.
> 
> It is proposed that new Tomcat 4.0.x and 4.1.x releases are made, at
> which time the exploit will be publicized. The security advisory will
> also include an easy workaround to protect existing Tomcat
> installations, so upgrading is not a necessity.
> 
> Tomcat 4.0.5 release
> 
> 
> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
> - a bugfix to URL parsing
> - the security fix
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> Tomcat 4.1.12 Stable release
> 
> 
> Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its
> release. Tomcat 4.1.11, on which the release is based, has recieved
> positive feedback so far. The list of changes is available in the
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10
> release will be retired.
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> The proposed binaries for 4.0.5 and 4.1.12 are available at:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/
> 
> 4.0.5 was packaged on my new computer (which I have been using for all
> the 4.1.x releases), and may contain unwanted changes over 4.0.4. Please
> let me know if there are problems.
> 
> Remy

-- 
Costin



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

Re: Tomcat startup is slow

[Costin Manolache]

Chenthil Kumaran I wrote:

> Hi,
> 
> I am using tomcat 4.0.4 it seems to be slower compared to
> tomcat
> 3.3.x.  Is there any way i can speedup the tomcat initialization.
> (I
> have already costomised server.xml to my need)
> 
> I have one more doubt is there a way by which i can
> confirm the
> status of the of tomcat server.  ie, wether the startup is
> complete or
> inprogress.

4.1 will be faster, 5.0 will be as fast as 3.3

Costin

> 
> Thanks in advance.
> 
> ick

-- 
Costin



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

Re: Using a tomcat 4.0 connector with tomcat 4.1

[Amy Roh]

You can either add a mbean description for your connector similar to 
other Connectors in o.a.c.mbeans.mbeans-descriptors.xml or disable the 
two JMX supporting Listeners (ServerLifecycleListener and 
GlobalResourcesLifecycleListener)in server.xml if you don't want the JMX 
support.  I'd recommend adding something like this in 
mbeans-descriptors.xml so tomcat starts smoothly without complaining 
mbean not found for your connector.

   

   

Amy

[EMAIL PROTECTED] wrote:
> Hi,
> 
> i have a connector working with tomcat 4.0 and want to use it with
> tomcat 4.1. First problem was that the lifecycle interface had changed.
> I could fix that in a way i can deploy on 4.0 and 4.1.
> 
> But i still crash with an exception:
> java.lang.Exception: ManagedBean is not found with MyXyConnector
> at
> org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:225)
> at
> 
>org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:359)
> at
> 
>org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:716)
> at
> 
>org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:690)
> at
> 
>org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:329)
> at
> 
>org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
> at
> 
>org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:2184)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
> 
> I'm no JMX guru, what must i do to get rid of it?
> 
> Thanks
>  Haug
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 





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

Re: problems compiling tomcat-connectors w/ make

[Jon Monroe]

Hello all,

I'm still having problems compiling this without having to fix the 
configure/configure.in files?? I updated my stuff on my 7.0 box. It didn't 
help. I then copied my source over to my more modern RH 7.3 box. Using a 
very basic configuration test:

RH 7.3, totally stock, including:
libtool 1.4.2-7
automake-1.4p5-4
autoconf-2.13-17
apache_1.3.26 src
jakarta-tomcat-connectors-4.1.10-src.tar.gz
ibm jsdk 2.13

I'm running
cd /usr/src/jakarta/jakarta-tomcat-connectors-4.1.10-src/jk/native2

sh ./buildconf.sh
../configure --with-apache13=/usr/src/apache/apache_1.3.26


It's still building that weirdo configure from the supplied configure.in. 
It's checking for file existence of the directory name ( -f) , and 
declaring variables with slashes and periods in the name? :))

Again, the first error message I get is:

configure: error: can't locate /usr/src/apache/apache_1.3.26/

Incidentally, I tried the native (not native2) and it works fine.

Thanks,
Jon
Jon Monroe
Systems Administrator
ImageBuilder Software
(503) 684-5151
(503) 639-6334 FAX


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

AW: [POLL] Tomcat 3.3.2 updates

[Hans Schmid]

Hi,

since our application uses TopLink, we can not upgrade to xerces 2.
There are hardcoded xerces 1 classes used directly from TopLink.

So 2) is a showstopper for all people with 3rd party jars requiring xerces 1

MBeans are useful for us, but not required. We are already using mx4j and
mx4j-tools in our webapp together with xerces 1.4.0 and xalan 2.1.0

My preference would be. Leave it as it is, but give a short
readme hat to copy where to be abe to use MxInterceptor


Thanks,
Hans

> -Ursprungliche Nachricht-
> Von: Henri Gomez [mailto:[EMAIL PROTECTED]]
> Gesendet: Montag, 23. September 2002 16:02
> An: [EMAIL PROTECTED]
> Betreff: [POLL] Tomcat 3.3.2 updates
>
>
> Hi to all,
>
> If you tracked the discussion about MxInterceptor and it's
> use in Tomcat 3.3.2-dev you should know that we have some
> modification to Tomcat 3.3.2 jars layout to be able to
> use MxInterceptor :
>
> 1) mx4j and mx4j-tools should goes in lib/common
>
> 2) mx4j-tools HTTP adaptor require TRAX (xalan),
> so we should put in common/lib JAXP+XML PARSER+TRANSFORMER,
> and as such could use :
>
> xerces-j2 2.1.0
> xalan-j2 2.4.0
> xml-commons-apis 1.0
>
> Since these jars will be in lib/common, users won't be able
> to use another one for it's own apps.
>
> 3) We'll have to remove JAXP/XML-PARSER for lib/container.
>
>
> Thanks to give your opinion here.
>
> [ ] 1. Don't care about MBeans, or do want to be able to have
> different XML apis for apps and container, so keep the
> current situation.
>
> [ ] 2. MxInterceptor is really needed, ok to change the layout,
> we'll warn users in Changelog / Readme
>
> [ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to
> have a copy of DynamicMBeanProxy from jtc/util located in
> a location compatible with container/lib (to be in
> container_util.jar we could copy it in org.apache.tomcat.util.mx)
>
> [ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't
> want to make the copy and could provide some code to avoid that.
>
>
> Personally, I'd like solution 4 (but don't know how to), so I'll be
> pragmatic and retains 3.
>
>
>
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 



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

Re: Tomcat startup is slow

[Eddie Bush]

Sweet - can't wait to see 5!  Good luck, guys - wish I had the expertise 
to help!

Costin Manolache wrote:

>Chenthil Kumaran I wrote:
>
>>Hi,
>>
>>I am using tomcat 4.0.4 it seems to be slower compared to
>>tomcat
>>3.3.x.  Is there any way i can speedup the tomcat initialization.
>>(I
>>have already costomised server.xml to my need)
>>
>>I have one more doubt is there a way by which i can
>>confirm the
>>status of the of tomcat server.  ie, wether the startup is
>>complete or
>>inprogress.
>>
>4.1 will be faster, 5.0 will be as fast as 3.3
>
>Costin
>
>>Thanks in advance.
>>
>>ick
>>

-- 
Eddie Bush




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

DO NOT REPLY [Bug 11552] - Iteration tags do not resynchronize scripting variables after doAfterBody()

[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=11552

Iteration tags do not resynchronize scripting variables after doAfterBody()





--- Additional Comments From [EMAIL PROTECTED]  2002-09-23 17:35 ---
As of Tomcat 4.1.11, AT_BEGIN and NESTED scripting variables are
synchronized after doStart(), unless their tag handler implements
BodyTag, in which case they are synchronized after doInitBody().

In addition, if the tag handler implements IterationTag, AT_BEGIN and
NESTED variables are synchronized after doAfterBody().

In addition, AT_BEGIN and AT_END variables are always synchronized
after doEnd().

This fixes your problem.

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

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_uriMap.h

[mturk]

mturk   2002/09/23 10:36:25

  Modified:jk/native2/include jk_uriMap.h
  Log:
  Remove the defaultVhost, and add the port to the uriMap call.
  
  Revision  ChangesPath
  1.16  +1 -1  jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h
  
  Index: jk_uriMap.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jk_uriMap.h   15 Aug 2002 11:21:47 -  1.15
  +++ jk_uriMap.h   23 Sep 2002 17:36:25 -  1.16
  @@ -109,7 +109,6 @@
* level.
*/
   struct jk_map *vhosts;
  -struct jk_uriEnv *defaultVhost;
   
   /* -- Methods -- */
   
  @@ -142,6 +141,7 @@
   
   struct jk_uriEnv *(*mapUri)(struct jk_env *env, jk_uriMap_t *_this,
   const char *vhost,
  +int port,
   const char *uri);
   
   /*  @deprecated  */
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_uriEnv.h

[mturk]

mturk   2002/09/23 10:36:50

  Modified:jk/native2/include jk_uriEnv.h
  Log:
  Add the port to the uriEnv
  
  Revision  ChangesPath
  1.17  +7 -5  jakarta-tomcat-connectors/jk/native2/include/jk_uriEnv.h
  
  Index: jk_uriEnv.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriEnv.h,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- jk_uriEnv.h   15 Aug 2002 09:21:50 -  1.16
  +++ jk_uriEnv.h   23 Sep 2002 17:36:50 -  1.17
  @@ -128,11 +128,16 @@
   /** Full name */
   char *name;
   
  -/* Virtual server handled - NULL means 'global' ( visible in all
  +/* Virtual server handled - '*' means 'global' ( visible in all
* virtual servers ). Part of the uri name.
*/
   char *virtual;
   
  +/* Virtual server port - '0' means 'all' ( visible in all
  + * ports on the virtual servers ). Part of the uri name.
  + */
  +int port;
  +
   /* Original uri ( unparsed ). Part of the uri name.
*/
   char *uri;
  @@ -193,6 +198,7 @@
   If NULL - no config was attached.
   ( this will be used in future for run-time deployment )
*/
  +
   struct jk_config *config;
   
   /*  Other properties  */
  @@ -209,10 +215,6 @@
   
   int merged;
   
  -/* Reverse mappings
  - */
  -int reverse;
  -
   /** XXX .
*/
   /* int status; */
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c

[mturk]

mturk   2002/09/23 10:38:04

  Modified:jk/native2/common jk_uriMap.c
  Log:
  Rewrite the uriMap using hostname:port scheme.
  The default host is now named *.
  
  Revision  ChangesPath
  1.41  +219 -351  jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- jk_uriMap.c   22 Sep 2002 09:58:16 -  1.40
  +++ jk_uriMap.c   23 Sep 2002 17:38:04 -  1.41
  @@ -77,10 +77,6 @@
   
   static INLINE const char *jk2_findExtension(jk_env_t *env, const char *uri);
   
  -static jk_uriEnv_t *jk2_uriMap_mapUri(jk_env_t *env, jk_uriMap_t *uriMap,
  -  const char *vhost,
  -  const char *uri);
  -
   static int jk2_uriMap_checkUri(jk_env_t *env, jk_uriMap_t *uriMap, 
  const char *uri);
   
  @@ -140,46 +136,44 @@
   uri in the table ( XXX use a map keyed on name ). In init() we process this
   and set the right structures.
*/
  -static int jk2_uriMap_addUriEnv( jk_env_t *env, jk_uriMap_t *uriMap, jk_uriEnv_t 
*uriEnv )
  +static int jk2_uriMap_addUriEnv(jk_env_t *env, jk_uriMap_t *uriMap,
  +jk_uriEnv_t *uriEnv)
   {
  -uriMap->maps->put( env, uriMap->maps, uriEnv->name, uriEnv, NULL );
  -if( uriMap->mbean->debug > 0 ) 
  +uriMap->maps->put(env, uriMap->maps, uriEnv->name, uriEnv, NULL);
  +if (uriMap->mbean->debug > 0) 
   env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  -  "uriMap.addUriEnv() %s %s %s\n", uriEnv->name, 
uriEnv->virtual, uriEnv->uri);
  +  "uriMap.addUriEnv() %s %s %s\n", uriEnv->name,
  +  uriEnv->virtual, uriEnv->uri);
   return JK_OK;
   }
   
   static int JK_METHOD jk2_uriMap_setProperty(jk_env_t *env, jk_bean_t *mbean,
  -  char *name, void *valueP)
  +char *name, void *valueP)
   {
  -jk_uriMap_t *uriMap=mbean->object;
  -char *value=valueP;
  +jk_uriMap_t *uriMap = mbean->object;
  +char *value = valueP;
   
   return JK_OK;
   }
   
   static jk_uriEnv_t *jk2_uriMap_prefixMap(jk_env_t *env, jk_uriMap_t *uriMap,
jk_map_t *mapTable, const char *uri, 
  - int uriLen, int reverse)
  + int uriLen)
   {
  -int best_match=0;
  -jk_uriEnv_t *match=NULL;
  +int best_match = 0;
  +jk_uriEnv_t *match = NULL;
   int i;
   
  -int sz=mapTable->size( env, mapTable);
  -for(i = 0 ; i < sz ; i++) {
  -jk_uriEnv_t *uwr=mapTable->valueAt( env, mapTable, i);
  -
  -if( uriLen < uwr->prefix_len ) continue;
  -if( strncmp( uri, uwr->prefix, uwr->prefix_len ) == 0 ) {
  -if( uwr->prefix_len > best_match ) {
  +int sz = mapTable->size(env, mapTable);
  +for (i = 0; i < sz; i++) {
  +jk_uriEnv_t *uwr = mapTable->valueAt(env, mapTable, i);
  +
  +if (uriLen < uwr->prefix_len)
  +continue;
  +if (strncmp(uri, uwr->prefix, uwr->prefix_len) == 0) {
  +if (uwr->prefix_len >best_match) {
   best_match=uwr->prefix_len;
  -if (reverse > 0) {
  -if (uwr->reverse)
  -match=uwr;
  -}
  -else if (!uwr->reverse)
  -match=uwr;
  +match=uwr;
   }
   }
   }
  @@ -188,21 +182,19 @@
   
   static jk_uriEnv_t *jk2_uriMap_exactMap(jk_env_t *env, jk_uriMap_t *uriMap,
   jk_map_t *mapTable, const char *uri, 
  -int uriLen, int reverse)
  +int uriLen)
   {
   int i;
  -int sz=mapTable->size( env, mapTable);
  -for(i = 0 ; i < sz ; i++) {
  -jk_uriEnv_t *uwr=mapTable->valueAt( env, mapTable, i);
  +int sz = mapTable->size(env, mapTable);
  +jk_uriEnv_t *match=NULL;
  +
  +for (i = 0; i < sz; i++) {
  +jk_uriEnv_t *uwr = mapTable->valueAt( env, mapTable, i);
   
  -if( uriLen != uwr->prefix_len ) continue;
  -if( strncmp( uri, uwr->prefix, uriLen ) == 0 ) {
  -if (reverse > 0) {
  -if (uwr->reverse)
  -return uwr;
  -}
  -else if (!uwr->reverse)
  -return uwr;
  +if (uriLen != uwr->prefix_len)
  +continue;
  +if (strncmp(uri, uwr->prefix, uriLen) == 0) {
  +return uwr;
   

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c

[mturk]

mturk   2002/09/23 10:39:24

  Modified:jk/native2/common jk_uriEnv.c
  Log:
  Rewrite the uriEnv using the apr_uri_t.
  
  Revision  ChangesPath
  1.27  +105 -83   jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
  
  Index: jk_uriEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- jk_uriEnv.c   22 Sep 2002 02:50:42 -  1.26
  +++ jk_uriEnv.c   23 Sep 2002 17:39:24 -  1.27
  @@ -69,6 +69,7 @@
   #include "jk_uriMap.h"
   #include "jk_registry.h"
   
  +#include "apr_uri.h"
   /** Parse the name:
  VHOST/PATH
   
  @@ -80,35 +81,41 @@
   static int jk2_uriEnv_parseName( jk_env_t *env, jk_uriEnv_t *uriEnv,
char *name)
   {
  -char *n=name;
  -char *slash=strchr( name, '/' );
  -
  -/* fprintf( stderr, "XXX parseURI %s\n", name ); */
  +
  +apr_uri_t uri;
  +char s[1024];
  +
  +/* If it uri starts with / then it is simple 
  + * default host uri
  + */
  +if (*name == '/')
  +strcpy(s, name);
  +else {
  +strcpy(s, "http://";);
  +strcat(s, name);
  +}
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  +  "uriEnv.parseName() uri %s name %s real %s\n", 
  +  uriEnv->name, name, s);
   
  -if( slash==NULL ) {
  -/* That's a virtual host definition ( no actual mapping, just global
  - * settings like aliases, etc
  - */
  -uriEnv->match_type= MATCH_TYPE_HOST;
  -if( name[0]=='\0' ) {
  -uriEnv->virtual=NULL; /* "" for the default host */
  -} else {
  -uriEnv->virtual=name;
  +if (apr_uri_parse(uriEnv->pool->_private, s, &uri) == APR_SUCCESS) {
  +
  +uriEnv->port = uri.port;
  +if (uri.hostname) {
  +if (!uriEnv->port)
  +uriEnv->virtual = uri.hostname;
  +else
  +uriEnv->virtual = apr_pstrcat(uriEnv->pool->_private,
  +uri.hostname, ":", uri.port_str, NULL);
   }
  +else
  +uriEnv->virtual = "*";
  +uriEnv->uri = uri.path;
  +if (!uri.path)
  +uriEnv->match_type = MATCH_TYPE_HOST;
   return JK_OK;
   }
  -
  -/* If it doesn't start with /, it must have a vhost */
  -if( *name != '/' ) {
  -uriEnv->virtual=uriEnv->pool->calloc( env, uriEnv->pool, slash - name + 2 );
  -strncpy( uriEnv->virtual, name, slash-name );
  -}
  -
  -n=slash;
  -
  -uriEnv->uri=uriEnv->pool->pstrdup(env, uriEnv->pool, n);
  -
  -return JK_OK;
  +return JK_ERR;
   }
   
   static void * JK_METHOD jk2_uriEnv_getAttribute(jk_env_t *env, jk_bean_t *bean,
  @@ -134,59 +141,71 @@
   jk_uriEnv_t *uriEnv=mbean->object;
   char *valueParam=valueP;
   
  -char *name=uriEnv->pool->pstrdup(env,uriEnv->pool, nameParam);
  -char *val=uriEnv->pool->pstrdup(env,uriEnv->pool, valueParam);
  +char *name = uriEnv->pool->pstrdup(env,uriEnv->pool, nameParam);
  +char *val = uriEnv->pool->pstrdup(env,uriEnv->pool, valueParam);
   
  -uriEnv->properties->add( env ,uriEnv->properties,
  - name, val );
  +uriEnv->properties->add(env ,uriEnv->properties,
  +name, val);
   
  -if( strcmp("group", name) == 0 ) {
  -uriEnv->workerName=val;
  +if (strcmp("group", name) == 0) {
  +uriEnv->workerName = val;
   return JK_OK;
  -} else if( strcmp("context", name) == 0 ) {
  -
  +} 
  +else if (strcmp("context", name) == 0) {
   uriEnv->contextPath=val;
  -uriEnv->ctxt_len=strlen( val );
  +uriEnv->ctxt_len = strlen(val);
   
  -if( strcmp( val, uriEnv->uri ) == 0 ) {
  -uriEnv->match_type= MATCH_TYPE_CONTEXT;
  +if (strcmp(val, uriEnv->uri) == 0) {
  +uriEnv->match_type = MATCH_TYPE_CONTEXT;
   }
   return JK_OK;
  -} else if( strcmp("servlet", name) == 0 ) {
  +} 
  +else if (strcmp("servlet", name) == 0) {
   uriEnv->servlet=val;
  -} else if( strcmp("timing", name) == 0 ) {
  -uriEnv->timing=atoi( val );
  -} else if( strcmp("reverse", name) == 0 ) {
  -uriEnv->reverse=atoi( val );
  -} else if( strcmp("alias", name) == 0 ) {
  -if( uriEnv->match_type == MATCH_TYPE_HOST ) {
  -if( uriEnv->aliases==NULL ) {
  -jk2_map_default_create( env, &uriEnv->aliases, mbean->pool );
  +} 
  +else if (strcmp("timing", name) == 0) {
  +uriEnv->timing = atoi(val);
  +}
  +else if (strcmp("alias", name) == 0) {
  +if (uriEnv->match_type == MATCH_T

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

[mturk]

mturk   2002/09/23 10:40:17

  Modified:jk/native2/server/apache2 mod_jk2.c
  Log:
  Supply the hostname if not virtual and port if not default to the uriMap
  
  Revision  ChangesPath
  1.53  +10 -5 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- mod_jk2.c 22 Sep 2002 09:35:46 -  1.52
  +++ mod_jk2.c 23 Sep 2002 17:40:17 -  1.53
  @@ -629,7 +629,8 @@
   {
   jk_uriEnv_t *uriEnv;
   jk_env_t *env;
  -
  +int port;
  +
   if(r->proxyreq || workerEnv==NULL) {
   return DECLINED;
   }
  @@ -677,10 +678,14 @@
  If positive, we'll fill a ws_service_t and do the rewrite and
  the real mapping. 
   */
  -
  +
  +port = ap_get_server_port(r);
  +if (ap_is_default_port(port, r))
  +port = 0;
   uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,
  -r->server->is_virtual ? r->hostname : NULL,
  -r->uri );
  +r->server->is_virtual ? ap_get_server_name(r) : NULL,
  +port,
  +r->uri);
   
   if( uriEnv== NULL || uriEnv->workerName == NULL) {
   workerEnv->globalEnv->releaseEnv( workerEnv->globalEnv, env );
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 mod_jk2.c

[mturk]

mturk   2002/09/23 10:41:44

  Modified:jk/native2/server/apache13 mod_jk2.c
  Log:
  Supply the port to the uriMap call, This is TODO.
  
  Revision  ChangesPath
  1.20  +2 -2  jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- mod_jk2.c 12 Sep 2002 10:43:36 -  1.19
  +++ mod_jk2.c 23 Sep 2002 17:41:43 -  1.20
  @@ -438,7 +438,7 @@
   /* get_env() */
   env = workerEnv->globalEnv->getEnv( workerEnv->globalEnv );
   
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL, 0,r->uri );
   
   if(uriEnv==NULL || uriEnv->workerName==NULL) {
   workerEnv->globalEnv->releaseEnv( workerEnv->globalEnv, env );
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[mturk]

mturk   2002/09/23 10:42:38

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  Supply the port to the uriMap call, This is a TODO, just like for the Apache2.
  
  Revision  ChangesPath
  1.44  +3 -3  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.43
  retrieving revision 1.44
  diff -u -r1.43 -r1.44
  --- jk_isapi_plugin.c 21 Sep 2002 07:29:47 -  1.43
  +++ jk_isapi_plugin.c 23 Sep 2002 17:42:38 -  1.44
  @@ -334,14 +334,14 @@
   env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  "In HttpFilterProc Virtual Host redirection of %s\n", 
  Host);
  -uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,Host,uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,Host, 
0, uri );
   }
   
   if (uriEnv==NULL) {
   env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  "In HttpFilterProc test Default redirection of %s\n", 
  uri);
  -uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL, 
0, uri );
   }
   
   if( uriEnv!=NULL ) {
  
  
  

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

[5][PATCH]catalina/tester fix golden files for new request listener noise

[Steve Downey]

JSP includes now trigger request listeners with the attributes for dispatcher 
types and dispatcher request paths. This patch adds the output from the 
request listener to the golden files.



Index: JspInclude01a.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/web/golden/JspInclude01a.txt,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 JspInclude01a.txt
--- JspInclude01a.txt	18 Jul 2002 16:47:25 -	1.1.1.1
+++ JspInclude01a.txt	23 Sep 2002 17:36:30 -
@@ -1,6 +1,8 @@
 This is before the include
 Include00a PASSEDSessionListener01: sessionCreated()
 SessionListener02: sessionCreated()
+RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_TYPE,8)
+RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_REQUEST_PATH,/JspInclude01.jsp)
 
 This is after the include
 
Index: JspInclude02a.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/web/golden/JspInclude02a.txt,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 JspInclude02a.txt
--- JspInclude02a.txt	18 Jul 2002 16:47:25 -	1.1.1.1
+++ JspInclude02a.txt	23 Sep 2002 17:36:30 -
@@ -1,6 +1,8 @@
 This is before the include
 Include00a PASSEDSessionListener01: sessionCreated()
 SessionListener02: sessionCreated()
+RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_TYPE,8)
+RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_REQUEST_PATH,/JspInclude02.jsp)
 
 This is after the include
 



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

Re: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 23, 2002 3:57 AM
Subject: Re: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh


> Bill Barker wrote:
>
> >
> > - Original Message -
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, September 18, 2002 9:21 PM
> > Subject: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh
> >
> >
> >> billbarker2002/09/18 21:21:17
> >>
> >>   Modified:src/shell tomcat.bat tomcat.sh
> >>   Log:
> >>   Temporary stop-gap until I work out all of the ClassLoader issues.
> >>
> >
> > Ok, there are a couple of options here:
> > 1) Add a Class-Path to the Manifest (and make a comment in the release
> > notes for people using Java 1.1.x).
> >
> > 2) Revert o.a.t.u.compat.* and o.a.t.u.depend.* to using System.err
> > instead of c-l, since they are loaded in the System ClassLoader when
> > running from the scripts.
> >
> > 3) Re-implement the required methods from o.a.t.u.compat.* in
> > o.a.t.startup.Main so that we can leave o.a.t.u.depend.* and
> > o.a.t.u.compat.* out of the jar.
> >
> > My personal choices are in order, 3-1-2.  However 1 is the easiest, and
> > seems to be in the direction that the proposals are heading.
> >
> > Opinions (Larry/Costin)?
>
> I used to like a lot (1), however I've been bitten few times. I still
> think it is a good solution, but with a lot of care.
>
> (2) is very easy to implement, and can solve the problem.
>
> The big question is: do we want to keep the very small/minimal parent
> loader - with commons-logging-api in the container loader ?
>
> BTW, I'm not sure what was the original problem you are trying
> to solve. I have a lot of mail to sort through, I would apreciate
> some more context info :-)

I went ahead and converted most of j-t o.a.t.util.** to use commons-logging.
At the moment, since o.a.t.u.depend and o.a.t.u.compat are in the System
ClassLoader, then commons-logging needs to be there as well.



>
> --
> Costin
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

[JK2] new uriMap using hostname:port

[Mladen Turk]

Think I didn't miss something :)

Here is how it works:

All the mappings are done in the following way:

[:port]

Meaning '*' is used for the default host.

You can make now something like:

[uri:*:8080]
Info=will map the all the default servers on the port 8080 

Aliases should work now:

[uri:*]
alias=localhost
alias=www.apache.org

I have dropped the reverse attribute for now. Its too clumsy, and it
will be enabled if pcre is ever adopted.

IIS (work to some extend) and Apache 1.3 need some extra tuning :-)

Please do test.

MT.


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

[5][PATCH]catalina-tester assumes that ServletExceptions are NOT unwrapped

[Steve Downey]

Per Servlet 2.3, if a servlet throws a wrapped exception, the error handler 
that receives it gets the underlying root cause as the exception. That is, if 
ServletException(new TesterException()) is thrown, the exception in the 
request under attribute "javax.servlet.error.exception" will be 
TesterException, not ServletException.

The test in catalina/tester assumes that the root cause will still be wrapped 
in a ServletException.


With this patch, plus the others I've posted, the tomcat-5 passes all of the 
catalina tester tests. If anyone is interested, I can post a rolled up set of 
patches.




? conf
Index: tester/org/apache/tester/ErrorPage04.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/src/tester/org/apache/tester/ErrorPage04.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 ErrorPage04.java
--- tester/org/apache/tester/ErrorPage04.java	18 Jul 2002 16:47:26 -	1.1.1.1
+++ tester/org/apache/tester/ErrorPage04.java	23 Sep 2002 17:44:46 -
@@ -89,28 +89,19 @@
 value = request.getAttribute("javax.servlet.error.exception");
 if (value == null)
 sb.append(" exception is missing/");
-else if (!(value instanceof javax.servlet.ServletException)) {
+else if (!(value instanceof TesterException)) {
 sb.append(" exception class is ");
 sb.append(value.getClass().getName());
 sb.append("/");
 } else {
-exception = (ServletException) value;
-rootCause = exception.getRootCause();
-if (rootCause == null) {
-sb.append(" rootCause is missing/");
-} else if (!(rootCause instanceof TesterException)) {
-sb.append(" rootCause is ");
-sb.append(rootCause.getClass().getName());
-sb.append("/");
-} else {
-TesterException te = (TesterException) rootCause;
+TesterException te = (TesterException) value;
 if (!"ErrorPage03 Threw Exception".equals(te.getMessage())) {
 sb.append(" exception message is ");
 sb.append(te.getMessage());
 sb.append("/");
 }
 }
-}
+
 
 value = request.getAttribute("javax.servlet.error.exception_type");
 if (value == null)
@@ -121,7 +112,7 @@
 sb.append("/");
 } else {
 Class clazz = (Class) value;
-if (!"javax.servlet.ServletException".equals(clazz.getName())) {
+if (!"org.apache.tester.TesterException".equals(clazz.getName())) {
 sb.append(" exception_type class is ");
 sb.append(clazz.getName());
 sb.append("/");



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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, September 23, 2002 7:04 AM
Subject: [VOTE] [4.0.5] [4.1.12] Security releases


> A security vulnerability which affects all releases of Tomcat 4.x has
> been discovered.
>
> It is proposed that new Tomcat 4.0.x and 4.1.x releases are made, at
> which time the exploit will be publicized. The security advisory will
> also include an easy workaround to protect existing Tomcat
> installations, so upgrading is not a necessity.
>
> Tomcat 4.0.5 release
> 
>
> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
> - a bugfix to URL parsing
> - the security fix
>
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
>
> 
>
> Tomcat 4.1.12 Stable release
> 
>
> Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its
> release. Tomcat 4.1.11, on which the release is based, has recieved
> positive feedback so far. The list of changes is available in the
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10
> release will be retired.
>
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
>
> 
>
> The proposed binaries for 4.0.5 and 4.1.12 are available at:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/
>
> 4.0.5 was packaged on my new computer (which I have been using for all
> the 4.1.x releases), and may contain unwanted changes over 4.0.4. Please
> let me know if there are problems.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[mturk]

mturk   2002/09/23 11:30:40

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  Use the GetServerVariable for the SERVER_NAME and
  SERVER_PORT variables.
  
  Revision  ChangesPath
  1.45  +19 -14
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- jk_isapi_plugin.c 23 Sep 2002 17:42:38 -  1.44
  +++ jk_isapi_plugin.c 23 Sep 2002 18:30:40 -  1.45
  @@ -258,6 +258,7 @@
   char snuri[INTERNET_MAX_URL_LENGTH]="/";
   char Host[INTERNET_MAX_URL_LENGTH];
   char Translate[INTERNET_MAX_URL_LENGTH];
  +char Port[INTERNET_MAX_URL_LENGTH];
   BOOL (WINAPI * GetHeader) 
   (struct _HTTP_FILTER_CONTEXT * pfc, LPSTR lpszName, LPVOID 
lpvBuffer, LPDWORD lpdwSize );
   BOOL (WINAPI * SetHeader) 
  @@ -268,7 +269,7 @@
   DWORD sz = sizeof(uri);
   DWORD szHost = sizeof(Host);
   DWORD szTranslate = sizeof(Translate);
  -
  +DWORD szPort = sizeof(Port);
   #ifdef SF_NOTIFY_AUTH_COMPLETE
   if (auth_notification_flags == SF_NOTIFY_AUTH_COMPLETE) {
   
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)->GetHeader;
  @@ -329,20 +330,24 @@
   }
   jk_requtil_getParents(uri);
   
  -
  -if(GetHeader(pfc, "Host:", (LPVOID)Host, (LPDWORD)&szHost)) {
  -env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  -   "In HttpFilterProc Virtual Host redirection of %s\n", 
  -   Host);
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,Host, 
0, uri );
  +if (pfc->GetServerVariable(pfc, SERVER_NAME, (LPVOID)Host, 
(LPDWORD)&szHost)){
  +if (szHost > 0) {
  +Host[szHost-1] = '\0';
  +}
   }
  -
  -if (uriEnv==NULL) {
  -env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  -   "In HttpFilterProc test Default redirection of %s\n", 
  -   uri);
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL, 
0, uri );
  +Port[0] = '\0';
  +if (pfc->GetServerVariable(pfc, "SERVER_PORT", (LPVOID)Port, 
(LPDWORD)&szPort)){
  +if (szPort > 0) {
  +Port[szPort-1] = '\0';
  +}
   }
  +szPort = atoi(Port);
  +if (szPort == 80)
  +szPort = 0;
  +env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  +"In HttpFilterProc Virtual Host redirection of %s : 
%d\n", 
  +Host, Port);
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,Host, 0, 
uri );
   
   if( uriEnv!=NULL ) {
   char *forwardURI;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[mturk]

mturk   2002/09/23 11:34:56

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  Forgot the Port to the uriMap call, sorry wrong source directory.
  
  Revision  ChangesPath
  1.46  +2 -2  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.45
  retrieving revision 1.46
  diff -u -r1.45 -r1.46
  --- jk_isapi_plugin.c 23 Sep 2002 18:30:40 -  1.45
  +++ jk_isapi_plugin.c 23 Sep 2002 18:34:56 -  1.46
  @@ -347,7 +347,7 @@
   env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
   "In HttpFilterProc Virtual Host redirection of %s : 
%d\n", 
   Host, Port);
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,Host, 0, 
uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,Host, 
Port, uri );
   
   if( uriEnv!=NULL ) {
   char *forwardURI;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[mturk]

mturk   2002/09/23 11:36:38

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  It's not my day :-) Passing char * insted of int.
  
  Revision  ChangesPath
  1.47  +2 -2  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- jk_isapi_plugin.c 23 Sep 2002 18:34:56 -  1.46
  +++ jk_isapi_plugin.c 23 Sep 2002 18:36:38 -  1.47
  @@ -347,7 +347,7 @@
   env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
   "In HttpFilterProc Virtual Host redirection of %s : 
%d\n", 
   Host, Port);
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,Host, 
Port, uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,Host, 
szPort, uri );
   
   if( uriEnv!=NULL ) {
   char *forwardURI;
  
  
  

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

DO NOT REPLY [Bug 12931] New: - Catalina eats System.out.println()

[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=12931

Catalina eats System.out.println()

   Summary: Catalina eats System.out.println()
   Product: Tomcat 4
   Version: 4.1.10
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a servlet that is the first servlet to startup and all it does in its 
init method is System.out.println("in the init"); 

if I turn off all loggers the message never goes anywhere...

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

RE: [VOTE] [4.0.5] [4.1.12] Security releases

[Larry Isaacs]

> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, September 23, 2002 10:05 AM
> To: Tomcat Developers List
> Subject: [VOTE] [4.0.5] [4.1.12] Security releases
> 
> 
> A security vulnerability which affects all releases of Tomcat 4.x has 
> been discovered.
> 
> It is proposed that new Tomcat 4.0.x and 4.1.x releases are made, at 
> which time the exploit will be publicized. The security advisory will 
> also include an easy workaround to protect existing Tomcat 
> installations, so upgrading is not a necessity.
> 
> Tomcat 4.0.5 release
> 
> 
> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
> - a bugfix to URL parsing
> - the security fix
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> Tomcat 4.1.12 Stable release
> 
> 
> Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 
> since its 
> release. Tomcat 4.1.11, on which the release is based, has recieved 
> positive feedback so far. The list of changes is available in the 
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10 
> release will be retired.
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> The proposed binaries for 4.0.5 and 4.1.12 are available at:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/
> 
> 4.0.5 was packaged on my new computer (which I have been 
> using for all 
> the 4.1.x releases), and may contain unwanted changes over 
> 4.0.4. Please 
> let me know if there are problems.
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

RE: [POLL] Tomcat 3.3.2 updates

[Larry Isaacs]

Hi Henri,

I would prefer to minimize the impact of upgrading from
3.3.1 to 3.3.2.  I agree with Costin that using 4 with
documentation on the steps to enable the MxInterceptor
would be a resonable way to implement this.

Cheers,
Larry

> -Original Message-
> From: Henri Gomez [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, September 23, 2002 10:02 AM
> To: [EMAIL PROTECTED]
> Subject: [POLL] Tomcat 3.3.2 updates
> 
> 
> Hi to all,
> 
> If you tracked the discussion about MxInterceptor and it's
> use in Tomcat 3.3.2-dev you should know that we have some
> modification to Tomcat 3.3.2 jars layout to be able to
> use MxInterceptor :
> 
> 1) mx4j and mx4j-tools should goes in lib/common
> 
> 2) mx4j-tools HTTP adaptor require TRAX (xalan),
> so we should put in common/lib JAXP+XML PARSER+TRANSFORMER,
> and as such could use :
> 
> xerces-j2 2.1.0
> xalan-j2 2.4.0
> xml-commons-apis 1.0
> 
> Since these jars will be in lib/common, users won't be able
> to use another one for it's own apps.
> 
> 3) We'll have to remove JAXP/XML-PARSER for lib/container.
> 
> 
> Thanks to give your opinion here.
> 
> [ ] 1. Don't care about MBeans, or do want to be able to have
> different XML apis for apps and container, so keep the
> current situation.
> 
> [ ] 2. MxInterceptor is really needed, ok to change the layout,
> we'll warn users in Changelog / Readme
> 
> [ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to
> have a copy of DynamicMBeanProxy from jtc/util located in
> a location compatible with container/lib (to be in
> container_util.jar we could copy it in 
> org.apache.tomcat.util.mx)
> 
> [ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't
> want to make the copy and could provide some code to 
> avoid that.
> 
> 
> Personally, I'd like solution 4 (but don't know how to), so I'll be 
> pragmatic and retains 3.
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

cvs commit: jakarta-tomcat-5 gump.xml

[bobh]

bobh2002/09/23 12:33:08

  Modified:.gump.xml
  Log:
  - another step towards making gump builds available as nightly releases
  
  Revision  ChangesPath
  1.9   +1 -1  jakarta-tomcat-5/gump.xml
  
  Index: gump.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/gump.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- gump.xml  11 Sep 2002 21:09:52 -  1.8
  +++ gump.xml  23 Sep 2002 19:33:08 -  1.9
  @@ -10,7 +10,7 @@
 
   org.apache.catalina
   
  -
  +
 
 
 
  
  
  

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

DO NOT REPLY [Bug 12707] - Problems with Component class name in JSP

[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=12707

Problems with Component class name in JSP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2002-09-23 19:48 ---
This looks more like a problem with the underlying JDK (J2SE 1.4.1).

The attached program uses Introspector.getBeanInfo() to get the BeanInfo
associated with the class specified on the command line, and then enumerates the
PropertyDescriptor[] returned by BeanInfo.getPropertyDescriptors().

When I specify "test.Component" as the class to be introspected, I am getting
the following wrong result, which is identical to introspecting
"java.awt.Component":

  java Introspect test.Component
  class: test.Component
  pd.length: 7
  0:
  public java.awt.Color java.awt.Component.getBackground()
  class java.awt.Color
  1:
  public boolean java.awt.Component.isEnabled()
  boolean
  2:
  public boolean java.awt.Component.isFocusable()
  boolean
  3:
  public java.awt.Font java.awt.Component.getFont()
  class java.awt.Font
  4:
  public java.awt.Color java.awt.Component.getForeground()
  class java.awt.Color
  5:
  public java.lang.String java.awt.Component.getName()
  class java.lang.String
  6:
  public boolean java.awt.Component.isVisible()
  boolean

This would explain why you are getting this compile-time exception when
accessing test-error/test.jsp:

  org.apache.jasper.JasperException: Cannot find any information on property
'data' in a bean of type 'test.Component'

However, when i specify "test.component" (with a lower-case 'c') as
the class to be introspected, I get the expected result:

  java Introspect test.component
  class: test.component
  pd.length: 2
  0:
  public final native java.lang.Class java.lang.Object.getClass()
  class java.lang.Class
  1:
  public java.lang.String test.component.getData()
  class java.lang.String

which is why accessing test-work/test.jsp works just fine.

Still investigating ...

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

DO NOT REPLY [Bug 12707] - Problems with Component class name in JSP

[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=12707

Problems with Component class name in JSP





--- Additional Comments From [EMAIL PROTECTED]  2002-09-23 19:49 ---
Created an attachment (id=3181)
Introspection program

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

Re: [JK2] new uriMap using hostname:port

[Costin Manolache]

All that matter to me is to preserve the equivalence with 
'native' apache config.

In other words, 

[uri:HOST:PORT/URL]
properties

Must be equivalent with

 
ServerAlias ...


JkUriSet  



By this criteria, I would prefer use of '_default_' for the default 
server.

For the syntax of HOST, port, URL - just make sure it matches the 
documented semantics of apache VirtualHost and Location.  

Costin

Mladen Turk wrote:

> 
> Think I didn't miss something :)
> 
> Here is how it works:
> 
> All the mappings are done in the following way:
> 
> [:port]
> 
> Meaning '*' is used for the default host.
> 
> You can make now something like:
> 
> [uri:*:8080]
> Info=will map the all the default servers on the port 8080
> 
> Aliases should work now:
> 
> [uri:*]
> alias=localhost
> alias=www.apache.org
> 
> I have dropped the reverse attribute for now. Its too clumsy, and it
> will be enabled if pcre is ever adopted.
> 
> IIS (work to some extend) and Apache 1.3 need some extra tuning :-)
> 
> Please do test.
> 
> MT.

-- 
Costin



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

Re: [5][PATCH]catalina-tester assumes that ServletExceptions are NOT unwrapped

[micael]

That would be appreciated, John.

At 02:01 PM 9/23/2002 -0400, you wrote:
>Per Servlet 2.3, if a servlet throws a wrapped exception, the error handler
>that receives it gets the underlying root cause as the exception. That is, if
>ServletException(new TesterException()) is thrown, the exception in the
>request under attribute "javax.servlet.error.exception" will be
>TesterException, not ServletException.
>
>The test in catalina/tester assumes that the root cause will still be wrapped
>in a ServletException.
>
>
>With this patch, plus the others I've posted, the tomcat-5 passes all of the
>catalina tester tests. If anyone is interested, I can post a rolled up set of
>patches.
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 



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

Re: [5][PATCH]catalina-tester assumes that ServletExceptions are NOT unwrapped

[micael]

Er, I mean, Steve.

At 02:01 PM 9/23/2002 -0400, you wrote:
>Per Servlet 2.3, if a servlet throws a wrapped exception, the error handler
>that receives it gets the underlying root cause as the exception. That is, if
>ServletException(new TesterException()) is thrown, the exception in the
>request under attribute "javax.servlet.error.exception" will be
>TesterException, not ServletException.
>
>The test in catalina/tester assumes that the root cause will still be wrapped
>in a ServletException.
>
>
>With this patch, plus the others I've posted, the tomcat-5 passes all of the
>catalina tester tests. If anyone is interested, I can post a rolled up set of
>patches.
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 



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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Bojan Smojver]

On Tue, 2002-09-24 at 00:04, Remy Maucherat wrote:

> Tomcat 4.0.5 release
> 

> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> Tomcat 4.1.12 Stable release
> 
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 

Bojan


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

Re: [POLL] Tomcat 3.3.2 updates

[Bojan Smojver]

On Tue, 2002-09-24 at 00:01, Henri Gomez wrote:

> Thanks to give your opinion here.
> 
> [X] 1. Don't care about MBeans, or do want to be able to have
> different XML apis for apps and container, so keep the
> current situation.
> 
> [ ] 2. MxInterceptor is really needed, ok to change the layout,
> we'll warn users in Changelog / Readme
> 
> [ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to
> have a copy of DynamicMBeanProxy from jtc/util located in
> a location compatible with container/lib (to be in
> container_util.jar we could copy it in org.apache.tomcat.util.mx)
> 
> [ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't
> want to make the copy and could provide some code to avoid that.

However, as long as I can:

1. Disable it completely in server.xml
2. Remove unwanted XML parser JAR's manually

I'm OK with any, really.

Bojan


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

Re: [JK2] new uriMap using hostname:port

[Eugene Gluzberg]

Yikes! today's version no longer compiles without APR on 1.3:


   [so] Output:
[so] rm -f 
/home/eugene/tomcat/jakarta-tomcat-connectors/jk/build/jk2/apache13/common/.libs/jk_uriEnv.lo
[so] cc -c 
-I/home/eugene/tomcat/jakarta-tomcat-connectors/jk/native2/include 
-I/home/eugene/tomcat/jakarta-tomcat-connectors/jk/native2/common 
"-I\${build.compiler.base}/include" -I/usr/include -I/usr/include/apache 
-I/home/eugene/tomcat/jakarta-tomcat-connectors/jk/native2/include 
-I/usr/java/j2sdk1.4.1/jre/../include 
-I/usr/java/j2sdk1.4.1/jre/../include/linux -g -W -DEAPI -D_REENTRANT 
-DCHUNK_SIZE=4096 -DHAVE_MMAP 
/home/eugene/tomcat/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c 
 -fPIC -DPIC -o 
/home/eugene/tomcat/jakarta-tomcat-connectors/jk/build/jk2/apache13/common/.libs/jk_uriEnv.lo
[so] StdErr:
[so] 
/home/eugene/tomcat/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c:72:21: 
apr_uri.h: No such file or directory


Costin Manolache wrote:
> All that matter to me is to preserve the equivalence with 
> 'native' apache config.
> 
> In other words, 
> 
> [uri:HOST:PORT/URL]
> properties
> 
> Must be equivalent with
> 
>  
> ServerAlias ...
> 
> 
> JkUriSet  
> 
> 
> 
> By this criteria, I would prefer use of '_default_' for the default 
> server.
> 
> For the syntax of HOST, port, URL - just make sure it matches the 
> documented semantics of apache VirtualHost and Location.  
> 
> Costin
> 
> Mladen Turk wrote:
> 
> 
>>Think I didn't miss something :)
>>
>>Here is how it works:
>>
>>All the mappings are done in the following way:
>>
>>[:port]
>>
>>Meaning '*' is used for the default host.
>>
>>You can make now something like:
>>
>>[uri:*:8080]
>>Info=will map the all the default servers on the port 8080
>>
>>Aliases should work now:
>>
>>[uri:*]
>>alias=localhost
>>alias=www.apache.org
>>
>>I have dropped the reverse attribute for now. Its too clumsy, and it
>>will be enabled if pcre is ever adopted.
>>
>>IIS (work to some extend) and Apache 1.3 need some extra tuning :-)
>>
>>Please do test.
>>
>>MT.
> 
> 


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

JBoss 3.0 and Tomcat 4.1

[micael]

Is there any particular reason why I could not configure Tomcat 4.1 instead 
of 4.0 to the JBoss 3.0 j2ee server setup?

Micael

---

This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank you 



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

[PATCH] [JK2 docs] Minor patch to jk2 docs

[Eugene Gluzberg]

Just some additional installation info.


Index: jk/xdocs/jk2/configweb.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml,v
retrieving revision 1.6
diff -c -r1.6 configweb.xml
*** jk/xdocs/jk2/configweb.xml  20 Sep 2002 21:35:31 -  1.6
--- jk/xdocs/jk2/configweb.xml  23 Sep 2002 21:20:46 -
***
*** 100,105 
--- 100,115 
  Description
  
  
+ file
+ ${serverRoot}/conf/workers2.properties
+ Location of the workers2.properties file
+ 
+ 
+ debug
+ 0
+ Set the debug level of the config component
+ 
+ 
  debugEnv
  0
  Set the debug level of the hidden env component 
Index: jk/xdocs/jk2/installhowto.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/xdocs/jk2/installhowto.xml,v
retrieving revision 1.2
diff -c -r1.2 installhowto.xml
*** jk/xdocs/jk2/installhowto.xml   20 Sep 2002 21:35:31 -  1.2
--- jk/xdocs/jk2/installhowto.xml   23 Sep 2002 21:20:46 -
***
*** 3,8 
--- 3,9 
  
  Installation of mod_jk2 in the Web Server
  Jean-Frederic Clere
+ Eugene Gluzberg
  $Date: 2002/09/20 21:35:31 $
  

***
*** 14,19 
--- 15,34 
installation.
  
  
+   
+For this example, we are running on a standard RH 7.3 system Apache 1.3 rpm 
+installed.
+The commands are executed in the jakarta-tomcat-connectors directory.
+These instructions should also work with other RH 7.x systems..
+   
+   
+ Copy the dso files in the modules location:
+ cp jk/build/jk2/apache2/mod_jk2.so /etc/httpd/modules
+ Add mod_jk2 loading in the httpd.conf:
+ LoadModule jk2_module modules/mod_jk2.so
+ AddModule mod_jk2.c
+ Point mod_jk2 to your workers2.properties file inside 
+httpd.conf::
+ JkSet "config.file" "/etc/httpd/conf/workers2.properties"
+   
  

  In the following example Apache-2.0 is installed in



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

DO NOT REPLY [Bug 12657] - using name-from-attribute in tld causes NullPointerException

[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=12657

using name-from-attribute in tld causes NullPointerException





--- Additional Comments From [EMAIL PROTECTED]  2002-09-23 21:33 ---
I fail to reproduce this problem. I am attaching a sample webapp which defines a
single custom tag whose TLD entry specifies a scripting variable whose name is
determined by the value of the 'id' attribute. Can you run this and see if it
works for you? You may also want to attach your own webapp which uncovered this
problem.

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

Re: JSR45

[Kin-Man Chung]

JSR45 support is already in Tomcat 5, which is yet to be released.  You
can, however, build it from source and try it out yourself.


> Date: Wed, 18 Sep 2002 16:48:00 +0200
> From: Damian Frach <[EMAIL PROTECTED]>
> Subject: JSR45
> To: [EMAIL PROTECTED]
> 
> Hi,
> 
> I am a member of the web app group of  the Forte tools.
> 
> Our group is responsible for the Tomcat integration with the 
> Netbeans/Forte IDE.
> 
> We are now planning new features for the next Forte release. We have 
> plans for a JSR45 implementation.
> Can you give me information of your plans in this issue?
> 
> It will really help us.
> 
> Thanks, Damian.
> 
> -
> Damian Frach   
> 
> Software Engineer, Forte Tools   
> Software Platforms and Products   
> 
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
> Sun Microsystems Czech s.r.o.   
> Evropska 33E   
> 160 00 Prague 6 - Dejvice   
> Tel.:   +420 (2)   3300 - 9183
>   3300 - 9311
> Fax.:   +420 (2)   3300 - 9299   
> Mobile: +420 (604) 6277 - 20
> 
> Private:
> Tunelaru 328 Praha 5 - Zbraslav 15600
>  Tel:  +420 (2)   57924924
> Polni 10Stepankovice74728
>  Tel:  +420 (653) 6750 - 27
> -
> 
> 
> 
> 
> -- 
> -
> Damian Frach  
> 
> Software Engineer, Forte Tools
> Software Platforms and Products   
> 
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
> Sun Microsystems Czech s.r.o. 
> Evropska 33E  
> 160 00 Prague 6 - Dejvice 
> Tel.:   +420 (2)   3300 - 9183
>3300 - 9311
> Fax.:   +420 (2)   3300 - 9299
> Mobile: +420 (604) 6277 - 20
> 
> Private:
>  Tunelaru 328 Praha 5 - Zbraslav 15600
>   Tel:  +420 (2)   57924924
>  Polni 10Stepankovice74728
>   Tel:  +420 (653) 6750 - 27
> -
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


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

DO NOT REPLY [Bug 12657] - using name-from-attribute in tld causes NullPointerException

[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=12657

using name-from-attribute in tld causes NullPointerException





--- Additional Comments From [EMAIL PROTECTED]  2002-09-23 21:34 ---
Created an attachment (id=3186)
sample webapp

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

Re: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh

[Costin Manolache]

Bill Barker wrote:
 
> I went ahead and converted most of j-t o.a.t.util.** to use
> commons-logging. At the moment, since o.a.t.u.depend and o.a.t.u.compat
> are in the System ClassLoader, then commons-logging needs to be there as
> well.

+1

We shoud do it for j-t-c o.a.t.util as well, if not already done ( but
after 4.1 is out ).

IMPORNTANT: it's commons-logging-api.jar that should be in common loader !!
( I assume that's what you meant, just want to be sure everyone is aware of 
this issue ).

The -api.jar was created exactly to allow this kind of setup, with 
commons-logging in the parent loader and different child loaders using
different logging implementations. 


Costin



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

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c

[Costin Manolache]

As I mentioned, I prefer doing this _after_ jk2.0 ( i.e. the first 
milestone), possibly in a branch. 

Alternatively, you can use ifdefs - but please keep the old code 
at least for a while. When we decide to require apr, all the old
code can/should be removed - the pools, socket, etc. We keep it 
for a single reason - to support the possible cases when apr can't 
be used and build problems on those platforms. 

I'm -1 on making such a big change ( requiring apr/aprutil ) right
now, and not only because of compilation issues with apache1.3 - when 
we do it we should go all the way.

Costin

[EMAIL PROTECTED] wrote:

> mturk   2002/09/23 10:39:24
> 
>   Modified:jk/native2/common jk_uriEnv.c
>   Log:
>   Rewrite the uriEnv using the apr_uri_t.
>   
>   Revision  ChangesPath
>   1.27  +105 -83  
>   jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
>   
>   Index: jk_uriEnv.c
>   ===
>   RCS file:
>   /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
>   retrieving revision 1.26 retrieving revision 1.27
>   diff -u -r1.26 -r1.27
>   --- jk_uriEnv.c 22 Sep 2002 02:50:42 -  1.26
>   +++ jk_uriEnv.c 23 Sep 2002 17:39:24 -  1.27
>   @@ -69,6 +69,7 @@
>#include "jk_uriMap.h"
>#include "jk_registry.h"
>
>   +#include "apr_uri.h"
>/** Parse the name:
>   VHOST/PATH
>
>   @@ -80,35 +81,41 @@
>static int jk2_uriEnv_parseName( jk_env_t *env, jk_uriEnv_t *uriEnv,
> char *name)
>{
>   -char *n=name;
>   -char *slash=strchr( name, '/' );
>   -
>   -/* fprintf( stderr, "XXX parseURI %s\n", name ); */
>   +
>   +apr_uri_t uri;
>   +char s[1024];
>   +
>   +/* If it uri starts with / then it is simple
>   + * default host uri
>   + */
>   +if (*name == '/')
>   +strcpy(s, name);
>   +else {
>   +strcpy(s, "http://";);
>   +strcat(s, name);
>   +}
>   +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
>   +  "uriEnv.parseName() uri %s name %s real %s\n",
>   +  uriEnv->name, name, s);
>
>   -if( slash==NULL ) {
>   -/* That's a virtual host definition ( no actual mapping, just
>   global
>   - * settings like aliases, etc
>   - */
>   -uriEnv->match_type= MATCH_TYPE_HOST;
>   -if( name[0]=='\0' ) {
>   -uriEnv->virtual=NULL; /* "" for the default host */
>   -} else {
>   -uriEnv->virtual=name;
>   +if (apr_uri_parse(uriEnv->pool->_private, s, &uri) == APR_SUCCESS)
>   { +
>   +uriEnv->port = uri.port;
>   +if (uri.hostname) {
>   +if (!uriEnv->port)
>   +uriEnv->virtual = uri.hostname;
>   +else
>   +uriEnv->virtual = apr_pstrcat(uriEnv->pool->_private,
>   +uri.hostname, ":", uri.port_str,
>   NULL);
>}
>   +else
>   +uriEnv->virtual = "*";
>   +uriEnv->uri = uri.path;
>   +if (!uri.path)
>   +uriEnv->match_type = MATCH_TYPE_HOST;
>return JK_OK;
>}
>   -
>   -/* If it doesn't start with /, it must have a vhost */
>   -if( *name != '/' ) {
>   -uriEnv->virtual=uriEnv->pool->calloc( env, uriEnv->pool, slash
>   - name + 2 );
>   -strncpy( uriEnv->virtual, name, slash-name );
>   -}
>   -
>   -n=slash;
>   -
>   -uriEnv->uri=uriEnv->pool->pstrdup(env, uriEnv->pool, n);
>   -
>   -return JK_OK;
>   +return JK_ERR;
>}
>
>static void * JK_METHOD jk2_uriEnv_getAttribute(jk_env_t *env,
>jk_bean_t *bean,
>   @@ -134,59 +141,71 @@
>jk_uriEnv_t *uriEnv=mbean->object;
>char *valueParam=valueP;
>
>   -char *name=uriEnv->pool->pstrdup(env,uriEnv->pool, nameParam);
>   -char *val=uriEnv->pool->pstrdup(env,uriEnv->pool, valueParam);
>   +char *name = uriEnv->pool->pstrdup(env,uriEnv->pool, nameParam);
>   +char *val = uriEnv->pool->pstrdup(env,uriEnv->pool, valueParam);
>
>   -uriEnv->properties->add( env ,uriEnv->properties,
>   - name, val );
>   +uriEnv->properties->add(env ,uriEnv->properties,
>   +name, val);
>
>   -if( strcmp("group", name) == 0 ) {
>   -uriEnv->workerName=val;
>   +if (strcmp("group", name) == 0) {
>   +uriEnv->workerName = val;
>return JK_OK;
>   -} else if( strcmp("context", name) == 0 ) {
>   -
>   +}
>   +else if (strcmp("context", name) == 0) {
>uriEnv->contextPath=val;
>   -uriEnv->ctxt_len=strlen( val );
>   +uriEnv->ctxt_len = strlen(val);
>
>   -if( strcmp( val, uriEnv->uri ) == 0 ) {
>   -uriEnv->match_type= MATCH_TYPE_CONTEXT;
>   +if (strcmp(val, uriEnv->uri) == 0) {

Re: [JK2] new uriMap using hostname:port

[Dmitry Letin]

Does not work for me for some reason.

I have updated to latest version of CVS and recompiled mod_jk2.so for
apache2.
I looks that it does not load hosts at all.

Before I had this in my jk2 log file:

[Sat Sep 21 18:09:40 2002] (debug ) [jk_uriMap.c (371)]  uriMap.init()
loaded host www.i-com.com

Now I do not have it

In my workers2.properties among other stuff I have:


[uri:*]
alias=localhost
debug=10

[uri:www.i-com.com:80]
debug=10

[status:status]
debug=10

[uri:*/jkstatus/*]
worker=status:status
debug=10

[uri:www.i-com.com:80/*.jsp]
worker=ajp13:localhost:8013
debug=10



Neither of the mappings work, even jkstatus



Did you have i chance to look at the simple patch that I used:

http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/msg66936.html




List: tomcat-dev
Subject:  [JK2] new uriMap using hostname:port
From: "Mladen Turk" <[EMAIL PROTECTED]>
Date: 2002-09-23 17:53:50
[Download message RAW]


Think I didn't miss something :)

Here is how it works:

All the mappings are done in the following way:

[:port]

Meaning '*' is used for the default host.

You can make now something like:

[uri:*:8080]
Info=will map the all the default servers on the port 8080

Aliases should work now:

[uri:*]
alias=localhost
alias=www.apache.org

I have dropped the reverse attribute for now. Its too clumsy, and it
will be enabled if pcre is ever adopted.

IIS (work to some extend) and Apache 1.3 need some extra tuning :-)

Please do test.

MT.



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

cgi servlet

[Khan, Rabeeha]

Hi, 
I am trying to run a cgi script using Tomcat 4.0.4.  However, when I try to
call the servlet, I get an error, which I believe is related to the path of
the servlet.  I think this path is specified somewhere in the CGIServlet
file and am not quite sure how to fix it.   Any advice would be very
helpful.  Thanks.  
This is the error that I am getting (I believe the problem is the path
specified for the cgi.  I don't think it should be under bin.  Please advise
how to fix this):

java.io.IOException:
org.apache.catalina.servlets.CGIServlet$CGIRunnerIllegal Character in CGI
command path ('.' or '..') detected.  Not running CGI
[C:\jakarta-tomcat-4.0.4\bin\..\webapps\examples\WEB-INF\cgi\hello.cgi].
at
org.apache.catalina.servlets.CGIServlet$CGIRunner.run(CGIServlet.java:1533)
at
org.apache.catalina.servlets.CGIServlet.doGet(CGIServlet.java:635)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
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.ja
va:190)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:475)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
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:5
66)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
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:5
66)
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:
1027)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125
)
at java.lang.Thread.run(Thread.java:484)


--
This message is intended only for the personal and confidential use of the designated 
recipient(s) named above.  If you are not the intended recipient of this message you 
are hereby notified that any review, dissemination, distribution or copying of this 
message is strictly prohibited.  This communication is for information purposes only 
and should not be regarded as an offer to sell or as a solicitation of an offer to buy 
any financial product, an official confirmation of any transaction, or as an official 
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or 
error-free.  Therefore, we do not represent that this information is complete or 
accurate and it should not be relied upon as such.  All information is subject to 
change without notice.



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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c

[costin]

costin  2002/09/23 15:15:04

  Modified:jk/native2/common jk_uriEnv.c
  Log:
  Revert  ( actually  use ifdefs ) the change, so it compiles again in 1.3.
  
  Revision  ChangesPath
  1.28  +41 -0 jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
  
  Index: jk_uriEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- jk_uriEnv.c   23 Sep 2002 17:39:24 -  1.27
  +++ jk_uriEnv.c   23 Sep 2002 22:15:04 -  1.28
  @@ -69,7 +69,9 @@
   #include "jk_uriMap.h"
   #include "jk_registry.h"
   
  +#ifdef HAS_APR
   #include "apr_uri.h"
  +
   /** Parse the name:
  VHOST/PATH
   
  @@ -117,6 +119,45 @@
   }
   return JK_ERR;
   }
  +
  +#else
  +/* Old version, deprecated - used only if APR is not available
  + */
  +static int jk2_uriEnv_parseName( jk_env_t *env, jk_uriEnv_t *uriEnv,
  + char *name)
  +{
  +char *n=name;
  +char *slash=strchr( name, '/' );
  +
  +/* fprintf( stderr, "XXX parseURI %s\n", name ); */
  +
  +if( slash==NULL ) {
  +/* That's a virtual host definition ( no actual mapping, just global
  + * settings like aliases, etc
  + */
  +uriEnv->match_type= MATCH_TYPE_HOST;
  +if( name[0]=='\0' ) {
  +uriEnv->virtual=NULL; /* "" for the default host */
  +} else {
  +uriEnv->virtual=name;
  +}
  +return JK_OK;
  +}
  +
  +/* If it doesn't start with /, it must have a vhost */
  +if( *name != '/' ) {
  +uriEnv->virtual=uriEnv->pool->calloc( env, uriEnv->pool, slash - name + 2 );
  +strncpy( uriEnv->virtual, name, slash-name );
  +}
  +
  +n=slash;
  +
  +uriEnv->uri=uriEnv->pool->pstrdup(env, uriEnv->pool, n);
  +
  +return JK_OK;
  +}
  +
  +#endif
   
   static void * JK_METHOD jk2_uriEnv_getAttribute(jk_env_t *env, jk_bean_t *bean,
char *name )
  
  
  

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

Re: [VOTE] [4.0.5] [4.1.12] Security releases

[Denis Benoit]

On Mon, 23 Sep 2002, Remy Maucherat wrote:

> Tomcat 4.0.5 release
> 
> 
> Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of:
> - a bugfix to URL parsing
> - the security fix
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 
> 
> Tomcat 4.1.12 Stable release
> 
> 
> Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its 
> release. Tomcat 4.1.11, on which the release is based, has recieved 
> positive feedback so far. The list of changes is available in the 
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10 
> release will be retired.
> 
> 
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
> 
> 

-- 
Denis Benoit
[EMAIL PROTECTED]


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

DO NOT REPLY [Bug 12938] New: - servlets do not register PUT request

[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=12938

servlets do not register PUT request

   Summary: servlets do not register PUT request
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Create a servlet that implements doPut()

public void doPut(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/plain");
PrintWriter out = response.getWriter();
out.println("got PUT call");
}


Call it with a client that does a PUT:

public  static void main (String args[]) {
try {

//  URL url = new 
URL("http://localhost:8080/blah/servlets/PutServletTest";);
URL url = new 
URL("http://localhost:8080/blah/servlet/com.sri.chemsense.server.PutServletTest";);
HttpURLConnection conn = 
(HttpURLConnection)url.openConnection();
conn.setRequestMethod("PUT");
conn.setDoOutput(true);
conn.setDoInput(true);
// in real servlet, stuff the contents of a ZIP file down 
output stream
conn.getOutputStream().close();

// get input
InputStream stream = conn.getInputStream();
BufferedInputStream in = new BufferedInputStream(stream);
int i = 0;
while ((i = in.read()) != -1) {
System.out.write(i);
}
in.close();
} catch (Exception e) {
e.printStackTrace();
}
}


The PUT servlet will not initialize, nor will it return a response.  Now if that 
servlet also implements doGet, you can send a GET request, and the servlet will 
initialize, and only then a PUT request will succeed.

Setting
1
does not affect the PUT servlet's ability to receive that first request.

Tomcat 3.x does not show this problem, but I have tested on 4.0.3 and 4.0.4 and both 
show this problem.

The log file shows that the PUT was received, but doesn't seem to find a "registered" 
servlet.

127.0.0.1 - - [23/Sep/2002:15:45:00 -0800] "PUT /blah/servlet/PutServletTest HTTP/1.1" 
405 733

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspRuntimeContext.java

[glenn]

glenn   2002/09/23 16:53:06

  Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch JspRuntimeContext.java
  Log:
  Make sure the CodeSource for JSP pages is created consistently the same
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.2.3   +16 -14
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java
  
  Index: JspRuntimeContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java,v
  retrieving revision 1.4.2.2
  retrieving revision 1.4.2.3
  diff -u -r1.4.2.2 -r1.4.2.3
  --- JspRuntimeContext.java20 Sep 2002 23:04:12 -  1.4.2.2
  +++ JspRuntimeContext.java23 Sep 2002 23:53:05 -  1.4.2.3
  @@ -369,20 +369,21 @@
   if( policy != null ) {
   try {  
   // Get the permissions for the web app context
  -String contextDir = context.getRealPath("/");
  -if( contextDir == null ) {
  -contextDir = options.getScratchDir().toString();
  +String docBase = context.getRealPath("/");
  +if( docBase == null ) {
  +docBase = options.getScratchDir().toString();
   }
  -URL url = new URL("file:" + contextDir);
  +if (!docBase.endsWith(File.separator)){
  +docBase = docBase + File.separator;
  +}
  +File contextDir = new File(docBase);
  +URL url = contextDir.getCanonicalFile().toURL();
   codeSource = new CodeSource(url,null);
   permissionCollection = policy.getPermissions(codeSource);
   
   // Create a file read permission for web app context directory
  -if (contextDir.endsWith(File.separator)) {
  -contextDir = contextDir + "-";
  -} else {
  -contextDir = contextDir + File.separator + "-";
  -}
  +docBase = docBase + "-";
  +permissionCollection.add(new FilePermission(docBase,"read"));
   
   // Create a file read permission for web app tempdir (work) 
directory
   String workDir = options.getScratchDir().toString();
  @@ -425,7 +426,8 @@
   permissionCollection.add(
   new FilePermission(jndiUrl,"read") );
   }
  -} catch(MalformedURLException mfe) {
  +} catch(Exception e) {
  +context.log("Security Init for context failed",e);
   }
   }
   }
  
  
  

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticatorSSLAuthenticator.java

[Qingqing Ouyang]

Hi, Bill:

Sorry for getting back a bit late.  I was trying to track
down the exact spec for the claim I am about to make.  But
the JSSE contact person is not available today.

I took a look at the changes you made in the coyote connector,
it seems to me that the implementation there still does
not take into the consideration that the second handshake
is asynchronous.

Basically, the SSLSession.getPeerCertificateChain() will not
return anything valid until the handshake has gone through.
The JDK API doc for javax.net.ssl.SSLSocket startHandshake()
method states that it "is synchronous for the initial handshake".
I think I remembered reading somewhere that the second handshake,
which is what the connector is doing, is async.

In order to make sure the SSLSession.getPeerCertitificateChain()
returns the valid certificates, you will have to register a
javax.net.ssl.HandshakeCompletedListener, which should be responsible
in supplying the Request with the appropriate client certificates.
(I'll find out which spec actually states that and email it to you).

In any case, this also seems to be the behavior I am observing.
I downloaded your fix but the client cert authentication still
fails because SSLSession.getPeerCertificateChain() contains no
valid certificates.

Thoughts?

Thanx,
Q^2



Bill Barker wrote:
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, September 20, 2002 11:50 PM
> Subject: cvs commit:
> jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator
> SSLAuthenticator.java
> 
> 
> 
>>billbarker2002/09/20 23:50:30
>>
>>  Modified:catalina/src/share/org/apache/catalina/authenticator
>>SSLAuthenticator.java
>>  Log:
>>  Final level in replacing CertificatesValve under Coyote.
>>
>>  This is a little hackish, but is portable to 4.x without changing the
> 
> API.  Here, it should probably change once Coyote is properly exposed to
> Catalina.
> 
>>  If there aren't any major complaints, I'll port to the 4.1 branch later.
>>
> 
> 
> SSL authentication should be working now for TC 5.0/Coyote-standalone (at
> least for JSSE).  I've no doubt that there is a better implementation (since
> everyone knows that I'm very far from a Catalina expert :).  But that is why
> I've only committed the functional changes to the 5.0 branch.  Peer review
> is very much welcome.
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



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

DO NOT REPLY [Bug 12707] - Problems with Component class name in JSP

[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=12707

Problems with Component class name in JSP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-09-24 00:57 ---
This is a known problem that is scheduled to be fixed in J2SE 1.4.2.

This problem occurs only when introspecting a bean named "Component".

By default, the Introspector adds "sun.beans.infos" to the search path
for explicit BeanInfos. "sun.beans.infos" contains a single class:
"ComponentBeanInfo".

When introspecting a class, the Introspector checks to see if an
explicit BeanInfo for the class exists in the search path. If the
class being introspected is named "Component", the Introspector finds
a match: "sun.beans.infos.ComponentBeanInfo" in its search path and
uses it, even though "sun.beans.infos.ComponentBeanInfo" really is
intended as the BeanInfo for "java.awt.Component".

The existing bug reports on this problem mention 2 workarounds: 

- Set the BeanInfo search path to an empty array, as in:

Introspector.setBeanInfoSearchPath(new String[] { });

  This workaround would have to be implemented by Jasper.

- Tag library authors may implement their own explicit "ComponentBeanInfo"
  class and place it in the same package as their "Component" class.

Since this is a known problem in the underlying Java runtime that is
going to be fixed in the upcoming J2SE 1.4.2 release, and for which a
workaround exists that may be implemented by tag library authors, we
are not going to implement the workaround in Jasper.

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

[VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS

[Glenn Nielsen]

Tomcat SecurityManager XML Policy configuration
---

I have finished implementing support within Tomcat for using XML based security policy
files.  This was proposed and discussed on the list back 3-4 months ago.

I would like to commit this to the jakarta-tomcat-4.0 CVS HEAD and have it included in
future 4.1.x releases. Initially it could be listed as either experimental, alpha, or 
beta.
Whichever we decide.

- This new feature is fully backward compatible with current methods
   of using catalina.policy.  Use of the XML based policy is
   invoked by using the -security-xml startup option instead of -security.

- Catalina can be compiled without support for use of an XML policy.
   To build with support for an XML policy the Castor XML Schema
   jar file and the Jakarta ORO jar files must both be present.

   http://castor.exolab.org/
   http://jakarta.apache.org/oro/

Here is a URL to the updated Security Manager HOW-TO which documents
the new XML Policy features.

http://duke.more.net/~glenn/tomcat-docs/security-manager-howto.html#Optional%20XML%20Policy%20Configuration

Please review the above before voting.

If you are interested in looking at the code before I commit I could
create a patch file with all the changes against jakarta-tomcat-4.0
CVS HEAD and make it available. Just let me know.

Here is a ballot. I would prefer not creating a Tomcat 4.2 development
branch yet, that just adds more CVS branches to commit bug fixes to.


  [ ]  commit XML Policy source to jakarta-tomcat-4.0 HEAD
   and include it in future release of Tomcat 4.1.x
  [ ]  commit to CVS but don't add to the next release
  [ ]  create a Tomcat 4.2 development branch and commit there (Ugh!)
  [ ]  -1 Don't commit to CVS (Please explain why)


Thanks,

Glenn


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

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS

[Costin Manolache]

Glenn Nielsen wrote:

> Tomcat SecurityManager XML Policy configuration
> ---
> 
> I have finished implementing support within Tomcat for using XML based
> security policy
> files.  This was proposed and discussed on the list back 3-4 months ago.
> 
> I would like to commit this to the jakarta-tomcat-4.0 CVS HEAD and have it
> included in future 4.1.x releases. Initially it could be listed as either
> experimental, alpha, or beta. Whichever we decide.
> 
> - This new feature is fully backward compatible with current methods
>of using catalina.policy.  Use of the XML based policy is
>invoked by using the -security-xml startup option instead of -security.
> 
> - Catalina can be compiled without support for use of an XML policy.
>To build with support for an XML policy the Castor XML Schema
>jar file and the Jakarta ORO jar files must both be present.
> 
>http://castor.exolab.org/
>http://jakarta.apache.org/oro/
> 
> Here is a URL to the updated Security Manager HOW-TO which documents
> the new XML Policy features.
> 
> 
http://duke.more.net/~glenn/tomcat-docs/security-manager-howto.html#Optional%20XML%20Policy%20Configuration
> 
> Please review the above before voting.
> 
> If you are interested in looking at the code before I commit I could
> create a patch file with all the changes against jakarta-tomcat-4.0
> CVS HEAD and make it available. Just let me know.
> 
> Here is a ballot. I would prefer not creating a Tomcat 4.2 development
> branch yet, that just adds more CVS branches to commit bug fixes to.
> 
> 
>   [ ]  commit XML Policy source to jakarta-tomcat-4.0 HEAD
>and include it in future release of Tomcat 4.1.x
>   [ ]  commit to CVS but don't add to the next release
>   [ ]  create a Tomcat 4.2 development branch and commit there (Ugh!)
>   [ ]  -1 Don't commit to CVS (Please explain why)
> 

I'm -0 on adding yet another config file - WEB-INF/policy.xml is also
strange as webapps ( which shouldn't be trusted ) get to set the security
policy. This is very tricky - and will need a lot of review.

However I'm -1 on adding deps on castor and doing schema validations - at
least at this stage ( and after the experience we had with web.xml 
schemas ). Castor is very nice, but is also a big thing.

The current policy file is standard and likely to be understood by tools.
XML may be in theory easier, however I doubt too many tools understand
this particular DTD. So I prefer keeping the current file format as default,
at least until a standard security policy DTD is defined ( standard == 
we're not the only ones using it :-).

If you need this functionality - I would propose making it a separate 
module ( sort of add-on to tomcat ), instead of bundling it with tomcat
by default. 

Costin






> 
> Thanks,
> 
> Glenn

-- 
Costin



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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net JSSESupport.java

[billbarker]

billbarker2002/09/23 23:11:59

  Modified:util/java/org/apache/tomcat/util/net JSSESupport.java
  Log:
  Add missing try-catch block for first try at getting the client-cert.
  
  The first call was throwing out past the second call, so the re-negotiation never 
got a chance to happen.
  
  Also reduce logging for exceptions.
  
  Revision  ChangesPath
  1.5   +5 -3  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESupport.java
  
  Index: JSSESupport.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESupport.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- JSSESupport.java  21 Sep 2002 04:39:33 -  1.4
  +++ JSSESupport.java  24 Sep 2002 06:11:59 -  1.5
  @@ -115,7 +115,11 @@
   X509Certificate jsseCerts[] = null;
   java.security.cert.X509Certificate x509Certs[] = null;
   try {
  -jsseCerts = session.getPeerCertificateChain();
  + try {
  + jsseCerts = session.getPeerCertificateChain();
  + } catch(Exception bex) {
  + // ignore.
  + }
   if (jsseCerts == null)
   jsseCerts = new X509Certificate[0];
if(jsseCerts.length <= 0 && force) {
  @@ -138,8 +142,6 @@
   x509Certs[i] = (java.security.cert.X509Certificate)
 cf.generateCertificate(stream);
   }
  - } catch (IOException iex) {
  - throw iex;
} catch (Throwable t) {
return null;
   }
  
  
  

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

RE: [JK2] new uriMap using hostname:port

[Mladen Turk]

> -Original Message-
> From: Dmitry Letin [mailto:[EMAIL PROTECTED]] 

:-)
 
> 
> [uri:*]
> alias=localhost
> debug=10
> 
> [uri:www.i-com.com:80]
> debug=10
>

If the 80 is default server port then you have to ommit it
Simply use the 
[uri:www.i-com.com]


The port directive is used for non default ports only.

MT.


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