Re: Juli/Logging

[Rainer Jung]

David Blevins wrote:
My personal opinion: java.util.logging very much lacks a good 
formatter. The default 2 line formatting of messages, splitting 
timestamps and message in separate lines, is not really useful in 
production. Many ad hoc log analysis practices work on a line oriented 
basis.


Was wondering about that.  I've heard people grumble about 
java.util.logging, but haven't (till now) heard anything specific.  
Maybe I wasn't paying close enough attention, but the Tomcat 6 log files 
still seem to follow the one line per message format.  How did you pull 
that off?


That's what I get:

Aug 1, 2007 10:26:37 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-28680
Aug 1, 2007 10:26:37 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2854 ms
Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.13
Aug 1, 2007 10:26:40 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-28680

One line for timestamp, class and method, a second line for log level 
and message. That's the format of the default formatter, the simple log 
format.


That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


Regards,

Rainer

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

Re: Juli/Logging

[Remy Maucherat]

Rainer Jung wrote:
That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


What should it look like ?

Rémy

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

Re: Juli/Logging

[Rainer Jung]

Hi Remy,

if we only want to give an alternative for the SimpleFormatter:

that one is not configurable, so it's capabilities are printing out a 
localized timestamp, after that the class and method, a localized level 
string, and last the log message. All of those are basically given by 
the log record, level localization is provided by the Level class, 
Timestamp is not problem (milliseconds in the log record), and should 
also contain the millisesond fraction.


Of course we could add configurability in a next step, which would 
basically mean an accesslog/log4j like pattern string for the log line.


The log record carries the following information:

- level
- message
- milliseconds timestamp
- source class and method name
- thread id
- logger name
- sequence number (interesting feature, so one can easily describe, 
which message instance in a log one is talking about)


and more complex objects

- thrown (throwable associated with the record)
- resource bundle and/or resource bundle name to format message string
- parameters, log data extension

The simple objects could be configured by a simple pattern character, 
the more complex ones need more thought :)


I think already the direct simpleformatter replacement, even without 
configurability would be an improvement!


If that formatter would work with j.u.l. i.e. without juli, I would love 
it even more. The configurability of course might add a slight 
dependency to juli (where do we get the parameters from, i.e. how do we 
pass the information from logging.properties to the formatter). Not 
really a dependency, but probably additional setters that are called by 
juli, and when using the formatter in j.u.l one would have to write the 
code that calls the setters oneself (or use juli).


Regards,

Rainer


Remy Maucherat wrote:

Rainer Jung wrote:
That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


What should it look like ?

Rémy




 Object[]   getParameters()
  Get the parameters to the log message.
 ResourceBundle getResourceBundle()
  Get the localization resource bundle
 String getResourceBundleName()
  Get the localization resource bundle name
 long   getSequenceNumber()
  Get the sequence number.
 Throwable  getThrown()
  Get any throwable associated with the log record.

 void   setParameters(Object[] parameters)
  Set the parameters to the log message.
 void   setResourceBundle(ResourceBundle bundle)
  Set the localization resource bundle.
 void   setResourceBundleName(String name)
  Set the localization resource bundle name.
 void   setSequenceNumber(long seq)
  Set the sequence number.
 void   setThrown(Throwable thrown)
  Set a throwable associated with the log event.

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

Re: Juli/Logging

[Rainer Jung]

Forget the previous post, it contained garbage at the end

Hi Remy,

if we only want to give an alternative for the SimpleFormatter:

that one is not configurable, so it's capabilities are printing out a 
localized timestamp, after that the class and method, a localized level 
string, and last the log message. All of those are basically given by 
the log record, level localization is provided by the Level class, 
Timestamp is not problem (milliseconds in the log record), and should 
also contain the millisesond fraction.


Of course we could add configurability in a next step, which would 
basically mean an accesslog/log4j like pattern string for the log line.


The log record carries the following information:

- level
- message
- milliseconds timestamp
- source class and method name
- thread id
- logger name
- sequence number (interesting feature, so one can easily describe, 
which message instance in a log one is talking about)


and more complex objects

