On Tuesday 05 September 2006 11:58, David Leangen wrote:
> > I'll try playing around with this a little more. Right now, it would be
> > a big deal (at least a few days work) to get everything up and running
> > with Felix, I think.
> >
> > I'll let you know how things go.
>
> Well, no luck.
>
> I
> I'll try playing around with this a little more. Right now, it would be
> a big deal (at least a few days work) to get everything up and running
> with Felix, I think.
>
> I'll let you know how things go.
Well, no luck.
I think I have no choice but to make the move to PaxRunner/Felix. Sigh.
I
> The Wiki says;
>
> Import the logging APIs that are used in your client bundle. To ensure that
> your bundle's logging will get routed to Pax Logging Service, and not linked
> to another JCL or Log4J implementation (perhaps exported by a third-party
> bundle), you should specify the attribute
On Tuesday 05 September 2006 10:54, David Leangen wrote:
> Import-Package: org.ops4j.pax.logging.service,
> org.apache.commons.logging; specification-version=1.0.4;
> provider=paxlogging
>
> When building, I include these dependencies:
>
>
>
>
> But I get this error:
>
>
Thanks for all the help! I'm almost there...
I'm just trying to resolve the JCL package. This is the closest I've got
so far:
Import-Package: org.ops4j.pax.logging.service,
org.apache.commons.logging; specification-version=1.0.4;
provider=paxlogging
When building, I include these dependencies:
On Tuesday 05 September 2006 09:50, David Leangen wrote:
> > [ERROR] BUILD FAILURE
> >
> >
> > Sounds like a classpath or "unclean" problem.
> > I suggest that you start by using the binary 0.9.4 out of the
> > http://repository.ops4j.org/maven2/org/ops4j/pax/logging.
>
> You're probably ri
> [ERROR] BUILD FAILURE
>
> Sounds like a classpath or "unclean" problem.
> I suggest that you start by using the binary 0.9.4 out of the
> http://repository.ops4j.org/maven2/org/ops4j/pax/logging.
You're probably right. I started afresh and it built correctly.
I don't understand the
On 9/5/06, David Leangen <[EMAIL PROTECTED]> wrote:
> If you use Pax Logging 0.9.x, that is correct. The BundleActivator> doesn't need to do anything in the client bundles.> If you use Pax Logging prior to 0.9.0 , then the client had to set the
> bundle context for the LogFactory. This way is no lo
> If you use Pax Logging 0.9.x, that is correct. The BundleActivator
> doesn't need to do anything in the client bundles.
> If you use Pax Logging prior to 0.9.0 , then the client had to set the
> bundle context for the LogFactory. This way is no longer supported.
Ah, he he... that's what I thou
On 9/4/06, David Leangen <[EMAIL PROTECTED]> wrote:
Could somebody please remind me how the logging factory works?I'm trying to get XFire working in OSGi, and I need to wire up thelogging to figure out what's going on.XFire does this: private final static Log logger =
LogFactory.getLog(XFireServlet
Thanks for the reply, Eelco.
I think that this must have something to do with the way the Pax logger
works. I agree that in a simple environment, it should be working fine.
Guess I'll have to take a look at Pax internals (though my version is
still an older one).
On Sun, 2006-09-03 at 21:
Yeah, that should be enough. Verify that Log4J is actually used, and
that that properties file (log4j.properties) is actually loaded by
Log4J. Additionally, you can have this in your classpath:
commons-logging.properties with:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogg
Hello!
Could somebody please remind me how the logging factory works?
I'm trying to get XFire working in OSGi, and I need to wire up the
logging to figure out what's going on.
XFire does this:
private final static Log logger =
LogFactory.getLog(XFireServlet.class);
Should that not be enough
13 matches
Mail list logo
