Do they even remotely resemble the ones I mentioned?
I personally believe that all the DI frameworks which have been adapted to OSGi have largely done it the same way in the past and are failing for the same reasons; they have fundamentally done dynamics wrong.
On Tue, Jul 12, 2016 at 11:57 AM, Guillaume Nodet <[hidden email]> wrote:
Guillaume, I decided to start a new thread on this topic.
I'd be very interested in this work.
It's actually a topic I've recently discussed with several other OSGi community people and I think there is, at least in my view, reasonable doubt that this could be the right approach for dealing with non-osgi dependency injection frameworks in general.
My belief is that one should NOT try to hammer dynamics into DI frameworks which were not originally designed with it in mind. Rather, DS has what I consider the perfect model for it AND what should happen is that DS should "host" a client DI framework.
This next idea came from Tim Ward. His suggestion is that the DS bits be generated into a synthetic class which would:
a) control the lifecycle of the DI client framework (create/destroy)
b) populate the DI context with the references, letting the client DI wire them into the appropriate places.
With this model, I feel that we could make a base implementation on top of which we could put
- Spring DI
- Google Guice (sisu, peaberry, etc.)
- you name it!!!
- gains all the power of modern OSGi; all the cardinality mappings, integration with cm, metatype, etc.
- gains lossless power of the DI framework
Could you describe the main principles of your design?
I'm interested to hear your perception or definition of how DI frameworks are failing. That's quite possibly true but I'm not sure. Are they not succeeding commercially and in adoption? Are they failing technically? Obviously the community feels rather motivated to find a different answer. When you say the dynamics were done wrong are you specifically referring to the use of proxies to allow for bootstrap without concern for ordering at the downside cost of perhaps a proxy never gets bound? Insights are always welcome.
On Tue, Jul 12, 2016 at 11:43 AM, Raymond Auge <[hidden email]> wrote:
On Tue, Jul 12, 2016 at 12:54 PM, Brad Johnson <[hidden email]> wrote:
Service damping is an utter failure from my point of view. It simply cannot be used in a on premise product with optional features.
We had blueprint in place for several months in the initial phases of our project and simply had to gut it out completely. We needed real non-busy wait behavior.
Besides blueprint we also built our very own proxy based dependency mechanism for those places where we could not use DS or blueprint (because the code is outside the framework) on which we followed the very best practices based on blueprint's design and still it's subject to the same painful limitations.
In short, there's simply no way wish away dynamics!
The only solution is making the code aware of dynamics OR put the dynamics outside the reach of the code that can't handle it.
We have lots of spring customers, we have lots of CDI customers, we have transactions, we have AOP, we have tones of proxies, we pretty much have the entire Java EE stack to support. But I simply will not subject them to the pain of service damping!
PS: I forgot the state that I simply see no way for anyone to implement a non-OSGi DI framework without some form of service damping. At some point your container will come up and the services will either be there or they will not, at which point the code either waits and retries later, fails immediately, or knows how to deal with the dynamics.- Ray
On Tue, Jul 12, 2016 at 1:07 PM, Raymond Auge <[hidden email]> wrote:
Interesting. I guess I haven't run into that issue with Blueprint but then I'm usually not waiting for optional features either. I can see where that would be problem since as a user you wouldn't know if the proxy is bound. As far as I can tell there are only two things that proxies do well. They allow the system to boot and wire up without concern for order. They permit easy reloading of bundles and services as well. I really haven't run into that many problems. I build large and complex systems but don't have optionals.
On Tue, Jul 12, 2016 at 12:14 PM, Raymond Auge <[hidden email]> wrote:
In reply to this post by Raymond Auge
Let me describe what I've done which is available in pax-cdi master branch.
I've defined a bunch of CDI annotations for the DS semantics (@Component, @Service, @Filter, @Property, @Immediate, @Dynamic, @Greedy, @Optional, etc...). Multiple cardinality is done through Instance<X>, the usual CDI way. The extensions delegates to an embedded Felix SCR implementation. SO it's not DS hosing CDI, but the opposite really, and DS is not visible at all, since the public APIs do not provide any low-level access required for such interactions.
The trick for integrating the dynamic aspect inside CDI is that beans that have an OSGi service dependency have a specific OSGi scope (so that a singleton can still be injected and CDI will handle the damping, same as if it was a servlet request scoped bean for example). This limitation (about the fact that you can only inject into beans with custom scopes) can be removed with an additional @Global annotation. The effect is that the whole container lifecycle will be bound to this dependency being available or not (as you explained in your solution).
One deviance from pure DS is the split between components / services. In DS, you can only inject OSGi services. I've hacked things a bit so that you can also inject another @Component without the need to go through the OSGi registry.
So far, the config admin integration is done using @Config on the injection point, where the injected type is an annotation too. A proxy is generated for this annotation based on the configuration from ConfigAdmin with default values provided by the annotation default values.
Fwiw, the current RFC drafted at the OSGi alliance for CDI integration relies heavily on service damping and proxies, which is a really bad decision. I kinda hope the work I've done could change that a bit, but if my implementation has to deviate from the OSGi standard to be relevant, so be it : I don't consider myself bound and limited by crappy standards ;-)
2016-07-12 18:43 GMT+02:00 Raymond Auge <[hidden email]>:
Are you making your CDI RFC concerns visible, audible, tangible, and obvious to the eg working on the RFC? For instance, since blueprint seems to enjoy considerable popularity among some, it might not be obvious to everyone involved with the RFC why service damping is such a bad idea.
I voiced my concern in the EEG 3 years ago when I was working on the RFC I think, maybe not loud enough.
I reached to Emily who is leading the RFC about what I've done and exchanged a few emails a few weeks ago.
I'll try to write an email to send to the EEG about that to make sure about the visibility of my concerns.
2016-07-13 0:20 GMT+02:00 David Jencks <[hidden email]>:
I was working with Camel SCR over the week end evaluating readiness and state for my next project. So I came back to read your comments about the pax-cdi. While there's a great deal to like about Camel SCR and DS and from all the reading about the problems with service damping it appears that blueprint will either have to fundamentally change in the future or be replaced.
The problem I ran into with Camel specifically was the lack of mechanics for doing any injection of beans for use in routes. Standard annotations don't work and the implementation is very much a straight jacket. Since I'm working almost exclusively in middleware and integration Camel is at the heart and soul. I suspect that 90% of those of us who use blueprint are in that crowd.
The great irony in Camel is it is very easy to go from XML to invoke handlers/beans by very simple reference mechanics but trying to do the same thing from the Camel Java DSL isn't any easier and in Camel SCR it is extremely inelegant - .method(this, "invokeMyMethod") where one can't even call the method directly.
I'm rewriting an existing application that was written entirely in blueprint XML and XSLTs to be in Java using beanio, dozer, handlers and other more developer friendly items. But it didn't appear there was going to be an easy way to do that with SCR without converting the one bundle into about 10.
I think the real issue there might be something like external OSGi concerns versus internal wiring and dependency injection of bundle internals. That seems non-existent. I recognize that isn't directly your concern or project just and observation.
On Wed, Jul 13, 2016 at 2:32 AM, Guillaume Nodet <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|