DO NOT REPLY [Bug 26171] - NullPointerException in AccessLogValve

2004-01-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26171.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

NullPointerException in AccessLogValve

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-15 16:20 ---
Added a null check in the relevant method, which will generate a new date 
object only if needed.  I wonder why the lifecycle start wasn't taking care of 
this.

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



Re: DO NOT REPLY [Bug 26171] - NullPointerException in AccessLogValve

2004-01-15 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26171.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

NullPointerException in AccessLogValve

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Additional Comments From [EMAIL PROTECTED]  2004-01-15 16:20 ---
Added a null check in the relevant method, which will generate a new date 
object only if needed.  I wonder why the lifecycle start wasn't taking care of 
this.
It was.

public void start() throws LifecycleException {

// Validate and update our current component state
if (started)
throw new LifecycleException
(sm.getString(accessLogValve.alreadyStarted));
lifecycle.fireLifecycleEvent(START_EVENT, null);
started = true;
// Initialize the timeZone, Date formatters, and currentDate
TimeZone tz = TimeZone.getDefault();
timeZone = calculateTimeZoneOffset(tz.getRawOffset());
if (fileDateFormat==null || fileDateFormat.length()==0)
fileDateFormat = -MM-dd;
dateFormatter = new SimpleDateFormat(fileDateFormat);
dateFormatter.setTimeZone(tz);
dayFormatter = new SimpleDateFormat(dd);
dayFormatter.setTimeZone(tz);
monthFormatter = new SimpleDateFormat(MM);
monthFormatter.setTimeZone(tz);
yearFormatter = new SimpleDateFormat();
yearFormatter.setTimeZone(tz);
timeFormatter = new SimpleDateFormat(HH:mm:ss);
timeFormatter.setTimeZone(tz);
currentDate = new Date();
dateStamp = dateFormatter.format(currentDate);
timeTakenFormatter = new DecimalFormat(0.000);
open();

}

I think it could be some other bug, but I don't know for sure. It could 
have been working already.
However, never use the install/remove tasks. Always point out they're 
deprecated in favor of deploy/undeploy.

I have a test .war like that (struts-example), with a context.xml and 3 
access log valves in it (there was a bug if you had more than once of 
the same valve in the pipeline), and it works: deploy / undeploy / 
retsart / etc.

I won't integrate the patch in 5.0.18 (if start of the valve doesn't get 
called, it's a much bigger problem).
It could be a concurrent request which went in too soon, who knows.

Rémy



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