I have to agree with David, So, more feedback from someone doing a really huge enterprise product migrating from Java EE to OSGi (4+ years in the making...)
Service Damping is hell. You will not enjoy experiencing the complexity that service damping will impose on your already complex environment, particular if your goal has at least some designs on optionality. Since there is no (to my knowledge) alternative for dealing with service references in blueprint other than service damping, this made it so painful for us that after more than a couple years with BP in our lives we recently undertook to remove it all. Had blueprint NOT been implemented with service damping, it could have been tolerable and even likely that we would have used it more. Perhaps if BP-next provides an alternative more akin to DS (passive wait via listeners) we may go back to it in some rare cases. However, even when it comes to things like transactions and security, there are other models that work just as well. Lastly, I think it's just a bad idea to try to shoehorn dynamics into non-dynamic models like spring/CDI because they have fundamentally different expectations. Sincerely, - Ray On Mon, Jul 20, 2015 at 11:41 AM, David Jencks <david.a.jen...@gmail.com> wrote: > yes. The R6 version of DS does too. (build it yourself from felix scr > trunk at this point). > > My opinion on DS vs blueprint: > > The proxies are sort of irrelevant. With DS, with a mandatory dynamic > reference, your component will be present when at least one instance of the > required service is available and not present otherwise. If you change the > target of the reference by starting the new service and then stopping the > old one, then your component will just switch without any interruption. > > To me the biggest functional advantage of DS is the really good > integration with config admin (even better in R6). This makes the > configuration of your service instances orthogonal to their specification. > While Aries blueprint does have config admin integration, it’s sort of > bolted on and no one has figured out a plausible way to get it into the > blueprint spec (possibly due to lack of interest). > > While when it started I thought blueprint was ideal, as I’ve learned more > about OSGI I’ve come to regard blueprint as a transition crutch for those > addicted to Spring. However, I have only used OSGI to develop app servers, > I’ve never tried to write an enterprise app using OSGI, so there may be > different considerations for your use. > > thanks > david jencks > > > On Jul 20, 2015, at 9:17 AM, Alex Sviridov <ooo_satu...@mail.ru> wrote: > > > > Hello, Christian. Thank you very much for detailed answers and great > tutorial! > > > > I have one question - Does blueprint support scopes - I need new > instance of service for every consumer? > > > > > > > >> Понедельник, 20 июля 2015, 9:24 +02:00 от Christian Schneider < > ch...@die-schneider.net>: > >> > >> > >> > >> Am 20.07.2015 um 07:33 schrieb Alex Sviridov: > >>> > >>> I have a few questions (I found some information but I'm afraid it is > old): > >>> > >>> > >>> 2) Does blueprint support generating xml files via annotations like > DS. If yes, then what maven plugin should we use > >> There is a blueprint-maven-plugin from aries. It supports using JEE > >> annotations for most of the functionality of blueprint. > >> Basically the goal is to provide annotations for blueprint that are as > >> compatible to JEE as possible so people who learned JEE feel at home. > >> http://aries.apache.org/modules/blueprint-maven-plugin.html > >> The example below shows a small application that uses just annotations. > >> In practice you can also add hand written blueprint for things the > >> plugin does not cover (like e.g. CXF integration). > >> > http://www.liquid-reality.de/display/liquid/2015/03/05/Apache+Karaf+Tutorial+Part+9+-+Annotation+based+blueprint+and+JPA > >> > >> The plugin works quite well and is already used in production at one of > >> our customers. The scope of the plugin is limited a bit though. > >> For example it already supports simple transaction and jpa injections > >> but it is not yet compatible to Aries JPA 2. > >> I will probably need to introduce some extension support for the plugin > >> so people can extend it to support other blueprint namespaces. > >> > >> So I encourage you to try it out and see if it fits your current needs. > >> As the code of the plugin is quite small you can also just fork it to > >> adapt to your internal needs > >> if something does not work like you want. In that case I would be happy > >> about feedback or even pull requests so I can add such impovements to > >> the aries version. > >> > >>> 3) What is the influence of using proxies for every service on > performance in comparison with DS? > >> There is not much performance overhead for proxies. As your service > >> calls should not be extremely fine grained anyway I do not think you > >> will notice a problem. > >> The problem with proxies is more in some other regards. For example > >> blueprint blocks a service call if a mandatory service goes away. So if > >> your business code needs to guarantee short response times > >> this may speak against blueprint. > >> Proxies also make debugging harder as you often hit the proxy impl code > >> while stepping thorugh your code. > >> > >>> 4) Could anyone provide a link to example of using blueprint of last > version? > >> You can have a look at my Karaf Tutorials. They cover many blueprint > >> features as well as some of the integrations to other frameworks > >> blueprint provides. > >> Starting with my newest Tutorial I will also provide more examples of > >> DS. My goal is to look into things like security, REST, SOAP. > >> http://www.liquid-reality.de/display/liquid/Karaf+Tutorials > >> > >> Christian > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >> For additional commands, e-mail: users-h...@felix.apache.org > >> > > > > > > -- > > Alex Sviridov > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
