Why Akka-Http still uses older Akka-Actor? - maven

I have added the latest akka-http to my project but that includes the very old 2.4.19 version on akka-actor. Hence I also added akka-actor version 2.5.4 to the dependency. However, that results into following error:-
Detected java.lang.NoSuchMethodError error, which MAY be caused by incompatible Akka versions on the classpath.
My maven config is like below:-
<dependencies>
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-http_2.11</artifactId>
<version>10.0.9</version>
</dependency>
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-actor_2.11</artifactId>
<version>2.5.4</version>
</dependency>
</dependencies>
What am I missing? Is there any version of akka-http which uses the latest akka-actor?
Update: Added dependency graph

From the Compatibility Guidelines page in the documentation:
Akka HTTP 10.0.x is (binary) compatible with both Akka 2.4.x as well as Akka 2.5.x, however in order to facilitate this the build (and thus released artifacts) depend on the 2.4 series. Depending on how you structure your dependencies, you may encounter a situation where you depended on akka-actor of the 2.5 series, and you depend on akka-http from the 10.0 series, which in turn would transitively pull in the akka-streams dependency in version 2.4 which breaks the binary compatibility requirement that all Akka modules must be of the same version, so the akka-streams dependency MUST be the same version as akka-actor (so the exact version from the 2.5 series).
In order to resolve this dependency issue, you must depend on akka-streams explicitly, and make it the same version as the rest of your Akka environment....
Change your Maven dependencies to the following:
<dependencies>
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-actor_2.11</artifactId>
<version>2.5.4</version>
</dependency>
<!-- Explicitly depend on akka-streams in same version as akka-actor -->
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-stream_2.11</artifactId>
<version>2.5.4</version>
</dependency>
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-http_2.11</artifactId>
<version>10.0.9</version>
</dependency>
</dependencies>

Related

Defining maven dependency for JBoss 5.1.0 GA

I'm migrating a legacy project to maven, right now I have some classes that depend on this org.apache.log4j.Logger class. I am sure that this class is provided by the JBoss AS 5.1.0 GA in which it is deployed. But I don't know what groupId, artifactId and version specify for this provided dependency. Do you have some idea of which ones are the correct values for this version of JBoss?
According to this post it is, 1.2.14 version. You can add like below.
https://developer.jboss.org/thread/242961
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
<scope>provided</scope>
</dependency>

Cannot find openam-oauth2-common 13.0.0 version

We are upgrading openam to version 13. I've set artifacts version to 13.0.0 but when I start building the service with Maven I get a error message saying:
failure to find org.forgerock.openam:openam-oauth2-common:jar:13.0.0.
We are using forgerock repository: http://maven.forgerock.org/repo/repo/
Question: why the dependency is suddendly not available any longer and how to properly upgrade it?
It appears that the artifact you were using has been refactored, moving from a single project (i.e. a library) to a multi-module project (several modules, several libraries). Hence, although its Maven coordinates have not changed (GAV, GroupId, ArtifactId, Version), the usage (the consumption) of this library has been directly affected because its type has changed (again, from jar to pom).
Version 11.0.0, for example, was a jar, hence you could import it as most of the Maven dependency, via a dependency section.
However, since version 12.0.0, the artifact is a pom defining the following modules:
<module>oauth2-core</module>
<module>oauth2-restlet</module>
<module>openid-connect-core</module>
<module>openid-connect-restlet</module>
<module>oauth2-oidc-test-server</module>
Hence, what previously would have been:
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openam-oauth2-common</artifactId>
<scope>provided</scope>
<version>11.0.0</version>
</dependency>
It cannot be simply upgraded via its version number but must be replaced via several dependencies (you can now narrow down what you actually need):
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-core</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-restlet</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openid-connect-core</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openid-connect-restlet</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-oidc-test-server</artifactId>
<version>13.0.0</version>
</dependency>
Most probably version 11.0.0 is provided as a subset of the dependencies above, including them should fix the issue (but you could also investigate later on which one is effectively required by your project, e.g. the last one, oauth2-oidc-test-server, is most probably not required simply looking at its artifactId name, as an immediate guess).

Is there a link between org.wildfly.bom and the version of the wildfly server used?

