Right, Atomos is doing the same thing with respect to scanning for JARs on a flat class path, among other things. My concern was that Winegrower is looking for a "lightweight" implementation to provide the OSGi runtime where perhaps it is thought that a full OSGi implementation would be "too much".
On the other hand, I think the existing framework implementations can start up quickly enough and they will provide you with more fidelity for the OSGi runtime. Tom On Fri, Apr 17, 2020 at 9:43 AM Jean-Baptiste Onofre <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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 <[email protected] > > > >>> 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 <[email protected]> > >>>> napisał(a): > >>>> > >>>>> Inline... > >>>>> > >>>>>> On Apr 12, 2020, at 3:23 PM, Christian Schneider < > >>>>> [email protected]> 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 < > >>>>>> [email protected]>: > >>>>>> > >>>>>>> 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 <[email protected]> > >> 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 > >>>>>>>> <[email protected]> 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 < > >>>>>>>>> [email protected]>: > >>>>>>>>> > >>>>>>>>>> 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 > >>>>>>>> [email protected] > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> -- > >>>>>> Christian Schneider > >>>>>> http://www.liquid-reality.de > >>>>>> > >>>>>> Computer Scientist > >>>>>> http://www.adobe.com > >>>>> > >>>>> > >>>> > >> > >> > >
