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 >
