And here’s come Winegrower: the OSGi programming flavor (with service) with a single flat class loader ;)
Regards JB > Le 15 avr. 2020 à 08:11, Grzegorz Grzybek <gr.grzy...@gmail.com> a écrit : > > 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 >> >>
