You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Nichols, Jon" <jn...@UEIC.com> on 2006/06/01 06:21:49 UTC
Resource Bundles and logs
Hello,
I'm just starting to use Felix with our media application, switching
over from Oscar. Things are working well, but I'm having some issues
with resource loading. Whenever I attempt to load a resource bundle:
ResourceBundle bundle =
ResourceBundle.getBundle("org/simplecenter/localization");
String str = bundle.getString("WindowTitle");
System.out.println("String: " + str);
I get the following warning printed to the System output:
ERROR: ****
****
Class 'org/simplecenter/localization' was not found. Bundle 6 does not
import package '', nor is the package exported by any other bundle or
available from the system class loader.
****
****
ERROR: ****
****
Class 'org/simplecenter/localization_en' was not found. Bundle 6 does
not import package '', nor is the package exported by any other bundle
or available from the system class loader.
****
****
Everything works fine otherwise, but we load tons of strings, and each
time we get a handful of these printed out. I can track the problem to
org.apache.felix.framework.searchpolicy.ContentClassLoader.getResource()
:
m_contentLoader.getLogger().log(
Logger.LOG_WARNING,
ex.getMessage(),
ex);
Should this really be logging? If so, how do I prevent all of these
messages?
Jon
Re: Resource Bundles and logs
Posted by Rob Walker <ro...@ascert.com>.
> I still don't consider it 'done' by any way.
>
Maybe not - but it's a shed-load closer to 'done' than the internal hack
we did!
-- Rob
Re: Resource Bundles and logs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 07 June 2006 15:52, Rob Walker wrote:
> Guess I must have missed the original announcement / post on this ?
Maybe not you, but me who missed making a proper announcement...
I still don't consider it 'done' by any way.
Cheers
Niclas
Re: Resource Bundles and logs
Posted by Rob Walker <ro...@ascert.com>.
Niclas
> Ok, tell me what is missing in Pax Logging and I'll add it;
>
> http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:logging
>
> Essentially;
>
> - Log4J drives the backend.
> - Each bundle, class uses whatever Logging API it wishes.
>
>
>
Looks very interesting - I'll take a more detailed look and see if
there's anything we did here that might be a worthwhile addition.
Guess I must have missed the original announcement / post on this ?
-- Rob
Re: Resource Bundles and logs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 06 June 2006 23:08, Rob Walker wrote:
> In my mind, the model I envisaged that could be workable was:
>
> * a "logger" bundle that whilst supporting the standard OSGi
> LogService API for the very basic case, also offered a fairly rich
> LOG4J (maybe SLF4J now) set of API functionality
Ok, tell me what is missing in Pax Logging and I'll add it;
http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:logging
Essentially;
- Log4J drives the backend.
- Each bundle, class uses whatever Logging API it wishes.
Cheers
Niclas
Re: Resource Bundles and logs
Posted by Enrique Rodriguez <en...@gmail.com>.
John E. Conlon wrote:
...
> Like Rob, did a simple bundlizing of an existing logging framework, but
> one based on SLF4J. (Enrique has also done a similar logging bundle in
> ApacheDS.) I included the adapter that maps the apache commons logging
> to SLF4J. To this like Rob, added an OSGi logging service (adapted to
> SLF4J). As mentioned SLF4J sits on top of a underlying logging stack,
> for this bundle used the NLOG4J native SLF4J logging stack which is
> configured similarly to log4j. One neat OSGi feature that was added was
> a simple activator that reread the configuration file on startup, thus
> allowing a rereading the config without shutting down the framework.
...
We took SLF4J, wrapped it with the Felix M2 Plugin, and exported a
handful of packages. John contributed the Activator to re-read the
config. Since ApacheDS uses SLF4J this fits right in. Re-loading
config is really convenient.
...
> Looking forward to the opening of a Felix commons area for consolidating
> these different implementations.
...
I agree and can move over our reusable SLF4J bundle.
Enrique
Re: Resource Bundles and logs
Posted by Rob Walker <ro...@ascert.com>.
I have to say - logging to most people is probably the dullest subject
they can imagine - but it's also the best (and worst) part of a lot of
frameworks I've worked with.
So for me, it's actually right up there with some of the most important
components you can build - ok, so if that makes me dull, I'll take it ;)
I'm really looking forward to seeing how we can take these ideas forward
into something really solid
Great input John, thanks
-- Rob
John E. Conlon wrote:
> On Tue, 2006-06-06 at 16:08 +0100, Rob Walker wrote:
>
>>> So, until then there is no way to "hide" these errors. Perhaps there
>>> is another approach too. One thing that we could do (in addition to
>>> eventually using the log service) is to have a property that allows us
>>> to disable diagnostic messages...otherwise, I don't know.
>>>
>> In our app. this was our reasoning behind basing our logging on LOG4J -
>> so we had very flexible "soft switches" to control and configured what
>> got logged at runtime. I haven't looked at SLF4J yet - but I think it
>> extends this concept further with a generic 'commons' style API that can
>> also sit on top of other logging frameworks.
>>
> Yes it's API is very nice and it sits on several logging stacks now.
> http://www.slf4j.org/
>
>
>> We did a not very good "hack" to enable us to wire LOG4J in as an Osgi
>> service - so I can't really recommend the actual approach we took for
>> general usage - but the outcome has been pretty good, and it's given us
>> a degree of flexibility around the level of diagnostic and application
>> message noise which gets logged.
>>
>
> Like Rob, did a simple bundlizing of an existing logging framework, but
> one based on SLF4J. (Enrique has also done a similar logging bundle in
> ApacheDS.) I included the adapter that maps the apache commons logging
> to SLF4J. To this like Rob, added an OSGi logging service (adapted to
> SLF4J). As mentioned SLF4J sits on top of a underlying logging stack,
> for this bundle used the NLOG4J native SLF4J logging stack which is
> configured similarly to log4j. One neat OSGi feature that was added was
> a simple activator that reread the configuration file on startup, thus
> allowing a rereading the config without shutting down the framework.
>
> OSGi, Apache-Commons, SLF4J logging and log4j configuration.
>
>> In my mind, the model I envisaged that could be workable was:
>>
>> * a "logger" bundle that whilst supporting the standard OSGi
>> LogService API for the very basic case, also offered a fairly rich
>> LOG4J (maybe SLF4J now) set of API functionality
>>
>
> Just bundlizing the SLF4J jars would get us along way to having what we
> need. Then we could pick and choose what we need the OSGi way. The only
> other thing that I think would be helpful is to add a SLF4J to OSGi Log
> Reader service.
>
> Looking forward to the opening of a Felix commons area for consolidating
> these different implementations.
>
>
>> Needless to say, time prevented me from creating this generalised "split
>> brain" logging module, but I think it's feasible and has merit.
>>
>> And of course beyond this, there then opens up the possibility of remote
>> log message or / logging access through things like JMX or simpler APIs
>> (ours is actually a very simple XMLRPC based one that let's us pull back
>> captured log messages for viewing on a client)
>>
> If we use the SLF4J/log4j think we can plug into all the fine remote
> work that has already been done with log4j, JMS, Chainsaw, etc.
>
> cheers,
> John
>
>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Resource Bundles and logs
Posted by "John E. Conlon" <jc...@verticon.com>.
On Tue, 2006-06-06 at 16:08 +0100, Rob Walker wrote:
> > So, until then there is no way to "hide" these errors. Perhaps there
> > is another approach too. One thing that we could do (in addition to
> > eventually using the log service) is to have a property that allows us
> > to disable diagnostic messages...otherwise, I don't know.
> In our app. this was our reasoning behind basing our logging on LOG4J -
> so we had very flexible "soft switches" to control and configured what
> got logged at runtime. I haven't looked at SLF4J yet - but I think it
> extends this concept further with a generic 'commons' style API that can
> also sit on top of other logging frameworks.
Yes it's API is very nice and it sits on several logging stacks now.
http://www.slf4j.org/
>
> We did a not very good "hack" to enable us to wire LOG4J in as an Osgi
> service - so I can't really recommend the actual approach we took for
> general usage - but the outcome has been pretty good, and it's given us
> a degree of flexibility around the level of diagnostic and application
> message noise which gets logged.
Like Rob, did a simple bundlizing of an existing logging framework, but
one based on SLF4J. (Enrique has also done a similar logging bundle in
ApacheDS.) I included the adapter that maps the apache commons logging
to SLF4J. To this like Rob, added an OSGi logging service (adapted to
SLF4J). As mentioned SLF4J sits on top of a underlying logging stack,
for this bundle used the NLOG4J native SLF4J logging stack which is
configured similarly to log4j. One neat OSGi feature that was added was
a simple activator that reread the configuration file on startup, thus
allowing a rereading the config without shutting down the framework.
OSGi, Apache-Commons, SLF4J logging and log4j configuration.
>
> In my mind, the model I envisaged that could be workable was:
>
> * a "logger" bundle that whilst supporting the standard OSGi
> LogService API for the very basic case, also offered a fairly rich
> LOG4J (maybe SLF4J now) set of API functionality
Just bundlizing the SLF4J jars would get us along way to having what we
need. Then we could pick and choose what we need the OSGi way. The only
other thing that I think would be helpful is to add a SLF4J to OSGi Log
Reader service.
Looking forward to the opening of a Felix commons area for consolidating
these different implementations.
>
> Needless to say, time prevented me from creating this generalised "split
> brain" logging module, but I think it's feasible and has merit.
>
> And of course beyond this, there then opens up the possibility of remote
> log message or / logging access through things like JMX or simpler APIs
> (ours is actually a very simple XMLRPC based one that let's us pull back
> captured log messages for viewing on a client)
If we use the SLF4J/log4j think we can plug into all the fine remote
work that has already been done with log4j, JMS, Chainsaw, etc.
cheers,
John
Re: Resource Bundles and logs
Posted by Rob Walker <ro...@ascert.com>.
> So, until then there is no way to "hide" these errors. Perhaps there
> is another approach too. One thing that we could do (in addition to
> eventually using the log service) is to have a property that allows us
> to disable diagnostic messages...otherwise, I don't know.
In our app. this was our reasoning behind basing our logging on LOG4J -
so we had very flexible "soft switches" to control and configured what
got logged at runtime. I haven't looked at SLF4J yet - but I think it
extends this concept further with a generic 'commons' style API that can
also sit on top of other logging frameworks.
We did a not very good "hack" to enable us to wire LOG4J in as an Osgi
service - so I can't really recommend the actual approach we took for
general usage - but the outcome has been pretty good, and it's given us
a degree of flexibility around the level of diagnostic and application
message noise which gets logged.
In my mind, the model I envisaged that could be workable was:
* a "logger" bundle that whilst supporting the standard OSGi
LogService API for the very basic case, also offered a fairly rich
LOG4J (maybe SLF4J now) set of API functionality
Needless to say, time prevented me from creating this generalised "split
brain" logging module, but I think it's feasible and has merit.
And of course beyond this, there then opens up the possibility of remote
log message or / logging access through things like JMX or simpler APIs
(ours is actually a very simple XMLRPC based one that let's us pull back
captured log messages for viewing on a client)
Just some thoughts ....
-- Rob
Re: Resource Bundles and logs
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Following up on this...these messages are actually being sent to Felix'
internal "logger", but currently that is just hard-wired to stdout. The
ultimate goal is to have the internal logger use the Log Service if it
is available, but this hasn't been implemented yet.
So, until then there is no way to "hide" these errors. Perhaps there is
another approach too. One thing that we could do (in addition to
eventually using the log service) is to have a property that allows us
to disable diagnostic messages...otherwise, I don't know.
It is unfortunate that resource loading also probes classes too, but in
most cases these "errors" are harmless.
-> richard
John E. Conlon wrote:
> When Richard tightened the classloading restrictions he added more
> verbose logging. Must admit some of the messages are just noise and I
> ignore them.
>
> It would be nice to modulate logging to eliminate some or all of the
> 'noisy' ones.
>
> Here are three variations of 'error' messages that I ignore:
>
> 1. My slf4j logging bundle will look for non-existence BeanInfo objects
> so felix will generate messages like this one:
>
> ERROR: ****
> ****
> Package 'org.apache.log4j' is imported by bundle 7 from bundle 7, but
> the export ed package from bundle 7 does not contain the requested class
> 'org.apache.log4j. PatternLayoutBeanInfo'. Please verify that the class
> name is correct in the impo rting bundle 7 and/or that the exported
> package is correctly bundled in 7.
> ****
>
>
> 2. Couple of my bundles use JXPath to query business objects. JXPath
> will search for metadata objects to aid its search, causing felix to
> generate messages like this one:
>
> ERROR: ****
> ****
> Package 'com.verticon.react2.business' is imported by bundle 20 from
> bundle 20, but the exported package from bundle 20 does not contain the
> requested class
> 'com.verticon.react2.business.MovementHistoryEntryXBeanInfo'. Please
> verify that the class name is correct in the importing bundle 20 and/or
> that the exported package is correctly bundled in 20.
> ****
>
> 3. Using beanshell script in a bundle to bring in complex configuration
> information. Beanshell tries to load metadata as well. In response Felix
> logs messages like:
>
> ERROR: ****
> ****
> Class 'java.lang.bsh' was not found. Bundle 21 does not import package
> 'java.lang', nor is the package exported by any other bundle or
> available from the system class loader.
> ****
> ****
>
>
> - John
>
> On Thu, 2006-06-01 at 14:18 +0800, Niclas Hedhman wrote:
>
>> On Thursday 01 June 2006 12:21, Nichols, Jon wrote:
>>
>>> Should this really be logging? If so, how do I prevent all of these
>>> messages?
>>>
>> I have noticed these too... (not been on Felix more than a few minutes ;o) )
>>
>> Apparently, Felix wants to warn people that resource loading fails. BUT, many
>> applications are designed to fail and try something else, like
>> ResourceBundle.
>>
>> I guess that a discriminatory logging would be needed, i.e. one can declare
>> which packages are expected to fail in this fashion, and only for other
>> failures will Felix output a Warning.
>>
>>
>> Cheers
>> Niclas
>>
>>
>
>
>
Re: Resource Bundles and logs
Posted by "John E. Conlon" <jc...@verticon.com>.
When Richard tightened the classloading restrictions he added more
verbose logging. Must admit some of the messages are just noise and I
ignore them.
It would be nice to modulate logging to eliminate some or all of the
'noisy' ones.
Here are three variations of 'error' messages that I ignore:
1. My slf4j logging bundle will look for non-existence BeanInfo objects
so felix will generate messages like this one:
ERROR: ****
****
Package 'org.apache.log4j' is imported by bundle 7 from bundle 7, but
the export ed package from bundle 7 does not contain the requested class
'org.apache.log4j. PatternLayoutBeanInfo'. Please verify that the class
name is correct in the impo rting bundle 7 and/or that the exported
package is correctly bundled in 7.
****
2. Couple of my bundles use JXPath to query business objects. JXPath
will search for metadata objects to aid its search, causing felix to
generate messages like this one:
ERROR: ****
****
Package 'com.verticon.react2.business' is imported by bundle 20 from
bundle 20, but the exported package from bundle 20 does not contain the
requested class
'com.verticon.react2.business.MovementHistoryEntryXBeanInfo'. Please
verify that the class name is correct in the importing bundle 20 and/or
that the exported package is correctly bundled in 20.
****
3. Using beanshell script in a bundle to bring in complex configuration
information. Beanshell tries to load metadata as well. In response Felix
logs messages like:
ERROR: ****
****
Class 'java.lang.bsh' was not found. Bundle 21 does not import package
'java.lang', nor is the package exported by any other bundle or
available from the system class loader.
****
****
- John
On Thu, 2006-06-01 at 14:18 +0800, Niclas Hedhman wrote:
> On Thursday 01 June 2006 12:21, Nichols, Jon wrote:
> > Should this really be logging? If so, how do I prevent all of these
> > messages?
>
> I have noticed these too... (not been on Felix more than a few minutes ;o) )
>
> Apparently, Felix wants to warn people that resource loading fails. BUT, many
> applications are designed to fail and try something else, like
> ResourceBundle.
>
> I guess that a discriminatory logging would be needed, i.e. one can declare
> which packages are expected to fail in this fashion, and only for other
> failures will Felix output a Warning.
>
>
> Cheers
> Niclas
>
Re: Resource Bundles and logs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 01 June 2006 12:21, Nichols, Jon wrote:
> Should this really be logging? If so, how do I prevent all of these
> messages?
I have noticed these too... (not been on Felix more than a few minutes ;o) )
Apparently, Felix wants to warn people that resource loading fails. BUT, many
applications are designed to fail and try something else, like
ResourceBundle.
I guess that a discriminatory logging would be needed, i.e. one can declare
which packages are expected to fail in this fashion, and only for other
failures will Felix output a Warning.
Cheers
Niclas