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 < [email protected]>: > 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 <[email protected] > > > 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 < > > [email protected]>: > > > > > +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 < > [email protected]> > > > 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
