On 11/04/2008, Michael Greifeneder <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I have a problem with Pax Logging,
>
> I would like to know if this is the correct way to use Pax logging with
> pax construct:
>
> I have done:
>
> >pax-create-project -g mygroup -a project
>
> >cd project
>
> >pax-create-bundle -p mygroup.mybundle -n mybundle
>
> >pax-import-bundle -g org.ops4j.pax.logging -a pax-logging-api -v 1.0.0
>
> >pax-import-bundle -g org.ops4j.pax.logging -a pax-logging-service -v
> 1.0.0
>
> >cd mygroup.mybundle
>
^ this should be "cd mybundle" because the directory will
be the same as the bundle name, which you set using -n
> >pax-import-bundle -g log4j -a log4j -v 1.2.13
>
^ this part is wrong, you shouldn't add Log4J to the list of
deployed bundles because it conflicts with the Pax-Logging
API bundle that provides the same Log4J API
your app bundles might then get wired to the Log4J bundle
instead of the Pax-Logging bundles, which would mean they
would log to Log4J, not the centralized Pax-Logging service
you would probably also see various classloading issues
> Adding this line to
> src/main/java/mygroup/mybundle/internal/ExampleActivator.java:
>
>
> org.apache.log4j.Logger.getLogger(this.getClass()).info("LOG4J message");
>
> >cd ..
>
> >mvn install pax:provision
>
> I get this error:
>
> org.osgi.framework.BundleException: Activator start error.
>
> at org.apache.felix.framework.Felix._startBundle(Felix.java:1629)
>
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1519)
>
> at
> org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1104)
>
> at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:258)
>
> at java.lang.Thread.run(Thread.java:619)
>
> Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Category
>
it's because you're deploying the vanilla Log4J bundle alongside
Pax-Logging which already provides this API - you can use Log4J
to compile against (ie. scope compile) but you shouldn't deploy it
at the same time as Pax-Logging
> What's wrong?
>
> Funny thing is that I have another project where it works and diffs with
> all pom.xml files and osgi.bnd doesn't show any obvious difference.
>
> Thanks for any help.
>
> Best regards,
>
> Mike
>
check the provision pom.xml - there's probably a difference there
or it might be that it just happens to wire to the Pax-Logging bundle
before the Log4J bundle in the other project (ie. the other project
would break if it ever wired the Log4J bundle first, this this doesn't
happen for timing reasons, etc...)
I've updated your example to show various ways of using Pax-Logging:
=============================================================
# this assumes you are using Pax-Construct v1.1
# ---------------------------------------------
pax-create-project -g mygroup -a project
cd project
pax-create-bundle -p mygroup.mybundle -n mybundle
# import the Pax-Logging bundles for the global project
pax-import-bundle -g org.ops4j.pax.logging -a pax-logging-api -v 1.0.0
pax-import-bundle -g org.ops4j.pax.logging -a pax-logging-service -v 1.0.0
# NOTE that by default this global set of imported bundles is NOT added to
# the classpath of individual bundles (this is to avoid potential clashes)
# but you can edit the pom.xml of individual bundles to add this classpath
# ... see example below ...
# BTW, the directory is 'mybundle' not 'mygroup.mybundle' because you chose
# a specific name using the -n option, and the directory comes from the name
cd mybundle
# here you have a choice if you want to compile against the Log4J API
# ==either==
# 1) import the Pax-Logging API bundle for this particular local bundle
pax-import-bundle -g org.ops4j.pax.logging -a pax-logging-api -v 1.0.0
# ==OR==
# 2) uncomment the following entry from the generated local bundle pom:
# <!--
# | uncomment to add all imported (non-local) bundles to your
compilation classpath
# <dependency>
# <type>pom</type>
# <groupId>${parent.groupId}</groupId>
# <artifactId>provision</artifactId>
# <optional>true</optional>
# </dependency>
# -->
# to get the global classpath, including the logging bundles you just
imported
# ==OR==
# 3) manually add the Log4J artifact to your bundle as a *compile*
dependency
# <dependency>
# <groupId>log4j</groupId>
# <artifactId>log4j</artifactId>
# <version>1.2.13</version>
# <scope>compile</scope>
# <optional>true</optional>
# </dependency>
# do NOT add the Log4J artifact using pax-import-bundle, or add it using
provided
# scope, as it will then be deployed onto the OSGi framework and potentially
cause
# problems. Instead rely on the Pax-Logging API bundle at deploy time, even
if you
# decide the compile against the real Log4J artifact at compile time.
# You can now add your Log4J call to the bundle activator and it should
compile ok:
#
# org.apache.log4j.Logger.getLogger(this.getClass()).info("LOG4J
message");
#
cd ..
# head back to the project root and let's try to build and deploy...
mvn clean install pax:provision
=================================================================
HTH (I'll add this to the wiki)
_______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
>
>
--
Cheers, Stuart
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
