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,
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
>
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
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 {
v
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 ph
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 altho
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 cl
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);
}
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
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
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 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 s
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 c
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 different
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 doin
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
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 wrote:
>
>
> On 05/02/15 16:59, Pawel Pogorzels
On 05/02/15 16:59, Pawel Pogorzelski wrote:
Guys,
I have a generic interface IRepository 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
Guys,
I have a generic interface IRepository 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 I
19 matches
Mail list logo