Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

[costinm]

On Mon, 22 Jul 2002, Craig R. McClanahan wrote:

> In Servlet 2.4 (Community Draft 2), it looks like the language in Section
> 9.10 that describes this hasn't changed.  The basic rule is that you
> combine the "partial URLs" specified in the welcome file list to the
> incoming request for a "directory" resource in the WAR -- and if "a
> resource in the WAR is mapped that request URI" then it's supposed to be
> served by the servlet corresponding to the complete request URI.

And that can't work - if index.jsp is specified as index, then 
*.jsp mapping will allways match.

Acording the the servlet spec there is no requirement for index.jsp
to be present ( it can be precompied ), and no way to ask a servlet
like JspServlet if a request will work without executing it. 

So the only correct implementation would be to execute service() - 
and if the result is a 404 then we should try the next match.

However there is no guarantee that the extension-mapped servlet
will return 404 - in many cases servlets are using the pathinfo
to do some actions ( like Struts ) and may return something
valid.


> Catalina interprets the requirement as meaning that there has to be a
> static resource that matches.  This has the side effect that you can't use
> a regular servlet mapping that doesn't correspond to a static resource --
> if you could, that would mean that a welcome file like "foo.jsp" would
> match every time, even if there wasn't such a page in the specified
> directory, because of the "*.jsp" mapping.

I know. And I think you can't use index.do or pre-compiled jsps 
( unless you also have the jsp source files - which in many cases is 
not desirable ). 

3.3 has a similar implementation - and I don't think either implements 
the spec corectly. 

> It would seem that a web connector should at least be able to emulate what
> Catalina does, by checking for the existence of a static file in the
> webapp directory.

+1


> I don't know how you could implement a generic servlet matching a "welcome
> file" path, unless we were to exclude extension mapping and default
> servlet from the definition of "matching".  And I'm not sure that even
> that would do the right thing in all circumstances.

It's the index.jsp that worries me - combined with precompile jsps.

That could be an extremely common case - and will fail with the 
current implementation.

And of course, I would be good to know if it is at least possible
to implement this - and if not to have it fixed in the spec.

My proposal was to consider all exact and prefix mappings ( that
would cover precompiled jsps and struts ), as well as static files. 


Costin


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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

[Bojan Smojver]

Quoting [EMAIL PROTECTED]:

> It's jk_translate who decides if a request is to be handled by
> jk ( by mapping it to a uriEnv ).
> 
> You can add a test for r->handler==DIR_MAGIC_TYPE, but don't assume
> any uriEnv is set.

Actually, r->handler is always NULL in jk_translate(). At least in mod_jk 1.2.0
(but I'm suspecting that would be the case in mod_jk2 as well, because it's
Apache that determines that). So, adding the test wouldn't do anything.

If DirectoryIndex is not used, by the time jk_handler() is reached with
DIR_MAGIC_TYPE, we're out of mod_dir. If DirectoryIndex is used, then we end up
in jk_handler() much sooner, by an explicit call from within mod_dir. That's, of
course, when a static file exists. In none of the cases is r->handler set while
in jk_translate().

So, for now, I think the only option is to rely on DIR_MAGIC_TYPE test in
jk_handler(). How's that going to work in mod_jk2, I have no idea... Hopefully,
Mark will do a few tests and then we'll know more.

Bojan

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

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

[Craig R. McClanahan]

On Sun, 21 Jul 2002 [EMAIL PROTECTED] wrote:

> On Mon, 22 Jul 2002, Bojan Smojver wrote:
>
> > > it can already map any URI. All it has to do is:
> > > - for each index:
> >
> > Just reading the algorithm and thinking about the implementation of it. Some of
>
> Well, don't take it as an algorithm - there are many other things to
> consider.
>
> > 
> >
> > The order of events would be:
> >
> > 1. mod_dir does a sub request for index.jsp
> > 2. jk_map_to_storage() receives the request
> > 3. jk_map_to_storage() engages map_uri_to_worker() <-- this would be new code
> > 4. map_uri_to_worker() finds nothing because it has no mapping to anything that
> > matches *.jsp
>
> That's actually a problem - map_uri_to_worker would find a match ( using
> *.jsp extension mapping ).
>
> That's very serious - need to check the servlet specs, maybe 2.4 has more
> details.
>

In Servlet 2.4 (Community Draft 2), it looks like the language in Section
9.10 that describes this hasn't changed.  The basic rule is that you
combine the "partial URLs" specified in the welcome file list to the
incoming request for a "directory" resource in the WAR -- and if "a
resource in the WAR is mapped that request URI" then it's supposed to be
served by the servlet corresponding to the complete request URI.

> I'm not sure how tomcat deals with that - we would find the extension
> mapping and find the JspServlet which is mapped to it. But there
> is no way to tell if this is a real match or not - without invoking
> JspServlet.
>

Catalina interprets the requirement as meaning that there has to be a
static resource that matches.  This has the side effect that you can't use
a regular servlet mapping that doesn't correspond to a static resource --
if you could, that would mean that a welcome file like "foo.jsp" would
match every time, even if there wasn't such a page in the specified
directory, because of the "*.jsp" mapping.

It would seem that a web connector should at least be able to emulate what
Catalina does, by checking for the existence of a static file in the
webapp directory.

> ( well, for JSPs we know that a file may be there, but what if the
> extension would be for something else ? )
>
> Craig, Remy - any ideas ?
>

I don't know how you could implement a generic servlet matching a "welcome
file" path, unless we were to exclude extension mapping and default
servlet from the definition of "matching".  And I'm not sure that even
that would do the right thing in all circumstances.

Craig