- thrown (throwable associated with the record)
- resource bundle and/or resource bundle name to format message string
- parameters, log data extension

The simple objects could be configured by a simple pattern character, 
the more complex ones need more thought :)


I think already the direct simpleformatter replacement, even without 
configurability would be an improvement!


If that formatter would work with j.u.l. i.e. without juli, I would love 
it even more. The configurability of course might add a slight 
dependency to juli (where do we get the parameters from, i.e. how do we 
pass the information from logging.properties to the formatter). Not 
really a dependency, but probably additional setters that are called by 
juli, and when using the formatter in j.u.l one would have to write the 
code that calls the setters oneself (or use juli).


Regards,

Rainer


Remy Maucherat wrote:

Rainer Jung wrote:
That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


What should it look like ?

Rémy


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

svn commit: r561799 - in /tomcat/container/tc5.5.x: modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java webapps/docs/changelog.xml

[pero]

Author: pero
Date: Wed Aug  1 06:59:00 2007
New Revision: 561799

URL: http://svn.apache.org/viewvc?view=rev&rev=561799
Log:
Ported from tomcat 6.0.x: Fix timeout setting on a replicated session.

Modified:

tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java?view=diff&rev=561799&r1=561798&r2=561799
==
--- 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
 Wed Aug  1 06:59:00 2007
@@ -1434,7 +1434,7 @@
 counterSend_EVT_SESSION_EXPIRED++ ;
 SessionMessage msg = new SessionMessageImpl(getName(),
 SessionMessage.EVT_SESSION_EXPIRED, null, id, id
-+ "-EXPIRED-MSG");
++ "-EXPIRED-MSG");
 if (log.isDebugEnabled())
 log.debug(sm.getString("deltaManager.createMessage.expire",
 getName(), id));
@@ -1664,6 +1664,8 @@
 session.setValid(true);
 session.setPrimarySession(false);
 session.setCreationTime(msg.getTimestamp());
+// use container maxInactiveInterval so that session will expire 
correctly in case of primary transfer
+session.setMaxInactiveInterval(getMaxInactiveInterval());
 session.setExpireTolerance(this.expireTolerance);
 session.access();
 if(notifySessionListenersOnReplication)

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=561799&r1=561798&r2=561799
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Wed Aug  1 06:59:00 2007
@@ -103,7 +103,11 @@
  
 42689: No way to timeout new connect attempts for 
replication sockets. 
 Patch by Casey Lucas (pero)
-  
+
+   
+ Fix timeout setting on a replicated DeltaSession.
+ Patch by Alexander Maas (fhanik,pero)
+ 
 
   
 



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

Re: Juli/Logging

[Filip Hanik - Dev Lists]

David Blevins wrote:

So another topic,

There's a thread going on in OpenEJB at the moment about possibly 
switching away from log4j for the reason that the logging config gets 
easily messed up in embedded environments (maven, specificaly) and of 
course to have one less dependency -- the 3.0 server is a bit beefier 
than the 1.0.


I remembered not seeing log4j or commons logging in Tomcat 6 and 
started investigating -- how I discovered the inlining.  Seems juli is 
a trimmed down version of commons-logging (attractive), but it isn't 
obvious what's driving the actual logging.  Didn't see any inlined 
log4j classes.  Are you using java.util.Logging or something else?

java.util.logging J-U-L-I


Also noticed the javadoc of juli says it allows for per-classloader 
configuration of logging.  What exactly does that mean?




Thanks!

-David


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



--No virus found in this incoming message.
Checked by AVG Free Edition.Version: 7.5.476 / Virus Database: 
269.11.0/929 - Release Date: 7/31/2007 5:26 PM







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

DO NOT REPLY [Bug 43009] New: - Reported exception is not original cause of problem

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

   Summary: Reported exception is not original cause of problem
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In this method from org.apache.catalina.manager.ManagerServlet

protected void uploadWar(HttpServletRequest request, File war)
throws IOException {

...

BufferedOutputStream ostream = null;
try {
istream = request.getInputStream();
ostream =
new BufferedOutputStream(new FileOutputStream(war), 1024);
...
} catch (IOException e) {
war.delete();
throw e;
} finally {
  ...
}
   ...
}

