I'm trying to use org.eclipse.persistence.moxy 2.7.4 in Karaf.
Karaf 4.2.6 is saying:
Error executing command: Error executing command on bundles:
Error starting bundle 71: Unable to resolve HelloWorld [71](R 71.0): missing requirement [HelloWorld [71](R 71.0)] osgi.wiring.package; (osgi.wiring.package=com.sun.codemodel) Unresolved requirements: [[HelloWorld [71](R 71.0)] osgi.wiring.package; (osgi.wiring.package=com.sun.codemodel)]
I think this is because moxy's META-INF includes:
Manifest-Version: 1.0
Bundle-SymbolicName: org.eclipse.persistence.moxy
Require-Bundle: org.eclipse.persistence.core;bundle-version="2.7.4";visibility:=reexport,org.eclipse.persistence.asm;bundle-version="7.0.0" ;resolution:=optional
Bundle-ManifestVersion: 2
Bundle-Vendor: Eclipse.org - EclipseLink Project
Import-Package: com.sun.xml.bind;resolution:=optional,com.sun.xml.bind.annotation;resolution:=optional,com.sun.xml.bind.api;resolution:=optional,com.sun.xml.bind.api.impl;resolution:=optional,com.sun.codemodel;resolution:=optional;version="[2.2.11,3)"
Bundle-Name: EclipseLink MOXy
Bundle-Version: 2.7.4.v20190115-ad5b7c6b2a
Note com.sun.codemodel;resolution:=optional;version="[2.2.11,3)
But it says "resolution:=optional". So why is this an unresolved requirement, and how can I make karaf treat it as optional?
Note that here, it's not moxy that complains about not finding that package, but your own service. Check your Import-Package in your META-INF/MANIFEST.MF, it's possible that if you use maven-bundle-plugin, the dependency is scanned thanks to your pom.xml and then inferred in your Import-Package clause.
Related
Trying to upgrade the springboot application which uses spring kafka to version 2.9.3 from 2.8.4.
I have followed the instructions here to pulldown kafka-client version 3.2.3 as a separate dependency.
My dependencies looks like this
implementation("org.springframework.kafka:spring-kafka:2.9.3") {
exclude group: "org.apache.kafka", module: "kafka-streams"
exclude group: "org.apache.kafka", module: "kafka-clients"
}
implementation("org.apache.kafka:kafka-clients:3.2.3")
testImplementation("org.springframework.kafka:spring-kafka-test:2.9.3")
When I try to kick off a test which makes use of EmbeddedKafka.
I am getting this NoClassDefFound error
Caused by: java.lang.NoClassDefFoundError: org/apache/kafka/common/requests/AlterIsrRequest$Builder
at kafka.server.KafkaServer.startup(KafkaServer.scala:313)
at kafka.utils.TestUtils$.createServer(TestUtils.scala:177)
at kafka.utils.TestUtils$.createServer(TestUtils.scala:172)
at kafka.utils.TestUtils.createServer(TestUtils.scala)
at org.springframework.kafka.test.EmbeddedKafkaBroker.afterPropertiesSet(EmbeddedKafkaBroker.java:350)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1863)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1800)
... 87 more
Caused by: java.lang.ClassNotFoundException: org.apache.kafka.common.requests.AlterIsrRequest$Builder
at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 94 more
I think I am missing a dependency?
You have a version mis-match between the kafka-clients and other kafka jars. All kafka jars must be the same version since the server uses classes from the clients jar.
I don't see AlterIsrRequest in jars since 3.1.2 - so it looks like, somehow, you have older kafka server jars on the class path.
spring-kafka-test:2.9.3 should pull in 3.2.3 transitively.
Since you are using Spring Boot, it will pull in 3.1.2 instead.
See the documentation (https://docs.spring.io/spring-kafka/docs/2.9.3/reference/html/#update-deps) for how to override the dependencies when using Spring Boot.
I am trying to run my war file using xsbt-web-plugin. My war itself does not contain tomcat-jdbc-pool jar and javax-servlet-api. I tried using container configuration. But sbt complains configuration does not exist.
If I use provided configuration, webapp-runner fails.
I am sure I am missing something. But unable to figure it out.
WARNING: Failed to register in JMX: [javax.naming.NamingException: Could not load resource factory class [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.jdbc.pool.DataSourceFactory]]
What version of xsbt-web-plugin are you using? Can you post the contents of your sbt build configuration?
The Tomcat plugin in xsbt-web-plugin relies on webapp-runner, which does not appear to bundle the tomcat-jdbc library. You can add it via containerLibs in Tomcat:
enablePlugins(TomcatPlugin)
containerLibs in Tomcat += "org.apache.tomcat" % "tomcat-jdbc" % "8.5.15"
when I try to run a failed test with this command :
./vendor/bin/phpunit
I get this Fatal Error :
PHPUnit 5.7.20 by Sebastian Bergmann and contributors.
PHP Fatal error: Class 'PHPUnit\Framework\ExpectationFailedException'
not found in /var/www/zend/vendor/zendframework/zend-
test/src/PHPUnit/Controller/AbstractControllerTestCase.php on line 444
Your version of phpunit is probably too old for your version of Zend. The class PHPUnit\Framework\ExpectationFailedException have been renamed in PhpUnit 6.X from PHPUnit_Framework_ExpectationFailedException to ExpectationFailedException
Please check your PhpUnit version: phpunit --version, it should be 6.X. Update it to the last version to avoid this error.
This is "fixed" by a script in Zend\Test called phpunit-class-aliases.php but it's not configured properly IMHO since it's in the autoload-dev section (meaning it doesn't propagate out to other projects.)
So, in your project composer.json, do something like this:
"autoload-dev": {
"files": [
"vendor/zendframework/zend-test/autoload/phpunit-class-aliases.php"
]
},
Then composer install
N.B. Zend\Test has a pull request that fixes this very thing, but they're saying it's PHPUnit's fault (Shame on you PHPUnit 4 for... idunno... having the wrong class name according to Zend\Test) So, I've done it instead: composer require illchuk/phpunit-class-aliases
This is a configuration flaw in zend-test. It consumes classes from Phpunit 6 but per it's Composer requirements, Phpunit before that version are OK to require:
"phpunit/phpunit": "^4.0 || ^5.0 || ^6.0",
Most likely as your system because of the PHP version does not satisfy the requirements of Phpunit 6, the next lower version was installed.
As the code in the base test case (https://github.com/zendframework/zend-test/blob/master/src/PHPUnit/Controller/AbstractControllerTestCase.php#L444) makes use of Phpunit 6 classes, I strongly assume that when the configuration flaw is made aware to the Zend-Test project, you won't be even able to install on your system any longer.
Therefore upgrade to a recent PHP version and then run
composer update
If you're stuk with the PHP version, downgrade zend-test to a version that supports an older Phpunit version. I don't know that project well, so it's just a suggestion, I don't know if such a version exists or can't even recommend one.
I filed a report, perhaps using that one class was an oversight or there is a less hard way to resolve the dependency: https://github.com/zendframework/zend-test/issues/50
I have an OSGi Bundle and a servlet. Now I want to access the bundle from the servlet. For that purpose I use the following in the servlet:
#Resource
BundleContext context
...
ServiceReference ref = context.getServiceReference("package.MyOSGiServiceInterface");
MyOSGiServiceInterface service = context.getService(ref);
The Problem is that my servlet doesn't know MyOSGiServiceInterface 'cause that is defined in the OSGiBundle. In Eclipse I added a reference to the bundle Project in my Build Path. But at runtime it obviously can't find it.
To solve that Problem I played around with
(in bundle manifest)
Export-Package: package-of-osgi-service-interface
(in servlet manifest)
Import-Package: package-of-osgi-service-Interface
Dependencies: ...,deployment.MyBundle
But I couldn't solve it.
Whats the missing step? How can I tell JBoss to add the package containing MyOSGiServiceInterface in OSGiBundle to the class path?
Thanks for answers!
(JBoss AS 7.1.1)
--> error message <--
Eventually I solved it. I had to put the right combination of settings together to reach my goal:
Deploy the bundle per: File - Export - "Deployable plug-ins and fragments" into folder: "jboss/standalone/deployments"
Bundle-Manifest:
Bundle-SymbolicName: TestBundle
Bundle-Version: 1.0.0
Export-Package: "package-which-includes-my-service"
Servlet-Manifest:
Dependencies: org.osgi.core,org.jboss.osgi.framework,deployment.TestBundle:1.0.0
Import-Package: "package-which-includes-my-service"
I am testing JBoss AS 7 prior to deployment with a .war file of an app running in a different server.
I get this error when I try to log onto the database via the app:
SEVERE [] (http--0.0.0.0-8080-4) java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
java.lang.ClassNotFoundException: org.apache.commons.codec.DecoderException from [Module "deployment.app.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at org.apache.commons.httpclient.HttpMethodBase.<init>(HttpMethodBase.java:220)
In some forums, they suggest adding the commons-codec jar, but I already have it in JBoss, right? (in here: jboss-as-7.1.1.Final/modules/org/apache/commons/codec/main/commons-codec-1.4.jar)
OSGi is not activated, frankly I have no idea to what purpose it serves, but when I try to activate it it messes with my war as it fails to deploy...
I have JDK, but no JRE if that's any help.
JBoss AS 7 does not use OSGi by default for modular class loading. It uses JBoss Modules so this has nothing to do with OSGi.
What you need to do if you want to use the commons-codec provided with JBoss AS 7 is add a dependency to your deployment.
Modules are not visible by your artefact classes automatically. You have three possibilities:
Define a global module in your standalone.xml
http://javahowto.blogspot.de/2012/09/how-to-create-global-modules-in-jboss.html
This module will be used by all artefacts you are deploying on Jboss.
Put it into your war artefact, into the lib folder. You can do that with Maven.
Define an explicit dependency within your Manifest. https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
Section Dependencies: Manifest Entries