-
1. Re: i18 logging
ataylor Mar 14, 2012 6:00 AM (in response to ataylor)regarding 1 i think we should have 1 logger/bundle per maven module or layer, so:
org.hornetq.core.server
org.hornetq.core.client
org.hornetq.jms.server
org.hornetq.jms.client
org.hornetq.ra
org.hornetq.as.integration
org.hornetq.bootstrap
org.hornetq.util (for commons)
org.hornetq.spring
org.hornetq.twitter
org.hornetq.service
this way we can handle a module at a time in parallel
what do people think?
-
2. Re: i18 logging
ataylor Mar 14, 2012 6:26 AM (in response to ataylor)just so you know the logging will look like
15:45:18,531 INFO [org.hornetq.core.server] HQ001001: live server is starting with configuration HornetQ Configuration ........
The id is the project code 'HQ' which we can change and the id of the message, we should probably be consistent around these, first digit for the module, 2nd for the level, i.e. info = 1. warn = 2 etc and the rest the message id.
-
3. Re: i18 logging
jbertram Mar 14, 2012 11:35 PM (in response to ataylor)- I agree that we should have 1 logger/bundle per module.
- What's stopping us from doing it on trunk and cutting the next release for AS7 from that? Having trunk, AS7, and EAP branches is a big head-ache IMO. Obviously we have to have a separate branch for EAP, but why separate branches for AS7 and trunk?
- Which one here is simpler in the long run? Is changing HornetQException a bad thing?
- What exactly do you mean by format? In any case, I think we should make standalone and what goes in AS7 as close as possible.
-
4. Re: i18 logging
clebert.suconic Mar 22, 2012 4:23 PM (in response to jbertram)It was my understanding it wasn't needed to have debug / trace converted.. and I have seen many DEBUGs being converted.
DEBUG / TRACE should be kept in English, right?
-
5. Re: i18 logging
clebert.suconic Mar 22, 2012 4:25 PM (in response to clebert.suconic)One issue I have against jboss-logging is that jboss-logging extensively uses SimpleDataFormat, which is really single threaded.
During the EAP tests there were several tests that would fail without logging, and would pass when setting TRACE, and the reason was that our old log format had a single point of synchronziation. After removing that debugging was much easier.
-
6. Re: i18 logging
clebert.suconic Mar 22, 2012 4:30 PM (in response to jbertram)I think we can keep this on master only... and have it being moved on the next release... The way you guys are doing so far.
It's just that we don't need DEBUG/TRACE.. that would be a lot of messages...
And I'm really, really concerned about the SimpleDateFormat... it means it's impossible to debug anything in trace mode which is a big deal for a message system (where things are really happening in multi-thread).
If you guys remember we have had lots of issues where we couldn't debug with trace in the past and this is a bit better recently, right? This was becuase of the change I have made into our Logger.
-
7. Re: i18 logging
jbertram Mar 22, 2012 9:13 PM (in response to clebert.suconic)I think having different levels of messages using different logging implementations would be a bit of a mess. There would be two places to configure formatting etc., and it isn't clear to me that they would even be able to log to the same file. Even if DEBUG and TRACE level messages don't need internationalization I think they should still use JBoss Logging.
-
8. Re: i18 logging
clebert.suconic Mar 22, 2012 4:48 PM (in response to jbertram)It's a bit messy to me why a Logging library is also controlling internationalization.. Why such functionality is not isolated outside of logging?
Anyway.. I'm not complaining about the use of JBoss Logging... I'm complaining about the fact that JBoss Logging is using SDF which is a big no from my point of view. There should be an alternative inside JBoss Logging to avoid that.
-
-
10. Re: i18 logging
ataylor Apr 16, 2012 9:21 AM (in response to clebert.suconic)I'm going to get these merged a module at a time, the last rebase i did i had lots of conflicts to fix. It will mean we will have 2 logging impls for a bit but i think we can live with that. If anyone has any issues with this let me know.
core is done and I will get this pulled today, @Francisco, could you check any areas where you have made lots of changes, im thinking about around hornetqaserverimpl and replication code, it should be ok tho.
One issue i have discovered is to do with the client jar, currently we have one logging class that the client will use, however this imports lots of non client code, this will need fixing, anyone have any ideas on how best to approach this?
-
11. Re: i18 logging
clebert.suconic Apr 16, 2012 10:59 AM (in response to ataylor)One issue i have discovered is to do with the client jar, currently we have one logging class that the client will use, however this imports lots of non client code, this will need fixing, anyone have any ideas on how best to approach this?
We may need to add new jars to the client for the new logging stuff. What server stuff is depending on now?