Hi Wayne, I am using Aries JAX-RS whiteboard for REST. It works pretty well. Implementing a REST service is only part of the solution for a full cloud native microservice. I want to build an easy to replicate example for a microservice that is integrated with all the goodies you need in the cloud. You can take a look at the current state in: https://github.com/cschneider/osgi-best-practices
Some of the solutions like the prometheus support are still a bit limited. Ideally I would like to have a MetricRegistry as a service in OSGi and auto update the prometheus export whenever new metrics are added by any OSGi component. My example is currently also missing authenticatition. I hope that collaborating on an example allows us to the find good solutions to all of those aspects. Christian Am So., 12. Apr. 2020 um 21:48 Uhr schrieb Wayne Tackabury <way...@gmail.com >: > Howdy Christian, J-B, et al…. > > I’ve been working on such a thing for the last few weeks in a cloud of > shelter-in-place frustration, and I believe I can donate what I have > if it’s helpful at all (otherwise, I’ll be very interested in what you > have to see how it differs). I had that moment of glorious arrival on > Friday when my bundle finally deployed in gogo and the diagnostic > print from my activation routine printed to System.out. > > Now, for my stuff, it’s currently a bit of what a former Irish company > president of mine would call a “dog’s dinner”, since I have tons of > redundant export-package references and such to remove. I also am > thinking the well-established packages (like the ones pulled from > referencing the felix obr repository) do really want to remain > separate bundles, just cleanly pulled in and activated at the time of > REST/microservice deploy (which is what mine is doing). > > Really, what I did was to consolidate other examples I had, none of > which built or activated properly on Felix 6.0.3 for me and I got > frustrated and created my own which did after a moderate amount of > struggle. > > Also, mine is about 50% Apache Jersey (which might be reduandant w.r.t > some of the karaf-ery), 50% Felix content/reference-wise. Do you want > to make it pure felix? It’s all just pom.xml references otherwise. > > And just to be clear, is there anything manifestly “microservice”-y > that would distinguish from a reasonably well-featured REST framework? > I take it you’re looking to pull in karaf (I haven’t yet, but will, > I’m just learning to go slow because one false/erroneous move can > break the entire thing I’m finding). I have it up and speaking, I > just need to create a notion of universal deploy-ability (and that > includes guidance for docker-ization, which I’m thinking I’ll do by > having container initialization that drives felix/gogo via commands to > do the resolve and deploy). > > In summary, if you’d rather go solo, that’s cool, but I’m all over > this this week and could help if it helps at all, would be happy to > contribute. > > Regards, > Wayne > > On Sun, Apr 12, 2020 at 1:46 PM Jean-Baptiste Onofre <j...@nanthrax.net> > wrote: > > > > Hi Christian, > > > > That’s interesting, but I think that people are expecting more than that. > > > > 1. Most of the time, we do things too much complex. > > 2. Assembly again layers is not always easy > > 3. Where’s the runtime ? > > > > Your main point is valid: lot of people went too far in fine grained > services and now, they are thinking about "smart" micro services. > > That’s exactly the purpose of Netflix using Apache Karaf. > > > > Back on your point, that’s the target of "new" Karaf tool that I > restarted (re-starting/founding Karaf Boot we discussed while ago that > addressed exactly the points you mentioned). > > > > So, why not having a blueprint (I still think people wants to create > their own blueprint), but having tool + runtime is more interesting and > that’s why I’m working on Karaf "DevX code" PoC. > > > > Regards > > JB > > > > > Le 12 avr. 2020 à 11:58, Christian Schneider <ch...@die-schneider.net> > a écrit : > > > > > > 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
