On 9/3/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
Version 0.9.4. I have the logging bundles listed first in the pax runner pom config file, and they show up first in the order in equinox bundle list, but does that mean they met the criteria of being started first? i'm not sure about that.
It is difficult to understand exactly what is going on with logger.. i plan to dig into it more today or tomorrow, but it would be nice if logger had more information about what was configured etc. As it is, it is hard for me to figure out the path of my logging output and which components/bundles are involved.
My goal is to get a file logger setup for each of my bundles in a /log directory, wich each file having the name of the bundle. such as /log/<bundleName>.log
Not sure i understand you here, you saing Log4J-ConfigFile option is not something that should be used? I'm not well versed with OSGi central administration, so i'm just trying to get each logger sending output to its own file. Right the log output from different bundles to the console are getting intermixed and the logs are unreadable.
Ya, that was the reason for this email, to get an idea of what *should* work, so i know to say away from headaches related to stuff that doesn't.
On 9/3/06, Kabe < [EMAIL PROTECTED]> wrote:I'm having some trouble getting Pax Logging working for my bundles. I am including only the provided dependency of JCL for each bundle. Each bundle has a MANIFEST.MF entry with Log4J-LoggerName and Log4J-ConfigFile, which points to a bundle root log4j.properties. In my configuration for Pax Runner i'm including the dependency of API, LOG4J, JCL, and SERVICE bundles.
However this doesn't seem to work, it never picks up my log4j.properties, and the output looks like it is default JCL output. I have almost no other bundles loaded other then some basic core bundles for equinox.
One important piece missing; Which version?
IIRC, we have released a Pax Logging last week or so, which included a patch with a nasty side-effect. IF, the Legacy API bundle (JCL) is not started before the client bundle start using it, then it defaults to System.out output and will not 're-route' when things get up and operational, which IMHO is worse than the previous exception and refusal to start the client bundle.
Combining that with Pax Runner which yet doesn't allow start levels, and KF doing asynchronous starts, and you might have these kinds of problems.
Version 0.9.4. I have the logging bundles listed first in the pax runner pom config file, and they show up first in the order in equinox bundle list, but does that mean they met the criteria of being started first? i'm not sure about that.
It is difficult to understand exactly what is going on with logger.. i plan to dig into it more today or tomorrow, but it would be nice if logger had more information about what was configured etc. As it is, it is hard for me to figure out the path of my logging output and which components/bundles are involved.
My goal is to get a file logger setup for each of my bundles in a /log directory, wich each file having the name of the bundle. such as /log/<bundleName>.log
Hmmm, I don't think this has been removed (yet). It is meant more for debugging/development and not for production, when it is more likely to have a central admin of all logging configurations. Need to check that tomorrow when I am back in the office.Is this supposed to work? Do i just need to fight the configuration a bit more? I've read the Pax Logging wiki page a few dozen times and haven't found anything i'm not doing.
Does anyone have this working for their bundle, where the bundle is using just JCL and they have Pax Logging as part of the container and each bundle has custom log4j configuration? There is not a single place in the pax source that i see any bundle using Log4J-ConfigFile in the MANIFEST.MF file, so i'm starting to wonder if this even works.
Not sure i understand you here, you saing Log4J-ConfigFile option is not something that should be used? I'm not well versed with OSGi central administration, so i'm just trying to get each logger sending output to its own file. Right the log output from different bundles to the console are getting intermixed and the logs are unreadable.
Sorry you have so much trouble, but these things are reason why it *is* still 0.x, and not considered ready for production use. Thanks for helping clearing out problems.
Ya, that was the reason for this email, to get an idea of what *should* work, so i know to say away from headaches related to stuff that doesn't.
_______________________________________________ general mailing list [EMAIL PROTECTED] http://lists.ops4j.org/mailman/listinfo/general
