Re: Web apps vs. Logging vs. Tomcat

[Jess Holle]

Bill Barker wrote:
You just need to provide the methods (if you wanted to code against
Catalina, you'd just create a LifecycleListener :).  This is a hook into
commons-modeler, so you technically could use a plain old JavaBean.
Otherwise, DynamicMBeans probably work best (or, at least give you the most
control).
 

I have gotten used to using my own subclasses to StandardMBean.  This 
allows me to lay out the "static" portion of my MBean with an interface 
and extend it as necessary -- adding dynamic and open MBean behaviors as 
necessary in my own classes.

Java 1.5's APT turns out to make automated generation of MBean 
descriptions, operation parameter names, impacts, etc, from MBean 
interface Javadoc, formal parmeter names, annotations, etc, quite 
simple.  A little more elbow grease and the descriptions are localized 
(based on the server's locale).

--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Jess Holle]

Remy Maucherat wrote:
Jess Holle wrote:
Why out of curiosity?  I don't have a pro-UGLI ax to grind here, but 
Commons-Logging's behavior in Tomcat is really undesirable as is.
It would be the same anyway: the loading configuration and the logger 
instances will be tied to the webapp classloader. It has to work this 
way. As I understand it, the thing that does not work for you right 
now is that Tomcat uses your webapp's logger namespace before your 
callbacks are called.
Yes.  The issue is really that Tomcat uses log4j out of my web app for 
loggers that are to be used outside my web app.  Not only is the library 
used out of my web app but so is the configuration -- meaning web app A 
gets core Tomcat log output from web apps B and C...

Yoav confirmed that the solution is to move log4j and a default 
configuration higher in the stack so that everything uses it.  This 
together with a per-web-app ClassLoader (but not contextual 
classloader!) based LoggerRepository will ensure each web app gets its 
own loggers and configuration files and Tomcat core gets its own.

Now if you're inside JBoss and it has pre-established log4j and 
configured it prior to Tomcat loading, then I don't see a problem 
with Commons Logging.  Standalone Tomcat's Commons Logging behavior 
vis-a-vis log4j would seem to be an issue, though.  The issues are 
especially bad and bizarre when log4j is used in a web app but Tomcat 
itself does not have log4j installed, but this is only part of the 
issue.
I don't see any real difference. There should be plenty of container 
listeners and stuff available to configure this.
(I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue 
what it is)
The nice thing about this as I understand it is that it would allow me 
to set up my own MBeans for a Tomcat-level / app-wide log4j 
LoggerRepository.

You're right, though, as far as per-web-app MBeans and 
LoggerRepository's -- there are more than enough servlet listeners, etc, 
in the servlet spec to handle this.

BTW, JBoss (supposedly, I didn't check personally) uses 
commons-logging everywhere, and the logging implementation used is log4j.
That works since *everything* uses log4j.  The issue is with Tomcat is 
really one of *not* having log4j at the Tomcat level but having it in 
your web app.  This leads to:

   * whole crop of loggers using java.util.logging (fine, to be
 expected, and there are Java 5 MBeans -- albeit limited -- to
 interact with these)
   * a few core Tomcat loggers that are *not* by nature per web app
 loggers using the log4j jar and configuration of the first web app
 that uses the class enclosing them (e.g. the first web app to get
 a request!)
   * the web app's own classes using whatever you specify
It is the 2nd of these 3 bullet that is so disturbing to me.  I'd like 
to see these either have separate loggers for each web app, or behave 
like the rest the Tomcat loggers and cause a leak of data and references 
between web apps.  This -- and a reasonable set of MBeans to 
control/expose loggers seems quite doable with the approach Yoav and 
Bill laid out.  It's just unfortunate that the out-of-the-box behavior 
with web apps using log4j is so onerous.

--
Jess Holle

RE: Web apps vs. Logging vs. Tomcat

[Yoav Shapira]

Hi,

> Yoav Shapira wrote:
> > UGLI is far from mature enough to be used by Tomcat at this point.  When
> > log4j 1.3 is out, we'll see.
> 
> I already voted on that: -1.
> 
> Rémy

Yup, I know.  I'm holding out for the possibility that UGLI will be a good
enough solution and a significant enough improvement of JCL to merit
re-consideration at some future time.

As I said, it's not something I'm pushing now, as the above is far (on the
time scale) from happening.

Yoav


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bernhard Kluschat/EZW/EN01 ist außer Haus.

[Bernhard . Kluschat]

Ich werde ab  18.03.2005 nicht im Büro sein. Ich kehre zurück am
04.04.2005.

Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

In dringenden Fällen wenden Sie sich bitte an meinen Kollegen
 Rolf-Dieter Gross, Tel.: 02056/ 259-5440
e-mail:[EMAIL PROTECTED]
oder erreichen mich unter Mobil: 0172 745 81 45




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Bill Barker]

- Original Message -
From: "Jess Holle" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Thursday, March 17, 2005 3:12 PM
Subject: Re: Web apps vs. Logging vs. Tomcat


> Bill Barker wrote:
>
> >- Original Message -
> >From: "Jess Holle" <[EMAIL PROTECTED]>
> >To: "Tomcat Developers List" 
> >Sent: Thursday, March 17, 2005 2:25 PM
> >Subject: Re: Web apps vs. Logging vs. Tomcat
> >
> >
> >>Just one more stupid question:
> >>
> >>How/where would I register/deregister (start/stop) MBeans at the
> >>Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
> >>than in my ServletContextListener?
> >>
> >>
> >
> >Sounds like a good use for conf/tomcat5-mbeans.xml.  It invokes the
standard
> >Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your
MBeans
> >at the corresponding points of the Engine's Lifecycle, as well as
handling
> >JMX registration and un-registration.
> >
> >
> Cool!  Thanks!
>
> Do I have to actually implement Lifecycle or just provide these
> methods?  Will a standard/dynamic MBean do or does it have to be a model
> MBean?  [Mine extend StandardMBean and implement MBeanRegistration at
> the moment.]
>

You just need to provide the methods (if you wanted to code against
Catalina, you'd just create a LifecycleListener :).  This is a hook into
commons-modeler, so you technically could use a plain old JavaBean.
Otherwise, DynamicMBeans probably work best (or, at least give you the most
control).

> --
> Jess Holle
>
>



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[Jean-Jacques Clar]

Greetings,
As Norm did, I was able to build and test against 2.1.4 beta and 2.0.52
for NetWare.
I ran load testing against 1.2.9dev today with 400 virtual clients
requesting JSPs and Servlets on a dual proc p4 with HT enabled. 
It is looking solid. The test will run overnight.
 
I will find time tomorrow to look at the 1.3 issues, I did not build
for 1.3 since jk1.2.8.
 
Regards,
JJ

>>> [EMAIL PROTECTED] 3/17/2005 1:26:49 PM >>>

Greetings All,
Still get a clean build for NetWare against Apache 2.1 and 2.0.53.
The XML pages work fine, although the HTML status pages might put the 
numbers under headings better if 'border=1' was enabled.
AFAIK builds for Apache 1.1.3 for NetWare still has issues, since I've

not seen mention of updates for that version. Perhaps JJC can comment?

Regards,
Norm


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Remy Maucherat]

Jess Holle wrote:
Why out of curiosity?  I don't have a pro-UGLI ax to grind here, but 
Commons-Logging's behavior in Tomcat is really undesirable as is.
It would be the same anyway: the loading configuration and the logger 
instances will be tied to the webapp classloader. It has to work this 
way. As I understand it, the thing that does not work for you right now 
is that Tomcat uses your webapp's logger namespace before your callbacks 
are called.

Now if you're inside JBoss and it has pre-established log4j and 
configured it prior to Tomcat loading, then I don't see a problem with 
Commons Logging.  Standalone Tomcat's Commons Logging behavior vis-a-vis 
log4j would seem to be an issue, though.  The issues are especially bad 
and bizarre when log4j is used in a web app but Tomcat itself does not 
have log4j installed, but this is only part of the issue.
I don't see any real difference. There should be plenty of container 
listeners and stuff available to configure this.
(I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue 
what it is)

BTW, JBoss (supposedly, I didn't check personally) uses commons-logging 
everywhere, and the logging implementation used is log4j.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Jess Holle]

Bill Barker wrote:
- Original Message -
From: "Jess Holle" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Thursday, March 17, 2005 2:25 PM
Subject: Re: Web apps vs. Logging vs. Tomcat
 

Just one more stupid question:
   How/where would I register/deregister (start/stop) MBeans at the
   Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
   than in my ServletContextListener?
   

Sounds like a good use for conf/tomcat5-mbeans.xml.  It invokes the standard
Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans
at the corresponding points of the Engine's Lifecycle, as well as handling
JMX registration and un-registration.
 

Cool!  Thanks!
Do I have to actually implement Lifecycle or just provide these 
methods?  Will a standard/dynamic MBean do or does it have to be a model 
MBean?  [Mine extend StandardMBean and implement MBeanRegistration at 
the moment.]

--
Jess Holle

Re: Web apps vs. Logging vs. Tomcat

[Bill Barker]

- Original Message -
From: "Jess Holle" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Thursday, March 17, 2005 2:25 PM
Subject: Re: Web apps vs. Logging vs. Tomcat


> Just one more stupid question:
>
> How/where would I register/deregister (start/stop) MBeans at the
> Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
> than in my ServletContextListener?
>

Sounds like a good use for conf/tomcat5-mbeans.xml.  It invokes the standard
Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans
at the corresponding points of the Engine's Lifecycle, as well as handling
JMX registration and un-registration.

> For per-web-app MBeans, I can use ServletContextListener, of course,
> but given that log4j loggers are not JMX-exposed, I'd like to put
> some MBeans to do this up at the Tomcat application level.  I do
> this in my web app, but I'd like to have the Tomcat-level MBeans
> installed even without any of my web apps installed.
>
> --
> Jess Holle
>
> Yoav Shapira wrote:
>
> >Hola,
> >Your approach is right and should work.  You basically have to move
> >everything up the classloader hierarchy into Tomcat's section, and have a
> >copy of the MBean stuff in each webapp classloader repository that you
want
> >to manage.
> >
> >And I agree that it sucks...
> >
> >Yoav
> >
> >
> >
> >>-Original Message-
> >>From: Jess Holle [mailto:[EMAIL PROTECTED]
> >>Sent: Thursday, March 17, 2005 4:30 PM
> >>To: Tomcat Developers List
> >>Subject: Re: Web apps vs. Logging vs. Tomcat
> >>
> >>Thanks.  That answers that part of the question quite succinctly.
> >>
> >>Now what remains is how can I work with log4j and commons logging --
> >>commons logging's behavior vis-a-vis the contextual classloader seems
> >>onerous if not just plain wrong.
> >>
> >>The only way I can see to "fix" this is to deploy log4j in Tomcat's own
> >>lib directories -- and deploy my log4j controller MBeans there for the
> >>default LoggeRepository and again in each web app for each web app's
> >>LoggerRepository.
> >>
> >>If that's what I need to do, I'll get on with doing it, but I'd like to
> >>know I'm not just overlooking the obvious...
> >>
> >>--
> >>Jess Holle
> >>
> >>Yoav Shapira wrote:
> >>
> >>
> >>
> >>>UGLI is far from mature enough to be used by Tomcat at this point.
When
> >>>log4j 1.3 is out, we'll see.
> >>>
> >>>Yoav
> >>>
> >>>
> >>>
> >>>
> -Original Message-
> From: Jess Holle [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 17, 2005 4:17 PM
> To: Tomcat Developers List
> Subject: Re: Web apps vs. Logging vs. Tomcat
> 
> P.S.  Why does Tomcat use Commons Logging rather than UGLI?
> 
> Jess Holle wrote:
> 
> 
> 
> 
> 
> >I had e-mailed this to users mailing list, but I have what I believe
> >is a more "dev" follow-on question:
> >
> >  Is there a good way to get my own start/stop action called at a
> >  per-VM level?
> >
> >  This is assuming I end up having to move log4j up into Tomcat's
> >  classloaders -- at which point I'll want to install my
> >  LoggerRepository controlling MBeans up at this level as well -- as
> >  log4j's MBeans have issues and using log4j loggers means you don't
> >  get the (admittedly sparse) java.util.logging MBean coverage.
> >
> >--
> >Jess Holle
> >
> >Jess Holle wrote:
> >
> >
> >
> >
> >
> >>I have been trying to get really serious about log4j in web apps.
> >>
> >>I note that Tomcat (thanks to commons-logging) uses
java.util.logging
> >>*except* for loggers created while my web app's classloader is the
> >>current contextual classloader -- at which point it suddenly uses
> >>log4j (since my web app does) without giving my web app a chance to
> >>initialize it in any way as best I can tell.
> >>
> >>My web app has a ServletContextListener which initializes log4j by
> >>setting up its own LoggerRepository, configuration file and watcher
> >>(since log4j's won't shutdown), etc.  Of course, every Tomcat logger
> >>created within my web app up until this point is now using log4j
from
> >>my web app (!) and using the basic log4j.properties [if present]
from
> >>my web app -- for loggers that apply to all web apps!
> >>
> >>How is one supposed to work this?  I am currently using a static
> >>LoggerRepository reference within my web app so that a log4j loaded
> >>higher in the classloader tree won't cause LoggerRepository sharing.
> >>I was using a JNDI-based LoggerRepositorySelector as per log4j
author
> >>recommendations, but this goes a step further than above -- it puts
> >>all the Tomcat loggers that are errantly using my log4j into my
> >>LoggerRepository -- which would be fine if these loggers were not
> >>shared with other web apps.
> >>
> >>What's the solution h

DO NOT REPLY [Bug 20752] - Soft links to jars in a webapp causes IllegalArgumentException

[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://issues.apache.org/bugzilla/show_bug.cgi?id=20752


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20752] - Soft links to jars in a webapp causes IllegalArgumentException

[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://issues.apache.org/bugzilla/show_bug.cgi?id=20752


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version||All




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 23:40 ---
You need to use the allowLinking property. See
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/resources.html

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Jess Holle]

Just one more stupid question:
   How/where would I register/deregister (start/stop) MBeans at the
   Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
   than in my ServletContextListener?
   For per-web-app MBeans, I can use ServletContextListener, of course,
   but given that log4j loggers are not JMX-exposed, I'd like to put
   some MBeans to do this up at the Tomcat application level.  I do
   this in my web app, but I'd like to have the Tomcat-level MBeans
   installed even without any of my web apps installed.
--
Jess Holle
Yoav Shapira wrote:
Hola,
Your approach is right and should work.  You basically have to move
everything up the classloader hierarchy into Tomcat's section, and have a
copy of the MBean stuff in each webapp classloader repository that you want
to manage.
And I agree that it sucks...
Yoav
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 4:30 PM
To: Tomcat Developers List
Subject: Re: Web apps vs. Logging vs. Tomcat
Thanks.  That answers that part of the question quite succinctly.
Now what remains is how can I work with log4j and commons logging --
commons logging's behavior vis-a-vis the contextual classloader seems
onerous if not just plain wrong.
The only way I can see to "fix" this is to deploy log4j in Tomcat's own
lib directories -- and deploy my log4j controller MBeans there for the
default LoggeRepository and again in each web app for each web app's
LoggerRepository.
If that's what I need to do, I'll get on with doing it, but I'd like to
know I'm not just overlooking the obvious...
--
Jess Holle
Yoav Shapira wrote:
   

UGLI is far from mature enough to be used by Tomcat at this point.  When
log4j 1.3 is out, we'll see.
Yoav
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 4:17 PM
To: Tomcat Developers List
Subject: Re: Web apps vs. Logging vs. Tomcat
P.S.  Why does Tomcat use Commons Logging rather than UGLI?
Jess Holle wrote:

   

I had e-mailed this to users mailing list, but I have what I believe
is a more "dev" follow-on question:
 Is there a good way to get my own start/stop action called at a
 per-VM level?
 This is assuming I end up having to move log4j up into Tomcat's
 classloaders -- at which point I'll want to install my
 LoggerRepository controlling MBeans up at this level as well -- as
 log4j's MBeans have issues and using log4j loggers means you don't
 get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:

 

I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging
*except* for loggers created while my web app's classloader is the
current contextual classloader -- at which point it suddenly uses
log4j (since my web app does) without giving my web app a chance to
initialize it in any way as best I can tell.
My web app has a ServletContextListener which initializes log4j by
setting up its own LoggerRepository, configuration file and watcher
(since log4j's won't shutdown), etc.  Of course, every Tomcat logger
created within my web app up until this point is now using log4j from
my web app (!) and using the basic log4j.properties [if present] from
my web app -- for loggers that apply to all web apps!
How is one supposed to work this?  I am currently using a static
LoggerRepository reference within my web app so that a log4j loaded
higher in the classloader tree won't cause LoggerRepository sharing.
I was using a JNDI-based LoggerRepositorySelector as per log4j author
recommendations, but this goes a step further than above -- it puts
all the Tomcat loggers that are errantly using my log4j into my
LoggerRepository -- which would be fine if these loggers were not
shared with other web apps.
What's the solution here?  Do I have to put log4j into Tomcat's lib
directories to force it to use its own centralized log4j?  Is that
the best solution?
--
Jess Holle
   


 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Web apps vs. Logging vs. Tomcat

[Jess Holle]

Remy Maucherat wrote:
Yoav Shapira wrote:
UGLI is far from mature enough to be used by Tomcat at this point.  When
log4j 1.3 is out, we'll see.
I already voted on that: -1.
Why out of curiosity?  I don't have a pro-UGLI ax to grind here, but 
Commons-Logging's behavior in Tomcat is really undesirable as is.

Now if you're inside JBoss and it has pre-established log4j and 
configured it prior to Tomcat loading, then I don't see a problem with 
Commons Logging.  Standalone Tomcat's Commons Logging behavior vis-a-vis 
log4j would seem to be an issue, though.  The issues are especially bad 
and bizarre when log4j is used in a web app but Tomcat itself does not 
have log4j installed, but this is only part of the issue.

--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Remy Maucherat]

Yoav Shapira wrote:
UGLI is far from mature enough to be used by Tomcat at this point.  When
log4j 1.3 is out, we'll see.
I already voted on that: -1.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[markt]

markt   2005/03/17 13:38:28

  Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users
DeleteGroupsAction.java DeleteUsersAction.java
  Log:
  Support managing users/groups with names containing '=' (and other odd 
characters) from within
   the admin webapp.
   - Port of fixes for 28178 and 34033 from TC5
  
  Revision  ChangesPath
  1.51  +3 -3  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
  
  Index: MBeanUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- MBeanUtils.java   26 Aug 2004 21:36:08 -  1.50
  +++ MBeanUtils.java   17 Mar 2005 21:38:28 -  1.51
  @@ -1173,7 +1173,7 @@
   
   ObjectName name = null;
   name = new ObjectName(domain + ":type=Group,groupname=" +
  -  group.getGroupname() + ",database=" +
  +  encodeStr(group.getGroupname()) + ",database=" 
+
 group.getUserDatabase().getId());
   return (name);
   
  @@ -1559,7 +1559,7 @@
   
   ObjectName name = null;
   name = new ObjectName(domain + ":type=User,username=" +
  -  user.getUsername() + ",database=" +
  +  encodeStr(user.getUsername()) + ",database=" +
 user.getUserDatabase().getId());
   return (name);
   
  
  
  
  1.4   +4 -2  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/DeleteGroupsAction.java
  
  Index: DeleteGroupsAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/DeleteGroupsAction.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- DeleteGroupsAction.java   17 Mar 2005 20:51:03 -  1.3
  +++ DeleteGroupsAction.java   17 Mar 2005 21:38:28 -  1.4
  @@ -19,6 +19,7 @@
   
   
   import java.io.IOException;
  +import java.net.URLDecoder;
   import java.util.Locale;
   import javax.servlet.ServletException;
   import javax.servlet.http.HttpServletRequest;
  @@ -126,7 +127,8 @@
   
   for (int i = 0; i < groups.length; i++) {
   ObjectName oname = new ObjectName(groups[i]);
  -params[0] = oname.getKeyProperty("groupname");
  +params[0] =
  +URLDecoder.decode(oname.getKeyProperty("groupname"));
   mserver.invoke(dname, "removeGroup",
  params, signature);
   }
  
  
  
  1.4   +3 -2  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/DeleteUsersAction.java
  
  Index: DeleteUsersAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/DeleteUsersAction.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- DeleteUsersAction.java17 Mar 2005 20:51:03 -  1.3
  +++ DeleteUsersAction.java17 Mar 2005 21:38:28 -  1.4
  @@ -19,6 +19,7 @@
   
   
   import java.io.IOException;
  +import java.net.URLDecoder;
   import java.util.Locale;
   import javax.servlet.ServletException;
   import javax.servlet.http.HttpServletRequest;
  @@ -126,7 +127,7 @@
   
   for (int i = 0; i < users.length; i++) {
   ObjectName oname = new ObjectName(users[i]);
  -params[0] = oname.getKeyProperty("username");
  +params[0] = 
URLDecoder.decode(oname.getKeyProperty("username"));
   mserver.invoke(dname, "removeUser",
  params, signature);
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Web apps vs. Logging vs. Tomcat

[Yoav Shapira]

Hola,
Your approach is right and should work.  You basically have to move
everything up the classloader hierarchy into Tomcat's section, and have a
copy of the MBean stuff in each webapp classloader repository that you want
to manage.

And I agree that it sucks...

Yoav

> -Original Message-
> From: Jess Holle [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 17, 2005 4:30 PM
> To: Tomcat Developers List
> Subject: Re: Web apps vs. Logging vs. Tomcat
> 
> Thanks.  That answers that part of the question quite succinctly.
> 
> Now what remains is how can I work with log4j and commons logging --
> commons logging's behavior vis-a-vis the contextual classloader seems
> onerous if not just plain wrong.
> 
> The only way I can see to "fix" this is to deploy log4j in Tomcat's own
> lib directories -- and deploy my log4j controller MBeans there for the
> default LoggeRepository and again in each web app for each web app's
> LoggerRepository.
> 
> If that's what I need to do, I'll get on with doing it, but I'd like to
> know I'm not just overlooking the obvious...
> 
> --
> Jess Holle
> 
> Yoav Shapira wrote:
> 
> >UGLI is far from mature enough to be used by Tomcat at this point.  When
> >log4j 1.3 is out, we'll see.
> >
> >Yoav
> >
> >
> >>-Original Message-
> >>From: Jess Holle [mailto:[EMAIL PROTECTED]
> >>Sent: Thursday, March 17, 2005 4:17 PM
> >>To: Tomcat Developers List
> >>Subject: Re: Web apps vs. Logging vs. Tomcat
> >>
> >>P.S.  Why does Tomcat use Commons Logging rather than UGLI?
> >>
> >>Jess Holle wrote:
> >>
> >>
> >>
> >>>I had e-mailed this to users mailing list, but I have what I believe
> >>>is a more "dev" follow-on question:
> >>>
> >>>   Is there a good way to get my own start/stop action called at a
> >>>   per-VM level?
> >>>
> >>>   This is assuming I end up having to move log4j up into Tomcat's
> >>>   classloaders -- at which point I'll want to install my
> >>>   LoggerRepository controlling MBeans up at this level as well -- as
> >>>   log4j's MBeans have issues and using log4j loggers means you don't
> >>>   get the (admittedly sparse) java.util.logging MBean coverage.
> >>>
> >>>--
> >>>Jess Holle
> >>>
> >>>Jess Holle wrote:
> >>>
> >>>
> >>>
> I have been trying to get really serious about log4j in web apps.
> 
> I note that Tomcat (thanks to commons-logging) uses java.util.logging
> *except* for loggers created while my web app's classloader is the
> current contextual classloader -- at which point it suddenly uses
> log4j (since my web app does) without giving my web app a chance to
> initialize it in any way as best I can tell.
> 
> My web app has a ServletContextListener which initializes log4j by
> setting up its own LoggerRepository, configuration file and watcher
> (since log4j's won't shutdown), etc.  Of course, every Tomcat logger
> created within my web app up until this point is now using log4j from
> my web app (!) and using the basic log4j.properties [if present] from
> my web app -- for loggers that apply to all web apps!
> 
> How is one supposed to work this?  I am currently using a static
> LoggerRepository reference within my web app so that a log4j loaded
> higher in the classloader tree won't cause LoggerRepository sharing.
> I was using a JNDI-based LoggerRepositorySelector as per log4j author
> recommendations, but this goes a step further than above -- it puts
> all the Tomcat loggers that are errantly using my log4j into my
> LoggerRepository -- which would be fine if these loggers were not
> shared with other web apps.
> 
> What's the solution here?  Do I have to put log4j into Tomcat's lib
> directories to force it to use its own centralized log4j?  Is that
> the best solution?
> 
> --
> Jess Holle
> 
> 
> >>>
> >>>
> >>>
> >>>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Jess Holle]

Thanks.  That answers that part of the question quite succinctly.
Now what remains is how can I work with log4j and commons logging -- 
commons logging's behavior vis-a-vis the contextual classloader seems 
onerous if not just plain wrong.

The only way I can see to "fix" this is to deploy log4j in Tomcat's own 
lib directories -- and deploy my log4j controller MBeans there for the 
default LoggeRepository and again in each web app for each web app's 
LoggerRepository.

If that's what I need to do, I'll get on with doing it, but I'd like to 
know I'm not just overlooking the obvious...

--
Jess Holle
Yoav Shapira wrote:
UGLI is far from mature enough to be used by Tomcat at this point.  When
log4j 1.3 is out, we'll see.
Yoav
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 4:17 PM
To: Tomcat Developers List
Subject: Re: Web apps vs. Logging vs. Tomcat
P.S.  Why does Tomcat use Commons Logging rather than UGLI?
Jess Holle wrote:
   

I had e-mailed this to users mailing list, but I have what I believe
is a more "dev" follow-on question:
  Is there a good way to get my own start/stop action called at a
  per-VM level?
  This is assuming I end up having to move log4j up into Tomcat's
  classloaders -- at which point I'll want to install my
  LoggerRepository controlling MBeans up at this level as well -- as
  log4j's MBeans have issues and using log4j loggers means you don't
  get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:
 

I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging
*except* for loggers created while my web app's classloader is the
current contextual classloader -- at which point it suddenly uses
log4j (since my web app does) without giving my web app a chance to
initialize it in any way as best I can tell.
My web app has a ServletContextListener which initializes log4j by
setting up its own LoggerRepository, configuration file and watcher
(since log4j's won't shutdown), etc.  Of course, every Tomcat logger
created within my web app up until this point is now using log4j from
my web app (!) and using the basic log4j.properties [if present] from
my web app -- for loggers that apply to all web apps!
How is one supposed to work this?  I am currently using a static
LoggerRepository reference within my web app so that a log4j loaded
higher in the classloader tree won't cause LoggerRepository sharing.
I was using a JNDI-based LoggerRepositorySelector as per log4j author
recommendations, but this goes a step further than above -- it puts
all the Tomcat loggers that are errantly using my log4j into my
LoggerRepository -- which would be fine if these loggers were not
shared with other web apps.
What's the solution here?  Do I have to put log4j into Tomcat's lib
directories to force it to use its own centralized log4j?  Is that
the best solution?
--
Jess Holle
   


 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: Web apps vs. Logging vs. Tomcat

[Yoav Shapira]

UGLI is far from mature enough to be used by Tomcat at this point.  When
log4j 1.3 is out, we'll see.

Yoav

> -Original Message-
> From: Jess Holle [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 17, 2005 4:17 PM
> To: Tomcat Developers List
> Subject: Re: Web apps vs. Logging vs. Tomcat
> 
> P.S.  Why does Tomcat use Commons Logging rather than UGLI?
> 
> Jess Holle wrote:
> 
> > I had e-mailed this to users mailing list, but I have what I believe
> > is a more "dev" follow-on question:
> >
> >Is there a good way to get my own start/stop action called at a
> >per-VM level?
> >
> >This is assuming I end up having to move log4j up into Tomcat's
> >classloaders -- at which point I'll want to install my
> >LoggerRepository controlling MBeans up at this level as well -- as
> >log4j's MBeans have issues and using log4j loggers means you don't
> >get the (admittedly sparse) java.util.logging MBean coverage.
> >
> > --
> > Jess Holle
> >
> > Jess Holle wrote:
> >
> >> I have been trying to get really serious about log4j in web apps.
> >>
> >> I note that Tomcat (thanks to commons-logging) uses java.util.logging
> >> *except* for loggers created while my web app's classloader is the
> >> current contextual classloader -- at which point it suddenly uses
> >> log4j (since my web app does) without giving my web app a chance to
> >> initialize it in any way as best I can tell.
> >>
> >> My web app has a ServletContextListener which initializes log4j by
> >> setting up its own LoggerRepository, configuration file and watcher
> >> (since log4j's won't shutdown), etc.  Of course, every Tomcat logger
> >> created within my web app up until this point is now using log4j from
> >> my web app (!) and using the basic log4j.properties [if present] from
> >> my web app -- for loggers that apply to all web apps!
> >>
> >> How is one supposed to work this?  I am currently using a static
> >> LoggerRepository reference within my web app so that a log4j loaded
> >> higher in the classloader tree won't cause LoggerRepository sharing.
> >> I was using a JNDI-based LoggerRepositorySelector as per log4j author
> >> recommendations, but this goes a step further than above -- it puts
> >> all the Tomcat loggers that are errantly using my log4j into my
> >> LoggerRepository -- which would be fine if these loggers were not
> >> shared with other web apps.
> >>
> >> What's the solution here?  Do I have to put log4j into Tomcat's lib
> >> directories to force it to use its own centralized log4j?  Is that
> >> the best solution?
> >>
> >> --
> >> Jess Holle
> >
> >
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Jess Holle]

P.S.  Why does Tomcat use Commons Logging rather than UGLI?
Jess Holle wrote:
I had e-mailed this to users mailing list, but I have what I believe 
is a more "dev" follow-on question:

   Is there a good way to get my own start/stop action called at a
   per-VM level?
   This is assuming I end up having to move log4j up into Tomcat's
   classloaders -- at which point I'll want to install my
   LoggerRepository controlling MBeans up at this level as well -- as
   log4j's MBeans have issues and using log4j loggers means you don't
   get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:
I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging 
*except* for loggers created while my web app's classloader is the 
current contextual classloader -- at which point it suddenly uses 
log4j (since my web app does) without giving my web app a chance to 
initialize it in any way as best I can tell.

My web app has a ServletContextListener which initializes log4j by 
setting up its own LoggerRepository, configuration file and watcher 
(since log4j's won't shutdown), etc.  Of course, every Tomcat logger 
created within my web app up until this point is now using log4j from 
my web app (!) and using the basic log4j.properties [if present] from 
my web app -- for loggers that apply to all web apps!

How is one supposed to work this?  I am currently using a static 
LoggerRepository reference within my web app so that a log4j loaded 
higher in the classloader tree won't cause LoggerRepository sharing.  
I was using a JNDI-based LoggerRepositorySelector as per log4j author 
recommendations, but this goes a step further than above -- it puts 
all the Tomcat loggers that are errantly using my log4j into my 
LoggerRepository -- which would be fine if these loggers were not 
shared with other web apps.

What's the solution here?  Do I have to put log4j into Tomcat's lib 
directories to force it to use its own centralized log4j?  Is that 
the best solution?

--
Jess Holle


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ExpandWar doesn't set the lastModified attribute

[Jochen Wiedmann]

Nag! The mail below was sent by me two weeks ago. Is the idea to 
maintain timestamps so absurd, that it's not even worth a comment?

--
Hi,
would anyone please be so nice and comment
http://issues.apache.org/bugzilla/show_bug.cgi?id=33636
Please note, that it contains a suggested patch.
Regards,
Jochen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve AccessLogValveForm.java AddValveAction.java DeleteValveAction.java DeleteValvesAction.java EditValveAction.java RemoteAddrValveForm.java RemoteHostValveForm.java RequestDumperValveForm.java SaveAccessLogValveAction.java SaveRemoteAddrValveAction.java SaveRemoteHostValveAction.java SaveRequestDumperValveAction.java SaveSingleSignOnValveAction.java SingleSignOnValveForm.java ValveForm.java ValveUtil.java

[markt]

markt   2005/03/17 12:51:05

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
ActionTag.java ActionsTag.java
ApplicationServlet.java CommitChangesAction.java
DataTag.java DumpRegistryAction.java
DumpServerAction.java LabelTag.java
LogOutAction.java RowTag.java SetLocaleAction.java
SetUpTreeAction.java TableTag.java
TomcatTreeBuilder.java TreeControlTestAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector
AddConnectorAction.java DeleteConnectorAction.java
DeleteConnectorsAction.java
EditConnectorAction.java
   
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext
AddDefaultContextAction.java
DefaultContextForm.java
DeleteDefaultContextAction.java
DeleteDefaultContextForm.java
DeleteDefaultContextsAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/filters
SetCharacterEncodingFilter.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/host
AddAliasAction.java AddHostAction.java
DeleteAliasAction.java DeleteAliasForm.java
DeleteAliasesAction.java DeleteHostAction.java
DeleteHostForm.java DeleteHostsAction.java
EditHostAction.java SaveAliasAction.java
SaveHostAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/logger
AddLoggerAction.java DeleteLoggerAction.java
DeleteLoggersAction.java EditLoggerAction.java
LoggerForm.java SaveLoggerAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm
AddRealmAction.java DeleteRealmAction.java
DeleteRealmsAction.java EditRealmAction.java
JDBCRealmForm.java JNDIRealmForm.java
MemoryRealmForm.java RealmForm.java
SaveJDBCRealmAction.java SaveJNDIRealmAction.java
SaveMemoryRealmAction.java
SaveUserDatabaseRealmAction.java
UserDatabaseRealmForm.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
BaseForm.java DataSourceForm.java
DataSourcesForm.java DeleteDataSourcesAction.java
DeleteEnvEntriesAction.java
DeleteMailSessionsAction.java
DeleteResourceLinksAction.java
DeleteUserDatabasesAction.java EnvEntriesForm.java
EnvEntryForm.java ListDataSourcesAction.java
ListEnvEntriesAction.java
ListMailSessionsAction.java
ListResourceLinksAction.java
ListUserDatabasesAction.java MailSessionForm.java
MailSessionsForm.java ResourceLinkForm.java
ResourceLinksForm.java ResourceUtils.java
SaveDataSourceAction.java SaveEnvEntryAction.java
SaveMailSessionAction.java
SaveResourceLinkAction.java
SaveUserDatabaseAction.java
SetUpDataSourceAction.java SetUpEnvEntryAction.java
SetUpMailSessionAction.java
SetUpResourceLinkAction.java
SetUpUserDatabaseAction.java UserDatabaseForm.java
UserDatabasesForm.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/server
EditServerAction.java SaveServerAction.java
ServerForm.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service
AddServiceAction.java DeleteServiceAction.java
DeleteServicesAction.java EditServiceAction.java
SaveServiceAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users
BaseForm.java DeleteGroupsAction.java
DeleteRolesAction.java DeleteUsersAction.java
GroupForm.java GroupsForm.java
ListGroupsAction.java ListRolesAction.java
ListUsersAction.java RoleForm.java RolesForm.java
SaveGroupAction.java SaveRoleAction.java
SaveUserAction.java SetUpGroupAction.java
  

Edward Furlong/IE/TLS/PwC is out of the office.

[edward . furlong]

I will be out of the office starting  16/03/2005 and will not return until
21/03/2005.

.
_
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web apps vs. Logging vs. Tomcat

[Jess Holle]

I had e-mailed this to users mailing list, but I have what I believe is 
a more "dev" follow-on question:

   Is there a good way to get my own start/stop action called at a
   per-VM level?
   This is assuming I end up having to move log4j up into Tomcat's
   classloaders -- at which point I'll want to install my
   LoggerRepository controlling MBeans up at this level as well -- as
   log4j's MBeans have issues and using log4j loggers means you don't
   get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:
I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging 
*except* for loggers created while my web app's classloader is the 
current contextual classloader -- at which point it suddenly uses 
log4j (since my web app does) without giving my web app a chance to 
initialize it in any way as best I can tell.

My web app has a ServletContextListener which initializes log4j by 
setting up its own LoggerRepository, configuration file and watcher 
(since log4j's won't shutdown), etc.  Of course, every Tomcat logger 
created within my web app up until this point is now using log4j from 
my web app (!) and using the basic log4j.properties [if present] from 
my web app -- for loggers that apply to all web apps!

How is one supposed to work this?  I am currently using a static 
LoggerRepository reference within my web app so that a log4j loaded 
higher in the classloader tree won't cause LoggerRepository sharing.  
I was using a JNDI-based LoggerRepositorySelector as per log4j author 
recommendations, but this goes a step further than above -- it puts 
all the Tomcat loggers that are errantly using my log4j into my 
LoggerRepository -- which would be fine if these loggers were not 
shared with other web apps.

What's the solution here?  Do I have to put log4j into Tomcat's lib 
directories to force it to use its own centralized log4j?  Is that the 
best solution?

--
Jess Holle

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

>> 2) The test in configure about functionality of the timeouts is broken.
>> The test program does not compile under Solaris, because it needs
>> "-lsocket".
>
> Can you provide a patch for that?

How about:

*** configure.in.orig   Thu Mar 17 17:00:36 2005
--- configure.inThu Mar 17 21:28:29 2005
***
*** 56,63 
  dnl check for flock function.
  AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()]))

