Hi Thomas, Did you take a look on Winegrower ? (Just curious):
https://github.com/apache/karaf-winegrower <https://github.com/apache/karaf-winegrower> Regards JB > Le 17 avr. 2020 à 15:47, Thomas Watson <tjw...@gmail.com> a écrit : > > I just want to clarify a bit on Atomos and OSGi Connect. While OSGi > Connect does allow some more flexibility in the Module Layer of OSGi, it is > not entirely getting rid of it. There is still a resolution, there are > still bundle wirings and the powerful requirement/capability model, there > are still bundle events and so on. What it does allow is loading of > bundles from alternative formats/sources to allow the usage of OSGi > technology in environments not previously possible (such as Graal > native-image). If you have issues today getting resolution to work for a > particular deployment of OSGi bundles then these same resolution issues > will be present when using Atomos. On the other hand, if you find value in > the OSGi development model then you can continue to develop your bundles as > you do today but then have the flexibility to deploy your bundles in > environments not previously possible. The fact that we continue to do a > resolution of connect bundles is an effort to make sure all the things your > bundle needs to be functional is available and accessible from your connect > bundle. > > Tom > > On Wed, Apr 15, 2020 at 1:11 AM Grzegorz Grzybek <gr.grzy...@gmail.com> > wrote: > >> Hello >> >> First, I'm not good at telling what should be done or providing visions for >> something new and revolutionary. I'm experienced with checking what SHOULD >> NOT be done and how to polish/stabilize/cleanup existing things, created by >> much clever people than me. >> >> [...] such as graalvm or quarkus. (I know so little about this that I could >>> be wrong about what these are). >>> >> >> I can provide a little explanation, but I'm not core Quarkus dev. When >> talking about "cloud", the above are very important. >> >> GraalVM is based on HotSpot with these (roughly) differences: >> - through JVMCI interface (https://openjdk.java.net/jeps/243) the normal >> _compiler_ of hotspot (the bytecode -> native code compiler, not the source >> -> bytecode one) is replaced by Graal compiler >> - Graal compiler is written in Java, so it's JITted itself >> - Graal claims to create better native code >> - *Graal allows ahead-of-time compilation* >> - SubstrateVM being part of Graal has `native-image` tool, so you can get >> ELF binary from a Jar >> >> Quarkus leverages the above, and brings many dev-friendly aspects to it >> (it's developed by Red Hat and it's kind of similar situation as with >> Kubernetes - OpenShift) - mind that I'm not much experienced with it yet >> - brings new tools to the dev toolkit (mostly maven plugins) >> - brings an API to expose the ahead-of-time aspects of Graal - generally, >> you can mark methods/classes of your code (through annotations) as "running >> in build phase" >> - "build phase" is executed before even starting the VM. Imagine >> HIbernate. When you create Hibernate based µservice and you start it, lots >> of time is spent reading XML/annotations and building SessionFactory. With >> Quarkus, this *all can be done at build phase* and you end up with bytecode >> (or in native case - premade memory pages that can simply be mapped to your >> process). Then when your main() starts, you don't have to create >> SessionFactory - you *have it* >> >> Mind that the above is not precise, but should not miss the picture (I'm >> for example not sure about the premade memory pages). >> >> OK. Now what should be avoided. In Red Hat Fuse 6 was based only on Karaf. >> Fuse 7 though has more forms and there's a lot about OpenShift. The >> problematic thing was - how to put Karaf into OpenShift. >> >> Think about what is important in "cloud" - you need your pod/container >> start as fast as possible because of all this scaling-to-demand thing. >> Imagine lambda-functions (or whatever it's called nowadays). If a µservice >> would spend 95% of the time building SessionFactory and 5% inserting the >> record into database, it'd be crazy. >> >> With OSGi, lots of warmup comes from bundle resolution. I know the >> resolution state can be persisted. But still. >> >> I don't have clear answers or even clear feedback to this thread. I feel >> one thing - there are 2 critical and fundamental OSGi aspects: >> - module layer (bundles, manifests, caps-reqs) >> - service layer (service registry) >> >> And while the service layer (supported by e.g., SCR annotations/runtime) is >> *the synonym of µservices* (see blog from 2010 when no one talked about it >> yet: https://blog.osgi.org/2010/03/services.html), the module layer is >> what >> may be a problem here. >> >> All the effort with felix-connect, Atomos (which I've just checked covers >> SubstrateVM scenarios - I wasn't aware of this) is about making >> module-layer more cloud friendly. >> >> I feel a little confused. Having worked 100% with OSGi for >6 years I found >> the original module layer the most important thing - because of the bundle >> resolution, cap-req matching, versioning, bundle revisions and wirings. The >> API and programming model aspect of OSGi was not that important which has >> two consequences: >> 1) I just got used to it that I have access to BundleContext, >> BundleRevision and other API interfaces and e.g., blueprint.xml format >> 2) If not the module layer of OSGi, nothing would keep me using the above >> API >> >> CDI and Spring (annotations, XML) are other, widely used programming (and >> code-architecting) models and I somehow feel that when module layer is >> gone, these models are simply better, more flexible and less constraining >> than SCR or Blueprint. >> >> So when OSGi "adopts" the module layer to the "cloud", turning it into >> flat-classpath deployment, what's the reason to call it OSGi at all? >> >> Please don't get me wrong - I'm not going to sabotage any effort, I want to >> avoid the confusion. >> >> Imagine this >> - we turn module layer into flat classpath >> - we use aries-cdi to allow programming beans/services using CDI >> annotations (JavaEE) >> - we use aries-jaxrs to create WS/REST endpoints using Jax-RS annotations >> (JavaEE) >> - we hide BundleContext.getServiceReference()/getService() APi >> >> Where's the OSGi then? >> >> I don't have answers. As I've noted at the beginning, I'm experienced with >> imagining what could go wrong (though I'm never 100% right) and with making >> things maintainable (pax-logging refactoring and now pax-web refactoring). >> >> From my experience, the biggest problem with OSGi is that when you install >> a lot of feature into Karaf (or in my case Fuse-Karaf) you end up with lots >> of conflicts, double OSGi chains and guava version. One of my reactions to >> this problem was etc/org.apache.karaf.features.xml and "new blacklisting >> and override mechanism" for Karaf. >> But generally I know the pain and the percentage of real problem cases >> related to bad OSGi resolution. >> >> I think (sorry for the email becoming too long) I want to highlight the >> problem - if we focus on µservices too much, imagining it's "set of ~20 >> bundles" running on flat classpath with aries-cdi + aries-jaxrs then again >> - where's the OSGi? Could you answer a stack overflow question like that? >> And explain why it's better than e.g., Spring Boot? >> >> I hope you didn't get me wrong - I'm not against OSGi, because I like it ;) >> >> regards >> Grzegorz Grzybek >> >> pon., 13 kwi 2020 o 00:45 David Jencks <david.a.jen...@gmail.com> >> napisał(a): >> >>> Inline... >>> >>>> On Apr 12, 2020, at 3:23 PM, Christian Schneider < >>> ch...@die-schneider.net> wrote: >>>> >>>> Hi David, >>>> >>>> actually I did not think about Aries but you are right, it could also >> fit >>>> there. If the Felix community thinks Aries is the better place I will >>>> propose it there too. >>>> I think for marketing purposes Felix is a lot more known than Aries. >>>> The main purpose I want to achieve is that people consider doing >>>> microservices with OSGi. So I wanted to leverage a well known brand >> that >>>> people associate with OSGi. >>>> Apart from that the only Aries project I use in my experiments is Aries >>>> JAX-RS whiteboard but I use lots of felix bundles. >>> >>> That seems like a conceptual circular dependency with which I am not >>> entirely comfortable. However, it wouldn’t be blocking for me. >>> >>>> >>>> I agree about the naming. Blueprint was a bad choice. What do you think >>>> about "felix cloud native starter”. >>> >>> Names are hard…. ’native’ to me suggests you will be targeting one (or >>> more) of the nontraditional javas (that I am only vaguely acquainted with >>> from watching the Camel list) such as graalvm or quarkus. (I know so >> little >>> about this that I could be wrong about what these are). >>> >>> I do think that this initiative is a great idea! Maybe you could start it >>> at GitHub while the location/name/description is hammered out? >>> >>> Thanks, >>> David Jencks >>> >>>> >>>> Christian >>>> >>>> >>>> Am Mo., 13. Apr. 2020 um 00:05 Uhr schrieb David Jencks < >>>> david.a.jen...@gmail.com>: >>>> >>>>> Hi Christian, >>>>> >>>>> I’d like to know why felix is a better location for this than aries. >>>>> >>>>> I also think that you should find a description or name other than >>>>> “blueprint” as that term has unfortunately been taken by the osgi >>> blueprint >>>>> spec. Seeing your subject line I wondered why a blueprint (as in >> spring >>>>> for osgi) project would fit in felix. >>>>> >>>>> Thanks >>>>> David Jencks >>>>> >>>>>> On Apr 12, 2020, at 2:05 PM, Karl Pauls <karlpa...@gmail.com> wrote: >>>>>> >>>>>> Hi Christian, >>>>>> >>>>>> I don't think we are at that point just yet. Given that this is a >>>>>> holiday surrounded weekend for a lot of us (due to the easter break) >> I >>>>>> would say we should at least give it a couple of more days to see >>>>>> where the discussion is going. >>>>>> >>>>>> That said, I personally would like to see a little bit more about >> what >>>>>> you had in mind. Is there already some existing body of work or are >>>>>> you planning to create something from scratch? >>>>>> >>>>>> regards, >>>>>> >>>>>> Karl >>>>>> >>>>>> On Sun, Apr 12, 2020 at 9:32 PM Christian Schneider >>>>>> <ch...@die-schneider.net> wrote: >>>>>>> >>>>>>> There seems to be some interest in having such a blueprint or even >>> more >>>>>>> than one variant at felix. >>>>>>> >>>>>>> Should I start in felix-dev or use a new repo? >>>>>>> I would prefer a new repo as the code will be a multi module maven >>>>> project. >>>>>>> I propose a repo name "felix-cloud-native-starter". >>>>>>> We could have and have different blueprints (e.g. CDI and DS) >> inside. >>>>>>> I thought about but disliked to have "blueprint" in the name as >> people >>>>>>> might confuse it with the blueprint dependency injection. >>>>>>> >>>>>>> Christian >>>>>>> >>>>>>> Am So., 12. Apr. 2020 um 11:58 Uhr schrieb Christian Schneider < >>>>>>> ch...@die-schneider.net>: >>>>>>> >>>>>>>> In recent years we saw a big trend towards micro services and >> cloud. >>>>>>>> Lately people discovered though that such services are often made >> too >>>>> fine >>>>>>>> grained. >>>>>>>> The newest trend goes to building bigger micro services on the >> level >>> of >>>>>>>> domain driven design bounded contexts. >>>>>>>> >>>>>>>> Especially for these services OSGi is a very interesting platform >> as >>>>> they >>>>>>>> need more internal structure than the more fine grained services. >>>>>>>> Unfortunately it is quite hard to build a cloud native service in >>> OSGi >>>>>>>> from scratch. >>>>>>>> >>>>>>>> So I would like to offer a blueprint for cloud native micro >> services >>>>>>>> inside the felix community. The goal is to provide all parts of a >>> cloud >>>>>>>> native >>>>>>>> system that are usually needed, like: >>>>>>>> >>>>>>>> * Declarative services as dependency injection >>>>>>>> * Aries Jaxrs Whiteboard for REST >>>>>>>> * Dropwizard metrics exported as Prometheus metrics >>>>>>>> * Swagger >>>>>>>> * Halbrowser >>>>>>>> * Felix healthchecks >>>>>>>> * Configuration using OSGi configurator + Environment variables >>> plugin >>>>>>>> * Logging to console >>>>>>>> * Final application is provided as a runnable jar >>>>>>>> * Example docker build files >>>>>>>> * Example kubernetes yaml >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Christian >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> Christian Schneider >>>>>>>> http://www.liquid-reality.de >>>>>>>> >>>>>>>> Computer Scientist >>>>>>>> http://www.adobe.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Christian Schneider >>>>>>> http://www.liquid-reality.de >>>>>>> >>>>>>> Computer Scientist >>>>>>> http://www.adobe.com >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Karl Pauls >>>>>> karlpa...@gmail.com >>>>> >>>>> >>>> >>>> -- >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Computer Scientist >>>> http://www.adobe.com >>> >>> >>
