Spring 3 web Jars - issue as Bundle - with org.apacje.log4j imports

My application uses Log4j for logging . I have downloaded log4j bundle version 1.2.15 from spring repository.

In my application bundle i have import

org.apache.log4j;bundle-symbolic-name="com.springsource.org.apache.log4j",

When i use Spring 3.0 web related jars i get uses conflict because

Spring web has imports like

org.apache.log4j;version=" [1.2.15, 2.0.0)" [org.springframework.web-3.0.0.RELEASE.jar]

I feel spring resolves to imports from slf4j present in DM server lib.

How do i solve this issue ?

The slf4j bundles in lib only export slf4j and commons logging packages and not log4j packages.

I recommend using the Admin Console to explore the state dump that is produced when the uses conflict is detected. You'll be able to see any multiple suppliers of packages and, with a bit of thoughtful analysis, work out what's going on.

I have verified with latest version(2.0.1) of DM kernel and Dm server.

Dm kernel doesnt export it , but Dm server does have it.

\springsource-dm-server-2.0.1.RELEASE\repository\ext

Code:

---


com.springsource.slf4j.org.apache.log4j-1.5.10.jar

---

manifest which exports

Code:

---


Export-Package: org.apache.log4j;provider="slf4j";version="1.2.15";use
 s:="org.slf4j"

---

You should be able to use that version of the org.apache.log4j package, but if you must specify a bundle symbolic name, it should of course be "com.springsource.slf4j.org.apache.log4j" rather than "com.springsource.org.apache.log4j".

(In general, I would avoid specifying bundle symbolic name on a package import as it will tend to constrain the resolver and may give rise to uses constraint violations, but I guess you had some specific reason for doing so.)

Glyn,

My issue came because of multiple bundles exporting "org.apache.log4j"

In my application i want to use log4j. For this reason i add bundle symbolic name to "com.springsource.org.apache.log4j" in my application bundles.

This causes issue whn i use Spring Web bundles which has imports for org.apache.log4j (without any explicit bundle symbolic name), which in some cases resolves to com.springsource.slf4j.org.apache.log4j.

This causes uses voilation -

My app -[uses] - Spring web [uses] - com.springsource.slf4j.org.apache.log4j

My app - [uses] - com.springsource.org.apache.log4j

So does changing the bundle symbolic name to com.springsource.slf4j.org.apache.log4j fix your problem?

Actually i did not change my application bundle to import from com.springsource.slf4j.org.apache.log4j. This is because i am converting legacy code into bundles which heavily use log4j(com.springsource.org.apache.log4j) functionalities.

So in my application i would still continue to use imports from log4j bundle(com.springsource.org.apache.log4j).

Is there any other way i can solve this issue and make spring web bundle also import from this log4j jar(without altering spring web bundle manifest) ?

The problem you face is that the Spring web bundle currently resolves before your application and so its wiring will not depend on your application's requirements.

You may be able to deploy your application early in the user region, presumably just before the plan com.springsource.server.web. See this thread for some clues about how to do this. If the resolver plays nicely, this will force Spring web to wire consistently with your application. If the resolver doesn't do this, then the approach won't work.

So this feels risky, but since your application seems to have a heavy dependency on log4j, you may feel that the above experiment is worth the investment in time.

Hope that helps.

Isnt it a bad practice for the following two bundles to have same package structure(org.apache.log4j)

com.springsource.slf4j.org.apache.log4j (server/repository/ext)

com.springsource.org.apache.log4j (spring repository)

Also these two bundles are not alternative technologies , rather they complement each other.

The Enterprise Bundle Repository is intended for broad use in many OSGi environments, so it's not surprising it contains some bundles which would not be of use in a dm Server environment.