! AC_DEFUN(JK_CHECK_SETSOCKOPT, [
  AC_MSG_CHECKING(whether to use $1 with setsockopt())
  AC_TRY_RUN([
  #include 
  #include 
--- 56,65 
  dnl check for flock function.
  AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()]))

! AC_DEFUN([JK_CHECK_SETSOCKOPT], [
  AC_MSG_CHECKING(whether to use $1 with setsockopt())
+ saved_LIBS="$LIBS"
+ LIBS="$saved_LIBS -lsocket"
  AC_TRY_RUN([
  #include 
  #include 
***
*** 88,93 
--- 90,96 
  , [ AC_MSG_RESULT([yes]) AC_DEFINE(USE_$1, 1, [Define to use $1 with
setsockopt()]) ]
  , [ AC_MSG_RESULT([no]) ]
  )
+ LIBS="$saved_LIBS"
  ])dnl

  dnl check for SO_RCVTIMEO and SO_SNDTIMEO

Since it's only changed line and three added I did not use local CVS to
make diff -u and I hope this context diff suffices.

That way the test runs smoothly, of course with the same negative but
clean result:

configure:19433: checking whether to use SO_RCVTIMEO with setsockopt()
configure:19480: gcc -specs=/usr/local/apautobuild/specs -o conftest -O2  
conftest.c  -lsocket >&5
configure:19483: $? = 0
configure:19485: ./conftest
configure:19488: $? = 1
configure: program exited with status 1

Regards,
Rainer




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[NormW]

Greetings All,
Still get a clean build for NetWare against Apache 2.1 and 2.0.53.
The XML pages work fine, although the HTML status pages might put the 
numbers under headings better if 'border=1' was enabled.
AFAIK builds for Apache 1.1.3 for NetWare still has issues, since I've 
not seen mention of updates for that version. Perhaps JJC can comment?

Regards,
Norm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[Mladen Turk]

Henri Gomez wrote:
jk 1.2.9-dev build on iSeries without problem.
Wit my admins to redeploy and test it
Cool!
I'll probably tag that tomorrow.
Its getting late here :)
Since Apache infrastructure will be unavailable over the
weekend I hope the beta will be mirrored by that time.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[Henri Gomez]

jk 1.2.9-dev build on iSeries without problem.

Wit my admins to redeploy and test it


On Thu, 17 Mar 2005 20:37:58 +0100, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Rainer Jung wrote:
> > Concerning socket_timeout:
> >
> > 1) In common/jk_connect.c there is a typo:
> >
> >374  setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
> >375 (const void *) &tv, sizeof(tv));
> >376  setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
> >377 (const void *) &tv, sizeof(tv));
> >
> > so both setsockopts use the same option. It should be SO_SNDTIMEO in line
> > 376. Maybe that's easy enough to change for 1.2.9.
> >
> 
> Yes, it should be SO_SNDTIMEO. Seems like typo :).
> 
> 
> > 2) The test in configure about functionality of the timeouts is broken.
> > The test program does not compile under Solaris, because it needs
> > "-lsocket".
> >
> 
> Can you provide a patch for that?
> 
> >
> > When I compile the test program with "-lsocket" it compiles but it exits
> > as expected with "1". So under Solaris the two timeouts are defined in the
> > include files, but they do not work with setsockopt. Since this doesn't
> > change the result in the end, it might also be corrected after 1.2.9.
> >
> 
> Sure, that's the purpose of JK_CHECK_SETSOCKOPT function.
> 
> 
> Regards,
> Mladen.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c

