I think that could make a lot of sense. So winegrower could focus on the additional aspects like application assembly and producing docker containers.
Christian Am Fr., 17. Apr. 2020 um 16:35 Uhr schrieb Thomas Watson <tjw...@gmail.com>: > 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 > > >>> > > >>> > > >> > > > > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
