11 Replies Latest reply: Apr 16, 2012 10:59 AM by Clebert Suconic RSS

i18 logging

Andy Taylor Master

I have created a new branch at https://svn.jboss.org/repos/hornetq/branches/i18n_logging/hornetq-core/src/main/resources/org/hornetq/core/server/impl/ that contains a small prototype of how the new logging will work, basically ive added a logger and changed the logging in HornetQSErverImpla couple of things to look at:

 

HornetQLogger is a basic logger for normal log messages.

 

HornetQMessageBundle contains messages and exceptions.

 

so we need to decide:

 

1) How many logger and messgae bundle classes do we need and where, currently we do it at a class level but i think we should either:

     a) have just 1 logger and bundle

     b) do it on a package level

     c) do it on a component level, i.e. server, client etc

 

2) How best to attack doing this, we need to do it on both trunk and the AS7 branch

 

3) how we handle exceptions, if you look at the bundle/hornetqserverimpl there are 2 ways to do this, either by creating the exception in the bundle or just creating the message for the exception, the first requires a slight code change on HornetQException.

 

4) what format we want for standalone, for now i have taken it from the AS7 project

 

comments?

 

btw a downside is that we need to ship jboss logging 3 as a dependency

  • 1. Re: i18 logging
    Andy Taylor Master

    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
    Andy Taylor Master

    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
    Justin Bertram Master
    1. I agree that we should have 1 logger/bundle per module.
    2. 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?
    3. Which one here is simpler in the long run?  Is changing HornetQException a bad thing?
    4. 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 Master

    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 Master

    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 Master

    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
    Justin Bertram Master

    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 Master

    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
    Andy Taylor Master

    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 Master

    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?