Re: OSGi Declarative Services

Thanks Carsten! Cheers, Roy > On 3 Oct 2016, at 12:02, Carsten Ziegeler wrote: > > Roy Teeuwen wrote >> Hey Neil, >> >> Thanks, I guess I have to use ObjectClassDefinition and AttributeDefinition >> annotations then :) >> > Yepp, > I've some additional tutorials/samples

Re: OSGi Declarative Services

Roy Teeuwen wrote > Hey Neil, > > Thanks, I guess I have to use ObjectClassDefinition and AttributeDefinition > annotations then :) > Yepp, I've some additional tutorials/samples at: http://blog.osoco.de/2015/11/osgi-components-simply-simple-part-iii/ Carsten -- Carsten Ziegeler Adobe

Re: OSGi Declarative Services

7, Neil Bartlett <njbartl...@gmail.com> wrote: >>>> >>>> Hi Roy, >>>> >>>> What are you looking for exactly? Service properties are simply key-value >>>> pairs. >>>> >>>> Regards, >>

Re: OSGi Declarative Services

at 23:37, Neil Bartlett <njbartl...@gmail.com> wrote: >>> >>> Hi Roy, >>> >>> What are you looking for exactly? Service properties are simply key-value >>> pairs. >>> >>> Regards, >>> Neil >>>

Re: OSGi Declarative Services

>> What are you looking for exactly? Service properties are simply key-value >> pairs. >> >> Regards, >> Neil >> >> >>> On 2 Oct 2016, at 22:13, Roy Teeuwen <r...@teeuwen.be> wrote: >>> >>> Hey all, >>> >>

Re: OSGi Declarative Services

exactly? Service properties are simply key-value > pairs. > > Regards, > Neil > > >> On 2 Oct 2016, at 22:13, Roy Teeuwen <r...@teeuwen.be> wrote: >> >> Hey all, >> >> Seeing as we upgraded our instance, we want to switch from Apache F

Re: OSGi Declarative Services

> Annotations to OSGi Declarative Services for new components. > One of the things I noticed is that there is no @Property and @Properties in > declarative services. Is there still a way to provide label and descriptions > for properties? > Looking at the @Component it is just key=value

OSGi Declarative Services

Hey all, Seeing as we upgraded our instance, we want to switch from Apache Felix SCR Annotations to OSGi Declarative Services for new components. One of the things I noticed is that there is no @Property and @Properties in declarative services. Is there still a way to provide label

Re: OSGi Declarative Services dependency on a generic supertype

You are right! My bad! I should have called the interface ' AVerySpecificButtonThatCanOnlyBeUsedWithThisParticularUsecase' ;) Luckily Java allows you to make use of more than one interface in your application so all the other valid reasons can be covered too ;) On Thu, Feb 5, 2015 at 10:04

Re: OSGi Declarative Services dependency on a generic supertype

I meant all implemented interfaces (although I did wrote all bundle-exported). I guess everybody agrees there are reasons for implementing and not exposing. Not that frequent in my opinion. So, the spec for org.osgi.service.component.annotations.Component.service() should be: If not specified,

Re: OSGi Declarative Services dependency on a generic supertype

Understood! As I said it's not that it's something crucial missing! However at least some alternative to iPOJO's @Stereotype would be nice. On Thu, Feb 5, 2015 at 10:03 PM, David Jencks david_jen...@yahoo.com.invalid wrote: One of the principles we've tried to keep to in DS is that all the

Re: OSGi Declarative Services dependency on a generic supertype

On 05/02/15 16:59, Pawel Pogorzelski wrote: Guys, I have a generic interface IRepositoryT extended by IAppleRepository, IOrangeRepository and so on. Concrete implementations like AppleRepository are registered in the container with non-generic interfaces like IAppleRepository. Is it possible

OSGi Declarative Services dependency on a generic supertype

Guys, I have a generic interface IRepositoryT extended by IAppleRepository, IOrangeRepository and so on. Concrete implementations like AppleRepository are registered in the container with non-generic interfaces like IAppleRepository. Is it possible to tell DS engine I need every service sublassing

Re: OSGi Declarative Services dependency on a generic supertype