[mturk]

mturk   2005/03/17 11:49:23

  Modified:jk/native/common jk_connect.c
  Log:
  WIN32 - do not change exiting var, because it is later used by nb_connect.
  
  Revision  ChangesPath
  1.49  +4 -4  jakarta-tomcat-connectors/jk/native/common/jk_connect.c
  
  Index: jk_connect.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
  retrieving revision 1.48
  retrieving revision 1.49
  diff -u -r1.48 -r1.49
  --- jk_connect.c  17 Mar 2005 19:41:58 -  1.48
  +++ jk_connect.c  17 Mar 2005 19:49:23 -  1.49
  @@ -362,11 +362,11 @@
   
   if (timeout > 0) {
   #if defined(WIN32)
  -timeout = timeout * 1000;
  +int tmout = timeout * 1000;
   setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
  -   (const char *) &timeout, sizeof(int));
  +   (const char *) &tmout, sizeof(int));
   setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
  -   (const char *) &timeout, sizeof(int));
  +   (const char *) &tmout, sizeof(int));
   #elif defined(SO_RCVTIMEO) && defined(USE_SO_RCVTIMEO) && 
defined(SO_SNDTIMEO) && defined(USE_SO_SNDTIMEO)
   struct timeval tv;
   tv.tv_sec  = timeout;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c

