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 > >>> > >>> > >> > >
