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 PM, Ferry Huberts maili...@hupie.com wrote:
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 {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make
it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a
matter
of convenience!
And why is that adding just one tiny step ('put @Component on your class')
is too difficult?
Besides, there are many valid reasons for implementing an interface and
_not_ exposing it as a service, also for your button case.
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
http://about.me/milen
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, the service types for this Component are all the
idirectly/i implemented interfaces of the class being annotated.
without idirectly/i in it. But that's just my opinion. It would really
make it easier for people familiar with other DI frameworks - for some
reason all of them take type hierarchy into account when wiring.
Thanks for the explanations!
Pawel
On Thu, Feb 5, 2015 at 10:04 PM, Ferry Huberts maili...@hupie.com wrote:
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 {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make
it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a
matter
of convenience!
And why is that adding just one tiny step ('put @Component on your class')
is too difficult?
Besides, there are many valid reasons for implementing an interface and
_not_ exposing it as a service, also for your button case.
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
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
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 philosophy behind DS which is unlikely to happen any time
soon. Having dealt with annotation processing for javaee I cannot express
how strongly I am against runtime annotation processing for DS.
thanks
david jencks
On Feb 5, 2015, at 3:41 PM, Milen Dyankov milendyan...@gmail.com wrote:
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 although I
can imagine different implementations
So I fully agree with you that it can be done. But in the context set by
the original question:
- Is this possible with DS as of now - AFAIK no
- is it something that DS/SCR should support - I don't know. I think it
could, but again there may be implications I'm not aware of.
On Thu, Feb 5, 2015 at 9:29 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
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 class you actually want
to
be a real live button with @Component so DS knows enough to create one,
you
could write an extension processor that would find your @AutoRegister
annotation on the interface in the inheritance hierarchy and add it to
the
exposed services.
thanks
david jencks
On Feb 5, 2015, at 3:21 PM, Milen Dyankov milendyan...@gmail.com
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 {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know
what,
just extend the AbstractButton, add your logic, build (tooling will
make
it
a bundle), deploy and your button will appear in the UI! Again it's
NOT
that there is some crucial missing feature in OSGi / DS but rather a
matter
of convenience!
On Thu, Feb 5, 2015 at 8:46 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
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.. I
guess you could register a byte-code weaver that looked for classes
implementing your interface of interest, and added byte code that got
the
bundle context from the class loader, and registered the instance in
the
service registry, but I don't think you would actually find that very
useful as there would be no way to specify service properties in order
to
distinguish different instances. It would certainly interfere with
any
existing component model such as DS or blueprint and probably with any
attempt to register a service in code.
david jencks
On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com
wrote:
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 with SCR/DS although it may be very convenient in some
cases.
Now if such feature was to be implemented the question is weather it
should
happen at run/deploy time (probably expensive) or build time (rather
a
matter of tooling and not strictly related to DS). However there may
also
be some side effects I have not thought about and perhaps a good
reason
not
to have it.
Just my 2 cents
Best,
Milen
On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
The default for scr annotations is to expose all the directly
implemented
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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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 {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a matter
of convenience!
And why is that adding just one tiny step ('put @Component on your
class') is too difficult?
Besides, there are many valid reasons for implementing an interface and
_not_ exposing it as a service, also for your button case.
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
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 philosophy behind DS
which is unlikely to happen any time soon. Having dealt with annotation
processing for javaee I cannot express how strongly I am against runtime
annotation processing for DS.
thanks
david jencks
On Feb 5, 2015, at 3:41 PM, Milen Dyankov milendyan...@gmail.com wrote:
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 although I
can imagine different implementations
So I fully agree with you that it can be done. But in the context set by
the original question:
- Is this possible with DS as of now - AFAIK no
- is it something that DS/SCR should support - I don't know. I think it
could, but again there may be implications I'm not aware of.
On Thu, Feb 5, 2015 at 9:29 PM, David Jencks david_jen...@yahoo.com.invalid
wrote:
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 class you actually want to
be a real live button with @Component so DS knows enough to create one, you
could write an extension processor that would find your @AutoRegister
annotation on the interface in the inheritance hierarchy and add it to the
exposed services.
thanks
david jencks
On Feb 5, 2015, at 3:21 PM, Milen Dyankov milendyan...@gmail.com 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 {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make
it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a
matter
of convenience!
On Thu, Feb 5, 2015 at 8:46 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
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.. I
guess you could register a byte-code weaver that looked for classes
implementing your interface of interest, and added byte code that got
the
bundle context from the class loader, and registered the instance in the
service registry, but I don't think you would actually find that very
useful as there would be no way to specify service properties in order
to
distinguish different instances. It would certainly interfere with any
existing component model such as DS or blueprint and probably with any
attempt to register a service in code.
david jencks
On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com
wrote:
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 with SCR/DS although it may be very convenient in some
cases.
Now if such feature was to be implemented the question is weather it
should
happen at run/deploy time (probably expensive) or build time (rather a
matter of tooling and not strictly related to DS). However there may
also
be some side effects I have not thought about and perhaps a good reason
not
to have it.
Just my 2 cents
Best,
Milen
On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
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
superclass or that is a super-interface of a directly implemented
interface
if you want, that won't hurt your class.
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 callbacks. Ultimately you can make this work either way, but OSGi has to pick a default, and (as we see with package exports) OSGi always chooses the default of hiding as much as possible within the bundle except where a developer makes an explicit choice to expose. Regards, Neil On 5 Feb 2015, at 18:06, Pawel Pogorzelski pawel.pogorzels...@gmail.com wrote: 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 differently - by defining a public interface and hiding the rest in private packages. The same with lookups - if you want to get a specific instance then OSGi filters is the way to go. So, if you're relaying on not registering under all interfaces probably means there's something wrong in your design or the container you run in. Paweł On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com wrote: 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 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, 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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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 superclass or that is a super-interface of a directly implemented interface if you want, that won't hurt your class. Your proposal of all bundle-exported interfaces seems really restrictive and odd to me, any directly implemented interface from another bundle (say from a spec) would force you to not use the default. To understand what the component exposes you would also have to try to figure out what the bundle exports, which is not obvious from the component class itself. thanks david jencks On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski pawel.pogorzels...@gmail.com wrote: 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 differently - by defining a public interface and hiding the rest in private packages. The same with lookups - if you want to get a specific instance then OSGi filters is the way to go. So, if you're relaying on not registering under all interfaces probably means there's something wrong in your design or the container you run in. Paweł On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com wrote: 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 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, 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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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, 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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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 your bundles should really advertise only/all of the interfaces you want/need. Your bundles can also advertise _only_ the supertype. It really depends on your needs. So, no clear answer :-) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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 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, 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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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 differently - by defining a public interface and hiding the rest in private packages. The same with lookups - if you want to get a specific instance then OSGi filters is the way to go. So, if you're relaying on not registering under all interfaces probably means there's something wrong in your design or the container you run in. Paweł On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com wrote: 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 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, 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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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 make the actual value depend on outside information that could change and wreak havoc, eg one of your super classes in potentially a different bundle implementing a listener interface causing an extra service to be registered. This is also the reason why the DS annotations are not inherited. Though this can sometimes kill sharing, it definitely makes things more predictable and therefore readable. Since reading in most long living apps is much more important than the one time writing that seems a valid trade off. Therefore, the current default is IMHO still by far the best. The enemy of good engineering is quite often automating too much. Kind regards, Peter Kriens Verstuurd vanaf mijn iPhone Op 5 feb. 2015 om 19:06 heeft Pawel Pogorzelski pawel.pogorzels...@gmail.com het volgende geschreven: 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 differently - by defining a public interface and hiding the rest in private packages. The same with lookups - if you want to get a specific instance then OSGi filters is the way to go. So, if you're relaying on not registering under all interfaces probably means there's something wrong in your design or the container you run in. Paweł On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com wrote: 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 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, 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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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 with SCR/DS although it may be very convenient in some cases. Now if such feature was to be implemented the question is weather it should happen at run/deploy time (probably expensive) or build time (rather a matter of tooling and not strictly related to DS). However there may also be some side effects I have not thought about and perhaps a good reason not to have it. Just my 2 cents Best, Milen On Thu, Feb 5, 2015 at 8:15 PM, David Jencks david_jen...@yahoo.com.invalid wrote: 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 superclass or that is a super-interface of a directly implemented interface if you want, that won't hurt your class. Your proposal of all bundle-exported interfaces seems really restrictive and odd to me, any directly implemented interface from another bundle (say from a spec) would force you to not use the default. To understand what the component exposes you would also have to try to figure out what the bundle exports, which is not obvious from the component class itself. thanks david jencks On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski pawel.pogorzels...@gmail.com wrote: 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 differently - by defining a public interface and hiding the rest in private packages. The same with lookups - if you want to get a specific instance then OSGi filters is the way to go. So, if you're relaying on not registering under all interfaces probably means there's something wrong in your design or the container you run in. Paweł On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com wrote: 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 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, 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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- http://about.me/milen
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.. I guess you could register a byte-code weaver that looked for classes implementing your interface of interest, and added byte code that got the bundle context from the class loader, and registered the instance in the service registry, but I don't think you would actually find that very useful as there would be no way to specify service properties in order to distinguish different instances. It would certainly interfere with any existing component model such as DS or blueprint and probably with any attempt to register a service in code. david jencks On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com wrote: 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 with SCR/DS although it may be very convenient in some cases. Now if such feature was to be implemented the question is weather it should happen at run/deploy time (probably expensive) or build time (rather a matter of tooling and not strictly related to DS). However there may also be some side effects I have not thought about and perhaps a good reason not to have it. Just my 2 cents Best, Milen On Thu, Feb 5, 2015 at 8:15 PM, David Jencks david_jen...@yahoo.com.invalid wrote: 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 superclass or that is a super-interface of a directly implemented interface if you want, that won't hurt your class. Your proposal of all bundle-exported interfaces seems really restrictive and odd to me, any directly implemented interface from another bundle (say from a spec) would force you to not use the default. To understand what the component exposes you would also have to try to figure out what the bundle exports, which is not obvious from the component class itself. thanks david jencks On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski pawel.pogorzels...@gmail.com wrote: 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 differently - by defining a public interface and hiding the rest in private packages. The same with lookups - if you want to get a specific instance then OSGi filters is the way to go. So, if you're relaying on not registering under all interfaces probably means there's something wrong in your design or the container you run in. Paweł On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com wrote: 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 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, 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 to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail:
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);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a matter
of convenience!
On Thu, Feb 5, 2015 at 8:46 PM, David Jencks david_jen...@yahoo.com.invalid
wrote:
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.. I
guess you could register a byte-code weaver that looked for classes
implementing your interface of interest, and added byte code that got the
bundle context from the class loader, and registered the instance in the
service registry, but I don't think you would actually find that very
useful as there would be no way to specify service properties in order to
distinguish different instances. It would certainly interfere with any
existing component model such as DS or blueprint and probably with any
attempt to register a service in code.
david jencks
On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com wrote:
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 with SCR/DS although it may be very convenient in some
cases.
Now if such feature was to be implemented the question is weather it
should
happen at run/deploy time (probably expensive) or build time (rather a
matter of tooling and not strictly related to DS). However there may also
be some side effects I have not thought about and perhaps a good reason
not
to have it.
Just my 2 cents
Best,
Milen
On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
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
superclass or that is a super-interface of a directly implemented
interface
if you want, that won't hurt your class. Your proposal of all
bundle-exported interfaces seems really restrictive and odd to me, any
directly implemented interface from another bundle (say from a spec)
would
force you to not use the default. To understand what the component
exposes
you would also have to try to figure out what the bundle exports, which
is
not obvious from the component class itself.
thanks
david jencks
On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski
pawel.pogorzels...@gmail.com wrote:
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 differently - by defining a public interface and hiding the
rest
in private packages. The same with lookups - if you want to get a
specific
instance then OSGi filters is the way to go. So, if you're relaying on
not
registering under all interfaces probably means there's something wrong
in
your design or the container you run in.
Paweł
On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com
wrote:
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 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, Pawel Pogorzelski wrote:
Guys,
I have a generic interface IRepositoryT extended by
IAppleRepository,
IOrangeRepository and so on. Concrete implementations like
AppleRepository
are
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 class you actually want to be a real live
button with @Component so DS knows enough to create one, you could write an
extension processor that would find your @AutoRegister annotation on the
interface in the inheritance hierarchy and add it to the exposed services.
thanks
david jencks
On Feb 5, 2015, at 3:21 PM, Milen Dyankov milendyan...@gmail.com 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 {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a matter
of convenience!
On Thu, Feb 5, 2015 at 8:46 PM, David Jencks david_jen...@yahoo.com.invalid
wrote:
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.. I
guess you could register a byte-code weaver that looked for classes
implementing your interface of interest, and added byte code that got the
bundle context from the class loader, and registered the instance in the
service registry, but I don't think you would actually find that very
useful as there would be no way to specify service properties in order to
distinguish different instances. It would certainly interfere with any
existing component model such as DS or blueprint and probably with any
attempt to register a service in code.
david jencks
On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com wrote:
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 with SCR/DS although it may be very convenient in some
cases.
Now if such feature was to be implemented the question is weather it
should
happen at run/deploy time (probably expensive) or build time (rather a
matter of tooling and not strictly related to DS). However there may also
be some side effects I have not thought about and perhaps a good reason
not
to have it.
Just my 2 cents
Best,
Milen
On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
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
superclass or that is a super-interface of a directly implemented
interface
if you want, that won't hurt your class. Your proposal of all
bundle-exported interfaces seems really restrictive and odd to me, any
directly implemented interface from another bundle (say from a spec)
would
force you to not use the default. To understand what the component
exposes
you would also have to try to figure out what the bundle exports, which
is
not obvious from the component class itself.
thanks
david jencks
On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski
pawel.pogorzels...@gmail.com wrote:
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 differently - by defining a public interface and hiding the
rest
in private packages. The same with lookups - if you want to get a
specific
instance then OSGi filters is the way to go. So, if you're relaying on
not
registering under all interfaces probably means there's something wrong
in
your design or the container you run in.
Paweł
On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com
wrote:
Services in OSGi are intended so that you can implement many
interfaces
but publish under a subset. Therefore the set of published
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 although I
can imagine different implementations
So I fully agree with you that it can be done. But in the context set by
the original question:
- Is this possible with DS as of now - AFAIK no
- is it something that DS/SCR should support - I don't know. I think it
could, but again there may be implications I'm not aware of.
On Thu, Feb 5, 2015 at 9:29 PM, David Jencks david_jen...@yahoo.com.invalid
wrote:
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 class you actually want to
be a real live button with @Component so DS knows enough to create one, you
could write an extension processor that would find your @AutoRegister
annotation on the interface in the inheritance hierarchy and add it to the
exposed services.
thanks
david jencks
On Feb 5, 2015, at 3:21 PM, Milen Dyankov milendyan...@gmail.com 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 {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make
it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a
matter
of convenience!
On Thu, Feb 5, 2015 at 8:46 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
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.. I
guess you could register a byte-code weaver that looked for classes
implementing your interface of interest, and added byte code that got
the
bundle context from the class loader, and registered the instance in the
service registry, but I don't think you would actually find that very
useful as there would be no way to specify service properties in order
to
distinguish different instances. It would certainly interfere with any
existing component model such as DS or blueprint and probably with any
attempt to register a service in code.
david jencks
On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com
wrote:
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 with SCR/DS although it may be very convenient in some
cases.
Now if such feature was to be implemented the question is weather it
should
happen at run/deploy time (probably expensive) or build time (rather a
matter of tooling and not strictly related to DS). However there may
also
be some side effects I have not thought about and perhaps a good reason
not
to have it.
Just my 2 cents
Best,
Milen
On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
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
superclass or that is a super-interface of a directly implemented
interface
if you want, that won't hurt your class. Your proposal of all
bundle-exported interfaces seems really restrictive and odd to me,
any
directly implemented interface from another bundle (say from a spec)
would
force you to not use the default. To understand what the component
exposes
you would also have to try to figure out what the bundle exports,
which
is
not obvious from the component class itself.
thanks
david jencks
On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski
pawel.pogorzels...@gmail.com wrote:
Alright, thanks Neil. I can see can see some corner
