Comments on: Annotations for OSGi Declarative Services http://www.toedter.com/blog/?p=46 Java, Eclipse, OSGi, and other cool stuff Thu, 19 Aug 2010 16:13:05 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: 3 variations on OSGi themes: part 8 « CodingAndBeyond http://www.toedter.com/blog/?p=46&cpage=1#comment-16451 3 variations on OSGi themes: part 8 « CodingAndBeyond Sat, 15 Aug 2009 19:10:51 +0000 http://www.toedter.com/blog/?p=46#comment-16451 [...] First impressions. From the OSGi application developer’s point of view, the most attractive from the three systems is OSGi DS, because it adds bare minimum to the OSGi framework to free application developers from the need to use ‘native’ OSGi API. In particular, it eliminates the need for bundle activators and service trackers or listeners for a relatively small price. On the good side of OSGi DS is flexible dynamic control over service dependencies, including service availability monitoring and configurable restart of importer component when imported service is updated. On the bad side, hovewer, is that component classes are not really POJOs. Another advantage is that OSGi DS specifications are included in the standard OSGi Compendium, so it’s expected to be available as a part of OSGi Framework implementation. Indeed, Equinox 3.5.0 has already included DS in its standard configuration. One useful improvement that can be added to OSGi DS is implementing support for Java annotations, as proposed, for instance, by Kai Tödter. [...] [...] First impressions. From the OSGi application developer’s point of view, the most attractive from the three systems is OSGi DS, because it adds bare minimum to the OSGi framework to free application developers from the need to use ‘native’ OSGi API. In particular, it eliminates the need for bundle activators and service trackers or listeners for a relatively small price. On the good side of OSGi DS is flexible dynamic control over service dependencies, including service availability monitoring and configurable restart of importer component when imported service is updated. On the bad side, hovewer, is that component classes are not really POJOs. Another advantage is that OSGi DS specifications are included in the standard OSGi Compendium, so it’s expected to be available as a part of OSGi Framework implementation. Indeed, Equinox 3.5.0 has already included DS in its standard configuration. One useful improvement that can be added to OSGi DS is implementing support for Java annotations, as proposed, for instance, by Kai Tödter. [...]

]]> By: 3 variations on OSGi themes « CodingAndBeyond http://www.toedter.com/blog/?p=46&cpage=1#comment-16376 3 variations on OSGi themes « CodingAndBeyond Sat, 25 Jul 2009 00:48:31 +0000 http://www.toedter.com/blog/?p=46#comment-16376 [...] Declarative Services (DS) exist in OSGi Service Compendium specifications since release 4 and continue evolving in later releases. Perhaps, the earliest practical introduction to DS can be found in Neil Bartlett’s ‘point-free blog’ (see Getting Started with OSGi, parts 7, 8). Reference implementation of DS provided by Equinox OSGi (see Equinox bundles) utilizes XML descriptors, as specified in the OSGi Service Compendium document. There are also early attempts to introduce annotations for OSGi DS (see Kai’s Blog), but in this project, I’m going to use standard Equinox implementation. [...] [...] Declarative Services (DS) exist in OSGi Service Compendium specifications since release 4 and continue evolving in later releases. Perhaps, the earliest practical introduction to DS can be found in Neil Bartlett’s ‘point-free blog’ (see Getting Started with OSGi, parts 7, 8). Reference implementation of DS provided by Equinox OSGi (see Equinox bundles) utilizes XML descriptors, as specified in the OSGi Service Compendium document. There are also early attempts to introduce annotations for OSGi DS (see Kai’s Blog), but in this project, I’m going to use standard Equinox implementation. [...]

]]> By: 3 variations on OSGi themes: part 5 « CodingAndBeyond http://www.toedter.com/blog/?p=46&cpage=1#comment-16373 3 variations on OSGi themes: part 5 « CodingAndBeyond Wed, 22 Jul 2009 22:38:49 +0000 http://www.toedter.com/blog/?p=46#comment-16373 [...] Declarative Services (DS) exist in OSGi Compendium specifications since release 4 and continue evolving in later releases. Perhaps, the earliest practical introduction to DS can be found in Neil Bartlett’s ‘point-free blog’ (see Getting Started with OSGi, parts 7, 8). Reference implementation of DS is provided by Equinox OSGi (see Equinox bundles), so it was a natural choice for me to use Eclipse IDE for developing this version of the code. Existing OSGi DS implementation uses XML descriptors, as specified in the OSGi Compendium document. There are also early attempts to introduce annotations for OSGi DS (see Kai’s Blog), but in this project, I’m going to use standard implementation. [...] [...] Declarative Services (DS) exist in OSGi Compendium specifications since release 4 and continue evolving in later releases. Perhaps, the earliest practical introduction to DS can be found in Neil Bartlett’s ‘point-free blog’ (see Getting Started with OSGi, parts 7, 8). Reference implementation of DS is provided by Equinox OSGi (see Equinox bundles), so it was a natural choice for me to use Eclipse IDE for developing this version of the code. Existing OSGi DS implementation uses XML descriptors, as specified in the OSGi Compendium document. There are also early attempts to introduce annotations for OSGi DS (see Kai’s Blog), but in this project, I’m going to use standard implementation. [...]

]]> By: Jose G http://www.toedter.com/blog/?p=46&cpage=1#comment-15953 Jose G Thu, 16 Apr 2009 10:15:13 +0000 http://www.toedter.com/blog/?p=46#comment-15953 I like this idea, very very nifty feature. To be honest, the XML way to declare services looks like a small step ahead if you compare it with the annotations way. I definitively give support to this idea and I hope to see it included in the specs very soon. I like this idea, very very nifty feature. To be honest, the XML way to declare services looks like a small step ahead if you compare it with the annotations way. I definitively give support to this idea and I hope to see it included in the specs very soon.

]]> By: Kai Tödter http://www.toedter.com/blog/?p=46&cpage=1#comment-15234 Kai Tödter Thu, 26 Feb 2009 08:42:28 +0000 http://www.toedter.com/blog/?p=46#comment-15234 I wrote a Wiki page with instructions how to browse and test the examples, see http://max-server.myftp.org/trac/pm/wiki/a4ds I wrote a Wiki page with instructions how to browse and test the examples, see http://max-server.myftp.org/trac/pm/wiki/a4ds

]]> By: Kai Tödter http://www.toedter.com/blog/?p=46&cpage=1#comment-15200 Kai Tödter Wed, 25 Feb 2009 14:04:01 +0000 http://www.toedter.com/blog/?p=46#comment-15200 @Philipp, Not yet, but it could. Currently you have to specify the header manually in the MANIFEST.MF: Service-Component: OSGI-INF/* This leads to the loading of all xml files in the OSGI-INF directory @Philipp,

