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))])
bundle 266 exports javax.servlet v=3.10 (I installed this one)
bundle 22 exports javax.servlet v=2.5 (provided by CQ5)
bundle 250 (mine) imports javax.servlet,version=[3.0,4) from 266. It also imports packages from 210 and 93.
bundle 210 imports javax.servelt v=2.5 from 22 (but the import in manifest does not have a version. maybe this is the problem?)
bundle 93 has javax.servlet; version="2.4" in the Import-package. but it resolved to javax.servlet,version=2.5.0 from (22) somehow.
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.
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.
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
Related
I've split up my Jetty installation from my configuration by using the "Jetty Base and Jetty Home" mechanism.
This made it very easy to upgrade Jetty 9.4.3 to 9.4.6 by just referencing to the new Jetty home directory.
In my Jetty base directory I have activated the cdi module, which had downloaded various lib files under {$jetty.base}/lib/cdi.
Although Jetty 9.4.6 has new versions of the weld framework referenced in its module description, those libs in my Jetty base directory did not get updated automatically. What is the recommended way to update these libs?
Deactivating the module, deleting the libs and reactivating it feels a little bit odd...
Add --create-files to your start.jar command line once.
If the module is defined properly (sometimes it isn't. if so, that's a bug), only the specific jar files needed are referenced, not the old ones.
I am attempting to create a Websockets- based application using the Grizzly Websockets bundles. I am doing this in Apache Felix using Bndtools.
Unfortunately, I seem to have all the needed dependencies, but the Grizzly bundles are failing to load due to the following failure:
org.glassfish.grizzly.websockets-server-2.3.23Unable to resolve
org.glassfish.grizzly.websockets-server [23](R 23.0): missing
requirement [org.glassfish.grizzly.websockets-server [23](R 23.0)]
osgi.wiring.package; (osgi.wiring.package=sun.misc) Unresolved
requirements: [[org.glassfish.grizzly.websockets-server [23](R 23.0)]
osgi.wiring.package; (osgi.wiring.package=sun.misc)]
I have researched this failure, originally looking for a bundle, only to discover that apparently this is some kind of JVM library that is really not needed. I have seen workarounds and solutions that involve adding a line to a conf/config.properties file:
org.osgi.framework.system.packages.extra=sun.misc
I understand that this is a dangerous workaround, and there are rumors of "safer" solutions to this problem. They all involve making changes to tags or to the config.properties file.
Unfortunately, in a Bndtools environment, there are apparently no such tags or files for me to edit!
Or, at least, I cannot find these things in my Bndtools project.
Is there some way to fix this "sun.misc" problem within a Bndtools- based project? I am using Bndtools repository and am wondering which of the various "bnd" files I need to edit, as well as what to put into those files.
Someone please advise...
You need to add -runsystempackages: sun.misc to the bnd/bndrun file.
The best tool for that is https://github.com/diffplug/osgiX
You just will change PKG=sun.misc(or another package) in gradle.properties and run gradlew build.
It will generate bundle-fragment, which you will can add to your class path.
The bundle then contains:
Manifest-Version: 1.0
Export-Package: sun.misc
Fragment-Host: system.bundle; extension:=framework
Bundle-ManifestVersion: 2
Bundle-License: public domain - http://unlicense.org/
Bundle-SymbolicName: com.diffplug.osgi.extension.sun.misc
Bundle-Version: 0.0.0
I have defined four bundles:
bundle 1 : export package x version 1
bundle 2 : import package x ver [1,2] and export package y;y uses x
bundle 3 : export package x version 2
bundle 4 : import package y and also import package x version 2
Using apache felix (distribuable binary), I found that I should manually impose to not resolve (or start) the bundle 1 and then bundle 2 before starting the bundle 3 (otherwise a uses constraint problem appears because bundle 2 will use package x version 1 and in bundle 4 will appear package x version 1 and version 2 --> uses constraint violation).
Thanks to the authors of these posts:
http://njbartlett.name/2011/02/09/uses-constraints.html
http://blog.springsource.com/2008/10/20/understanding-the-osgi-uses-directive/
I don't like to impose order to my bundles, I need to copy all my bundles in the /bundle directory and then the instance of framework install and start them.
I noticed that Apache felix sorts the bundles to be installed alphabetically (so bundle 1 will be installed and then started the first).
I tried with Apache karaf, I copied my bundles into /deploy and I found that the problem disappears, so my question is:
Does Apache Karaf, (or felix file install) apply a strategy to impose any order for starting bundles in order to avoid these kind of problems ?
You should try to use a Karaf feature for this kind of deployment. You create a feature file with one feature in it and add all the bundles to this feature. Karaf will then load all the bundles and resolve and start them in one pass. So the resolver should bee able to correctly resolve all your bundles.
Apache Karaf does automatically add a startlevel to the bundles in the deploy folder this is configurable. The default of it is 50. So all your custom bundles are installed as StartLevel 50. This also makes sure the basic bundles of karaf itself are already up and running, especially the file-installer bundle.
Felix FileInstall does not have any ordering capability.
Start order isn't really important (bundles should be able to be started in any order), but a good Management Agent should be able to install and resolve a batch of bundles as a single operation. However FileInstall installs/resolves/starts bundles whenever it happens to poll the filesystem directory. Therefore FileInstall is not really usable for production deployment.
I don't know anything about Karaf, but any management agent that simply polls a directory is likely to have the same problem.
I am getting weird errors on Heroku cedar using hibernate-memcached 1.3:
Caught CNFE decoding 438 bytes of data java.lang.ClassNotFoundException: org.hibernate.cache.entry.CacheEntry
Somehow hibernate-memcached 1.3 is failing to work with spymemcached 2.8.1 and up.
It does not matter if i explicitly list spymemcached 2.7.3 in my pom.xml or i set spymemcached scope as provided - i always get CNFE
I was able to replicate this issue locally when i upgraded to spymemcached 2.8.1
Thanks.
If you are using webapp-runner.jar to run your app, then yes, you're right: spymemcached class files are contained in the jar file to support caching of session data.
According to webapp-runner this is true for version 7.0.29.1 or newer.
The most recent version that does not contain spymemcached classes I was able to find, though, is 7.0.22.1.
I suspect that you can work around your problem by downgrading webapp-runner to version 7.0.22.1.
At least that worked for me when I ran into similar problems, getting exceptions like this:
org.springframework.beans.factory.CannotLoadBeanClassException:
Error loading class [net.spy.memcached.spring.MemcachedClientFactoryBean]
for bean with name 'memcachedClient' defined in class path resource [memcached-context.xml]:
problem with class file or dependent class;
nested exception is java.lang.NoClassDefFoundError: org/springframework/beans/factory/FactoryBean
These problems only occurred when I ran my war file with webapp-runner.jar. Running it from within Eclipse or with a local plain vanilla Tomcat 7 worked just fine.
Is it possible? Or do I have to try to install it?
I'll assume you're talking about OSGi Release 4, since in OSGi Release 3 and earlier any valid JAR file was also a valid OSGi bundle.
Simply read the JAR's manifest using the standard Java APIs in the java.util.jar package. The minimum headers required to be a valid R4 bundle are:
Bundle-ManifestVersion: 2
Bundle-SymbolicName: ...
As BJ points out, the "id" of the bundle is assigned when it is installed, but what many people take to be the "id" is actually the Bundle Symbolic Name.
You can check for the Bundle-Name, or a host of Bunde-XXX properties within the *meta-inf/manifest.m*f jar file.
The bundle id is assigned by the framework when the bundle is installed. Thus only an installed bundle has a bundle id.