[mturk]

mturk   2005/03/17 11:41:58

  Modified:jk/native/common jk_connect.c
  Log:
  Fix typo. We needed SO_SNDTIMEO here.
  
  Revision  ChangesPath
  1.48  +2 -2  jakarta-tomcat-connectors/jk/native/common/jk_connect.c
  
  Index: jk_connect.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- jk_connect.c  15 Mar 2005 08:23:38 -  1.47
  +++ jk_connect.c  17 Mar 2005 19:41:58 -  1.48
  @@ -373,7 +373,7 @@
   tv.tv_usec = 0;
   setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
  (const void *) &tv, sizeof(tv));
  -setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
  +setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
  (const void *) &tv, sizeof(tv));
   #endif
   if (JK_IS_DEBUG_LEVEL(l))
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[Mladen Turk]

Rainer Jung wrote:
Concerning socket_timeout:
1) In common/jk_connect.c there is a typo:
   374  setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
   375 (const void *) &tv, sizeof(tv));
   376  setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
   377 (const void *) &tv, sizeof(tv));
so both setsockopts use the same option. It should be SO_SNDTIMEO in line
376. Maybe that's easy enough to change for 1.2.9.
Yes, it should be SO_SNDTIMEO. Seems like typo :).

2) The test in configure about functionality of the timeouts is broken.
The test program does not compile under Solaris, because it needs
"-lsocket".
Can you provide a patch for that?
When I compile the test program with "-lsocket" it compiles but it exits
as expected with "1". So under Solaris the two timeouts are defined in the
include files, but they do not work with setsockopt. Since this doesn't
change the result in the end, it might also be corrected after 1.2.9.
Sure, that's the purpose of JK_CHECK_SETSOCKOPT function.
Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

