Hi Tom, Basically, Winegrower idea is to bring the OSGi programming model (activator, service, etc) with a "flat" class loader.
So, Winegrower is scanning the provided jar gathering in a single classloader. I’m adding new examples to show use cases. I’m open to any new ideas/features ;) Regards JB > Le 17 avr. 2020 à 16:35, Thomas Watson <tjw...@gmail.com> a écrit : > > Hi JB > > Changing subject to start new thread ... > > I have taken a look at Winegrower, but have not played around with it yet. > I am curious if something like Winegrower would be interested in using OSGi > Connect to back it with an OSGi R8 framework implementation or perhaps use > Atomos for bundle discovery? > > Tom > > On Fri, Apr 17, 2020 at 9:15 AM Jean-Baptiste Onofre <j...@nanthrax.net> > wrote: > >> 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 >>>>> >>>>> >>>> >> >>