I'm currently developing some applications and I'm using wildfly 9.0.2.Final as the application server. Currently I'm using bom version 8.2.2.Final for the following artifacts:
jboss-javaee-7.0-with-tools
jboss-javaee-7.0-with-hibernate
jboss-javaee-7.0-with-security
I've started using these versions while following a tutorial. However I've seen that now wildfly 10 is out and probably some other dependencies also have dependencies. Maybe in the future javaee-8.0 will be available.
Is there some documentation on what the different artifacts include and maybe what should be kept in mind when upgrading the parent bom version?
With WildFly 9+ boms we changed structure a bit, so now we only have 2 boms.
Where most of them were merged into one.
wildfly-javaee7
wildfly-javaee7-with-tools
Where second one includes not only APIs but also tools that are useful for testing like arquillian, junit, etc...
so best for your needs would be to use this in your pom.xml
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-javaee7-with-tools</artifactId>
<scope>import</scope>
<type>pom</type>
<version>10.0.0.Final</version>
</dependency>
</dependencies>
</dependencyManagement>
you can always find latest info and docs on how to use it at github at repository https://github.com/wildfly/boms
Your BOM version should match your deployment Wildfly version.
Assuming you use provided scope for dependencies that are provided by Wildfly, you want to ensure you're using the correct versions. If you use a wrong version, your application might not work as expected or even fail to start, because some API might be deprecated/removed, or because some features might not be available yet.
Side note: Wildfly BOMs lack some dependencies, so we're using parent as BOM:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-parent</artifactId>
<version>9.0.2.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

Drools 6 sisu-guava conflicts with guava

We have recently upgraded from Drools 5 to Drools 6 and have run into disturbing conflict issues.
We have kie-ci imported into out project. kie-ci brings in sisu-guava. sisu-guava changes the accessibility of some of the classes from google's guava. Unfortunately, it uses the same package name as google's guava.
Since we're working with google's guava in our project, we are running into conflicts of classes.
An attempt to remove sisu-guava from the project (using a maven exclusion) results in accessibility exceptions, as the kie-ci code attempt to access classes which are public in sisu-guava but are private in google's guava.
Any idea how to get round this.
This may not be correct solution for all situation, but I was able to resolve this issue by excluding the susi-guava jar in my pom:
<dependency>
<groupId>org.jbpm</groupId>
<artifactId>jbpm-kie-services</artifactId>
<version>${jbpm.version}</version>
<exclusions>
<exclusion>
<groupId>org.sonatype.sisu</groupId>
<artifactId>sisu-guava</artifactId>
</exclusion>
</exclusions>
</dependency>
I seem to have the same problem using drools 6.2. Drools is dependent on guava 10.0.1, where as my project had a dependency on guava 16 and maven was picking the version 16 (correctly).
On inspecting the dependency tree, I find that the drools dependency on guava is dictated by "org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5:runtime".
There is a newer version of org.eclipse.sisu.plexus, so I added the following to my project's pom to pick up the latest version, which is:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.eclipse.sisu</groupId>
<artifactId>org.eclipse.sisu.plexus</artifactId>
<version>0.3.1</version>
</dependency>
</dependencies>
</dependencyManagement>
Now, there does not seem to be a dependency on guava, for drools and the problem is solved and my project can use version 16 of guava.

How can i find which release of OSGI is supported by CQ5.5 .?

How can we find which release of OSGi is supported by CQ5.5 version, Is there any log file where i can find out the OSGi release in the CQ5 product?
CQ5.5 uses Apache Felix which is
... a community effort to implement the OSGi R4 Service Platform and other interesting OSGi-related technologies under the Apache license
The references to OSGI in the javadocs at dev.day.com point to R4 v4.2 specifically. This matches the compliance tests for the felix project
If you're building against the OSGI APIs in your application, then you'll need to add the following to your project pom.xml (assuming you're using maven):
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.core</artifactId>
<version>4.2.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.compendium</artifactId>
<version>4.2.0</version>
<scope>provided</scope>
</dependency>
in CQ 5.6 we don't use the org.ogsi dependencies anymore. instead we have (amongst others)
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.commons.osgi</artifactId>
<version>2.2.0</version>
<scope>provided</scope>
</dependency
also you have (again in 5.6, not sure about 5.5) a depfinder
http://localhost:4502/system/console/depfinder
here you can see which package/version a certain class you need belongs to.
The implementation of OSGi used by CQ is Apache Felix, which implements OSGi Service Platform Release 4.
You can find out more detail about CQ's Technical Foundation at http://dev.day.com/docs/en/cq/5-5/exploring/concepts.html

Resources