There is already one without OSGi (utilda: https://geronimo.apache.org/microprofile/), guess it is just a matter of finishing the OSGi meta for all the desired spec (guess health has not yet the right OSGi-CDI registration for ex). That said it already runs with winegrower having OSGi and CDI side by side :). Not sure a good home though for such example. After some thought I think Karaf can be saner than aries since it is the Apache integration project.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 15 avr. 2020 à 20:37, Christian Schneider <ch...@die-schneider.net> a écrit : > It sounds very good. Are you planning to provide a similar complete example > using the building blocks you mentioned? > > Christian > > Am Mi., 15. Apr. 2020 um 13:33 Uhr schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > Hi Christian, the openX i mentionned are the standards done at CNF so > > standard for metrics is openmetrics, for tracing opentracing etc. > > On my side I use Microprofile metrics and export it to prometheus with > the > > spec exporter but I know some java guys use jmx exporter so guess the > best > > we can do is to use a standard API with a default exporter, this is why i > > proposed microprofile. > > For the config I think being able to plug its own "source" without being > > vendor coupled is important but I agree defaults (system props, env and a > > file) is important, here mp-config (equivalent of spring environment) > makes > > sense IMO. Think Ray dod the work to make it runnable in OSGi. > > > > On the packaging side I know JIB works very well with all environment, > > including some more complex than OSGi but it can require some custom > > wrapping - I know JB started to look some time ago after we discussed > about > > it, not sure where we are today. Advantage compared to bnd standalone > build > > is that you dont specialize the build and enable to extend the OSGi > runtime > > with new layers - enabling to use layer cache - instead of forcing to > > restart from almost scratch. > > > > In terms of runtime I think winegrower can be interesting since, > depending > > what bundles you use, you can potentially go native with graalvm very > > easily keeping a dev experience quite fluent even outside eclipse (which > is > > the biggest pitfall of OSGi today IMHO). The docker/k8s move is likely > the > > devops move so dev part must be more friendly too IMHO. > > > > Hope it makes sense. > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le mer. 15 avr. 2020 à 13:25, Christian Schneider < > ch...@die-schneider.net > > > > > a écrit : > > > > > What do you mean by a runtime? For me the runtime is a suitable set of > > > bundles that provide what the application needs. What would be a more > > > concrete runtime? > > > > > > My approach here is to go with standards as far as possible. Ideally > also > > > rely on Apache bundle impls so we have some leverage if something needs > > to > > > be extended / fixed. > > > > > > I am looking forward to see what you have in mind with karaf devx but > > have > > > not seen anything there. > > > > > > Christian > > > > > > > > > Am Mi., 15. Apr. 2020 um 07:23 Uhr schrieb Jean-Baptiste Onofre < > > > j...@nanthrax.net>: > > > > > > > +0 for me. > > > > > > > > Again, it’s interesting, a blueprint/tutorial is possible but I would > > go > > > > with something more concrete. > > > > > > > > It’s what I started while ago with Karaf-boot and now on Karaf DevX > > > branch. > > > > > > > > Go ahead if you want but my concerns are: > > > > > > > > - it will be maybe too abstract and complex for non OSGi users > > > > (spring-boot guys especially) > > > > - as I follow agree with your view about "too much fine grained > > services" > > > > (it’s something that I discussed with Netflix), I think a runtime > would > > > be > > > > welcome > > > > > > > > So, I’m no against, but I think the DevX approach is more concrete, > > > > straight, and addressing non OSGi users. > > > > > > > > Regards > > > > JB > > > > > > > > > Le 15 avr. 2020 à 07:15, Christian Schneider < > > ch...@die-schneider.net> > > > > a écrit : > > > > > > > > > > (I first proposed this in felix. Some people hinted that Aries > might > > > be a > > > > > better fit. So I am also starting this discussion here) > > > > > > > > > > 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 > > > > > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com >