Concerning socket_timeout:

1) In common/jk_connect.c there is a typo:

   374  setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
   375 (const void *) &tv, sizeof(tv));
   376  setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
   377 (const void *) &tv, sizeof(tv));

so both setsockopts use the same option. It should be SO_SNDTIMEO in line
376. Maybe that's easy enough to change for 1.2.9.

2) The test in configure about functionality of the timeouts is broken.
The test program does not compile under Solaris, because it needs
"-lsocket".

Undefined   first referenced
 symbol in file
socket  /var/tmp//ccKuhLE0.o
setsockopt  /var/tmp//ccKuhLE0.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure:19481: $? = 1
configure: program exited with status 1

When I compile the test program with "-lsocket" it compiles but it exits
as expected with "1". So under Solaris the two timeouts are defined in the
include files, but they do not work with setsockopt. Since this doesn't
change the result in the end, it might also be corrected after 1.2.9.

3) in common/jk_connect.c in method jk_is_socket_connected the second
argument "timeout" is never used.

4) Still need to test functionality of socket_timeout under Solaris.

Regards,
Rainer

> Rainer Jung wrote:
>> Hi,
>>
>> I could help with Solaris info. If you tell me, what you are interested
>> in, I can do some tests.
>>
>
> Build, socket_timeout and JkShmFile.
>
> Regards,
> Mladen.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33885] - Tomcat 5.5.7 deleting context configuration and webapp

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=33885





