I have a component which was developed for Apache Karaf 4.0.5. However, it turns out it needs to be deployed on glassfish 4, which is based on an older version of Felix. I get this message when trying to deploy it:
missing requirement [319.0] osgi.extender; (&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))
However, my pom file does not show any explicit dependency on osgi.component. I think I must have used some OSGI R5 (or R6?) specific feature, but I don't know which would cause this error.
How can I either convince glassfish to accept my bundle, or change the bundle's build / pom so that I get warnings when trying to use OSGI features dependent on R5 or later?
You are probably using a recent version of bnd to generate your bundle and its metadata. Bnd will generate the requirement on the osgi.component extender (This is DS) when your bundle has DS components and either you require something new in DS 1.3 like field injection or you are using the very latest version of bnd.
You can disable the generation of the requirement in your bundle with the bnd instruction:
-dsannotations-options: norequirements
https://bnd.bndtools.org/instructions/dsannotations-options.html
Related
What impact will be happen if I change the Bundle-Version which present in Manifest.MF file?
Also I could not understand why we used Bundle-Version, Manifest-Version, Bundle-ManifestVersion into Manifest.MF file?
Manifest-Version is the version of the Java manifest specification that this manifest uses - normally always 1.0. You won't normally change this.
Bundle-ManifestVersion is the version of the OSGi manifest specification that this manifest uses. Again you won't normally change this.
Bundle-Version is the version of the plugin in the form 'major.minor.micro.qualifier'. 'qualifier' is usually some sort of build id. You will normally increment one of 'major', 'minor' or 'micro' each time you change the plugin.
OSGi uses the term 'Bundle' for what Eclipse calls a 'plug-in'.
Bundle-Version - The version of the OSGi bundle (in Eclipse bundles are also called plug-ins): bundles can define dependencies to other bundles in a version range
Manifest-Version - The version of the JAR Manifest format (up to now 1.0)
Bundle-ManifestVersion - The version of the OSGi Manifest format which extends the JAR Manifest format (2 since release 4)
I have a maven web app project, where I use JodaTime. JodaTime is not directly referenced in my maven project, but is a part of a transitive dependency. In other words, my web app war, has another project of mine as a direct dependency, and that jar contains JodaTime.
I am getting an error after executing these two lines. It compiles fine though.
DateTime firstDate = new DateTime();
firstDate = firstDate.withYear(2016);
And here is my error:
java.lang.NoSuchMethodError: org.joda.time.DateTime.withYear(I)Lorg/joda/time/DateTime;
I know that these kinds of errors can happen if I compile and run with different versions of a library, like this answer says, but the withYear() has been around since JodaTime 1.3, since 2006, and I can't see that I could ever have imported a version that old. I've even checked my final war-file, and the only JodaTime library present, is 2.9.2.
The two lines runs fine if I create a main-method snippet, and run it from within the same project in eclipse. They only fail upon compilation into a war file, and running from my weblogic 10.3.2 server.
Does anyone have any idea on how I can proceed to debug this one?
WebLogic 10.3.6 includes this on the classpath:
joda.time_1.2.1.0.jar
This is earlier than the 1.3 that has the missing method.
Your code compiles, which is a good indication that your app's classpath has at least Joda 1.3.
Thus I suspect this is a WebLogic classpath issue. When your app uses libraries that are also on the WebLogic classpath, you need to tell WebLogic which library to use. You do this with the prefer-application-packages element in src/main/webapp/WEB-INF/weblogic.xml.
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.3/weblogic-web-app.xsd">
<context-root>myApp</context-root>
<container-descriptor>
<prefer-application-packages>
<package-name>org.joda.time.*</package-name>
<package-name>org.slf4j.*</package-name>
<package-name>org.slf4j.impl.*</package-name>
<package-name>org.slf4j.spi.*</package-name>
<!-- others here -->
</prefer-application-packages>
</container-descriptor>
<!-- rest of weblogic.xml here -->
</weblogic-web-app>
WebLogic has a classpath analysis tool called wls-cat to help locate these conflicts, described in this blog post. One caveat - do not just copy wls-cat's prefer-application-packages block into your webapp and think you're done - you need to resolve each conflict one by one. Sometimes that means excluding dependencies from your webapp or using scope provided.
I have a Spring based web application which uses gRPC to communicate with my middle tier. I would like to be able to use the kotlin-script-util for the JSR-223 scripting engine. Being that kotlin-script-util relies on the kotlin-compiler dependency (which uses Guava), I am getting version conflicts with gRPC dependencies.
I see that there is a shaded kotlin-compiler-embeddable jar, but no kotlin-script-util that utilizes this dependency.
Is there something I can do to make these dependencies work together?
kotlin-script-util: 1.1.1
gRPC: 1.2.0
Unfortunately there is no ready-made solution for this problem. We'll try to address it in one of the next releases. (see KT-17556 for the relevant issue).
As a workaround, you can, for now, compile your own variant of the kotlin-script-utils. Just copy the project, change the appropriate dependency to the kotlin-compiler-embeddable, and then fix a few compilation errors by updating import statements (the com.intellij.openapi.* packages are relocated to org.jetbrains.kotlin.com.intellij.openapi.* in the kotlin-compiler-embeddable.)
I am trying to deploy a war onto a IBM Websphere Application Server Community Edition (WASCE) 3.0.0.3. I had some jars conflicting problems between those jars that comes with WASCE 3.0.0.3 and the jars comes from our application dependencies. At the end, I fixed the problem by using below property in geronimo-web.xml to force WASCE to load jars from my application.
<import-package>!the.conflicting.jars</import-package>
However, I would like to force WASCE to always take jars from my application first, i.e. inverse the default classloader behavior to load from application first. What is the correct config to change in this case?
After some searches, WASCE 3.0 is based on Geronimo 3.0 according to link. I found setting <inverse-classloading> in geronimo-web.xml may be helpful. But below two documents on Apache Geronimo 3.0 website mention that this function is no longer available on Geronimo 3.0
in Migrating from G 2.x to G 3.x, it says:
inverse-classloading Geronimo 3.0 does not support the element in the deployment plan.
in geronimo-web.xml,
The <sys:environment> element contains the following elements:
...
The <inverse-classloading> element can be used to specify that standard classloader delegation is to be reversed for this module. The Geronimo classloader delegation follows the Java EE 5 specifications, and the normal behavior is to load classes from a parent classloader (if available) before checking the current classloader. ...... ...... (Not supported in 3.0, use <import-package/> instead)
So if <inverse-classloading> is no longer available, what is the equivalent of this property in WASCE 3.0.0.3? Or how exactly should I do this using <import-package/> for all duplicated jars?
In the link you mentioned you will find the following section
<sys:environment>
The <sys:environment> XML element uses the Geronimo System namespace, which is used to specify the common elements for common libraries and module-scoped services, and is documented here:
http://geronimo.apache.org/schemas-3.0/docs/geronimo-module-1.2.xsd.html
The element contains the following elements:
The <moduleId> element is used to provide the configuration name for the web application as deployed in the Geronimo server. It contains elements for the groupId, artifactId, version and module type. Module IDs are normally printed with slashes between the four components, such as GroupID/ArtifactID/Version/Type.
The <dependencies> element is used to provide the configurations and third party libraries on which the web module is dependent upon. These configurations and libraries are made available to the web module via the Geronimo classloader hierarchy.
The <bundle-activator> element is used to create Bundle-Activator header in the manifest file of the web application. It specifies the entry point of the web application as deployed in the Geronimo server.
The <bundle-classPath> element is used to create Import-Package header in the manifest file of the web application. It contains a list of directories or embedded jar files, which are also called bundle resources and extend the classpath of the web application.
The <import-package> element is used to create Import-Package header in the manifest file of the web application. It specifies a list of packages to be resolved before the web application is started. Use <import-package>!packagename</import-package> to override the specific package in server.
The <export-package> element is used to create Export-Package header in the manifest file of the web application. It specifies a list of packages to be exported.
The <require-bundle> element is used create Require-Bundle header in the manifest file of the web application. It specifies a list of bundles to bind to regardless their packages.
The <dynamic-import-package> element is used to create DynamicImport-Package header in the manifest file of the web application. It specifies a list of packaged to be imported dynamically, especially during class loading.
So basically, you need to add the following directive i.e
<sys:import-package>!package-class-name-here*</sys:import-package> within the <sys:environment> stanza. Typically before the Application Context-Root directive.
As you already know, this is in the geronimo-web.xml embedded in the Application WAR/EAR -- as mentioned in the link
http://geronimo.apache.org/GMOxDOC30/geronimo-webxml.html
I created new xerces bundle from jar. I can see two org.apache.xerces bundles now - one from orbit 2.9.0 and "my" 2.11.0. If I try to export product then only the version from orbit is exported
I tried to specify version in dependency for org.apache.xerces using properties, but it does not help, the entry is also marked as erroneous (how to see the reason?).
I am using
Eclipse for RCP and RAP Developers
Version: Luna Service Release 1 (4.4.1)
Build id: 20140925-1800
I missed qualifier! I need to put e.g. 2.11.0.201411051547 instead of simply 2.11.0. That is not really what I want- modifying product configuration after each plugin build, but it helps to force export of missed bundle.