>
>
> > Now, the next step is rather tricky and is the key to the whole thing. Does
> > jk_map_to_storage():
> >
> > a) assume that there is index.jsp in one of the mappings that match the URI
> > minus the filename; jk_map_to_storage() could be very wrong about this - maybe
> > there is a default file there, but not index.jsp - this would then result in a
> > failed request
>
> If jk_map_to_storage finds an exact or prefix mapping - then the problem
> is solved, the request goes to tomcat.
>
> If it finds an extension mapping - I have no idea.
>
> If it doesn't find any mapping - then it's not a request for tomcat
> and you can look for static files ( or let mod_dir do it ).
>
>
>
> > Keep in mind that these are sub-requests that don't actually result in the file
> > being served. It's just mod_dir's  way of checking what would happen if there
> > was a file like that 'in the file system'. So, one cannot 'go back' and do all
> > this again, unless mod_dir is changed to do this kind of thing twice (which is
> > definitely a bad idea).
>
> No, you don't need to go back. For each attempted index you make a
> subrequest and you need to determine if tomcat could handle it.
>
> Assuming jk has knowledge about all the mappings in web.xml - you can
> do that ( again, I don't know how to deal with extension mappings ).
>
>
> > If my old kludge is applied (with the correct test this time) to jk_handler(),
> > things might be better. The kludge involved jk_handler() responding not just to
> > JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would
> > find the mapping (since the request is for a directory, not a file) and the
> > request would be served by Tomcat.
>
> I think this would work and is the best short-term solution.
>
> If it is a DIR, let tomcat serve it for now.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Any interest in a Poolman DataSource Factory class?

[Isaac Arias]

Hi,

I know that Tomcat is moving towards using the commons
db pool but there may be some people still using the
Poolman package to do connection pooling.

I created a PoolmanDataSourceFactory that can be
plugged into Tomcat 4.0.x and Tomcat 4.1.x to provide
Poolman managed pools through the Tomcat JNDI context.
This is a good way to transition projects into the
J2EE recommended JNDI/DataSource approach without
breaking old code that uses other Poolman APIs.

If there's any interest I'll be happy to send the file
over to whoever needs it.

Take care,

Ike

__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

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

Re: How to start the j_security_check servlet if using SSLAuthenticator

[Craig R. McClanahan]

On Tue, 23 Jul 2002, Andrew Grosser wrote:

> Date: Tue, 23 Jul 2002 04:39:09 +
> From: Andrew Grosser <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: How to start the j_security_check servlet if using
> SSLAuthenticator
>
>
> It should be possible to include this "magic" url in the SSLAuthenticator
> class too, no?
>

Are you planning to violate the servlet spec requirements for one and only
one authentication method (in the  element)?  If so, then,
of course you can do whatever you want to your own copy of
SSLAuthenticator -- but we can't do this to the standard one.

It's certainly not obvious to me what you're trying to accomplish with
supporting both.  The whole point of CLIENT-CERT authentication is to
avoid the need to challenge the user for their password -- the client
certificate is supposed to be sufficient proof of who they are.

Craig


> thanks
>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> >To: Tomcat Developers List <[EMAIL PROTECTED]>
> >CC: [EMAIL PROTECTED]
> >Subject: Re: How to start the j_security_check servlet if using
> >SSLAuthenticator
> >Date: Mon, 22 Jul 2002 21:25:30 -0700 (PDT)
> >MIME-Version: 1.0
> >Received: from [192.18.49.131] by hotmail.com (3.2) with ESMTP id
> >MHotMailBF062625008F400431D9C01231839BEF0; Mon, 22 Jul 2002 21:27:17 -0700
> >Received: (qmail 4771 invoked by uid 97); 23 Jul 2002 04:26:00 -
> >Received: (qmail 4759 invoked by uid 98); 23 Jul 2002 04:25:59 -
> >>From tomcat-dev-return-15135-dioptre Mon, 22 Jul 2002 21:27:35 -0700
> >Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> >Precedence: bulk
> >List-Unsubscribe: 
> >List-Subscribe: 
> >List-Help: 
> >List-Post: 
> >List-Id: "Tomcat Developers List" 
> >Delivered-To: mailing list [EMAIL PROTECTED]
> >X-Antivirus: nagoya (v4198 created Apr 24 2002)
> >In-Reply-To: <000801c231ff$96d41c60$0100a8c0@ga>
> >Message-ID: <[EMAIL PROTECTED]>
> >X-Spam-Rating: localhost 1.6.2 0/1000/N
> >X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> >
> >Right now, the choice between FORM and CLIENT-CERT is an either-or choice
> >in the servlet spec -- you cannot choose both on the same web application.
> >
> >The "j_security_check" URL is not actually mapped to a servlet -- it is a
> >"magic" URL that is only enabled (by FormAuthenticator) when the form
> >login page has been displayed.  None of the rest of Tomcat has a clue what
> >j_security_check is for.
> >
> >Craig
> >
> >
> >
> >On Tue, 23 Jul 2002, Andrew Grosser wrote:
> >
> > > Date: Tue, 23 Jul 2002 13:15:33 +0900
> > > From: Andrew Grosser <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: How to start the j_security_check servlet if using
> > > SSLAuthenticator
> > >
> > > Hello,
> > > I have been looking at extending the SSLAuthenticator class to accept
> > > Certificates AND Form type logins using a JDBC connector.
> > > This would have seemed relatively simple - but I have not been able to
> > > instantiate the j_security_check servlet for the SSLAuthenticator class
> > > (as it seems to only work for FormAuthenticator).
> > > I have not been able to find the reference for where j_security_check is
> > > called by the Context config/manager and how it recognizes whether the
> > > authentication used is of type FORM/CLIENT-CERT
> > >
> > > Perhaps it has something to do with the difference between
> > >
> > > ContextConfig[]: Configured an authenticator for method FORM
> > >
> > >  And
> > >
> > > ContextConfig[]: Configured an authenticator for method CLIENT-CERT
> > >
> > > But I cant seem to find it anywhere.
> > >
> > > Please help
> > >
> > > Cheers
> > >
> > >
> >
> >
> >--
> >To unsubscribe, e-mail:
> >
> >For additional commands, e-mail:
> >
> >
>
>
>
>
> _
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

[Bojan Smojver]

Quoting [EMAIL PROTECTED]:

> It's jk_translate who decides if a request is to be handled by
> jk ( by mapping it to a uriEnv ).
> 
> You can add a test for r->handler==DIR_MAGIC_TYPE, but don't assume
> any uriEnv is set.

OK, I did that in jk2_handler(), which now seems like the wrong place to do it,
and I also tried to make sure uriEnv is populated, but I don't think I'm picking
it from the correct spot (if it makes any difference at all). I did:

-
ap_get_module_config(r->server->module_config, &jk2_module);
-

where I maybe should have done:

-
ap_get_module_config(r->per_dir_config, &jk2_module);
-

Honestly, I don't understand neither mod_jk2 (surprise :-) nor Apache2 enough to
make a decision about that. So, I'll leave this up to you guys to correctly
identify.

However, the most confusing part of this whole business is this (I'll ask this
in terms of mod_jk, but it should be similar for mod_jk2):

If jk_translate() is the one mapping requests and also in charge of setting the
value of r->handler (which will later on be used by jk_handler() to recognise
that this as something for Tomcat and eventually serve the request), that would
mean that it must have recognised the requested URI that had
r->handler==DIR_MAGIC_TYPE as the one that should be mapped too. I don't see
anything in the code that would discriminate on the basis of r->handler, except
for manual mappings, which does not include DIR_MAGIC_TYPE.

So, the unsolved questions for me are:

1. What is it then that jk_handler() does that makes it actually serve the
request when DIR_MAGIC_TYPE is included in the test? It must be that its mapping
is 'better' than mapping of jk_translate()...

2. Or is it that jk_translate() never even gets involved during that request and
therefore never has the chance to do the mapping?

Bojan

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

Re: How to start the j_security_check servlet if using SSLAuthenticator

[Andrew Grosser]

It should be possible to include this "magic" url in the SSLAuthenticator 
class too, no?

thanks

>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
>To: Tomcat Developers List <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: How to start the j_security_check servlet if using 
>SSLAuthenticator
>Date: Mon, 22 Jul 2002 21:25:30 -0700 (PDT)
>MIME-Version: 1.0
>Received: from [192.18.49.131] by hotmail.com (3.2) with ESMTP id 
>MHotMailBF062625008F400431D9C01231839BEF0; Mon, 22 Jul 2002 21:27:17 -0700
>Received: (qmail 4771 invoked by uid 97); 23 Jul 2002 04:26:00 -
>Received: (qmail 4759 invoked by uid 98); 23 Jul 2002 04:25:59 -
>From tomcat-dev-return-15135-dioptre Mon, 22 Jul 2002 21:27:35 -0700
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>Precedence: bulk
>List-Unsubscribe: 
>List-Subscribe: 
>List-Help: 
>List-Post: 
>List-Id: "Tomcat Developers List" 
>Delivered-To: mailing list [EMAIL PROTECTED]
>X-Antivirus: nagoya (v4198 created Apr 24 2002)
>In-Reply-To: <000801c231ff$96d41c60$0100a8c0@ga>
>Message-ID: <[EMAIL PROTECTED]>
>X-Spam-Rating: localhost 1.6.2 0/1000/N
>X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
>
>Right now, the choice between FORM and CLIENT-CERT is an either-or choice
>in the servlet spec -- you cannot choose both on the same web application.
>
>The "j_security_check" URL is not actually mapped to a servlet -- it is a
>"magic" URL that is only enabled (by FormAuthenticator) when the form
>login page has been displayed.  None of the rest of Tomcat has a clue what
>j_security_check is for.
>
>Craig
>
>
>
>On Tue, 23 Jul 2002, Andrew Grosser wrote:
>
> > Date: Tue, 23 Jul 2002 13:15:33 +0900
> > From: Andrew Grosser <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: How to start the j_security_check servlet if using
> > SSLAuthenticator
> >
> > Hello,
> > I have been looking at extending the SSLAuthenticator class to accept
> > Certificates AND Form type logins using a JDBC connector.
> > This would have seemed relatively simple - but I have not been able to
> > instantiate the j_security_check servlet for the SSLAuthenticator class
> > (as it seems to only work for FormAuthenticator).
> > I have not been able to find the reference for where j_security_check is
> > called by the Context config/manager and how it recognizes whether the
> > authentication used is of type FORM/CLIENT-CERT
> >
> > Perhaps it has something to do with the difference between
> >
> > ContextConfig[]: Configured an authenticator for method FORM
> >
> >  And
> >
> > ContextConfig[]: Configured an authenticator for method CLIENT-CERT
> >
> > But I cant seem to find it anywhere.
> >
> > Please help
> >
> > Cheers
> >
> >
>
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>
>




_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


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

Re: How to start the j_security_check servlet if using SSLAuthenticator

[Craig R. McClanahan]

Right now, the choice between FORM and CLIENT-CERT is an either-or choice
in the servlet spec -- you cannot choose both on the same web application.

The "j_security_check" URL is not actually mapped to a servlet -- it is a
"magic" URL that is only enabled (by FormAuthenticator) when the form
login page has been displayed.  None of the rest of Tomcat has a clue what
j_security_check is for.

Craig



On Tue, 23 Jul 2002, Andrew Grosser wrote:

> Date: Tue, 23 Jul 2002 13:15:33 +0900
> From: Andrew Grosser <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: How to start the j_security_check servlet if using
> SSLAuthenticator
>
> Hello,
> I have been looking at extending the SSLAuthenticator class to accept
> Certificates AND Form type logins using a JDBC connector.
> This would have seemed relatively simple - but I have not been able to
> instantiate the j_security_check servlet for the SSLAuthenticator class
> (as it seems to only work for FormAuthenticator).
> I have not been able to find the reference for where j_security_check is
> called by the Context config/manager and how it recognizes whether the
> authentication used is of type FORM/CLIENT-CERT
>
> Perhaps it has something to do with the difference between
>
> ContextConfig[]: Configured an authenticator for method FORM
>
>  And
>
> ContextConfig[]: Configured an authenticator for method CLIENT-CERT
>
> But I cant seem to find it anywhere.
>
> Please help
>
> Cheers
>
>


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

How to start the j_security_check servlet if using SSLAuthenticator

[Andrew Grosser]

Hello, 
I have been looking at extending the SSLAuthenticator class to accept
Certificates AND Form type logins using a JDBC connector. 
This would have seemed relatively simple - but I have not been able to
instantiate the j_security_check servlet for the SSLAuthenticator class
(as it seems to only work for FormAuthenticator). 
I have not been able to find the reference for where j_security_check is
called by the Context config/manager and how it recognizes whether the
authentication used is of type FORM/CLIENT-CERT
 
Perhaps it has something to do with the difference between
 
ContextConfig[]: Configured an authenticator for method FORM 
 
 And 
 
ContextConfig[]: Configured an authenticator for method CLIENT-CERT
 
But I cant seem to find it anywhere.
 
Please help
 
Cheers
 

Tomcat Bug Urgent

[Yash]

Dear Sir,

Kindly tell me wether Bug#: 7013  has been fixed or not.If yes then in which release 
it has been
fixed.I am seeing the Release documents of 3.3 it says somthing but not clearly wether 
the above
mentioned bug has been fixed or not.I`m using 3.2.2 version of Tomcat and facing 
similar problemms.
Regards
Yash Bhatnagar
Monex Inc.
Pacific Century Place Marunouchi 19F,
1-11-1,Marunouchi, Chiyoda-Ku, Tokyo 1006219, Japan.
Tel:81-3-6212-3831(Direct)
Mobile:81-90-53071610,81-90-66533897


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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

[costinm]

On 23 Jul 2002, Bojan Smojver wrote:

> Before I do that, some questions about uriEnv in jk2_handler(), since
> that part is very different to mod_jk. The initial test involves asking:
> 
> if (uriEnv==NULL || strcmp(r->handler,JK_HANDLER)!= 0)

uriEnv == null means no match was found.

It is set by either jk2_translate or by a "JkSet" in a  
context.


> After the first test, there is the second test that goes:
> 
> if( uriEnv == NULL )

Yes, that's some old code that tryed to support the case when
someone would do:
  
SetHandler jakarta/servlet
  

I'll remove it - as you mention, it's obviously not working,
and I'm not sure it is a good idea - doing a JkSet has the 
same effect and it's not worth the extra complexity.


> How do I go through this mine field? What's going to be the value of
> uriEnv if r->handler is DIR_MAGIC_TYPE? If it's going to be NULL, I have

It's jk_translate who decides if a request is to be handled by
jk ( by mapping it to a uriEnv ).

You can add a test for r->handler==DIR_MAGIC_TYPE, but don't assume
any uriEnv is set.

uriEnv is the equivalent of a servlet mapping ( or the Container 
in 3.3 ).  

You should still do an internal mapping in handler and find 
some per/context or per/vhost uriEnv. 

Costin


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

DO NOT REPLY [Bug 11069] New: - Tomcat not flag error if tld is outside of /WEB-INF

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

Tomcat not flag error if tld is outside of /WEB-INF

   Summary: Tomcat not flag error if tld is outside of /WEB-INF
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


JSP1.2 spec 7.3.1 says :

   When deployed directly into a web application, the tag
   library descriptor files must always be in the /WEB-INF
   directory or some subdirectory of if.

But if jsp has taglib directive like :

   <%@taglib uri="/folder/my.tld" prefix="mytlib"%>

which points to outside of /WEB-INF, but tomcat accepts
this tld file.

This tld location should be invalid.

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

DO NOT REPLY [Bug 10789] - Setting DirectoryIndex of index.jsp does not get served by jk2

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

Setting DirectoryIndex of index.jsp does not get served by jk2





--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 02:20 ---
Mark, could you please give it another go. The new code is in, but since I'm not
mod_jk2 user, I can't really tell if it's good or not.

This time physical files, including aliases, and requests to default files not
specified in DirectoryIndex should be covered.

Bojan

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

DO NOT REPLY [Bug 11066] - method not found in class "java.lang.Runtime"

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

method not found in class "java.lang.Runtime"

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 00:48 ---
The CGI code is trying to run a method from JDK1.3.  You are apparently running
tomcat with JDK1.2

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

Re: Missing patch for Japanese support in admin

[Craig R. McClanahan]

On Mon, 22 Jul 2002, Amy Roh wrote:

> Date: Mon, 22 Jul 2002 14:54:05 -0700
> From: Amy Roh <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Dev <[EMAIL PROTECTED]>
> Subject: Missing patch for Japanese support in admin
>
> If I remember correctly, I believe someone sent a patch for Japanese
> support in admin webapp a while ago.  I accidentally deleted the email
> with the patch and cannot remember the title or the author.  Does anyone
> have that email or remember the title so I can search for it?
>

Among other places, it will be in the mailing list archives of TOMCAT-DEV,
including the one on Nagoya:

  http://nagoya.apache.org/eyebrowse/

I'm pretty sure it was in July, and had the word "Japanese" or "admin" in
the subject, so you should be able to search for it pretty quickly.

> Thanks,
> Amy
>

Craig


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

DO NOT REPLY [Bug 11066] New: - method not found in class "java.lang.Runtime"

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

method not found in class "java.lang.Runtime"

   Summary: method not found in class "java.lang.Runtime"
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows 9x
Status: UNCONFIRMED
  Severity: Major
  Priority: Other
 Component: Servlets:CGI
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Dear Sir/Madam,

I´m trying to run a cgi program written in C++ (its source code is below), but 
unfortunately I get the folowing message:

- Root Cause -
java.lang.NoSuchMethodError: java.lang.Runtime: method 
exec(Ljava/lang/String;[Ljava/lang/String;Ljava/io/File;)Ljava/lang/Process; not 
found

I followed all the instructions for setting up Tomcat 4.0.4 to run cgi programs.

Here is the C++ program:

#include  

void main (void) 
{ 
 printf("Content-type: text/html\n\n"); 
 printf("Test"); 
 printf("Testing 1,2,3" ); 
 printf("\n\n"); 
}

Thanks very much for any help on that.

Joao Carlos

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

Connectors on MacOS X

[Tobias Wunden]

Hi all,

I am currently trying to get the JK/JK2 connectors working on MacOS X 
(with little success so far, but that's another thing). Trouble already 
starts compiling the native sources using the provided ant buildfiles.
To make life easier for other mac users, would you mind making the 
following additional statements to your buildfiles in 
jk/native/build.xml and jk/native2/build.xml?

1) Detect MacOS X hosts:

 
 
 
 
 
 

2) Add the native java header files:

 Everywhere you include the native header files of the java 
distribution to include jni.h, insert one of the following lines, they 
both work, since ${java.home}/include is a symbolic link to 
${java.home}/../Headers:

 
 or
 

3) Provide Information on dlopen

MacOS X doesn't provide dlopen. But a kind person (Jorge Acereda 
<[EMAIL PROTECTED]>) wrote a wrapper for it, consisting of 
the headerfile dlfcn.h and an implementation which IMHO should at least 
be mentioned in the README if not included somewhere in your 
src-distribution. The link to the files is as followed:

 http://http://download.sourceforge.net/fink/dlcompat-20020709.tar.gz

Thanks for your help!

Greetings,
Tobias


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

JNDIRealm change proposal

[Ales Seifert]

Hi,
I'm sorry if i'm posting it to the wrong list,

I found small problem in JNDIRealm and I suggest small change.

in method protected List getRoles(DirContext context,
  String username, String dn)

is line

String role = (String) attr.get();

which is throwing ClassCastException, bacause not every attribute can
be converted to String.

So my suggestion is to use this way:

String role = attr.get().toString();

which should never thrown ClassCastException bacause every objects are
subclass of the Object class.

Can somebody make this change into source for next release?

Thanks

Alesak



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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

[Bojan Smojver]

I made an initial, most likely broken commit of this code for mod_jk2.
Can you go through it as I'm making assumptions in there that I am not
sure about. They are just a parallel from mod_jk, but that could be
totally bogus.

At least there is some 'meat' for you guys to play with.

Bojan

On Tue, 2002-07-23 at 07:44, [EMAIL PROTECTED] wrote:
> On 23 Jul 2002, Bojan Smojver wrote:
> 
> > Important note:
> > ---
> > THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC.
> > -
> > 
> > Do you want me to:
> > 
> > [ ] Revert it back to what it was before I put my fingers in it
> > [ ] Leave it alone
> > [+1] Attempt to apply the same stuff that's in this patch to it
> 
> Costin
> 
> 
> --
> 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/apache2 mod_jk2.c

[bojan]

bojan   2002/07/22 16:18:38

  Modified:jk/native2/server/apache2 mod_jk2.c
  Log:
  Initial, most likely *BROKEN* code to handle default directory files. The
  code in jk2_map_to_storage() should be OK.
  
  Most critical stuff is in jk2_handler() function, the part of code that
  attempts to get uriEnv from r->server->module_config.
  
  Please review!
  
  Revision  ChangesPath
  1.45  +41 -23jakarta-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.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- mod_jk2.c 21 Jul 2002 06:52:29 -  1.44
  +++ mod_jk2.c 22 Jul 2002 23:18:38 -  1.45
  @@ -532,8 +532,13 @@
   
   uriEnv=ap_get_module_config( r->request_config, &jk2_module );
   
  +/* We do DIR_MAGIC_TYPE here to make sure TC gets all requests, even
  + * if they are directory requests, in case there are no static files
  + *  visible to Apache and/or DirectoryIndex was not used */
  +
   /* not for me, try next handler */
  -if(uriEnv==NULL || strcmp(r->handler,JK_HANDLER)!= 0 )
  +if((uriEnv==NULL || strcmp(r->handler,JK_HANDLER)) &&
  +   strcmp(r->handler,DIR_MAGIC_TYPE))
 return DECLINED;
   
   /* If this is a proxy request, we'll notify an error */
  @@ -541,6 +546,17 @@
   return HTTP_INTERNAL_SERVER_ERROR;
   }
   
  +/* This is needed for DIR_MAGIC_TYPE. Not sure if this is good, bad or just
  + * plain ugly, but we really NEED to have uriEnv, otherwise everything else
  + * will blow up */
  +
  +if(uriEnv == NULL){
  +uriEnv = ap_get_module_config(r->server->module_config, &jk2_module);
  +
  +if(uriEnv == NULL) /* We still have nothing, go out */
  +  return DECLINED;
  +}
  +
   workerEnv = uriEnv->workerEnv;
   
   /* Get an env instance */
  @@ -708,30 +724,32 @@
   jk_uriEnv_t *uriEnv=ap_get_module_config( r->request_config, &jk2_module );
   
   if( uriEnv != NULL ) {
  -char *uri_p=r->uri;
  +
  +/* First find just the name of the file, no directory */
  +r->filename = (char *)apr_filename_of_pathname(r->uri);
   
  -/* This is old code which doesn't seem to work well with mod_dir
  -r->filename = (char *)apr_filename_of_pathname(r->uri); */
  +/* Only if sub-request for a directory, most likely from mod_dir */
  +if (r->main && r->main->filename &&
  +!*apr_filename_of_pathname(r->main->filename)){
  +
  +/* The filename from the main request will be set to what should
  + * be picked up, aliases included. Tomcat will need to know about
  + * those aliases or things won't work for them. Normal files
  + * should be fine. */
  +
  +/* Need absolute path to stat */
  +if (apr_filepath_merge(&r->filename,
  +   r->main->filename, r->filename,
  +   APR_FILEPATH_SECUREROOT |
  +   APR_FILEPATH_TRUENAME,
  +   r->pool)
  +!= APR_SUCCESS){
  +  return DECLINED; /* We should never get here, very bad */
  +}
   
  -/* if( uriEnv->mbean->debug > 0 ) { */
  -/*   env->l->jkLog(env, env->l, JK_LOG_INFO,  */
  -/* "mod_jk.map_to_storage(): map %s %s\n", */
  -/*  r->uri, r->filename); */
  -/* } */
  -
  -/* Absolute paths cannot be merged */
  -while (*uri_p == '/') ++uri_p;
  -
  -/* Need absolute path to stat */
  -if (apr_filepath_merge(&r->filename, ap_document_root(r), uri_p,
  -   APR_FILEPATH_SECUREROOT | APR_FILEPATH_TRUENAME,
  -   r->pool)
  -!= APR_SUCCESS){
  -  return DECLINED;
  +/* Stat the file so that mod_dir knows it's there */
  +apr_stat(&r->finfo, r->filename, APR_FINFO_TYPE, r->pool);
   }
  -
  -/* Stat the file so that mod_dir knows it's there */
  -apr_stat(&r->finfo, r->filename, APR_FINFO_TYPE, r->pool);
   
   return OK;
   }
  
  
  

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspDocumentParser.java JspUtil.java PageDataImpl.java TagConstants.java TagLibraryInfoImpl.java

[luehe]

luehe   2002/07/22 16:02:55

  Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java JspUtil.java
PageDataImpl.java TagConstants.java
TagLibraryInfoImpl.java
  Log:
  Added support for Tag File directives in Tag File Documents
  
  Revision  ChangesPath
  1.7   +34 -25
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- JspDocumentParser.java17 Jul 2002 20:06:58 -  1.6
  +++ JspDocumentParser.java22 Jul 2002 23:02:55 -  1.7
  @@ -183,21 +183,21 @@
Attributes attrsCopy = new AttributesImpl(attrs);
   
Node node = null;   
  - if (qName.equals(JSP_ROOT_TAG)) {
  + if (qName.equals(JSP_ROOT)) {
node = new Node.JspRoot(attrsCopy, start, current);
try {
addCustomTagLibraries(attrsCopy);
} catch (JasperException je) {
throw new SAXException(je);
}
  - } else if (qName.equals(JSP_PAGE_DIRECTIVE_TAG)) {
  + } else if (qName.equals(JSP_PAGE_DIRECTIVE)) {
node = new Node.PageDirective(attrsCopy, start, current);
String imports = attrs.getValue("import");
// There can only be one 'import' attribute per page directive
if (imports != null) {
((Node.PageDirective) node).addImport(imports);
}
  - } else if (qName.equals(JSP_INCLUDE_DIRECTIVE_TAG)) {
  + } else if (qName.equals(JSP_INCLUDE_DIRECTIVE)) {
node = new Node.IncludeDirective(attrsCopy, start, current);
String file = attrsCopy.getValue("file");
try {
  @@ -209,34 +209,42 @@
} catch (Exception e) {
throw new SAXException(e);
}
  - } else if (qName.equals(JSP_DECLARATION_TAG)) {
  + } else if (qName.equals(JSP_DECLARATION)) {
node = new Node.Declaration(start, current);
  - } else if (qName.equals(JSP_SCRIPTLET_TAG)) {
  + } else if (qName.equals(JSP_SCRIPTLET)) {
node = new Node.Scriptlet(start, current);
  - } else if (qName.equals(JSP_EXPRESSION_TAG)) {
  + } else if (qName.equals(JSP_EXPRESSION)) {
node = new Node.Expression(start, current);
  - } else if (qName.equals(JSP_USE_BEAN_TAG)) {
  + } else if (qName.equals(JSP_USE_BEAN)) {
node = new Node.UseBean(attrsCopy, start, current);
  - } else if (qName.equals(JSP_SET_PROPERTY_TAG)) {
  + } else if (qName.equals(JSP_SET_PROPERTY)) {
node = new Node.SetProperty(attrsCopy, start, current);
  - } else if (qName.equals(JSP_GET_PROPERTY_TAG)) {
  + } else if (qName.equals(JSP_GET_PROPERTY)) {
node = new Node.GetProperty(attrsCopy, start, current);
  - } else if (qName.equals(JSP_INCLUDE_TAG)) {
  + } else if (qName.equals(JSP_INCLUDE)) {
node = new Node.IncludeAction(attrsCopy, start, current);
  - } else if (qName.equals(JSP_FORWARD_TAG)) {
  + } else if (qName.equals(JSP_FORWARD)) {
node = new Node.ForwardAction(attrsCopy, start, current);
  - } else if (qName.equals(JSP_PARAM_TAG)) {
  + } else if (qName.equals(JSP_PARAM)) {
node = new Node.ParamAction(attrsCopy, start, current);
  - } else if (qName.equals(JSP_PARAMS_TAG)) {
  + } else if (qName.equals(JSP_PARAMS)) {
node = new Node.ParamsAction(start, current);
  - } else if (qName.equals(JSP_PLUGIN_TAG)) {
  + } else if (qName.equals(JSP_PLUGIN)) {
node = new Node.PlugIn(attrsCopy, start, current);
  - } else if (qName.equals(JSP_TEXT_TAG)) {
  + } else if (qName.equals(JSP_TEXT)) {
node = new Node.JspText(start, current);
  - } else if (qName.equals(JSP_BODY_TAG)) {
  + } else if (qName.equals(JSP_BODY)) {
node = new Node.JspBody(attrsCopy, start, current);
  - } else if (qName.equals(JSP_ATTRIBUTE_TAG)) {
  + } else if (qName.equals(JSP_ATTRIBUTE)) {
node = new Node.NamedAttribute(attrsCopy, start, current);
  + } else if (qName.equals(JSP_TAG_DIRECTIVE)) {
  + node = new Node.TagDirective(attrsCopy, start, current);
  + } else if (qName.equals(JSP_ATTRIBUTE_DIRECTIVE)) {
  + node = new Node.AttributeDirective(attrsCopy, start, current);
  + } else if (qName.equals(JSP_VARIABLE_DIRECTIVE)) {
  + node = new Node.VariableDirective(attrsCopy, start, current);
  + } else if (qName.equals(JSP_FRAGMENT_INPUT_DIRECTIVE)) {
  + node = new Node.FragmentInputDirective(attrsCopy, start, current);

FW: Jakarta-tomcat page requires update

[Pier Fumagalli]

Not acked...

Pier

--
I love introducing bug:  "Floating Point Exception this is Access Violation,
Access Violation, this is Floating Point Exception".  Eric Prud'Hommeaux

-- Forwarded Message
From: R Andrew Johnston <[EMAIL PROTECTED]>
Date: Mon, 22 Jul 2002 17:24:29 -0400 (EDT)
To: [EMAIL PROTECTED]
Subject: Jakarta-tomcat page requires update
Resent-From: Brian Behlendorf <[EMAIL PROTECTED]>
Resent-To: [EMAIL PROTECTED]
Resent-Date: Mon, 22 Jul 2002 15:16:59 -0700 (PDT)


on this page
http://jakarta.apache.org/site/sourceindex.html

Under Release Builds,

The link to Tomcat 4.0.3 is broken.
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.3/src/

and it should be to Tomcat 4.0.4
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/src

-- 
andrew





-- End of Forwarded Message


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

Announcing the JSP 2.0 Preview EA1 Implementation

[Mark Roth]

For those of you tracking the JSP 2.0 specification, we are pleased to
announce the availability of an Early Access Preview implementation, 
available now from:

http://developer.java.sun.com/developer/earlyAccess/jsp/
 
The primary goal of the JSP 2.0 specification is to make JSP technology
more productive and even easier to use.  The specification is being
developed by an expert group consisting of over 30 companies and
individuals, and is currently in Public Review stages.  More information
on the specification, including a public download, is available at
http://jcp.org/jsr/detail/152.jsp
 
This implementation was developed collectively in the Expert Group 
using Tomcat 4.1 and Jasper2 as a base.  The intent of the Expert
Group is to integrate this source base with Tomcat 5.0.
The Preview is intended solely to allow you, the developer
community, to experiment with some of the new JSP 2.0 features and
provide us, the JSR-152 (JSP 2.0) expert group, with hands-on feedback. 
Please send all feedback to [EMAIL PROTECTED]
 
Please note that this is not a production release, and that not all JSP
2.0 features are implemented.

Features implemented include:

* New JSP 2.0 APIs
* Integrated Expression Language Support
* Supports new  and  standard actions
* Supports new SimpleTag Handlers and JSP Fragments

Features not yet implemented include:

* JSR-45 Debugging Support
* Tag Files
* Attributes with Dynamic Names
* JSP Configuration

The download comes with pre-installed JSP 2.0 examples that help
illustrate the new feature set.

Please give it a try, and we look forward to hearing from you!

--
Mark Roth, Java Software
Specification Co-Lead of JSP 2.0
Sun Microsystems, Inc.



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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

[Bojan Smojver]

Before I do that, some questions about uriEnv in jk2_handler(), since
that part is very different to mod_jk. The initial test involves asking:

if (uriEnv==NULL || strcmp(r->handler,JK_HANDLER)!= 0)

and if so, the whole thing is skipped.

After the first test, there is the second test that goes:

if( uriEnv == NULL )

Obviously, that's not possible, since the first test would kick us out
of the function. But, in case the first test was changed to not involve
asking if uriEnv is null, the the code after the second test would hit a
NULL pointer here:

if( uriEnv->mbean->debug > 0 )

How do I go through this mine field? What's going to be the value of
uriEnv if r->handler is DIR_MAGIC_TYPE? If it's going to be NULL, I have
to change a lot of code in the whole function to make sure we don't bump
into a NULL pointer somewhere...

Bojan

On Tue, 2002-07-23 at 07:44, [EMAIL PROTECTED] wrote:
> On 23 Jul 2002, Bojan Smojver wrote:
> 
> > Important note:
> > ---
> > THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC.
> > -
> > 
> > Do you want me to:
> > 
> > [ ] Revert it back to what it was before I put my fingers in it
> > [ ] Leave it alone
> > [+1] Attempt to apply the same stuff that's in this patch to it
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

[costinm]

On 23 Jul 2002, Bojan Smojver wrote:

> Important note:
> ---
> THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC.
> -
> 
> Do you want me to:
> 
> [ ] Revert it back to what it was before I put my fingers in it
> [ ] Leave it alone
> [+1] Attempt to apply the same stuff that's in this patch to it

Costin


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

Missing patch for Japanese support in admin

[Amy Roh]

If I remember correctly, I believe someone sent a patch for Japanese
support in admin webapp a while ago.  I accidentally deleted the email
with the patch and cannot remember the title or the author.  Does anyone
have that email or remember the title so I can search for it?

Thanks,
Amy


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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

[Bojan Smojver]

I have tested this with and without DirectoryIndex.

In case there is DirectoryIndex, the physical file(s) are stat and if
that's successful mod_dir does its thing. It works nicely for at least 2
different file extensions (in my case *.jsp and *.vm). If the files
cannot be stat, it's up the jk_handler() to decide, which covers the
cases where there are no physical files present. The requests will still
end up in Tomcat if there is a mapping.

If there is no DirectoryIndex, jk_handler() makes its own decisions
about what's going to get served. Anything that is mapped will end up in
Tomcat.

Note that this whole thing does not affect real static files like
index.html. Tomcat will never serve (or attempt to serve) those, unless
they are mapped to Tomcat by some other means, not the extension. So I
hope this satisfies all relevant concerns for now.

Important note:
---
THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC.
-

Do you want me to:

[ ] Revert it back to what it was before I put my fingers in it
[ ] Leave it alone
[ ] Attempt to apply the same stuff that's in this patch to it

Bojan

On Tue, 2002-07-23 at 07:03, [EMAIL PROTECTED] wrote:
> bojan   2002/07/22 14:03:19
> 
>   Modified:jk/native/apache-2.0 mod_jk.c
>   Log:
>   Put back DIR_MAGIC_TYPE in case there is no DirectoryIndex and/or no
>   pysical files to stat.
>   
>   Lose one stat, not really needed. Fix a typo.
>   
>   Revision  ChangesPath
>   1.52  +10 -5 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
>   
>   Index: mod_jk.c
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
>   retrieving revision 1.51
>   retrieving revision 1.52
>   diff -u -r1.51 -r1.52
>   --- mod_jk.c22 Jul 2002 02:48:11 -  1.51
>   +++ mod_jk.c22 Jul 2002 21:03:19 -  1.52


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

cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

[bojan]

bojan   2002/07/22 14:03:19

  Modified:jk/native/apache-2.0 mod_jk.c
  Log:
  Put back DIR_MAGIC_TYPE in case there is no DirectoryIndex and/or no
  pysical files to stat.
  
  Lose one stat, not really needed. Fix a typo.
  
  Revision  ChangesPath
  1.52  +10 -5 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
  retrieving revision 1.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- mod_jk.c  22 Jul 2002 02:48:11 -  1.51
  +++ mod_jk.c  22 Jul 2002 21:03:19 -  1.52
  @@ -1181,9 +1181,14 @@
   jk_server_conf_t *conf;
   int  rc;
   
  -if(strcmp(r->handler,JK_HANDLER)) /* not for me, try next handler */
  +/* We do DIR_MAGIC_TYPE here to make sure TC gets all requests, even
  + * if they are directory requests, in case there are no static files
  + * visible to Apache and/or DirectoryIndex was not used */
  +
  +/* not for me, try next handler */
  +if(strcmp(r->handler,JK_HANDLER) && strcmp(r->handler,DIR_MAGIC_TYPE))
 return DECLINED;
  -
  +
   xconf = (jk_server_conf_t *)ap_get_module_config(r->server->module_config, 
&jk_module);
   worker_name = apr_table_get(r->notes, JK_WORKER_ID);
  @@ -1622,9 +1627,9 @@
   /* First find just the name of the file, no directory */
   r->filename = (char *)apr_filename_of_pathname(r->uri);
   
  -/* Ony if sub-request for a directory, most likely from mod_dir */
  +/* Only if sub-request for a directory, most likely from mod_dir */
   if (r->main && r->main->filename &&
  -ap_is_directory(r->pool, r->main->filename)){
  +!*apr_filename_of_pathname(r->main->filename)){

   /* The filename from the main request will be set to what should
* be picked up, aliases included. Tomcat will need to know about
  @@ -1638,7 +1643,7 @@
  APR_FILEPATH_TRUENAME,
  r->pool)
   != APR_SUCCESS){
  -  return DECLINED;
  +  return DECLINED; /* We should never get here, very bad */
   }
   
   /* Stat the file so that mod_dir knows it's there */
  
  
  

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

[kinman]

kinman  2002/07/22 13:35:27

  Modified:jasper2/src/share/org/apache/jasper/compiler Node.java
PageInfo.java Parser.java ParserController.java
Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties
  Log:
  - First batch of mods in support of tag files.
  
  Revision  ChangesPath
  1.20  +75 -3 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
  
  Index: Node.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- Node.java 19 Jul 2002 17:12:57 -  1.19
  +++ Node.java 22 Jul 2002 20:35:27 -  1.20
  @@ -389,6 +389,62 @@
   }
   
   /**
  + * Represents a tag directive
  + */
  +public static class TagDirective extends Node {
  +
  + public TagDirective(Attributes attrs, Mark start, Node parent) {
  + super(attrs, start, parent);
  + }
  +
  + public void accept(Visitor v) throws JasperException {
  + v.visit(this);
  + }
  +}
  +
  +/**
  + * Represents an attribute directive
  + */
  +public static class AttributeDirective extends Node {
  +
  + public AttributeDirective(Attributes attrs, Mark start, Node parent) {
  + super(attrs, start, parent);
  + }
  +
  + public void accept(Visitor v) throws JasperException {
  + v.visit(this);
  + }
  +}
  +
  +/**
  + * Represents a variable directive
  + */
  +public static class VariableDirective extends Node {
  +
  + public VariableDirective(Attributes attrs, Mark start, Node parent) {
  + super(attrs, start, parent);
  + }
  +
  + public void accept(Visitor v) throws JasperException {
  + v.visit(this);
  + }
  +}
  +
  +/**
  + * Represents a fragment-input directive
  + */
  +public static class FragmentInputDirective extends Node {
  +
  + public FragmentInputDirective(Attributes attrs, Mark start, Node parent) {
  + super(attrs, start, parent);
  + }
  +
  + public void accept(Visitor v) throws JasperException {
  + v.visit(this);
  + }
  +}
  +
  +/**
* Represents a Jsp comment
* Comments are kept for completeness.
*/
  @@ -1426,12 +1482,28 @@
doVisit(n);
}
   
  + public void visit(TagDirective n) throws JasperException {
  + doVisit(n);
  + }
  +
public void visit(IncludeDirective n) throws JasperException {
doVisit(n);
visitBody(n);
}
   
public void visit(TaglibDirective n) throws JasperException {
  + doVisit(n);
  + }
  +
  + public void visit(AttributeDirective n) throws JasperException {
  + doVisit(n);
  + }
  +
  + public void visit(VariableDirective n) throws JasperException {
  + doVisit(n);
  + }
  +
  + public void visit(FragmentInputDirective n) throws JasperException {
doVisit(n);
}
   
  
  
  
  1.7   +21 -3 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java
  
  Index: PageInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- PageInfo.java 16 Jul 2002 19:30:51 -  1.6
  +++ PageInfo.java 22 Jul 2002 20:35:27 -  1.7
  @@ -91,6 +91,8 @@
   private int maxTagNesting = 0;
   private boolean scriptless = false;
   private boolean scriptingEnabled = true;
  +private boolean elEnabled = true;
  +private boolean tagFile = false;
   
   PageInfo(BeanRepository beanRepository) {
this.beanRepository = beanRepository;
  @@ -229,5 +231,21 @@
   
   public boolean isScriptingEnabled() {
return scriptingEnabled;
  +}
  +
  +public void setELEnabled(boolean s) {
  + elEnabled = s;
  +}
  +
  +public boolean isELEnabled() {
  + return elEnabled;
  +}
  +
  +public void setTagFile(boolean s) {
  + tagFile = s;
  +}
  +
  +public boolean isTagFile() {
  + return tagFile;
   }
   }
  
  
  
  1.11  +95 -7 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- Parser.java   18 Jul 2002 20:18:10 -  1.10
  +++ Pars

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/funcspecs mbean-names.xml project.xml

[amyroh]

amyroh  2002/07/22 13:16:33

  Modified:webapps/tomcat-docs/funcspecs project.xml
  Added:   webapps/tomcat-docs/funcspecs mbean-names.xml
  Log:
  Add Tomcat MBean Names documentation that describes a naming convention
  for Tomcat MBeans.
  
  Revision  ChangesPath
  1.2   +1 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/funcspecs/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/funcspecs/project.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- project.xml   6 Aug 2001 19:08:53 -   1.1
  +++ project.xml   22 Jul 2002 20:16:33 -  1.2
  @@ -17,6 +17,7 @@
   
   
   
  +
   
   
   
  
  
  
  1.1  jakarta-tomcat-4.0/webapps/tomcat-docs/funcspecs/mbean-names.xml
  
  Index: mbean-names.xml
  ===
  
  
  ]>
  
  
&project;
  

  Craig McClanahan
  Amy Roh
  Tomcat MBean Names
  $Id: mbean-names.xml,v 1.1 2002/07/22 20:16:33 amyroh Exp $

  
  
  
  
  
  
  We will be using JMX MBeans as the technology for
  implementing manageability of Tomcat.
  
  One of the key concepts of JMX (and JSR-77) is that each management
  bean has a unique name in the MBeanServer's registry, and that
  management applications can utilize these names to retrieve the MBean
  of interest to them for a particular management operation.
  This document proposes a naming convention for MBeans that allows easy
  calculation of the name for a particular MBean.  For background
  information on JMX MBean names, see the Java Management Extensions
  Instrumentation and Agent Specification, version 1.0, section 6.
  In particular, we will be discussing the String Representation of
  ObjectName instances.
  
  
  
  
  
  Tomcat's servlet container implementation, called Catalina, can be
  represented as a hierarchy of objects that contain references to each other.
  The object hierarchy can be represented as a tree, or (isomorphically) based
  on the nesting of configuration elements in the conf/server.xml
  file that is traditionally used to configure Tomcat stand-alone.
  
  The valid component nestings for Catalina are depicted in the following
  table, with columns that contain the following values:
  
  Pattern - Nesting pattern of XML elements (in the
  conf/server.xml file) used to configure this component.
  Cardinality - Minimum and maximum number of occurrences of
  this element at this nesting position, which also corresponds to the
  minimum and maximum number of Catalina components.
  Identifier - Name of the JavaBeans property of this component
  that represents the unique identifier (within the nested hierarchy),
  if any.
  MBean ObjectName - The portion of the MBean object name that
  appears after the domain name.  For now, it should be
  assumed that all of these MBeans appear in the default JMX domain.
  
  
  In the MBean ObjectName descriptions, several types of symbolic
  expressions are utilized to define variable text that is replaced by
  corresponding values:
  
  ${GROUP} - One of the standard MBean names of the specified
  "group" category.  For example, the expression ${LOGGER}
  represents the values FileLogger,
  SystemErrLogger, and SystemOutLogger that
  identify the various MBeans for possible Logger components.
  ${name} - Replaced by the value of property name
  from the current component.
  ${parent.name} - Replaced by the value of property
  name from a parent of the current component, with the
  parent's type identified by parent.
  ${###} - An arbitrary numeric identifier that preserves
  order but has no other particular meaning.  In general, the server will
  assign numeric values to existing instances with large gaps into which
  new items can be configured if desired.
  
  
  
  

  Pattern
  Cardinality
  Identifier
  MBean ObjectName

  

  Server
  1..1
  (none)
  type=${SERVER}

  

  Server / Listener
  0..n
  (none)
  type=${LISTENER}, sequence=${###}

  

  Server / Service
  1..n
  name
  type=${SERVICE}, name=${name}

  

  Server / Service / Connector
  1..n
  address, port
  type=${CONNECTOR}, service=${service}, port=${port},
  address=${address}

  

  Server / Service / Connector / Factory
  0..1
  (none)
  (Only defined explicitly for an SSL connector, but can be treated
  as part of the connector component)

  

  Server / Service / Connector / Listener
  0..n
  (none)
  type=${LISTENER}, sequence=${###}, service=${service},
  port=${connect

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader ResourceEntry.java WebappClassLoader.java

[remm]

remm2002/07/22 12:53:45

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Added:   catalina/src/share/org/apache/catalina/loader
ResourceEntry.java
  Log:
  - Port fix for bug 10967.
  - Move ResourceEntry to a separate class.
  
  Revision  ChangesPath
  1.2   +4 -59 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- WebappClassLoader.java18 Jul 2002 16:48:04 -  1.1
  +++ WebappClassLoader.java22 Jul 2002 19:53:45 -  1.2
  @@ -2069,60 +2069,5 @@
   }
   
   
  -// -- Protected Classes
  -
  -
  -/**
  - * Resource entry.
  - */
  -protected static class ResourceEntry {
  -
  -
  -/**
  - * The "last modified" time of the origin file at the time this class
  - * was loaded, in milliseconds since the epoch.
  - */
  -protected long lastModified = -1;
  -
  -
  -/**
  - * Binary content of the resource.
  - */
  -protected byte[] binaryContent = null;
  -
  -
  -/**
  - * Loaded class.
  - */
  -protected Class loadedClass = null;
  -
  -
  -/**
  - * URL source from where the object was loaded.
  - */
  -protected URL source = null;
  -
  -
  -/**
  - * URL of the codebase from where the object was loaded.
  - */
  -protected URL codeBase = null;
  -
  -
  -/**
  - * Manifest (if the resource was loaded from a JAR).
  - */
  -protected Manifest manifest = null;
  -
  -
  -/**
  - * Certificates (if the resource was loaded from a JAR).
  - */
  -protected Certificate[] certificates = null;
  -
  -
  -}
  -
  -
   }
   
  
  
  
  1.1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/ResourceEntry.java
  
  Index: ResourceEntry.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/ResourceEntry.java,v
 1.1 2002/07/22 19:53:45 remm Exp $
   * $Revision: 1.1 $
   * $Date: 2002/07/22 19:53:45 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISI

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader ResourceEntry.java WebappClassLoader.java

[remm]

remm2002/07/22 12:52:40

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Added:   catalina/src/share/org/apache/catalina/loader
ResourceEntry.java
  Log:
  - Attempt to fix bug 10967.
  - Move ResourceEntry to a separate class.
  
  Revision  ChangesPath
  1.43  +4 -59 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- WebappClassLoader.java15 Jun 2002 14:42:29 -  1.42
  +++ WebappClassLoader.java22 Jul 2002 19:52:40 -  1.43
  @@ -2069,60 +2069,5 @@
   }
   
   
  -// -- Protected Classes
  -
  -
  -/**
  - * Resource entry.
  - */
  -protected static class ResourceEntry {
  -
  -
  -/**
  - * The "last modified" time of the origin file at the time this class
  - * was loaded, in milliseconds since the epoch.
  - */
  -protected long lastModified = -1;
  -
  -
  -/**
  - * Binary content of the resource.
  - */
  -protected byte[] binaryContent = null;
  -
  -
  -/**
  - * Loaded class.
  - */
  -protected Class loadedClass = null;
  -
  -
  -/**
  - * URL source from where the object was loaded.
  - */
  -protected URL source = null;
  -
  -
  -/**
  - * URL of the codebase from where the object was loaded.
  - */
  -protected URL codeBase = null;
  -
  -
  -/**
  - * Manifest (if the resource was loaded from a JAR).
  - */
  -protected Manifest manifest = null;
  -
  -
  -/**
  - * Certificates (if the resource was loaded from a JAR).
  - */
  -protected Certificate[] certificates = null;
  -
  -
  -}
  -
  -
   }
   
  
  
  
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/ResourceEntry.java
  
  Index: ResourceEntry.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/ResourceEntry.java,v
 1.1 2002/07/22 19:52:40 remm Exp $
   * $Revision: 1.1 $
   * $Date: 2002/07/22 19:52:40 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WA

DO NOT REPLY [Bug 10967] - Java Deadlock in WebappClassLoader

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

Java Deadlock in WebappClassLoader

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-07-22 19:52 ---
Glenn's investigation showed there could be problems with the fact that a static
inner class is used. The class has been taken out of WebappClassLoader, which
could fix the issue. The bug is very hard to reproduce, so it's difficult to
confirm. The fix will be in 4.1.8.

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

Re: JDK 1.4 Logging

[costinm]

On 22 Jul 2002, Bob Herrmann wrote:

> That is an interesting idea, although in my particular case, I walk
> the stack a variable amount. Namely if the stack has method "log()" or
> method "internalLog()" I keep unrolling the stack - this may not be
> a great idea - but it gives good stack traces without changing
> other parts of tomcat.

We'll walk a variable ammount as well - until the first class after 
wrapperClass ( i.e. we look for the caller of a method in wrapperClass ).

I don't think supporting wrappers which are wrapped by 
other wrappers is a goal :-)

Wrapping commons-logging ( which is a wrapper ) as a transition
mechanism should be enough.


> If a webapp wants to use its own logger wrapper, and the factory
> has a single attribute - would there be a conflict here?

That may be a problem. I'm not worried about webapps ( they 
shouldn't play with logger-wrapping :-), but about jasper
which may want to wrap as well.

There is a solution tough - add all the 'wrapperClass' 
passed to the factory to list, and check for any of them
when we un-wrap the stack. This will allow an unlimited number
of wrappers - as long as one wrapper doesn't call another wrapper
that wraps commons-logging, the wrapper. 

We should just use commons-logging - it is nice to have a 
smooth transition, but this should be just that, I don't 
think we should try to solve all the wrapping problems.

Costin


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

Re: JDK 1.4 Logging

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> On 22 Jul 2002, Bob Herrmann wrote:
> 
> 
>>This could be fixed by adding these methods to Log of commons-logger
>>
>> void trace(Object msg, Throwable thr, String className, String method);
>> void debug(Object msg, Throwable thr, String className, String method);
>> void info(Object msg, Throwable thr, String className, String method);
>> void warn(Object msg, Throwable thr, String className, String method);
>> void error(Object msg, Throwable thr, String className, String method);
>> void fatal(Object msg, Throwable thr, String className, String method);
> 
> 
> I think there is a simpler solution for this class of problems, and 
> that would also work with log4j and doesn't require _any_ API change.
> ( only changes to the adapter implementations )
> 
> Any 'wrapper' will use:
>   factory=LogFactory.getFactory();
>
>   factory.setAttribute( "commons-logging.wrapperClass", 
> "[CLASSNAME-OF-WRAPPER]");
>   factory.getLog(), etc.
> 
> The classname of wrapper will be passed to the impl..
> 
>  - for log4j - this just gets passed further, since log4j already supports 
> this feature.
>  - for jdk1.4 or other loggers who don't support wrapping - there is 
> already code in Jdk14Logger that walks the stack trace. Curently it
> uses a hard-coded '2 levels up', but it can use the wrapperClass
>  and walk up to find it.

Looks good :) +1.

Remy


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

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
>...
> I think there is a simpler solution for this class of problems, and 
> that would also work with log4j and doesn't require _any_ API change.
> ( only changes to the adapter implementations )
> 
> Any 'wrapper' will use:
>   factory=LogFactory.getFactory();
>
>   factory.setAttribute( "commons-logging.wrapperClass", 
> "[CLASSNAME-OF-WRAPPER]");
>   factory.getLog(), etc.
> 
> The classname of wrapper will be passed to the impl..
> 
>  - for log4j - this just gets passed further, since log4j already supports 
> this feature.
>  - for jdk1.4 or other loggers who don't support wrapping - there is 
> already code in Jdk14Logger that walks the stack trace. Curently it
> uses a hard-coded '2 levels up', but it can use the wrapperClass
>  and walk up to find it.

That is an interesting idea, although in my particular case, I walk
the stack a variable amount. Namely if the stack has method "log()" or
method "internalLog()" I keep unrolling the stack - this may not be
a great idea - but it gives good stack traces without changing
other parts of tomcat.

If a webapp wants to use its own logger wrapper, and the factory
has a single attribute - would there be a conflict here?

-bob





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

Re: JDK 1.4 Logging

[costinm]

On 22 Jul 2002, Bob Herrmann wrote:

> This could be fixed by adding these methods to Log of commons-logger
> 
>  void trace(Object msg, Throwable thr, String className, String method);
>  void debug(Object msg, Throwable thr, String className, String method);
>  void info(Object msg, Throwable thr, String className, String method);
>  void warn(Object msg, Throwable thr, String className, String method);
>  void error(Object msg, Throwable thr, String className, String method);
>  void fatal(Object msg, Throwable thr, String className, String method);

I think there is a simpler solution for this class of problems, and 
that would also work with log4j and doesn't require _any_ API change.
( only changes to the adapter implementations )

Any 'wrapper' will use:
  factory=LogFactory.getFactory();
   
  factory.setAttribute( "commons-logging.wrapperClass", 
"[CLASSNAME-OF-WRAPPER]");
  factory.getLog(), etc.

The classname of wrapper will be passed to the impl..

 - for log4j - this just gets passed further, since log4j already supports 
this feature.
 - for jdk1.4 or other loggers who don't support wrapping - there is 
already code in Jdk14Logger that walks the stack trace. Curently it
uses a hard-coded '2 levels up', but it can use the wrapperClass
 and walk up to find it.


Costin


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

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 13:00, [EMAIL PROTECTED] wrote:
> I'm close to -1 on this patch.
> 
> I think the right long-term solution is to use commons-logging in
> all tomcat and jasper, and stop defining our interfaces.
> 
> I am +1 on fixing commons-logger, this will probably be
> usefull for other packages that switch to commons-logger.

I agree.  I originally implemented a commons-logger logger, but
the result wasn't very satisfying.  Mostly when the commons-logger
uses JDK1.4 it always shows my logger's class and method name.

This could be fixed by adding these methods to Log of commons-logger

 void trace(Object msg, Throwable thr, String className, String method);
 void debug(Object msg, Throwable thr, String className, String method);
 void info(Object msg, Throwable thr, String className, String method);
 void warn(Object msg, Throwable thr, String className, String method);
 void error(Object msg, Throwable thr, String className, String method);
 void fatal(Object msg, Throwable thr, String className, String method);

Although, the bigger problem is all the Loggers have unique features
and trying to squeeze them through the commons-logger API is going to
result in impedance mismatch.  Not sure what to do about this.

I can take stab at this little change (although it means touching
just about every class in commons-logging.)  Is it worth it?  Votes?

Cheers,
-bob




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

DO NOT REPLY [Bug 11047] New: - getRealPath is broken since Tomcat 4.0.4, worked in Tomcat 4.0.3

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

getRealPath is broken since Tomcat 4.0.4, worked in Tomcat 4.0.3

   Summary: getRealPath is broken since Tomcat 4.0.4, worked in
Tomcat 4.0.3
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Suppose you have a specified a context in server.xml like this:
...


...
If you run the following code inside a JSP file:
<%
ServletContext context = application.getContext("/images/");
out.println(context.getRealPath("/foo.jpg"));
%>
Tomcat 4.0.3 correctly returned:
D:\images\foo.jpg

But Tomcat 4.0.4 does now return: 
D:\wwwroot\foo.jpg

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

Re: JDK 1.4 Logging

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> I'm close to -1 on this patch.
> 
> I think the right long-term solution is to use commons-logging in
> all tomcat and jasper, and stop defining our interfaces.
> 
> I am +1 on fixing commons-logger, this will probably be
> usefull for other packages that switch to commons-logger.

I share Costin's opinion on the subject: Tomcat should switch (over 
time) to commons-logging, not the individual loggers which are supposed 
to be abstracted by commons-logging.

Remy


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

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 12:37, Remy Maucherat wrote:
> 
> Assuming people actually like the JDK 1.4 logger and think it's useful, 
> I like that solution better (there are flags, use them).

The JDK Logger is pretty cool. Although the default output is pretty
plain. I use it with my own formatter. My formatter is tweaked for
Tomcat - so it condenses some information and colorizes some
information.

This is a sample of its output,

http://hue.jadn.com:81/~bob/xdmp.png

My formatter is attached. It assumes an Xterm window sized to 175 or so.

Cheers,
-bob





package com.jadn;

import java.util.logging.Formatter;
import java.util.logging.Level;
import java.util.logging.LogRecord;
import java.util.Date;
import java.sql.Timestamp;

/*

 designed for a XTERM window of withd 175 (or so)


 INSTALL
 compile it
 jar it (ie. jar cf jadn.jar com/jadn/XTermFormatter.class)
 install it (cp jadn.jar $JAVA_HOME/jre/lib/ext/jadn.jar

 edit $JAVA_HOME/jre/lib/logging.properties  and comment out the SimpleFormatter
and add this one in,

#java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.ConsoleHandler.formatter = com.jadn.XTermFormatter

 enjoy
*/

public class XTermFormatter extends Formatter {
/*
	  0	Black
	  1	Red
	  2	Green
	  3	Yellow
	  4	Blue
	  5	Magenta
	  6	Cyan
	  7	White
*/

// colors foreground/background (for xterm)
private static final String RESET = "\033[0m"; 
private static final String BOLD  = "\033[1m";

private static final String BLACK_WHITE  = "\033[30;47m";
private static final String RED_WHITE= "\033[31;47m";
private static final String GREEN_WHITE  = "\033[32;47m";
private static final String YELLOW_WHITE = "\033[33;47m";
private static final String BLUE_WHITE   = "\033[34;47m";
private static final String PINK_WHITE   = "\033[35;47m";
private static final String LTGREEN_WHITE= "\033[36;47m";

public synchronized String format(LogRecord lr){
	StringBuffer sb = new StringBuffer();


	// --  LOG: LEVEL

	Level level = lr.getLevel();
	if ( level == level.SEVERE )
	sb.append( RED_WHITE );
	else if ( level == level.WARNING )
	sb.append( YELLOW_WHITE );
	else if ( level == level.INFO )
	sb.append( BOLD+GREEN_WHITE );
	else if ( level == level.CONFIG )
	sb.append( PINK_WHITE );
	else if ( level == level.FINE )
	sb.append( BLUE_WHITE );
	else 
	sb.append( BLACK_WHITE );

	fill( sb, level.toString(), 5 );
	sb.append( RESET );
	sb.append( " " );


	// --  LOG: TIME STAMP 

Timestamp ts = new Timestamp(lr.getMillis());
	// -mm-dd hh:mm:ss.f
	// 0123456789012345678
	//   1
sb.append( ts.toString().substring(11, 19) );



	// --  LOG: LOGGER DOMAIN (or name of logger)

	sb.append( " " );
	sb.append( PINK_WHITE );
	String lgName = lr.getLoggerName();
	if ( lgName.length()>15){
	sb.append( ">" );
	sb.append( lgName.substring(lgName.length()-14) );
	} else {
	fill(sb, lgName, 15);
	}
	sb.append( RESET );
	sb.append( " " );


	// --  LOG: SOURCE CLASS AND METHOD

	String cname = shorten(lr.getSourceClassName());

	int lastDot = cname.lastIndexOf('.');
	if ( lastDot == -1 ){
	cname=BLUE_WHITE+cname+RESET;
	} else {
	cname=cname.substring(0,lastDot)+BLUE_WHITE+cname.substring(lastDot)+RESET;
	}
	cname += "." + lr.getSourceMethodName();

	fill( sb, cname, 60 );
	sb.append( " " );



	// --  LOG: MESSAGE AND EXCEPTION

	sb.append( lr.getMessage() );
	if (lr.getThrown() != null ){
	sb.append( " " );
	sb.append( lr.getThrown() );
	}

sb.append("\n");
	return sb.toString();
}


// try and shorten known names
private String shorten(String cname){
	if ( cname.startsWith( "org.apache.catalina" ) )
	cname = "o.a.c"+cname.substring("org.apache.catalina".length());
	if ( cname.startsWith( "org.apache" ) )
	cname = "o.a"+cname.substring("org.apache".length());
	return cname;
}


// fill with spaces until supplied string reaches requested minLen 
// (longer strings are passed through without being chopped)
private void fill( StringBuffer sb, String toAdd, int minLen ){
	sb.append(toAdd);
	int fillTo = minLen - toAdd.length();
	while (fillTo-->0 )
	sb.append(" ");
}

}




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

Re: JDK 1.4 Logging

[costinm]

I'm close to -1 on this patch.

I think the right long-term solution is to use commons-logging in
all tomcat and jasper, and stop defining our interfaces.

I am +1 on fixing commons-logger, this will probably be
usefull for other packages that switch to commons-logger.


Costin


On 22 Jul 2002, Bob Herrmann wrote:

> 
> Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> 
> I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> calls to commons-logging Log.  This was unsatisfying because the
> commons-logger unrolls the stack and logs the "class.method" of my
> logger, not my logger's caller. 
> 
> I was tempted to change the commons-logger to allow for specifying
> a class and method on all its methods, but that would be a large
> change the commons-logger (involving changes and decisions about
> how this new information should be pushed down and handled with
> the other loggers it supports.)  There is also some issues mapping
> tomcat verbosity levels, to common-logger log levels and then to JDK
> Logger levels.
> 
> So I punted and implemented the code below.  It is a
> "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> It allowed me to unroll the stack in a way that fits well with
> tomcat (ignoring stack frames calling with method log() or method
> internalLog() which are uninteresting.)  And allowed me to map
> verbosity to JDK Levels.
> 
> Cheers,
> -bob
> 
> 
> 


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

Re: JDK 1.4 Logging

[Patrick Luby]

Bob,

That would work. I forgot that Remy now puts out a JDK 1.4 build of 
Tomcat and using the build flags would allow it to be picked up by users 
of the JDK 1.4 builds.

Patrick

Bob Herrmann wrote:
> Humm...  How about this instead (not that I am lazy)?
> 
> $ cvs diff -u catalina/build.xml
> Index: catalina/build.xml
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
> retrieving revision 1.124
> diff -u -r1.124 build.xml
> --- catalina/build.xml29 Jun 2002 01:00:04 -  1.124
> +++ catalina/build.xml22 Jul 2002 16:31:07 -
> @@ -801,6 +801,8 @@
> unless="jdk.1.3.present"/>
> unless="jdk.1.3.present"/>
> +   +   unless="jdk.1.4.present"/>
> unless="compile.jmx"/>
> name="org/apache/naming/factory/DbcpDataSourceFactory.java" 
> 
> 
> On Mon, 2002-07-22 at 12:28, Patrick Luby wrote:
> 
>>Bob,
>>
>>This is a useful piece of code. However, your patch can't go into Tomcat 
>>as it will only compile with JDK 1.4. The standard builds of Tomcat that 
>>are downloadable from the jakarta.apache.org are built using JDK 1.3 and 
>>should be run without crashing Tomcat on JDK 1.2.
>>
>>So, if you would like this in Tomcat (and I think it would be a nice 
>>optional logger implementation), I think that you need to do the following:
>>
>>1. Remove all of the following import statements and replace them with
>>reflection calls so that the JDK 1.3 compiler can compile this class:
>>
>>import java.util.logging.Logger;
>>import java.util.logging.Level;
>>import java.util.logging.Formatter;
>>import java.util.logging.Handler;
>>import java.util.logging.LogRecord;
>>
>>2. Catch any ClassNotFound and MethodNotFound exceptions that will occur
>>when the code is run on JDK 1.2 or 1.3.
>>
>>Patrick
>>
>>
>>
>>
>>Bob Herrmann wrote:
>>
>>>Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
>>>
>>>I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
>>>calls to commons-logging Log.  This was unsatisfying because the
>>>commons-logger unrolls the stack and logs the "class.method" of my
>>>logger, not my logger's caller. 
>>>
>>>I was tempted to change the commons-logger to allow for specifying
>>>a class and method on all its methods, but that would be a large
>>>change the commons-logger (involving changes and decisions about
>>>how this new information should be pushed down and handled with
>>>the other loggers it supports.)  There is also some issues mapping
>>>tomcat verbosity levels, to common-logger log levels and then to JDK
>>>Logger levels.
>>>
>>>So I punted and implemented the code below.  It is a
>>>"o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
>>>It allowed me to unroll the stack in a way that fits well with
>>>tomcat (ignoring stack frames calling with method log() or method
>>>internalLog() which are uninteresting.)  And allowed me to map
>>>verbosity to JDK Levels.
>>>
>>>Cheers,
>>>-bob
>>>
>>>
>>>
>>>
>>>
>>>
>>>/*
>>> * $Header: $
>>> * $Revision: $
>>> * $Date: $
>>> *
>>> * 
>>> *
>>> * The Apache Software License, Version 1.1
>>> *
>>> * Copyright (c) 1999 The Apache Software Foundation.  All rights
>>> * reserved.
>>> *
>>> * Redistribution and use in source and binary forms, with or without
>>> * modification, are permitted provided that the following conditions
>>> * are met:
>>> *
>>> * 1. Redistributions of source code must retain the above copyright
>>> *notice, this list of conditions and the following disclaimer.
>>> *
>>> * 2. Redistributions in binary form must reproduce the above copyright
>>> *notice, this list of conditions and the following disclaimer in
>>> *the documentation and/or other materials provided with the
>>> *distribution.
>>> *
>>> * 3. The end-user documentation included with the redistribution, if
>>> *any, must include the following acknowlegement:
>>> *   "This product includes software developed by the
>>> *Apache Software Foundation (http://www.apache.org/)."
>>> *Alternately, this acknowlegement may appear in the software itself,
>>> *if and wherever such third-party acknowlegements normally appear.
>>> *
>>> * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
>>> *Foundation" must not be used to endorse or promote products derived
>>> *from this software without prior written permission. For written
>>> *permission, please contact [EMAIL PROTECTED]
>>> *
>>> * 5. Products derived from this software may not be called "Apache"
>>> *nor may "Apache" appear in their names without prior written
>>> *permission of the Apache Group.
>>> *
>>> * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
>>> * WARRANTIES, INCL

Re: JDK 1.4 Logging

[Remy Maucherat]

Bob Herrmann wrote:
> Humm...  How about this instead (not that I am lazy)?
> 
> $ cvs diff -u catalina/build.xml
> Index: catalina/build.xml
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
> retrieving revision 1.124
> diff -u -r1.124 build.xml
> --- catalina/build.xml29 Jun 2002 01:00:04 -  1.124
> +++ catalina/build.xml22 Jul 2002 16:31:07 -
> @@ -801,6 +801,8 @@
> unless="jdk.1.3.present"/>
> unless="jdk.1.3.present"/>
> +   +   unless="jdk.1.4.present"/>
> unless="compile.jmx"/>
> name="org/apache/naming/factory/DbcpDataSourceFactory.java" 

Assuming people actually like the JDK 1.4 logger and think it's useful, 
I like that solution better (there are flags, use them).

Remy


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

Re: JDK 1.4 Logging

[Bob Herrmann]

Humm...  How about this instead (not that I am lazy)?

$ cvs diff -u catalina/build.xml
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.124
diff -u -r1.124 build.xml
--- catalina/build.xml  29 Jun 2002 01:00:04 -  1.124
+++ catalina/build.xml  22 Jul 2002 16:31:07 -
@@ -801,6 +801,8 @@
unless="jdk.1.3.present"/>
   
+  
   
Bob,
> 
> This is a useful piece of code. However, your patch can't go into Tomcat 
> as it will only compile with JDK 1.4. The standard builds of Tomcat that 
> are downloadable from the jakarta.apache.org are built using JDK 1.3 and 
> should be run without crashing Tomcat on JDK 1.2.
> 
> So, if you would like this in Tomcat (and I think it would be a nice 
> optional logger implementation), I think that you need to do the following:
> 
> 1. Remove all of the following import statements and replace them with
> reflection calls so that the JDK 1.3 compiler can compile this class:
> 
> import java.util.logging.Logger;
> import java.util.logging.Level;
> import java.util.logging.Formatter;
> import java.util.logging.Handler;
> import java.util.logging.LogRecord;
> 
> 2. Catch any ClassNotFound and MethodNotFound exceptions that will occur
> when the code is run on JDK 1.2 or 1.3.
> 
> Patrick
> 
> 
> 
> 
> Bob Herrmann wrote:
> > Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> > 
> > I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> > calls to commons-logging Log.  This was unsatisfying because the
> > commons-logger unrolls the stack and logs the "class.method" of my
> > logger, not my logger's caller. 
> > 
> > I was tempted to change the commons-logger to allow for specifying
> > a class and method on all its methods, but that would be a large
> > change the commons-logger (involving changes and decisions about
> > how this new information should be pushed down and handled with
> > the other loggers it supports.)  There is also some issues mapping
> > tomcat verbosity levels, to common-logger log levels and then to JDK
> > Logger levels.
> > 
> > So I punted and implemented the code below.  It is a
> > "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> > It allowed me to unroll the stack in a way that fits well with
> > tomcat (ignoring stack frames calling with method log() or method
> > internalLog() which are uninteresting.)  And allowed me to map
> > verbosity to JDK Levels.
> > 
> > Cheers,
> > -bob
> > 
> > 
> > 
> > 
> > 
> > 
> > /*
> >  * $Header: $
> >  * $Revision: $
> >  * $Date: $
> >  *
> >  * 
> >  *
> >  * The Apache Software License, Version 1.1
> >  *
> >  * Copyright (c) 1999 The Apache Software Foundation.  All rights
> >  * reserved.
> >  *
> >  * Redistribution and use in source and binary forms, with or without
> >  * modification, are permitted provided that the following conditions
> >  * are met:
> >  *
> >  * 1. Redistributions of source code must retain the above copyright
> >  *notice, this list of conditions and the following disclaimer.
> >  *
> >  * 2. Redistributions in binary form must reproduce the above copyright
> >  *notice, this list of conditions and the following disclaimer in
> >  *the documentation and/or other materials provided with the
> >  *distribution.
> >  *
> >  * 3. The end-user documentation included with the redistribution, if
> >  *any, must include the following acknowlegement:
> >  *   "This product includes software developed by the
> >  *Apache Software Foundation (http://www.apache.org/)."
> >  *Alternately, this acknowlegement may appear in the software itself,
> >  *if and wherever such third-party acknowlegements normally appear.
> >  *
> >  * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
> >  *Foundation" must not be used to endorse or promote products derived
> >  *from this software without prior written permission. For written
> >  *permission, please contact [EMAIL PROTECTED]
> >  *
> >  * 5. Products derived from this software may not be called "Apache"
> >  *nor may "Apache" appear in their names without prior written
> >  *permission of the Apache Group.
> >  *
> >  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
> >  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> >  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> >  * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
> >  * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> >  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> >  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOS

Re: JDK 1.4 Logging

[Patrick Luby]

Bob,

This is a useful piece of code. However, your patch can't go into Tomcat 
as it will only compile with JDK 1.4. The standard builds of Tomcat that 
are downloadable from the jakarta.apache.org are built using JDK 1.3 and 
should be run without crashing Tomcat on JDK 1.2.

So, if you would like this in Tomcat (and I think it would be a nice 
optional logger implementation), I think that you need to do the following:

1. Remove all of the following import statements and replace them with
reflection calls so that the JDK 1.3 compiler can compile this class:

import java.util.logging.Logger;
import java.util.logging.Level;
import java.util.logging.Formatter;
import java.util.logging.Handler;
import java.util.logging.LogRecord;

2. Catch any ClassNotFound and MethodNotFound exceptions that will occur
when the code is run on JDK 1.2 or 1.3.

Patrick




Bob Herrmann wrote:
> Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> 
> I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> calls to commons-logging Log.  This was unsatisfying because the
> commons-logger unrolls the stack and logs the "class.method" of my
> logger, not my logger's caller. 
> 
> I was tempted to change the commons-logger to allow for specifying
> a class and method on all its methods, but that would be a large
> change the commons-logger (involving changes and decisions about
> how this new information should be pushed down and handled with
> the other loggers it supports.)  There is also some issues mapping
> tomcat verbosity levels, to common-logger log levels and then to JDK
> Logger levels.
> 
> So I punted and implemented the code below.  It is a
> "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> It allowed me to unroll the stack in a way that fits well with
> tomcat (ignoring stack frames calling with method log() or method
> internalLog() which are uninteresting.)  And allowed me to map
> verbosity to JDK Levels.
> 
> Cheers,
> -bob
> 
> 
> 
> 
> 
> 
> /*
>  * $Header: $
>  * $Revision: $
>  * $Date: $
>  *
>  * 
>  *
>  * The Apache Software License, Version 1.1
>  *
>  * Copyright (c) 1999 The Apache Software Foundation.  All rights
>  * reserved.
>  *
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions
>  * are met:
>  *
>  * 1. Redistributions of source code must retain the above copyright
>  *notice, this list of conditions and the following disclaimer.
>  *
>  * 2. Redistributions in binary form must reproduce the above copyright
>  *notice, this list of conditions and the following disclaimer in
>  *the documentation and/or other materials provided with the
>  *distribution.
>  *
>  * 3. The end-user documentation included with the redistribution, if
>  *any, must include the following acknowlegement:
>  *   "This product includes software developed by the
>  *Apache Software Foundation (http://www.apache.org/)."
>  *Alternately, this acknowlegement may appear in the software itself,
>  *if and wherever such third-party acknowlegements normally appear.
>  *
>  * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
>  *Foundation" must not be used to endorse or promote products derived
>  *from this software without prior written permission. For written
>  *permission, please contact [EMAIL PROTECTED]
>  *
>  * 5. Products derived from this software may not be called "Apache"
>  *nor may "Apache" appear in their names without prior written
>  *permission of the Apache Group.
>  *
>  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
>  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
>  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
>  * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
>  * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>  * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>  * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
>  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
>  * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>  * SUCH DAMAGE.
>  * 
>  *
>  * This software consists of voluntary contributions made by many
>  * individuals on behalf of the Apache Software Foundation.  For more
>  * information on the Apache Software Foundation, please see
>  * .
>  *
>  * [Additional notices, if required by prior licensing conditions]
>  *
>  */

RE: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 12:12, David Oxley wrote:
> Why does Tomcat not use Log4j for its logging?

Some parts of Tomcat do use Log4j, other parts do not.  I think
this is because different people have just chosen whatever
they felt was handy.   Tomcat doesn't yet have a unified logging
strategy.  I originally tried to use "commons-logging" as my
back-end and it can be configured to use Log4j, but as I described -
the result was unsatisfying.

Read this earlier thread on this topic,

 http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg28257.html


Cheers,
-bob

> 
> Dave.
> 
> > -Original Message-
> > From: Bob Herrmann [mailto:[EMAIL PROTECTED]]
> > Sent: 22 July 2002 15:51
> > To: Tomcat Developers List
> > Subject: JDK 1.4 Logging
> > 
> > 
> > Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> > 
> > I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> > calls to commons-logging Log.  This was unsatisfying because the
> > commons-logger unrolls the stack and logs the "class.method" of my
> > logger, not my logger's caller.
> > 
> > I was tempted to change the commons-logger to allow for specifying
> > a class and method on all its methods, but that would be a large
> > change the commons-logger (involving changes and decisions about
> > how this new information should be pushed down and handled with
> > the other loggers it supports.)  There is also some issues mapping
> > tomcat verbosity levels, to common-logger log levels and then to JDK
> > Logger levels.
> > 
> > So I punted and implemented the code below.  It is a
> > "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> > It allowed me to unroll the stack in a way that fits well with
> > tomcat (ignoring stack frames calling with method log() or method
> > internalLog() which are uninteresting.)  And allowed me to map
> > verbosity to JDK Levels.
> > 
> > Cheers,
> > -bob
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



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

DO NOT REPLY [Bug 11045] - Jikes compiler output appears in catalina.out not browser

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

Jikes compiler output appears in catalina.out not browser

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-22 16:14 ---
This will not be fixed, as Jikes is run in a separate process, making it very
difficult to capture the output.

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

RE: JDK 1.4 Logging

[David Oxley]

Why does Tomcat not use Log4j for its logging?

Dave.

> -Original Message-
> From: Bob Herrmann [mailto:[EMAIL PROTECTED]]
> Sent: 22 July 2002 15:51
> To: Tomcat Developers List
> Subject: JDK 1.4 Logging
> 
> 
> Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> 
> I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> calls to commons-logging Log.  This was unsatisfying because the
> commons-logger unrolls the stack and logs the "class.method" of my
> logger, not my logger's caller.
> 
> I was tempted to change the commons-logger to allow for specifying
> a class and method on all its methods, but that would be a large
> change the commons-logger (involving changes and decisions about
> how this new information should be pushed down and handled with
> the other loggers it supports.)  There is also some issues mapping
> tomcat verbosity levels, to common-logger log levels and then to JDK
> Logger levels.
> 
> So I punted and implemented the code below.  It is a
> "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> It allowed me to unroll the stack in a way that fits well with
> tomcat (ignoring stack frames calling with method log() or method
> internalLog() which are uninteresting.)  And allowed me to map
> verbosity to JDK Levels.
> 
> Cheers,
> -bob
> 


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

DO NOT REPLY [Bug 11045] - Jikes compiler output appears in catalina.out not browser

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

Jikes compiler output appears in catalina.out not browser





--- Additional Comments From [EMAIL PROTECTED]  2002-07-22 15:40 ---
Created an attachment (id=2436)
Extract of catalina.out, and browser output

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

DO NOT REPLY [Bug 11045] New: - Jikes compiler output appears in catalina.out not browser

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

Jikes compiler output appears in catalina.out not browser

   Summary: Jikes compiler output appears in catalina.out not
browser
   Product: Tomcat 4
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using Jasper2, you specify use of Jikes by adding to the jsp servlet  an 
init-param with a name of compiler and a value of one of the suppoted compiler 
names, jikes being the most obvious. Jasper2 recognizes this, but the output
from the compiler when there are error messages appears in catalina.out
instead of in the user's browser.

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

DO NOT REPLY [Bug 11043] New: - ServletContextListener

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

ServletContextListener

   Summary: ServletContextListener
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when the root path is set to something other than "ROOT" in server.xml, it
results in two copies of the same ServletContextListener. This is easily
verified by changing the "ROOT" path to something else and starting tomcat. I
haven't verified this against 4.0.4, but the same thing happens with tomcat
4.1.7 beta.

I can duplicate this every time by changing my root directory in server.xml

peter lin

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

DO NOT REPLY [Bug 10629] - include directive fails when referencing Parent Path within a WAR

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

include directive fails when referencing Parent Path within a WAR





--- Additional Comments From [EMAIL PROTECTED]  2002-07-22 15:21 ---
This bug has been marked as a duplicate of 10711, which has been marked as
RESOLVED FIXED; however it seems to me that the fix for 10711 only addresses the
issue of an included JSP file, not an HTML or text file. 

Isn't a change to getResourceAsStream and getResource needed? (Or to WARDirContext?)

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

DO NOT REPLY [Bug 11042] New: - Misleading comment in server.xml

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

Misleading comment in server.xml

   Summary: Misleading comment in server.xml
   Product: Tomcat 4
   Version: 4.1.7
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In server.xml is stated that:

That is wrong. If I specify -1 as timeout tomcat generates exception "socket 
timeout cannot be negative" on JDK 1.4. To disable connection timeout user have 
to specify 0. It is stated in JDK 1.4 java.net.Socket setSoTimeout. I test it - 
it works. I think that is applicable for all versions, all connectors etc. So, 
for every server.xml working on JDK 1.4

Thank you for wonderful software (Tomcat). Such a minor things in general does 
not count at all, but, please, correct it.

Timofei Bolshakov.

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

JDK 1.4 Logging

[Bob Herrmann]

Hi.  I am trying to get Tomcat to log to JDK1.4's logging.

I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
calls to commons-logging Log.  This was unsatisfying because the
commons-logger unrolls the stack and logs the "class.method" of my
logger, not my logger's caller. 

I was tempted to change the commons-logger to allow for specifying
a class and method on all its methods, but that would be a large
change the commons-logger (involving changes and decisions about
how this new information should be pushed down and handled with
the other loggers it supports.)  There is also some issues mapping
tomcat verbosity levels, to common-logger log levels and then to JDK
Logger levels.

So I punted and implemented the code below.  It is a
"o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
It allowed me to unroll the stack in a way that fits well with
tomcat (ignoring stack frames calling with method log() or method
internalLog() which are uninteresting.)  And allowed me to map
verbosity to JDK Levels.

Cheers,
-bob




/*
 * $Header: $
 * $Revision: $
 * $Date: $
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * .
 *
 * [Additional notices, if required by prior licensing conditions]
 *
 */


package org.apache.catalina.logger;

import java.sql.Timestamp;

import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;

import java.util.logging.Logger;
import java.util.logging.Level;
import java.util.logging.Formatter;
import java.util.logging.Handler;
import java.util.logging.LogRecord;


/**
 * Implementation of Logger that sends log messages to the
 * Jdk logger 
 *
 * @version $Revision: $ $Date: $
 */

public class JdkLogger
extends LoggerBase
implements Lifecycle {


// - Instance Variables


/**
 * The descriptive information about this implementation.
 */
protected static final String info =
"org.apache.catalina.logger.JdkLogger/1.0";

/**
 * The lifecycle event support for this component.
 */
protected LifecycleSupport lifecycle = new LifecycleSupport(this);

/**
 * The string manager for this package.
 */
pr

DO NOT REPLY [Bug 10711] - [PATCH] relative filenames with ../ do not work for JSP-includes

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

[PATCH] relative filenames with ../ do not work for JSP-includes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-07-22 14:19 ---
*** Bug 10629 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 10629] - include directive fails when referencing Parent Path within a WAR

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

include directive fails when referencing Parent Path within a WAR

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|Catalina|Jasper 2
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-07-22 14:19 ---
This should be resolved in Jasper (and a canonical path should be passed to the
getResource method IMO).
This should be fixed in Tomcat 4.1.8.

*** This bug has been marked as a duplicate of 10711 ***

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

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

[costinm]

On Sun, 21 Jul 2002, Bill Barker wrote:

> At the moment, the servlet-mapping issue is somewhat of a red-herring, since
> only 3.3.2-dev supports it (and even there, it is disabled by default).  For
> now, mod_jk(2) might as well assume that the physical jsp/vm file is there,
> since Tomcat requires that it is.  The real issue is that jk_map_to_storage

I'm beginning to doubt the spec can be implemented - I just can't find 
any reasonable way to deal with extensions mapping.

Yes, I know tomcat doesn't implement it very well either. 

> I *really* don't like the idea of passing DIR_MAGIC_TYPE requests to Tomcat,
> since I tend to set up directories with only static content that only Apache
> knows about.  Sending them to Tomcat just gives me very many 404 errors, so

Not all DIR_MAGIC_TYPE, only those that belong to a webapplication.

And possibly based on some option to enable/disable this behavior.


Costin


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

DO NOT REPLY [Bug 10629] - include directive fails when referencing Parent Path within a WAR

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

include directive fails when referencing Parent Path within a WAR





--- Additional Comments From [EMAIL PROTECTED]  2002-07-22 14:05 ---
Fixing this bug is particularly important when using Tomcat with JBoss, as JBoss
currently (3.0.0) does not provide a way to unpack the WARs.

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

Re: webapp

[peter lin]

I figured out why I was getting null back from
SERVLETCONTEXT.getServletContextName(), my web.xml file didn't have the
name defined. Now that I have it in there,
I see the event fired twice for my webapp.

Is that a bug? From what I can tell, it is creating the webapp twice. 
If I print out event.getSource() the objects are different.  Can someone
verify if this is a bug?


peter lin


peter lin wrote:
> 
> Does anyone know how to get the webapp name from ServletContext?  Here
> is a quick description of what i am trying to do.
> 
> I have a webapp that i want to load when tomcat starts. I want to make
> sure the webapp only starts for one webapp and not the others.
> 
> I wrote a test class that implements
> javax.servlet.ServletContextListener. What I'm seeing is the event is
> fired twice and therefore loading the app twice.  It seems a bit weird
> to have the event fire twice.  My test Listener checks to make sure the
> app isn't already in the ServletContext before creating it.  I have the
> root path set to specific path in server.xml.
> 
> thanks in advance.
> 
> peter lin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

webapp name question?

[peter lin]

Does anyone know how to get the webapp name from ServletContext?  Here
is a quick description of what i am trying to do.

I have a webapp that i want to load when tomcat starts. I want to make
sure the webapp only starts for one webapp and not the others.

I wrote a test class that implements
javax.servlet.ServletContextListener. What I'm seeing is the event is
fired twice and therefore loading the app twice.  It seems a bit weird
to have the event fire twice.  My test Listener checks to make sure the
app isn't already in the ServletContext before creating it.  I have the
root path set to specific path in server.xml.

thanks in advance.


peter lin

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

webapp

[peter lin]

Does anyone know how to get the webapp name from ServletContext?  Here
is a quick description of what i am trying to do.

I have a webapp that i want to load when tomcat starts. I want to make
sure the webapp only starts for one webapp and not the others.

I wrote a test class that implements
javax.servlet.ServletContextListener. What I'm seeing is the event is
fired twice and therefore loading the app twice.  It seems a bit weird
to have the event fire twice.  My test Listener checks to make sure the
app isn't already in the ServletContext before creating it.  I have the
root path set to specific path in server.xml.

thanks in advance.


peter lin

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

[GUMP] Build Failure - jakarta-tomcat-4.0

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

deploy-prepare:

deploy-static:

deploy:
 [echo] Target: Catalina - Deploy ...

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=only
 [echo] compile.debug=${compile.debug}
 [echo] compile.deprecation=${compile.deprecation}
 [echo] compile.optimize=${compile.optimize}
 [echo] --- Ant Flags ---
 [echo] 

DO NOT REPLY [Bug 11026] - After days' running, Apache Tomcat deny offer service.

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

After days' running, Apache Tomcat deny offer service.





--- Additional Comments From [EMAIL PROTECTED]  2002-07-22 07:23 ---
Code:
URL u = new URL(url);
URLConnection uc = u.openConnection();
uc.setDoOutput(true);
OutputStream os = uc.getOutputStream();
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(os));
bw.write(req);
bw.flush();
bw.close();
os.close();
InputStream is = uc.getInputStream(); //error occurs here
Document d = null;

Error message:
Apache Tomcat/4.0.4 - HTTP Status 500 - Internal Server Error



type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server Error) 
that prevented it from fulfilling this request.

exception 

java.io.IOException: Server returned HTTP response code: 500 for URL: 
http://abel:8080/exam/admin
at sun.net.www.protocol.http.HttpURLConnection.getInputStream
(HttpURLConnection.java:691)
at exam.AdminObj.getUrlResp(AdminObj.java:60)
at org.apache.jsp.exam_0005ftype_0005frese$jsp._jspService
(exam_0005ftype_0005frese$jsp.java:110)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service
(JspServlet.java:201)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:381)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.CertificatesValve.invoke
(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2347)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:468)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1027)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:536)





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