If an Exception is thrown while creating the OutputStream to write the war (say
due to lack of write permission in appBase), the useful Exception thrown is
caught and the method attempts to clean up with a war.delete(); If an Exception
is thrown during the delete (as is quite likely), that is thrown out and logged
instead of the original more useful one.

So the catch block in the code above would be better written something like 
this:

} catch (IOException originalException) {
try {
  war.delete();
} catch (IOException deleteException)
  log("Unable to clean up following ["+originalException+"] due
to ["+deleteException+"]");
  throw originalException;
}
}

-- 
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 43009] - Reported exception is not original cause of problem

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 07:23 ---
Ooops, patch should have been:

} catch (IOException originalException) {
try {
  war.delete();
} catch (IOException deleteException)
  log("Unable to clean up following ["+originalException+"] due
to ["+deleteException+"]");
}
finally {
  throw originalException;
}
}

-- 
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 42720] - A large amount of No destination message

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 07:28 ---
I have test the patch for tomcat 5.5 and it works fine.
Filip can we also patch the 6.0 code base?

Peter

-- 
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 42934] - sessionDidActivate() called before contextInitialized()

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 07:21 ---
According to the servlet spec, the listeners are supposed to be called in the
order that they're declared in web.xml. Except at shutdown the session listeners
are supposed to be called before the context listeners.

So the question is, how are the listeners declared in web.xml?

(I don't know anything about how Seam integrates with Tomcat, but I guess there
must be a deployment descriptor somewhere with the  declarations.)

-- 
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: [VOTE] Release build 6.0.14

[Peter Rossbach]

+1

Am 31.07.2007 um 00:48 schrieb Remy Maucherat:


The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.14/

According to the release process, the 6.0.14 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ x] Stable

Rémy

-
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]

svn commit: r561803 - in /tomcat/container/tc5.5.x: modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java webapps/docs/changelog.xml

[pero]

Author: pero
Date: Wed Aug  1 07:09:41 2007
New Revision: 561803

URL: http://svn.apache.org/viewvc?view=rev&rev=561803
Log:
Don't send a message if no cluster member exists.

Modified:

tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java?view=diff&rev=561803&r1=561802&r2=561803
==
--- 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
 Wed Aug  1 07:09:41 2007
