Details
-
Type:
Improvement
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.3
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
Description
This past month, I introducted a person to PicoContainer using the NanoContainer-JSF integration. One of the problems we had was that there weren't quite enough logging messsages for him to figure out any errors he was encountering.
To that end, I created a Tracing Decorator (in this case based on log4j).
I thought it might be useful for PicoContainer-Gems.
-Mike
Activity
I used it for a specific configuration issue, but I pretty much plan on leaving it there.
The particular issue is that ComponentMonitor does not log if a particular component was NOT found in the container. In this case, a client was running the JSF-NanoWAR integration and he hadn't properly set up the groovy configuration, but nothing was getting logged.
So its an attempt at increasing the amount of output to help a client that was unfamiliar with Pico/Nano.
Unfortunately, I've lost our client to Sp**** (I'll censor that 6 letter word! 
), but hopefully in the future, I can use this to get newbies the level of information they need to better understand what's going on.
-Mike
Michael Rimov
added a comment - I used it for a specific configuration issue, but I pretty much plan on leaving it there.
The particular issue is that ComponentMonitor does not log if a particular component was NOT found in the container. In this case, a client was running the JSF-NanoWAR integration and he hadn't properly set up the groovy configuration, but nothing was getting logged.
So its an attempt at increasing the amount of output to help a client that was unfamiliar with Pico/Nano.
Unfortunately, I've lost our client to Sp**** (I'll censor that 6 letter word! ), but hopefully in the future, I can use this to get newbies the level of information they need to better understand what's going on.
-Mike
Well, in this case I'd rather extend the ComponentMonitor with a new call.
Jörg Schaible
added a comment - Well, in this case I'd rather extend the ComponentMonitor with a new call. And correct me if I'm wrong, but since no ComponentAdapter is retrieved, I fail to see how the message of "no component found" can be propagated to the ComponentMonitor. (Only the lifecycle manager has the reference ultimately)
It seems like a lot of surgery and a fair amount of breaking backwards compatibility to me.
Don't get me wrong, that's the first thing I thought of as well, it just didn't seem feasible to me.
-Mike (R)
Michael Rimov
added a comment - And correct me if I'm wrong, but since no ComponentAdapter is retrieved, I fail to see how the message of "no component found" can be propagated to the ComponentMonitor. (Only the lifecycle manager has the reference ultimately)
It seems like a lot of surgery and a fair amount of breaking backwards compatibility to me.
Don't get me wrong, that's the first thing I thought of as well, it just didn't seem feasible to me.
-Mike (R) Checked in with test cases.
I'm happy to refactor into something different if desired.
Michael Rimov
added a comment - Checked in with test cases.
I'm happy to refactor into something different if desired. Michael Rimov
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 1.3 [ 11331 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
It would be nice to have also a commons logging implementation. The Monitor has this also. Background: Some big players use own logging frameworks and with c-l it is easy to route the logging to their home-grown implementation.
Jörg Schaible
added a comment - It would be nice to have also a commons logging implementation. The Monitor has this also. Background: Some big players use own logging frameworks and with c-l it is easy to route the logging to their home-grown implementation. I would altogether replace the Log4j implemention with Commons Logging, which can be used with Log4j as the underlying logger - unless Mike has a reason for the Log4j impl.
Also - Mike, minor comment: syntax of @since tag should be @since 1.3 AFAIK.
Mauro Talevi
added a comment - I would altogether replace the Log4j implemention with Commons Logging, which can be used with Log4j as the underlying logger - unless Mike has a reason for the Log4j impl.
Also - Mike, minor comment: syntax of @since tag should be @since 1.3 AFAIK.
I don't mind introducing the Commons-Logging implementation. I'm not particularly for transforming the Log4j into Commons-Logging because I too, have been bit by the Commons-Logging autodiscovery issues when it comes to classloading. So I'll get on it.
Mauro, thanks for the @since tag tip. For those watching the discussion:
http://java.sun.com/j2se/javadoc/writingdoccomments/#@since
backs up what Mauro's saying.
Michael Rimov
added a comment - I don't mind introducing the Commons-Logging implementation. I'm not particularly for transforming the Log4j into Commons-Logging because I too, have been bit by the Commons-Logging autodiscovery issues when it comes to classloading. So I'll get on it.
Mauro, thanks for the @since tag tip. For those watching the discussion:
http://java.sun.com/j2se/javadoc/writingdoccomments/#@since
backs up what Mauro's saying.
The problems with c-l have been solved with 1.1.
Jörg Schaible
added a comment - The problems with c-l have been solved with 1.1. CommonsLogging version checked in.
-Mike (R)
Michael Rimov
added a comment - CommonsLogging version checked in.
-Mike (R) 
Sure Mike, chuck it in gems.
I see that it does more that the ComponentMonitor. Did you use yours to overcome a specific configuration/assembly issue and then take it out of the live release? Or did you leave it in for general debugging?