CODEWITHSUNDEEP
osgiaem
santiagozky
santiagozky

Reputation: 2539

using servlet-api 3 bundle in adobe CQ5

I'm trying to use the servlet-api version 3 in an Adobe CQ5 installation, without much success.

there is already a bundle that exports the javax.servlet package (version 2.5), so I deployed a bundle with version 3.1.0. this bundle starts ok.

The problem is starting the bundle that uses the api v3. I am getting an OSGi exception that I cannot fully understand:

POST /system/console/bundles/250 HTTP/1.1] cqse-httpservice %bundles.pluginTitle: Cannot start (org.osgi.framework.BundleException:

Constraint violation for package 'javax.servlet' when resolving module 250.9 between existing import 266.0.javax.servlet

BLAMED ON [[250.9] package; (&(package=javax.servlet)(version>=3.0.0)(!(version>=4.0.0)))]

and uses constraint 22.1.javax.servlet

BLAMED ON [[250.9] package; (package=com.day.cq.wcm.foundation.forms), [210.0] package; (&(package=org.apache.sling.api.resource)(version>=2.0.0)), [93.0] package; (&(package=javax.servlet)(version>=2.4.0))])

The problem seems to be around the dependencies of bundle 250, but Im not sure what is the problem. AFAIK two versions of a package can coexist in an OSGi container. bundles 210 and 93 are running without issues.

Upvotes: 2

Views: 980

Answers (2)

santiagozky
santiagozky

Reputation: 2539

After reading the article left in the comments, I noticed that dependencies of my bundle expose classes of the servlet api 2.5. This is causing the constraint and prevents my bundle. If I understand correctly the classpath from bundle 210 is expanded up to my bundle.

So, the only option will be to remove the dependency of my bundle with the other bundles, which I am afraid I cannot do. I will have to deal without the V3 api

Upvotes: 0

Achim Nierbeck
Achim Nierbeck

Reputation: 5285

This is most likely due to the fact that the used http-service only supports servlet 2.5 that's why this is the pre-installed servlet version. Since you installed a servlet 3.0 api your bundle does resolve but as it tries to export a service which is picked up by the http-service you run into this issue. The root cause is the http-service implementation that is used. I don't know if this would work but you might try to replace the http service version by using Pax-Web 2 or 3 instead. Pax-Web does support Servlet API since version 2.

Upvotes: 0

Related Questions