logging notes from call
by John Mazzitelli
Here's the notes from our call this morning regarding the use of jboss logging - chime in if I got something wrong, or if you disagree (say, for example, we should use some other third party logging framework rather than JBoss Logging :-)
Here's an example from Undertow:
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
We agreed that Hawkular will not use this mechanism for DEBUG or TRACE level messages, but will use it for INFO, WARN, ERROR, and FATAL.
In our message interfaces, we can do what undertow does - that is, declare the logger instance right in the interface, for example, put this in your MsgLogger interface:
MsgLogger LOGGER = Logger.getMessageLogger(MsgLogger.class, MsgLogger.class.getPackage().getName());
Each major component will have its own logging prefix (alerts will have, for example, "HAWKALRT" or whatever they want to call it; metrics will have "HAWK-METRICS" or whatever; inventory another like "HAWKINV"). Each major component will then divy up the ID ranges how it sees fit.
It is most likely useful to have one logging interface per maven module within the major component; however, this is up to the developers how they want to separate or combine their messages - one uber interface or one per maven module or something else. but just keep in mind the pros and cons of each (e.g. if you have one uber interface, all of your maven modules will have a dependency on it - and if you add a message, all maven modules that depend on it will need to rebuild with it, even if they don't need the message - plus, all your developers will need to edit the same file throughout development, so there will be alot of git pulling, merging, and conflict resolutions).
Note that in my work, I put one message interface in each maven module that needs messages. I put them in a package called .log and I named them all "MsgLogger". I don't know if its the right thing to do to name them all the same - but having the package names differentiate them was all I needed so far to be able to find them when I needed to edit them in Eclipse (I just searched for "MsgLogger" and I got the full list of all my message loggers in the search window - each for me to pick which one I wanted). Again, time will tell if I should have named them differently rather than all the same - I really don't have an opinion either way. I don't have good argument for naming them the same OR naming them differently. Up to you what to do.
To log ad-hoc messages in the debug and trace level, you'll need to define a JBoss Logging Logger like this:
private final Logger log = Logger.getLogger(YourClass.class);
and use debugf to log debug messages as an example:
log.debugf("This is the first arg [%d] and this is the second [%s].", myNum, myStr);
We are hopefully going to have the parent pom declare the logging processor for us, so you only should have to declare logging deps in your maven modules, and the log code generation will just work. You need these two deps:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-annotations</artifactId>
<scope>provided</scope>
</dependency>
9 years, 3 months
Status on IRC
by Peter Palaga
Dear colleagues,
please consider adding some meaningful suffix such as
|afk
or
_away
to your IRC nick whenever you do not work so that others have a chance
to estimate if it is worth asking you anything at the given time.
Thanks,
Peter
9 years, 3 months
Time for BoM
by Peter Palaga
Hi *,
now that hk projects start to switch to jboss logging, it seems to be
inevitable to introduce the internal BoM in some form.
The task is basically to manage the common dependencies (such as
jboss-logging) of hk projects in a central place.
I see two options:
(a) put all to hawkular-parent
(b) introduce a new artifact called "hawkular-dep" in
hawkular-parent-pom repo. (I use "hawkular-dep" because "hawkular-bom"
should stay reserved for an "external BoM" that would contain only our
public APIs targeted at hawkular customers.)
Pros and cons
(b) is kind of cleaner, not mixing the build configuration with
dependency management. But I do not see any necessity in preferring (b)
With (a), it would be easier for the hk projects to consume the
depManagement (they would not need to import the BoM).
And even with (a), if a project cannot use hawkular-parent as its parent
for some reason, it still can import hawkular-parent in its
depentencyManagement as it would import any stock BoM.
I am going to try (a) if no one vetoes it within a reasonable time.
Thanks,
Peter
9 years, 3 months
checkstyle/enforcer
by John Mazzitelli
I just converted the bus code to use hawkular-parent which in turn brought checkstyle/enforcer into play.
I highly recommend everyone do this for your code as soon as you can - the earlier you integrate parent, and especially checkstyle/enforcer, the easier it will be on yourself. Lots of checkstyle and enforcer errors in my stuff that I had to go about fixing... you don't want to do this after you have lots of code that needs to be cleaned up.
9 years, 3 months
logging ID ranges
by John Mazzitelli
I would like to make a recommendation for logging range IDs for the different components.
Right now, the default width of IDs are 6 characters (they can be more or less, but that's the default). I'm assuming we all will use HAWK as the prefix (as opposed to HAWK vs. HAWKMETRICS vs. HAWKALERTS, etc).
Through my experience integrating this logging stuff the past few days in the bus modules, I've come to appreciate the fact that we should probably give more range than just 1000 IDs to a major component. I don't know exactly how to do it, but I found it easier to split the ranges up to my subcomponents when using the full 6-characters. This allows you to create multiple MessageLogger classes (one per maven module is what I think would be typical - especially if one module doesn't depend on others) and you can break your main range up into subranges, while still having enough IDs left for actual logs.
For example, suppose metrics has four subcomponents (and I'm just making this up) - metrics-aggregator, metrics-collector, metrics-ui, metrics-purge. Now, suppose metrics was given the range 1000-1999. Each subcomponent would only have 250 IDs each if you assign them their own subrange. If you don't, if you just give them all 1000 then you will probably only have a single MessageLogger for all 4, and that will get ugly (MessageLogger would live in one module, and they all would need to depend on it, and any new log message would require all modules to recompile, even if the other modules don't need that message).
So what I say is we give metrics the ID range (e.g.) HAWK-200000 to HAWK-299999. Each subcomponent could then be given:
metrics-aggregator = 200000-200999
metrics-collector = 201000-201999
metrics-ui = 202000-202999
metrics-purge = 203000-203999
So you can see each still has room for 1,000 message IDs individually with room for 100 subcomponents (that's the first three digits of the ID - 200-299).
Alerts would then be given the range HAWK-300000 to HAWK-399999 and it does the same thing.
Obviously, this can be tweeked; you can say the first two digits are the component (20-29) giving you room for 10 subcomponents, with each subcomponent now able to have 10,000 messages (e.g. 200000-209999).
Or we can give each their own prefix (HAWK vs HAWKMETRICS) giving each the full 6-digit ID range all to themselves.
In any event, if you haven't tried coding up log messages with this Jboss logging message ID stuff, I suggest you do it, and see what kinds of issues you will see crop up (mainly it deals with what ranges of IDs get assigned to what MessageLoggers and how many MessageLoggers do you create and where).
We don't want to do this wrong - it will be headaches later on in the future when we realize we handed out the IDs ranges poorly or we created MessageLoggers in the wrong places.
I'm not advocating any specific approach, but we need to think about this - this isn't one of those things where everyone can go rogue. Unless we give everyone their own id prefix (HAWK vs. HAWKMETRICS, for example) in which case, go crazy :)
9 years, 3 months