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
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
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 {
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
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
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
Hello,
Does anyone have any experience combining OSGi with the nashorn scripting
engine?
The specific use-case I'm trying to figure out would use the Java.type()
then the Java.extend() syntax described here:
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions
...to define (on the
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,
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
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
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
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
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 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..
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);
}
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
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
17 matches
Mail list logo
