Re: Cannot inject blueprint exposed service with annotations

Thanks everyone. I've been reading through the javadoc. Thanks also for reminding me to RTFM:) Not all of it is clear but it certainly helps a great deal. D On 02/02/2017 10:31 PM, Tim Ward wrote: Yes - the Reference annotation has a number of useful properties that you can set to control its

Re: DS components not Active

I agree, this should work, and there is a bug. Whether anyone will succeed in fixing it is another question. One thing to investigate might be what happens if you have 2 pids A and B, with identical configurations, one for blueprint and one for DS. What happens when you first update A then

Re: DS components not Active

I agree it is not the best, this is is just a way to overcome the multiple bundle needing the same configuration PID limitation. On the other hand it provides a convenient, centralized way to validate that the configuration is valid. Agree that a higher abstraction is the best, but it is not

Re: DS components not Active

A service that provides all config settings will create a lot of coupling. I rather thought about logically providing a common functionality on a higher level. Can you give some examples what you have in the current config? Christian On 03.02.2017 16:58, Alex Soto wrote: I actually played

Re: DS components not Active

I actually played with the idea of centralizing all configuration settings in a global service. This service is just a holder of the configuration. It is a DS component with just an activation method to load the configuration, and a bunch of getters. The rest of the services, even if in

Re: DS components not Active

I disagree with the earlier statement that Blueprint and DS cannot coexist in the same bundle. I have thought quite hard about this and can think of no reason whatsoever why it should not work. Tim Sent from my iPhone > On 3 Feb 2017, at 15:28, Christian Schneider

Re: DS components not Active

I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help. Christian On 03.02.2017 16:13, Alex Soto wrote: No,

Re: DS components not Active

No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in

Re: DS components not Active

As long as it is not in the same bundles mixing DS and blueprint is fine. I guess that using the same config pid in two bundles or two frameworks is the main problem. I had lots of problems when I tried this. Theoretically sharing a config pid can work now as far as I know but I would not bet

Re: DS components not Active

Is there any good reason for using DS and blueprint in the same bundle. While it can work we never test this case and recommend to not mix two DI frameworks in the same bundle. Christian On 03.02.2017 14:42, Alex Soto wrote: Yes, I hear you, I’ve read about it here as well. It is the same

Re: DS components not Active

Assuming you’re using Aries blueprint then that would be a JIRA against Apache Aries at https://issues.apache.org/jira/secure/Dashboard.jspa . Tim > On 3 Feb 2017, at 13:57, Alex Soto wrote: > > Do you know where

Re: DS components not Active

That sounds like a bug in blueprint then, unless there's a filter on the blueprint reference which prevents it from picking the reconfigured service it should definitely re-wire. Tim Sent from my iPhone > On 3 Feb 2017, at 13:42, Alex Soto wrote: > > Yes, I hear you,

Re: DS components not Active

Yes, I hear you, I’ve read about it here as well. It is the same bundle; both the Blueprint context and the component are in the same bundle. To summarize: a single bundle with both a DS component and a Blueprint context referencing the same configuration PID. The Blueprint context depends on