--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 20:04 ---
This bug is present in Tomcat 5.5.7 but is no longer present in the current 
cvs HEAD.   

The following stacktrace was captured during deletion of the test case app 
supplied using Tomcat 5.5.7:
at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:267)
at org.apache.catalina.startup.HostConfig.checkResources
(HostConfig.java:1024)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1166)
at org.apache.catalina.startup.HostConfig.lifecycleEvent
(HostConfig.java:292)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.backgroundProcess
(ContainerBase.java:1301)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChil
dren(ContainerBase.java:1561)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChil
dren(ContainerBase.java:1570)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run
(ContainerBase.java:1550)
at java.lang.Thread.run(Thread.java:595)

This bug appears to have been fixed along with the fix for Bug 33572
in revision 1.55 of jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java

[See comments 5 and 6 on that Bug 33572 as well.]

The fix should appear in release 5.5.8 (if it goes out) and later.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34061] - Tomcat hangs while starting

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34061


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 19:56 ---
Everything in this bug report suggests a configuration problem and nothing
suggests a bug.

Bugzilla is NOT a support forum. Please direct this question, and others like
it, to the tomact-user mailing list.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34057] - Deploy of war to context path like "/foo/bar" fails (but "/foo" works).

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34057





--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 18:32 ---
If anything other than single level context paths are not supported by the
manager webapp then it should at least produce a message that says why the
deployment failed, and if a subdirectory of webapps base happens to be there, it
should probably not put the undeployed war file there.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

Hi Mladen,
- Build for apache 1.3 OK (but see detailed comments).
- Running with apache 1.3 and JkShmFile: Looks OK
- jkstatus: Looks OK
- socket_timeout: Still needs to be tested (will try later)
- Logging shows mod_jk initialization two times! Once for a process A,
which does no longer exist after apache startup has finished, and a
second time the same lines for the usual parent process B. System call
trace shows, that A forks B and exits during startup. In my case, apache 
is not run from the root account.

Anything else (apart from socket_timeout) I should test (test cases?)
Details:
Code from CVS HEAD today 17:00 CET.
Environment Solaris 8 UltraSparc, autoconf 2.59, automake 1.9, libtool
1.5, GNU m4 1.4.2, GNU make 3.80, gcc 3.2, Solaris ld 1.279.
CFLAGS set to "-O2", CC set to "gcc -specs=MY_SPECS_PATH/specs" and the
specs file differs from the standard one by:
51c51
< %{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}%{shared:-lgcc_s%M}}}
---
 > %{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}}
This is to link statically against libgcc. Otherwise the runtime system
must have libgcc_s.so, which usually is not the case for Solaris systems.
buildconf.sh warns:
configure.in:59: warning: underquoted definition of JK_CHECK_SETSOCKOPT
   run info '(automake)Extending aclocal'
   or see
