Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 30 11:31
    rovarga commented #5
  • Sep 23 08:33
    atooni commented #5
  • Sep 23 08:31
    atooni commented #5
  • Sep 22 08:45
    karthickm512 commented #5
  • Jun 23 2020 11:22
    atooni labeled #6
  • Jun 23 2020 11:21
    atooni labeled #5
  • Jun 23 2020 11:20
    atooni closed #2
  • Jun 23 2020 11:20
    atooni commented #2
  • Jun 23 2020 11:20
    atooni closed #1
  • Jun 23 2020 11:20
    atooni commented #1
  • Jun 23 2020 11:17
    atooni assigned #5
  • Jun 23 2020 11:17
    atooni assigned #6
  • Jun 23 2020 11:15
    atooni commented #5
  • Jun 23 2020 11:13
    rovarga commented #6
  • Jun 23 2020 11:00
    atooni commented #6
  • Jun 23 2020 09:49
    rovarga edited #6
  • Jun 23 2020 09:49
    rovarga edited #6
  • Jun 23 2020 09:48
    rovarga opened #6
  • Jun 23 2020 09:42
    rovarga opened #5
  • Jun 20 2020 13:38

    atooni on main

    Moving GH workflow to main rath… Fixing typo in build workflow (compare)

Tobias Roeser
@lefou
Hi
Andreas Gies
@atooni
Hello ...
Andreas Gies
@atooni
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.
Tobias Roeser
@lefou
I'm not sure I understand what you are proposing here. Btw, we already track some split packages in #1 and #2.
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.
Tobias Roeser
@lefou
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/
Andreas Gies
@atooni
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.
Andreas Gies
@atooni
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.
Andreas Gies
@atooni
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.
Tobias Roeser
@lefou
I think we should create a ticket for the akka.stream - akka.actor relationship.
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?
Andreas Gies
@atooni
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
Tobias Roeser
@lefou
So what are the original akka bundles (actor, streams) doing? After all they work for blended, right?
Andreas Gies
@atooni
Not in scala 2.13 / Akka 2.6.6, but I don't think the Scala version matters here
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
Tobias Roeser
@lefou
Ok
Andreas Gies
@atooni
FYI. I have pushed my branch (though it is not entirely working)
Andreas Gies
@atooni

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

Andreas Gies
@atooni
Looks like we need to make sure that "split packages" are bundled into one of the jars as an exported package and removed from the other
Andreas Gies
@atooni
Ok - the strategy for split packages is to have the combined content as an export in one of the bundles
I have just made the final touches to make the blended containers come up again .
Tobias Roeser
@lefou
:+1:
Andreas Gies
@atooni
image.png
Container / HTTP server up and running with self generated manifests
Andreas Gies
@atooni
FYI: I have just switched master to main as discussed