Not yet, but it could. Currently you have to specify the header manually in the MANIFEST.MF:
Service-Component: OSGI-INF/*
This leads to the loading of all xml files in the OSGI-INF directory

]]> By: Philipp Kursawe http://www.toedter.com/blog/?p=46&cpage=1#comment-15198 Philipp Kursawe Wed, 25 Feb 2009 13:40:34 +0000 http://www.toedter.com/blog/?p=46#comment-15198 Does the AP also modify the MANIFEST.MF? Does the AP also modify the MANIFEST.MF?

]]> By: Scott Stanchfield http://www.toedter.com/blog/?p=46&cpage=1#comment-15000 Scott Stanchfield Fri, 20 Feb 2009 19:28:54 +0000 http://www.toedter.com/blog/?p=46#comment-15000 Hehehe... I just did something like this the other day. Mine looks like @Component(name="sampleService", immediate=true, services={@Service(IService.class)}, references={ @ServiceReference(name="x", iface=ActionListener.class, bind="addActionListener", unbind="removeActionListener", cardinality=Cardinality.ZeroOrMore ) } ) This generates a separate component.xml for each service class. The problem is that if you have more than one service class, updating the manifest.mf gets wonky. If you're doing a full build, the annotation processor knows about all the services and can properly set up the Service-Component header in the manifest. If you're doing an incremental build, it only knows about the classes that require rebuild... I could have it add to Service-Component if it doesn't exist, but then there's no good way to remove obsolete entries. Any thoughts? If you're interested in seeing what I've got, please email me: scott@javadude.com Hehehe… I just did something like this the other day. Mine looks like

@Component(name=”sampleService”, immediate=true,
services={@Service(IService.class)},
references={
@ServiceReference(name=”x”, iface=ActionListener.class,
bind=”addActionListener”,
unbind=”removeActionListener”,
cardinality=Cardinality.ZeroOrMore
)
}
)

This generates a separate component.xml for each service class.

The problem is that if you have more than one service class, updating the manifest.mf gets wonky.

If you’re doing a full build, the annotation processor knows about all the services and can properly set up the Service-Component header in the manifest.

If you’re doing an incremental build, it only knows about the classes that require rebuild…

I could have it add to Service-Component if it doesn’t exist, but then there’s no good way to remove obsolete entries.

Any thoughts?

If you’re interested in seeing what I’ve got, please email me: scott@javadude.com

]]> By: Jörg Matysiak http://www.toedter.com/blog/?p=46&cpage=1#comment-14972 Jörg Matysiak Fri, 20 Feb 2009 07:23:33 +0000 http://www.toedter.com/blog/?p=46#comment-14972 Hi Kai, very cool! This is exactly what I'm missing in the current DS implementation. Would be nice to have the thing as ant plug-in. :) Having all the information in one file (the java source file) is much simpler to manage than the current way using component.xml. Although the new service component editor is a big help to find problems, you still have to keep at least two files in sync. Hi Kai,

very cool!

This is exactly what I’m missing in the current DS implementation. Would be nice to have the thing as ant plug-in. :)

Having all the information in one file (the java source file) is much simpler to manage
than the current way using component.xml.

Although the new service component editor is a big help to find problems, you still have to keep at least two files in sync.

]]> By: Stuart McCulloch http://www.toedter.com/blog/?p=46&cpage=1#comment-14937 Stuart McCulloch Thu, 19 Feb 2009 10:32:14 +0000 http://www.toedter.com/blog/?p=46#comment-14937 Interesting, perhaps you could open an RFP to standardize these annotations in OSGi, then iPOJO and other frameworks could share them. Kind of like the AOP Alliance types used in various DI frameworks. Interesting, perhaps you could open an RFP to standardize these annotations in OSGi, then iPOJO and other frameworks could share them. Kind of like the AOP Alliance types used in various DI frameworks.

]]>