http://sources.redhat.com/automake/automake.html#Extending%20aclocal
configure.in: installing `scripts/build/unix/install-sh'
configure.in: installing `scripts/build/unix/missing'
The underquoted warning means, that future versions of automake might
require line 59 to include additional brackets:
AC_DEFUN([JK_CHECK_SETSOCKOPT], [
./configure --with-apxs=MY_APXS_PATH/apxs
Nothing special.
make: Warning:
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
but inspection of libtools show, that --finish would not do anything in
our case.
Copied apache-1.3/mod_jk.so.0.0.0 to libexec/mod_jk.so.
Configured apache:
LoadModule jk_module  libexec/mod_jk.so
AddModule mod_jk.c
JkWorkersFile /SOME_PATH/conf/workers.properties
JkShmFile /SOME_PATH/logs/mod_jk.shm
JkLogFile /SOME_PATH/logs/mod_jk.log
JkLogLevel trace
...
# Inside virtual host
# Where to put jk logs
JkLogFile /SOME_PATH/logs/mod_jk_21000.log
JkLogLevel trace
JkMount /status status
JkMount /*.jsp balancer
Test:
lynx -cfg=/home/jung/lib/lynx.cfg http://localhost:21000/status
shows version 1.2.9 and detail info for load balancing worker and single
worker.
Regards,
Rainer
Mladen Turk wrote:
Rainer Jung wrote:
Hi,
I could help with Solaris info. If you tell me, what you are 
interested in, I can do some tests.

Build, socket_timeout and JkShmFile.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34061] - Tomcat hangs while starting

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34061


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Tomcat hangs while starting |Tomcat hangs while starting




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34061] - Tomcat hangs while starting

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34061





--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 17:40 ---
Created an attachment (id=14510)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14510&action=view)
Server.xml

Server.xml file

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34061] New: - Tomcat hangs while starting

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34061

   Summary: Tomcat hangs while starting
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
OS/Version: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: P1
 Component: Connector:HTTP/1.1 (deprecated)
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Tomcat is working Fine , in WINDOW machine . And also working Fine in One Linux 
server on UAT .while same stops working on production . 
When istart same on Production it doesn't go ahead and hangs showing below 
message.
"HttpConnector Opening server socket on all host IP addresses" . While same is 
working Fine in other WINdows as well as UAT Linux Box.

I can send Server.xml if required.

Help would be appriciated, As my production is getting delayed.

Abhishek

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[Mladen Turk]

Rainer Jung wrote:
Hi,
I could help with Solaris info. If you tell me, what you are interested 
in, I can do some tests.

Build, socket_timeout and JkShmFile.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34057] - Deploy of war to context path like "/foo/bar" fails (but "/foo" works).

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34057


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 16:38 ---
I say no to feature bloat. This would need generation of a context file -> too
complex. You can still do dynamic deployment, but not with the manager webapp.
So sorry, it's not going to be supported.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34057] New: - Deploy of war to context path like "/foo/bar" fails (but "/foo" works).

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34057

   Summary: Deploy of war to context path like "/foo/bar" fails (but
"/foo" works).
   Product: Tomcat 5
   Version: 5.5.7
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P2
 Component: Webapps:Manager
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


>From the manager app:

Context Path (optional): /foo/bar
WAR or Directory URL: /tmp/bunk.war

fails with --
INFO: HTMLManager: install: Installing web application at '/foo/bar' from
'/tmp/bunk.war'
java.io.FileNotFoundException: /bus/deploy/productA.55/webapps/foo/bar.war (No
such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:179)
at java.io.FileOutputStream.(FileOutputStream.java:131)
at
org.apache.catalina.manager.ManagerServlet.copyInternal(ManagerServlet.java:1540)
at 
org.apache.catalina.manager.ManagerServlet.copy(ManagerServlet.java:1505)
at
org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:806)


This error is fixed by a "mkdir WEBAPPS_BASE/foo" before the deploy, but this
still does not end up deploying the app. The war file is placed in
"WEBAPPS_BASE/foo/bar.war", but it is not expanded, and it is not deployed. It
also is not deployed if tomcat is restarted.

The deploy only works if a single level path is specified. The same behaviour
happens with 5.5.8.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

Hi,
I could help with Solaris info. If you tell me, what you are interested 
in, I can do some tests.

Regards,
Rainer
Mladen Turk wrote:
Mark Thomas wrote:
I suspect that most of them are invalid/already fixed bug would be 
grateful if you could take a look.

Hi,
Yes, most are fixed. Other I simply do not understand.
I'll clean up fixed and invalid, and instruct the reporters
to check beta version. Some problem like Solaris one are
really hard to track down without a box :)
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34033] - Cannot delete users using Administration Tool webapp (HTTP 500 error)

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34033


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 15:21 ---
Thanks :)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native configure.in

[mturk]

mturk   2005/03/17 04:48:40

  Modified:jk/native configure.in
  Log:
  No need to add -I when calling apxs
  
  Revision  ChangesPath
  1.42  +2 -2  jakarta-tomcat-connectors/jk/native/configure.in
  
  Index: configure.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- configure.in  17 Mar 2005 12:31:13 -  1.41
  +++ configure.in  17 Mar 2005 12:48:40 -  1.42
  @@ -146,7 +146,7 @@
   else
   WEBSERVER="apache-2.0"
APRINCLUDEDIR=""
  - INCTEMP="-I`$APXS -q APR_INCLUDEDIR`"
  + INCTEMP="`$APXS -q APR_INCLUDEDIR`"
for INC in ${INCTEMP}; do
APRINCLUDEDIR="${APRINCLUDEDIR} -I${INC}"
done
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34036] - uriworkermap not redirecting requests to workers properly.

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34036





--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 13:41 ---
(In reply to comment #5)
> Not sure for 1.2.8, but 1.2.9-dev is working like I explained with /*/
> Wait couple of days for release.
> Mladen.

Phew... Thanks for that. Where would I find the dev version of 1.2.9? Is it 
available for download?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33248] - mod_jk fails to build

[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://issues.apache.org/bugzilla/show_bug.cgi?id=33248


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 13:33 ---
Fixed in the CVS.
You can try from HEAD or wait for 1.2.9.

Mladen

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native configure.in

[mturk]

mturk   2005/03/17 04:31:13

  Modified:jk/native configure.in
  Log:
  Allow multiple APR include dirs. Fixes #33248
  
  Revision  ChangesPath
  1.41  +6 -2  jakarta-tomcat-connectors/jk/native/configure.in
  
  Index: configure.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
  retrieving revision 1.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- configure.in  17 Mar 2005 11:35:11 -  1.40
  +++ configure.in  17 Mar 2005 12:31:13 -  1.41
  @@ -145,7 +145,11 @@
APXS_CPPFLAGS=""
   else
   WEBSERVER="apache-2.0"
  - APRINCLUDEDIR="-I`$APXS -q APR_INCLUDEDIR`"
  + APRINCLUDEDIR=""
  + INCTEMP="-I`$APXS -q APR_INCLUDEDIR`"
  + for INC in ${INCTEMP}; do
  + APRINCLUDEDIR="${APRINCLUDEDIR} -I${INC}"
  + done
APXSCFLAGS="`${APXS} -q CFLAGS` `${APXS} -q 
EXTRA_CFLAGS` -DHAVE_APR ${APRINCLUDEDIR}"
APXSCPPFLAGS="`${APXS} -q EXTRA_CPPFLAGS`"
   APACHE_CONFIG_VARS="`${APXS} -q 
exp_installbuilddir`/config_vars.mk"
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32998] - Error in communication between Apache and Tomcat through AJP

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32998


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 13:12 ---
Those are all related to mod_jk2.
mod_jk2 is not supported any more, please use mod_jk.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32696] - WEB-INF protection stops IIS

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32696


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 13:07 ---
Fixed in the CVS for mod_jk.
Thanks for spotting that we did not follow the Servlet spec.

Mladen



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/iis jk_isapi_plugin.c

[mturk]

mturk   2005/03/17 04:06:03

  Modified:jk/native/apache-1.3 mod_jk.c
   jk/native/apache-2.0 mod_jk.c
   jk/native/iis jk_isapi_plugin.c
  Log:
  Use 404 instead 403 when client tries to access WEB-INF.
  This is to comply with Servlet spec.
  
  Revision  ChangesPath
  1.74  +3 -3  jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
  retrieving revision 1.73
  retrieving revision 1.74
  diff -u -r1.73 -r1.74
  --- mod_jk.c  22 Feb 2005 14:40:36 -  1.73
  +++ mod_jk.c  17 Mar 2005 12:06:03 -  1.74
  @@ -2122,9 +2122,9 @@
   if (!strcasecmp(child_dir, "WEB-INF") ||
   !strcasecmp(child_dir, "META-INF")) {
   jk_log(l, JK_LOG_DEBUG,
  -   "mod_jk::jk_translate, AutoAlias 
FORBIDDEN for URI: %s",
  +   "mod_jk::jk_translate, AutoAlias 
HTTP_NOT_FOUND for URI: %s",
  r->uri);
  -return FORBIDDEN;
  +return HTTP_NOT_FOUND;
   }
   }
   }
  
  
  
  1.131 +3 -3  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.130
  retrieving revision 1.131
  diff -u -r1.130 -r1.131
  --- mod_jk.c  22 Feb 2005 14:40:37 -  1.130
  +++ mod_jk.c  17 Mar 2005 12:06:03 -  1.131
  @@ -2568,9 +2568,9 @@
   || !strcasecmp(child_dir, "META-INF")) {
   if (JK_IS_DEBUG_LEVEL(conf->log))
   jk_log(conf->log, JK_LOG_DEBUG,
  -   "mod_jk::jk_translate, AutoAlias 
HTTP_FORBIDDEN for URI: %s",
  +   "mod_jk::jk_translate, AutoAlias 
HTTP_NOT_FOUND for URI: %s",
  r->uri);
  -return HTTP_FORBIDDEN;
  +return HTTP_NOT_FOUND;
   }
   }
   }
  
  
  
  1.45  +49 -49jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- jk_isapi_plugin.c 25 Feb 2005 10:54:26 -  1.44
  +++ jk_isapi_plugin.c 17 Mar 2005 12:06:03 -  1.45
  @@ -79,11 +79,11 @@
   "Your browser (or proxy) sent a request that 
"  \
   "this server could not 
understand."
   
  -#define HTML_ERROR_403  ""  \
  -"Access 
forbidden!!"  \
  -"Access forbidden!\n" 
   \
  -"You don't have permission to access the 
requested object." \
  -"It is either read-protected or not readable 
by the server."
  +#define HTML_ERROR_404  ""  \
  +"Object not 
found!"   \
  +"The requested URL was not found 
on this server"  \
  +"\nIf you entered the URL 
manually please check your"  \
  +"spelling and try 
again."
   
   
   #define JK_TOLOWER(x)   ((char)tolower((BYTE)(x)))
  @@ -337,42 +337,42 @@
   int status;
   char *reason;
   } *r, reasons[] = {
  -{ 100, "Continue" }, 
  -{ 101, "Switching Protocols" }, 
  -{ 200, "OK" }, 
  -{ 201, "Created" }, 
  -{ 202, "Accepted" }, 
  -{ 203, "Non-Authoritative Information" }, 
  -{ 204, "No Content" }, 
  -{ 205, "Reset Content" }, 
  -{ 206, "Partial Content" }, 
  -{ 300, "Multiple Choices" }, 
  -{ 301, "Moved Permanently" }, 
  -{ 302, "Moved Temporarily" }, 
  -{ 303, "See Other" }, 
  -{ 304, "Not Modified" }, 
  -{ 305, "Use Proxy" }, 
  -{ 400, "Bad Request" }, 
  -{ 401, "Unauthorized" }, 
  -{ 402, "Payment Required" }, 
  -{ 403, "Forbidden" }, 
  -{ 404, "Not Found" }, 
  -{ 405, "Method Not Allowed" }, 
  -{ 406, "N

DO NOT REPLY [Bug 24628] - Unable to use multiple JkAutoAlias directives

[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://issues.apache.org/bugzilla/show_bug.cgi?id=24628


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 12:45 ---
You can have only one JkAutoAlias per virtual host.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 Makefile.apxs.in Makefile.in

[mturk]

mturk   2005/03/17 03:37:39

  Modified:jk/native/apache-1.3 Makefile.apxs.in Makefile.in
  Log:
  Add -DJK_PREFORK define for Apache1.3 as default.
  
  Revision  ChangesPath
  1.6   +1 -1  
jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in
  
  Index: Makefile.apxs.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Makefile.apxs.in  17 Feb 2005 09:11:31 -  1.5
  +++ Makefile.apxs.in  17 Mar 2005 11:37:39 -  1.6
  @@ -7,7 +7,7 @@
   [EMAIL PROTECTED]@
   
   JK=../common/
  -JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
  +JK_INCL=-DUSE_APACHE_MD5 -DJK_PREFORK -I ${JK}
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L 
${JAVA_HOME}/lib/${ARCH}/native_threads
   
  
  
  
  1.14  +1 -1  
jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- Makefile.in   17 Feb 2005 09:11:31 -  1.13
  +++ Makefile.in   17 Mar 2005 11:37:39 -  1.14
  @@ -25,7 +25,7 @@
   APACHE_FILES = Makefile.tmpl Makefile.libdir libjk.module
   
   JK=../common/
  -JK_INCL=-DUSE_APACHE_MD5 -I ${top_srcdir}/common
  +JK_INCL=-DUSE_APACHE_MD5 -DJK_PREFORK -I ${top_srcdir}/common
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L 
${JAVA_HOME}/lib/${ARCH}/native_threads
   [EMAIL PROTECTED]@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I${top_srcdir}/common
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native configure.in

[mturk]

mturk   2005/03/17 03:35:11

  Modified:jk/native configure.in
  Log:
  Add --enable-prefork configure flag so that threading code can be
  excluded when compiling for apache1 or apache2/prefork.
  
  Revision  ChangesPath
  1.40  +17 -1 jakarta-tomcat-connectors/jk/native/configure.in
  
  Index: configure.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
  retrieving revision 1.39
  retrieving revision 1.40
  diff -u -r1.39 -r1.40
  --- configure.in  25 Feb 2005 08:26:03 -  1.39
  +++ configure.in  17 Mar 2005 11:35:11 -  1.40
  @@ -286,6 +286,22 @@
   ])
   AC_SUBST(CFLAGS)
   
  +dnl CFLAGS for preforks mode
  +dnl it also allows the CFLAGS environment variable.
  +CFLAGS="${CFLAGS}"
  +AC_ARG_ENABLE(
  +prefork,
  +[  --enable-prefork   Turn on prefork web server mode],
  +[
  +case "${enableval}" in
  +y | Y | YES | yes | TRUE | true )
  +CFLAGS="${CFLAGS} -DJK_PREFORK"
  +AC_MSG_RESULT([...Enabling Prefork mode...])
  +;;
  +esac
  +])
  +AC_SUBST(CFLAGS)
  +
   dnl the APXSCFLAGS is given by apxs to the C compiler
   dnl the APXSLDFLAGS is given to the linker (for APRVARS).
   dnl APXSLDFLAGS=""
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jasper and external entities parsing

[Remy Maucherat]

Henri Gomez wrote:
From what I see in the 5.5.8 code the external entities cannot be
resolved since we provide an InputSource to the documentBuilder in
ParseUtils :
   private void processWebDotXml(ServletContext ctxt) throws JasperException {
InputStream is = null;
try {
is = ctxt.getResourceAsStream(WEB_XML);
if (is == null) {
// no web.xml
return;
}
ParserUtils pu = new ParserUtils();
TreeNode webApp = pu.parseXMLDocument(WEB_XML, is);
if (webApp == null
|| !"2.4".equals(webApp.findAttribute("version"))) {
defaultIsELIgnored = "true";
return;
}
As such when the documentBuilder found a partial external entities,
like , it has no idea of its root
location and as such consider as a file and provide it a dummy base
location.
What could be done it to use the ctxt.getResourceAsStream() after
cleaning the systemId reference from any file:// reference (ie:
file:///C:/eclipse3/base.xml => WEB-INF/base.xml).
Remmy do you agree on this since which such we stay independancy from
being on file or other way ?
Ask Jan. It seems quite ugly and special purpose.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_version.h

[mturk]

mturk   2005/03/17 03:31:22

  Modified:jk/native/common jk_version.h
  Log:
  Prepare for 1.2.9-beta release.
  
  Revision  ChangesPath
  1.34  +4 -4  jakarta-tomcat-connectors/jk/native/common/jk_version.h
  
  Index: jk_version.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_version.h,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- jk_version.h  24 Dec 2004 11:07:38 -  1.33
  +++ jk_version.h  17 Mar 2005 11:31:22 -  1.34
  @@ -29,10 +29,10 @@
   #define JK_VERSTRING"1.2.9"
   
   /* Beta number */
  -#define JK_VERBETA  0
  -#define JK_BETASTRING   "0"
  +#define JK_VERBETA  1
  +#define JK_BETASTRING   "1"
   /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */
  -#define JK_VERISRELEASE 0
  +#define JK_VERISRELEASE 1
   #define JK_VERRC0
   #define JK_RCSTRING "0"
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java

[remm]

remm2005/03/17 02:53:44

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
  Log:
  - Ignore ';' if it is in the query string.
  
  Revision  ChangesPath
  1.27  +4 -1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
  
  Index: ApplicationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- ApplicationContext.java   23 Jun 2004 13:51:35 -  1.26
  +++ ApplicationContext.java   17 Mar 2005 10:53:44 -  1.27
  @@ -417,6 +417,9 @@
* purposes
*/
   int semicolon = path.indexOf(';');
  +if (pos >= 0 && semicolon > pos) {
  +semicolon = -1;
  +}
   uriCC.append(path, 0, semicolon > 0 ? semicolon : pos);
   context.getMapper().map(uriMB, mappingData);
   if (mappingData.wrapper == null) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34016] - antiResourceLocking webapp fails to deploy on Tomcat restart after Commit Changes in Admin webapp

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34016


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34006] - Undeploy of webapps with antiResourceLocking in META-INF\context.xml fails after Tomcat restart

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34006


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk2

[Alistair Young]

ok, that's enlightening!
many thanks,
Alistair
On 17 Mar 2005, at 10:13, Mladen Turk wrote:
Alistair Young wrote:
Was there a reason mod_jk2 was replaced with mod_jk?
Too complex, uses APR that behaves badly with Apache1.3,
and lot more. Browse the mail archive for further details.
I found mod_jk2 much easier to use and it's a pity it's gone.
No it is not, but that's kind of personal opinion in any case.
Is it just looking for a maintainer?
No! Please, I'm tired of JK/JK2 discussions :).
It's a dead code. There are two active connectors projects
already mod_jk and mod_proxy for Apache 2.2
When AJP14 protocol gets accepted we'll probably have a third one,
so that's enough, thought.
Were there advantages of mod_jk2 over mod_jk?
None.
If you *really* like JK2 code, it's a BSD license, so you can
do with it what ever you wish, just don't call it Apache or Jakarta.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34036] - uriworkermap not redirecting requests to workers properly.

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34036


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 11:24 ---
Not sure for 1.2.8, but 1.2.9-dev is working like I explained with /*/
Wait couple of days for release.

Mladen.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk2

[Mladen Turk]

Alistair Young wrote:
Was there a reason mod_jk2 was replaced with mod_jk?
Too complex, uses APR that behaves badly with Apache1.3,
and lot more. Browse the mail archive for further details.
I found mod_jk2 
much easier to use and it's a pity it's gone.
No it is not, but that's kind of personal opinion in any case.
Is it just looking for a 
maintainer?

No! Please, I'm tired of JK/JK2 discussions :).
It's a dead code. There are two active connectors projects
already mod_jk and mod_proxy for Apache 2.2
When AJP14 protocol gets accepted we'll probably have a third one,
so that's enough, thought.
Were there advantages of mod_jk2 over mod_jk?
None.
If you *really* like JK2 code, it's a BSD license, so you can
do with it what ever you wish, just don't call it Apache or Jakarta.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 13 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-17032005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-17032005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR 
-I/usr/local/gump/public/workspace/apr/dest-17032005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-17032005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-17032005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 3117032005, brutus:brutus-public:3117032005
Gump E-mail Identifier (unique within run) #27.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34036] - uriworkermap not redirecting requests to workers properly.

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34036


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 10:46 ---
(In reply to comment #3)
> Looks I was closing the case on a second topic.
> For you case use:
> /*/=worker1


I have tried this as well. It does not still work.

Currently I have the worker map like this:

/developer/*=worker2
/*/=worker1

With this, all contexts fo to worker1. It is almost like the map
for worker2 did not exist.

When I try a resource that has to be served by worker2, for example:
http://myhost.com/developer/newsletter.html,
I get a HTTP 404.

When I check the logs, the request has actually gone to worker1. Should it
not have gone to worker2?

I still feel this could be a bug! I might be wrong.. but I am unable to get it 
to work either. 


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

mod_jk2

[Alistair Young]

Was there a reason mod_jk2 was replaced with mod_jk? I found mod_jk2 
much easier to use and it's a pity it's gone. Is it just looking for a 
maintainer?

Were there advantages of mod_jk2 over mod_jk?
Alistair
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Jasper and external entities parsing

[Henri Gomez]

>From what I see in the 5.5.8 code the external entities cannot be
resolved since we provide an InputSource to the documentBuilder in
ParseUtils :

   private void processWebDotXml(ServletContext ctxt) throws JasperException {

InputStream is = null;

try {
is = ctxt.getResourceAsStream(WEB_XML);
if (is == null) {
// no web.xml
return;
}

ParserUtils pu = new ParserUtils();
TreeNode webApp = pu.parseXMLDocument(WEB_XML, is);
if (webApp == null
|| !"2.4".equals(webApp.findAttribute("version"))) {
defaultIsELIgnored = "true";
return;
}

As such when the documentBuilder found a partial external entities,
like , it has no idea of its root
location and as such consider as a file and provide it a dummy base
location.

What could be done it to use the ctxt.getResourceAsStream() after
cleaning the systemId reference from any file:// reference (ie:
file:///C:/eclipse3/base.xml => WEB-INF/base.xml).

Remmy do you agree on this since which such we stay independancy from
being on file or other way ?

Regards

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DOS kind of Attack to your RAM?

[Andy Armstrong]

On 17 Mar 2005, at 04:31, John Smith wrote:
I know this is not exactly a Java/TC question, but that could happen 
to any
machine in a DMZ.
It's not even vaguely a Java/TC question.
Today as I showcased some app to my clients there was an incident of 
clients
entering data that is not saved.

It apparently happens in some cases, all data kept in sessions I keep 
in a
memory HSQL table only when a user is done I save the data on the back 
end
tables

But apparently they corrupted the in memory data somehow
Who did? What evidence is there that you were attacked? In what sense 
is it a DOS attack? What does it have to do with Jakarta?

How do these m*th$r f&ck!rs do that (any links?) and how can you avoid 
it?
You haven't really said what 'they' have done.
--
Andy Armstrong, hexten.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]