On 05/02/15 21:21, Milen Dyankov wrote: Agree to some extend. However here is what I meant with a stupid example. Say I have GUI where I can dynamically add buttons to perform operations on something. If I could do @AutoRegisterComponentsFromClassesImplementingMe public interface Button {

Re: OSGi Declarative Services dependency on a generic supertype

One of the principles we've tried to keep to in DS is that all the information about what to do is in the xml descriptor and we don't do significant runtime analysis of capabilities and we definitely don't do runtime class scanning. So it sounds like you are proposing a tectonic shift in the

Re: OSGi Declarative Services dependency on a generic supertype

Pawel, I disagree, and I believe the OSGi specification disagrees with you. Implementing an interface is a class-level concern. There are many reasons to implement an interface on a class that don’t imply any desire to communicate outside the module via that interface. For example, supporting

Re: OSGi Declarative Services dependency on a generic supertype

The default for scr annotations is to expose all the directly implemented interfaces. If you want something else you can explicitly list the classes to expose in the @Component annotation.. This is really easy to understand from the class itself. You can re-list an interface implemented by a

Re: OSGi Declarative Services dependency on a generic supertype

Thanks Ferry, it indeed works. Is there any way of doing it without specifying all the object supertypes during the registration? Maybe using Felix SCR annotations instead of OSGi ones? Cheers, Pawel On Thu, Feb 5, 2015 at 5:02 PM, Ferry Huberts maili...@hupie.com wrote: On 05/02/15 16:59,

Re: OSGi Declarative Services dependency on a generic supertype

On 05/02/15 17:15, Pawel Pogorzelski wrote: Thanks Ferry, it indeed works. Is there any way of doing it without specifying all the object supertypes during the registration? Maybe using Felix SCR annotations instead of OSGi ones? Don't know about SCR annotations, never used them. In general

Re: OSGi Declarative Services dependency on a generic supertype

Services in OSGi are intended so that you can implement many interfaces but publish under a subset. Therefore the set of published services must be listed explicitly. Neil On Thursday, 5 February 2015 at 16:15, Pawel Pogorzelski wrote: Thanks Ferry, it indeed works. Is there any way of

Re: OSGi Declarative Services dependency on a generic supertype

Alright, thanks Neil. I can see can see some corner cases where this behavior could would be desired. It's just the default that bothers me - I think by default a service should be registered under all the bundle-exported interfaces. After all, if you want to hide implementation you do it

Re: OSGi Declarative Services dependency on a generic supertype

The @Component implementation has a default for the registered services all directly implemented interfaces. The reason for this default is readability, the annotation and the default value are close together so a reader has all the knowledge close together. Using your proposed scheme would

Re: OSGi Declarative Services dependency on a generic supertype

I may be interpreting Pawel's case wrong but I also have had situations in the past where I wish I was able to somehow mark a interface (by using annotation for example) and basically say whoever implements that interface should be automatically registered as a service! AFAIK that is not possible

Re: OSGi Declarative Services dependency on a generic supertype

With DS and the spec annotations, if your component class directly implements the interface, it will be registered as a service exposing that interface. If your class is not a DS component, I'm not sure what you expect to create an instance of your class in order to register it as a service..

Re: OSGi Declarative Services dependency on a generic supertype

Agree to some extend. However here is what I meant with a stupid example. Say I have GUI where I can dynamically add buttons to perform operations on something. If I could do @AutoRegisterComponentsFromClassesImplementingMe public interface Button { void performActionOn (Something something); }

Re: OSGi Declarative Services dependency on a generic supertype

I still don't understand in your example what is supposed to create an instance of your button class. I think it's pretty odd, but I think with my proposal for extension annotation processors for DS and metatype annotation processing in bnd, if you were willing to use DS and mark the button

Re: OSGi Declarative Services dependency on a generic supertype

So as I mentioned earlier you have 2 options: (a) build time - which is exactly how @Component annotations are processed. Basically treat every class implementing the interface as if it was annotated with @Component and @Service (b) deploy / run time - which is more or less what you suggest

Configurable properties for a custom service are not configurable via the Configuration Console (OSGI Declarative Services - SCR)

On our project we are developing classes that are configurable via the Apache Felix Maven SCR Plugin and Felix Configuration Console. I understand the concept of the scr.property tag and am able to view and edit these properties within the Console Configuration screen. However, I am having