We need to reconsider the approach not to change the content og the jar. For the akka http jars (akka-http, akka-http-core and akka-parsing) we will see that classes share the same package name. For these jars the classes in question are generated classes. The classes as such are disjunct with no overlaps. When we don't change anything in the jar file, the package (i.e. akka.http.ccompat) will be exported by all jars which have classes for that package. As a result we may see ClassNotFoundExceptions, because only one or the other portion of the package becomes visible through an import. A "solution" without interfering to much with the development of the original jars is to use split packages with a merge directive. This will make split packages private packages in each affected jar and will include the combined content of the package.
Hence, for jars that are affected by split packages, our test to verify that the content has not changed, needs to take split-packages into consideration. The test, that no class may be dropped in the OSGi jar must work without change.
I know, that some Eclipse Bundles also had the problem of split packages
They added some kind of qualifier to the exports and re-import these qualified exports to export them again with no or another qualifier. I don't know the name of that concept now.
Here is just one link to a discussion, which describes the setup used in Eclipse bundles. https://www.eclipse.org/forums/index.php/t/37564/
The sugesstion is i.e. here: https://github.com/woq-blended/akka-osgi/blob/ct_213/build.sc#L241-L249. Before, within the blended project we have packaged the akka http API ourselves already. The approach there was to provide a combined jar that contains all the classes from akka-http, akka-http-core and akka-parsing, thus bypassing the split-package problem. Within akka-osgi we wanted to have a one-to-one relationship with the jars provided by the akka project. If we stick with that approach, we need to tackle the split packages.
The approach I was suggesting makes the required classes available where needed, but the classes occurr more than once in different jars within private packages. I have verified, the Akka HTTP API works as expected with the split packages I have suggested. I will have a look at the Eclipse solution later on. Perhaps I am missing something.
Just reread the thread in the eclipse forum. If I understand the attributed export correctly, it should be possible to leave the jar files untouched and still import the content for the same package from different sources if attributed correctly. If thats the case, we revrt back to our strategy of not changing the jar's content when republishing.
This having said, it would be interesting if the bnd tool still reports "split-packages" when applying the attributes. If it doesn it would be great. Then we could make the build fail when split packages are reported. If split packages are not being treated in one or the other way it is nearly a guarantee that the akka system will not work as expected.
It looks like there is a slight dependency between akka-actor and akka-stream. Per default Akka > 2.6 seems to use a Serializer that lives in akka.stream package. This Serializer is created upon start of the ActorSystem via reflection. It seems that that akka-actor must "see" akka-stream, while technically akka-stream must also see akka-actor. In my branch to make the blended container work with the wrapped Akka bundles I have now a working solution where I make the wrapped akka-stream a Fragment of akka-actor. This allows me to keep the separation like they appear in the akka project, but is a point to review.
Trying a similiar thing with the strongly related akka-http, akka-http-core and akka-parsing does not work. Either all classes of the split package end up in all jars or None. I have tried the suggested solution similar to the Eclipse thread, with the same result and even more warnings from bnd. I am inclined to use the solution we had in Blended 3.1 for akka http already. There we created a jar for the Akka HTTP API that combined the classes of all three akka provided jars and created a proper manifest. On top of that we have written our akka http server bundle exposing an akka http service.
The drawback is that we would end up with a n:1 relationship from akko to wrapped bundles and must keep a record which OSGi artefact is equivalent to which set of akka jars.
Personally, I don't like to use a bundle fragment.
What about an optional import or even a dynamic import
Will it fail, if the reflection access to akka.stream fails or is it completely optional?
Its not that I "like" the solution. Without being a fragment or a combined package the akka system in 2.13/Akka 2.6.6 won't start within OSGi. I am all up for tickets - once we have a container that works (which I haven't completely at the moment) we can discuss what we would like to see changed and open a ticket. This having said, for the split package the response was that most likely that would cause binary incompatibility, so its unlikely to change or at least very slow. My guess, it will be the same for the serializer moving from akka.stream to akka itself or something like that. It might be an easy fix to introduce the same class in another package and deprecate the one in akka.stream, but I havent looked into that yet.
My primary concern is to get the blended container up and running soon without using akka provided manifests
They have been marked as resolved, but the integration test suite failed
Due to the underlying ActorSystem not having started
It did work in Akka 2.5.x, but there the reference to akka.stream wasnt there in akka
Like I said, my primary goal ATM is to have a working container to see Akka 2.6.x is actually possible in blended (which I think as I am very close to a working container). Once we have that we can turn back and play with other implementation options. Once we are fairly happy with what we came up with we can propose it to a broader audience
This is the last remaining error in blended..container
3621 2020-06-19-15:03.15.186 | 7452 | ERROR [main] blended.launcher.Launcher :
3622 org.osgi.framework.BundleException: Activator start error in bundle blended.akka.http [110].
3623 at org.apache.felix.framework.Felix.activateBundle(Felix.java:2452)
3624 at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
3625 at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
3626 at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
3627 at blended.launcher.Launcher.$anonfun$moveToStartlevel$8(Launcher.scala:484)
3628 at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.scala:18)
3629 at scala.util.Try$.apply(Try.scala:210)
3630 at blended.launcher.Launcher.$anonfun$moveToStartlevel$6(Launcher.scala:484)
3631 at scala.collection.immutable.List.map(List.scala:250)
3632 at scala.collection.immutable.List.map(List.scala:79)
3633 at blended.launcher.Launcher.$anonfun$moveToStartlevel$1(Launcher.scala:480)
3634 at scala.util.Try$.apply(Try.scala:210)
3635 at blended.launcher.Launcher.moveToStartlevel(Launcher.scala:463)
3636 at blended.launcher.Launcher.$anonfun$start$3(Launcher.scala:526)
3637 at scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:190)
3638 at blended.launcher.Launcher.$anonfun$start$1(Launcher.scala:525)
3639 at scala.util.Try$.apply(Try.scala:210)
3640 at blended.launcher.Launcher.start(Launcher.scala:511)
3641 at blended.launcher.Launcher.run(Launcher.scala:545)
3642 at blended.launcher.Launcher$.run(Launcher.scala:203)
3643 at blended.launcher.Launcher$.main(Launcher.scala:47)
3644 at blended.launcher.Launcher.main(Launcher.scala)
3645 Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/apache/felix/framework/BundleWiringImpl$BundleClassLoader) previously initiated loading for a different type with name "akka/http/scaladsl/settings/ParserSettings$CookieParsingMode"
3646 at java.lang.ClassLoader.defineClass1(Native Method)
3647 at java.lang.ClassLoader.defineClass(ClassLoader.java:757)Guess I need to go and scratch my head for a bit
I have just made the final touches to make the blended containers come up again .