@@ -665,7 +665,7 @@
  * @param session
  */
 protected void sendCreateSession(String sessionId, DeltaSession session) {
-if(cluster.getMembers().length > 0 ) {
+if(cluster != null && cluster.getMembers().length > 0 ) {
 SessionMessage msg = new SessionMessageImpl(getName(),
 SessionMessage.EVT_SESSION_CREATED, null, sessionId,
 sessionId + "-" + System.currentTimeMillis());
@@ -1431,14 +1431,17 @@
  *session id
  */
 protected void sessionExpired(String id) {
-counterSend_EVT_SESSION_EXPIRED++ ;
-SessionMessage msg = new SessionMessageImpl(getName(),
-SessionMessage.EVT_SESSION_EXPIRED, null, id, id
-+ "-EXPIRED-MSG");
-if (log.isDebugEnabled())
-log.debug(sm.getString("deltaManager.createMessage.expire",
-getName(), id));
-send(msg);
+// FIX BUG 42720 : don't send a message if no cluster member exists.
+if (cluster != null && cluster.getMembers().length > 0) {
+counterSend_EVT_SESSION_EXPIRED++ ;
+SessionMessage msg = new SessionMessageImpl(getName(),
+SessionMessage.EVT_SESSION_EXPIRED, null, id, id
++ "-EXPIRED-MSG");
+if (log.isDebugEnabled())
+log.debug(sm.getString("deltaManager.createMessage.expire",
+getName(), id));
+send(msg);
+}
 }
 
 /**

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=561803&r1=561802&r2=561803
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Wed Aug  1 07:09:41 2007
@@ -108,6 +108,10 @@
  Fix timeout setting on a replicated DeltaSession.
  Patch by Alexander Maas (fhanik,pero)
  
+   
+ 42720: Don't send a message if no cluster member exists.
+ Patch by Keiichi Fujino (pero)
+   
 
   
 



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

DO NOT REPLY [Bug 43009] - Reported exception is not original cause of problem

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 07:37 ---
Rather File.delete throws a SecurityException, not an IOException so it should
have been:

} catch (IOException originalException) {
try {
  war.delete();
} catch (Exception deleteException)
  log("Unable to clean up following ["+originalException+"] due
to ["+deleteException+"]");
}
finally {
  throw originalException;
}
}

-- 
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 42934] - sessionDidActivate() called before contextInitialized()

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 08:05 ---
> According to the servlet spec, the listeners are supposed to be called in the
> order that they're declared in web.xml. Except at shutdown the session 
> listeners
> are supposed to be called before the context listeners.
> 
> So the question is, how are the listeners declared in web.xml?
> 
> (I don't know anything about how Seam integrates with Tomcat, but I guess 
> there
> must be a deployment descriptor somewhere with the  declarations.)

Yes, Seam has a listener.  And at shutdown in Tomcat 6 the Session Listeners are
correctly called before the Servlet Listeners.  The problem is that at server
'startup' the session listeners are also called before the Servlet Listeners
which is causing trouble for Seam since Seam needs contextInitialized() to be
called before sessionDidActivate().

Mike



-- 
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 42934] - sessionDidActivate() called before contextInitialized()

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 08:27 ---
You missed my point. The order in which the listeners are called depends (in
part) on the order in which they are declared. The behaviour that you describe
could be perfectly correct according to the servlet spec, *depending on how the
listeners are declared*. For more details, see section 10.3.3 and 10.3.4 of the
servlet specification.

Here is a concrete example. Suppose web.xml contains these declarations:


com.example.MySessionListener


com.example.MyContextListener


In this example, on startup the session listener will be called before the
context listener (according to section 10.3.3 of the servlet spec). On shutdown,
the session listener will again be called before the context listener (according
to section 10.3.4).

Another possibility is that a single listener class implements two listener
interfaces. In that case, the spec doesn't say what order they should be called
on startup. I guess if the listeners need to be called in a certain order, they
need to be implemented in separate classes so that you can specify the order.

So, how are the listeners declared in your case?
Please post the contents of web.xml, or just the part with the 
declarations.


-- 
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 42934] - sessionDidActivate() called before contextInitialized()

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 08:41 ---
I see the confusion.  When I say Session Listener I was talking about a class
that implements HttpSessionActivationListener where you were thinking I meant an
HttpSessionListener.  When HttpSessionActivationListeners are not declared in
the web.xml but are automatically called by the container when the instance
passivates and activates instances stored in the Session.

So what I'm saying is that I would expect the
ServletContextListener.contextInitialized() to be called before
HttpSessionActivationListener.sessionDidActivate().

When shutting down ServletContextListener.contextDestroyed() is currently
correctly called after HttpSessionActivationListener.sessionWillPassivate().

Does that clear things up?

-- 
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 42996] - POST with nio connector results in missing variables

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||WORKSFORME
Version|unspecified |6.0.13




--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 09:06 ---
A day later, things still seem OK, so at this point I'm comfortable saying that
it's fixed in 6.0.14.

-- 
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 42934] - sessionDidActivate() called before contextInitialized()

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 10:29 ---
Sorry, you're right, I forgot about HttpSessionActivationListener objects being
stored in the session itself.

As far as I can see, the spec doesn't say what order these events are fired
relative to the other types of events. Your idea that contextInitialized should
come before sessionDidActivate sounds reasonable, but you may be stuck in the
trap of "Tomcat follows the spec so it doesn't need to be fixed."


-- 
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 42934] - sessionDidActivate() called before contextInitialized()

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





--- Additional Comments From [EMAIL PROTECTED]  2007-08-01 10:31 ---
Ya, that's the trap I'm afraid of. :)  I'm hoping that because it is a Seam
problem perhaps Jboss might be able to assert some of their influence over
tomcat to get them to fix itbut I guess we'll see.  Thanks for looking at
the issue.

-- 
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: Inlining dependencies

[Jason Corley]

> I absolutely despise how that is built. It makes building that jar a
> complete NIGHTMARE. Presently we do not offer than jar on Gentoo and I
> have no plans to. Or worse potential ways to.

Before I mention how we solved this problem for JPackage let me say
that I agree with William that this sort of thing makes the packager's
job needlessly complicated.  I've never been fond of the technique but
I need JNDI resources to work out of the box so I had to come up with
a solution.

It took us quite a while in JPackage to come up with something that
did not require the tomcat SRPM to be distributed with three
additional projects sources or to heavily patch tomcat itself.
Eventually we settled on a custom ant task (written by Matt Wringe) for
jakarta-commons-{collections,dbcp,pool} packages that generates the
repackaged org.apache.tomcat.dbcp as part of a -tomcat5 subpackage (I
wish now I'd thought to name them without the trailing five).   The
benefit is that it is now all part of the j-c-{collections,dbcp,pool}
build process, and the resulting subpackage is not installed by
default and not required by anything other than tomcat.  Convoluted
admittedly, but it allows us to keep the versions in sync globally
while allowing JNDI resources to work from a built from source
solution.  I've been using this solution in a couple of production
environments with no problems.

Jason

P.S. If anyone is interested in the ant build.xml stubs they are here:

http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/jakarta-commons-collections/collections-tomcat5-build.xml?revision=1.1.2.1&root=jpackage&view=markup&pathrev=JPACKAGE-1_7
http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/jakarta-commons-dbcp/dbcp-tomcat5-build.xml?revision=1.1.2.4&root=jpackage&view=markup&pathrev=JPACKAGE-1_7
http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/jakarta-commons-pool/pool-tomcat5-build.xml?revision=1.1.2.4&root=jpackage&view=markup&pathrev=JPACKAGE-1_7

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

Re: Juli/Logging

[David Blevins]

On Aug 1, 2007, at 1:30 AM, Rainer Jung wrote:


David Blevins wrote:
My personal opinion: java.util.logging very much lacks a good  
formatter. The default 2 line formatting of messages, splitting  
timestamps and message in separate lines, is not really useful in  
production. Many ad hoc log analysis practices work on a line  
oriented basis.
Was wondering about that.  I've heard people grumble about  
java.util.logging, but haven't (till now) heard anything  
specific.  Maybe I wasn't paying close enough attention, but the  
Tomcat 6 log files still seem to follow the one line per message  
format.  How did you pull that off?


That's what I get:

Aug 1, 2007 10:26:37 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-28680
Aug 1, 2007 10:26:37 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2854 ms
Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.13
Aug 1, 2007 10:26:40 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-28680

One line for timestamp, class and method, a second line for log  
level and message. That's the format of the default formatter, the  
simple log format.


That's why it would be nice if someone took the burden of writing a  
better log formatter for j.u.l.


Got it.  Yea, that format is certainly grep unfriendly.

Looks like Harmony has a formatter we could copy from and fix to not  
add the new line.


  http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/ 
modules/logging/src/main/java/java/util/logging/SimpleFormatter.java



-David


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

Re: Juli/Logging

[Rainer Jung]

That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


Got it.  Yea, that format is certainly grep unfriendly.

Looks like Harmony has a formatter we could copy from and fix to not add 
the new line.


http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java 


Yes, that could be a good starting point (although that implementation 
does not care about localization).


Thanks for the pointer!

Regards,

Rainer

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

Re: Inlining dependencies

[William L. Thomson Jr.]

Jason,

On Wed, 2007-08-01 at 14:01 -0400, Jason Corley wrote:
> 
> It took us quite a while in JPackage to come up with something that
> did not require the tomcat SRPM to be distributed with three
> additional projects sources or to heavily patch tomcat itself.
> Eventually we settled on a custom ant task (written by Matt Wringe)
>
> P.S. If anyone is interested in the ant build.xml stubs they are here:

Thank you very much for sharing info on how you all were able to come up
with a solution. It's very possible I will see about adapting something
similar based on what you all are doing. Really want to close the long
standing bug, and provide a whole and complete tomcat from source on
Gentoo. :)

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

svn commit: r562006 - in /tomcat/site/trunk: docs/security-3.html xdocs/security-3.xml

[markt]

Author: markt
Date: Wed Aug  1 20:16:38 2007
New Revision: 562006

URL: http://svn.apache.org/viewvc?view=rev&rev=562006
Log:
Add info on CVE-2007-3384

Modified:
tomcat/site/trunk/docs/security-3.html
tomcat/site/trunk/xdocs/security-3.xml

Modified: tomcat/site/trunk/docs/security-3.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-3.html?view=diff&rev=562006&r1=562005&r2=562006
==
--- tomcat/site/trunk/docs/security-3.html (original)
+++ tomcat/site/trunk/docs/security-3.html Wed Aug  1 20:16:38 2007
@@ -237,6 +237,18 @@
There are no plans to issue a an update to Tomcat 3.x for this 
issue.
 
 Affects: 3.0, 3.1-3.1.1, 3.2-3.2.4, 3.3a-3.3.2
+
+
+low: Cross site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3384";>
+   CVE-2007-3384
+
+
+When reporting error messages, Tomcat does not filter user supplied data
+   before display. This enables an XSS attack. A source patch is available
+   from the Tomcat 3 download page.
+
+Affects: 3.3-3.3.2
   
 
 

Modified: tomcat/site/trunk/xdocs/security-3.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-3.xml?view=diff&rev=562006&r1=562005&r2=562006
==
--- tomcat/site/trunk/xdocs/security-3.xml (original)
+++ tomcat/site/trunk/xdocs/security-3.xml Wed Aug  1 20:16:38 2007
@@ -36,6 +36,16 @@
There are no plans to issue a an update to Tomcat 3.x for this 
issue.
 
 Affects: 3.0, 3.1-3.1.1, 3.2-3.2.4, 3.3a-3.3.2
+
+low: Cross site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3384";>
+   CVE-2007-3384
+
+When reporting error messages, Tomcat does not filter user supplied data
+   before display. This enables an XSS attack. A source patch is available
+   from the Tomcat 3 download page.
+
+Affects: 3.3-3.3.2
   
 
   



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

CVE-2007-3384: XSS in Tomcat cookies example

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2007-3384: XSS in Tomcat cookies example

Severity:
Low (Cross-site scripting)

Vendor:
The Apache Software Foundation

Versions Affected:
3.3 to 3.3.2

Description:
When reporting error messages, Tomcat does not filter user supplied
data before display. This enables an XSS attack.

Mitigation:
Remove examples web application.
Apply patch available from http://tomcat.apache.org/download-33.cgi

Credit:
This issue was discovered by Tomasz Kuczynski, Poznan Supercomputing
and Networking Center, who worked with the CERT/CC to report the
vulnerability.

Example:
http://localhost:8080/examples/servlet/CookieExample
populate Name or Value field with:
alert('XSS reflected');
and submit.

References:
http://tomcat.apache.org/security.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGsU0Vb7IeiTPGAkMRAoiwAJ4iETiZnDPLKM0v69YZ/FaIhGS8GwCgt+ux
FB0O3FigwHs+A8pP98+gRiA=
=VePF
-END PGP SIGNATURE-

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

svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

[mturk]

Author: mturk
Date: Wed Aug  1 23:06:18 2007
New Revision: 562022

URL: http://svn.apache.org/viewvc?view=rev&rev=562022
Log:
Fix the 401 not passed to the client.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?view=diff&rev=562022&r1=562021&r2=562022
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Wed Aug  1 23:06:18 
2007
@@ -2159,7 +2159,8 @@
 if (rc > 0) {
 /* If tomcat returned no body and the status is not OK,
let apache handle the error code */
-if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST) {
+if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST &&
+ r->status != HTTP_UNAUTHORIZED) {
 jk_log(conf->log, JK_LOG_INFO, "No body with status=%d"
" for worker=%s",
r->status, worker_name);

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diff&rev=562022&r1=562021&r2=562022
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Wed Aug  1 23:06:18 
2007
@@ -2250,7 +2250,8 @@
 
 /* [EMAIL PROTECTED] : under i5/OS sent_bodyct is not set correctly */
 /*   check for header_only to see if there was a body */
-if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST) {
+if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST &&
+ r->status != HTTP_UNAUTHORIZED) {
 jk_log(xconf->log, JK_LOG_INFO, "No body with status=%d"
" for worker=%s",
r->status, worker_name);

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diff&rev=562022&r1=562021&r2=562022
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Wed Aug  1 
23:06:18 2007
@@ -23,6 +23,16 @@
   new documentation project for JK was started.
   
 
+
+  
+  
+
+  
+Pass the 401 as OK instead sending 401 for authentication. (mturk)
+  
+
+  
+
 
   
   



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

svn commit: r562025 - in /tomcat/connectors/trunk/jk/native: common/jk_version.h iis/installer/isapi-redirector-win32-msi.ism iis/isapi_redirect.rc

[mturk]

Author: mturk
Date: Wed Aug  1 23:10:29 2007
New Revision: 562025

URL: http://svn.apache.org/viewvc?view=rev&rev=562025
Log:
Increment version to 1.2.25-dev

Modified:
tomcat/connectors/trunk/jk/native/common/jk_version.h

tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism
tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc

Modified: tomcat/connectors/trunk/jk/native/common/jk_version.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_version.h?view=diff&rev=562025&r1=562024&r2=562025
==
--- tomcat/connectors/trunk/jk/native/common/jk_version.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_version.h Wed Aug  1 23:10:29 
2007
@@ -26,14 +26,14 @@
 /** START OF AREA TO MODIFY BEFORE RELEASING */
 #define JK_VERMAJOR 1
 #define JK_VERMINOR 2
-#define JK_VERFIX   24
-#define JK_VERSTRING"1.2.24"
+#define JK_VERFIX   25
+#define JK_VERSTRING"1.2.25"
 
 /* Beta number */
 #define JK_VERBETA  0
 #define JK_BETASTRING   "0"
 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */
-#define JK_VERISRELEASE 1
+#define JK_VERISRELEASE 0
 #define JK_VERRC0
 #define JK_RCSTRING "0"
 

Modified: 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism?view=diff&rev=562025&r1=562024&r2=562025
==
--- 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism 
(original)
+++ 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism 
Wed Aug  1 23:10:29 2007
@@ -3409,7 +3409,7 @@
ProductIDnone
ProductLanguage1033
ProductNameTomcat Isapi 
Redirector
-   ProductVersion1.2.24
+   ProductVersion1.2.25
ProgressType0install
ProgressType1Installing
ProgressType2installed

Modified: tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc?view=diff&rev=562025&r1=562024&r2=562025
==
--- tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc (original)
+++ tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc Wed Aug  1 23:10:29 
2007
@@ -14,13 +14,13 @@
 "specific language governing permissions and " \
 "limitations under the License."
 
-#define JK_VERSION_STR  "1.2.24"
+#define JK_VERSION_STR  "1.2.25"
 #define JK_DLL_BASENAME "isapi_redirect-" JK_VERSION_STR
 
 
 1 VERSIONINFO
- FILEVERSION 1,2,24,0
- PRODUCTVERSION 1,2,24,0
+ FILEVERSION 1,2,25,0
+ PRODUCTVERSION 1,2,25,0
  FILEFLAGSMASK 0x3fL
 #if defined(_DEBUG)
  FILEFLAGS 0x01L



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

Serious regression in JK 1.2.24

[Mladen Turk]

Hi,

We have a problem with 1.2.24 that luckily is not security leak,
but it is security related.

The problem is that 401 from Tomcat without body
(a standard HTTP_UNAUTHORIZED) is treated as 401, meaning
that Apache is returning 401 page instead passing 401
to the client.

I already patched the SVN.
Can we roll 1.2.25?

Regards,
Mladen.

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