aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: [SPI Fly] Interest for a more dynamic plug-in/service discovery API?
Date Thu, 30 Aug 2012 15:29:47 GMT
Thanks Jeremias!

I'll have a look at this soon.

Cheers,

David

On 23 August 2012 15:39, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> Hi David
>
> Sorry for the delay. As life plays, you get side-tracked all the time,
> but since this is important to me I had to revisit eventually.
>
> I've simplified and cleaned up the code some more and added some tests.
> It's now ready for review:
> http://www.jeremias-maerki.ch/download/osgi/ch.jm.util.services-2.0.0.dev-src.zip
>
> So, if you still think this could be a good addition to Aries, I can
> rename the packages, switch to a Maven build (sigh) and prepare a
> package to vote upon for inclusion in Aries.
>
> What could we name it?
> - org.apache.aries.spifly.consumer
> - org.apache.aries.spifly.discovery
> - org.apache.aries.discovery
> - org.apache.aries.plugin.discovery
> - org.apache.aries.spi.catch ;-)
>
> You mentioned earlier that you don't see it as part of SPI-Fly. In its
> current state it actually relies on a working implementation of RFP 167
> (SPI Service Loader support) because I removed the extender that looks
> for META-INF/services from 1.0 to 2.0. So, while it is not part of RFC
> 167, it is still thighly connected to SPI-Fly, although not through
> package imports.
>
> On RFP 143: like I already mentioned, I do find it interesting. It can
> serve as a different approach to solving the same problem. However, my
> approach gets away with a 20KB JAR, compared to the 220KB of PojoSR
> (still small!). But my main argument is actually this: I need to find a
> way to sell an easy way to the Apache XML Graphics project to achieve
> OSGi compatibility including plug-in support without throwing everything
> upside down. Practically none of the committers are familiar with OSGi.
> Introducing an OSGi-compatible service registry is generally cool for
> someone who knows OSGi already but the others would probably ask: why do
> we need to learn about this? After all, the service registry can be a
> bit verbose for a newbie with ServiceReference, BundleContext and such.
> I believe that selling OSGi Connect would be more difficult in such a
> case than my small proposal.
>
> In the end, I'm looking for the best home for it. I think Aries is a
> logical place.
>
> When looking at PojoSR I was wondering about use cases. Personally, I'd
> rather have a full OSGi environment any time even if it means that I
> have to be able to maintain a bundle cache/storage folder on the local
> file system (I actually wonder why these are not pluggable and
> virtualizable, yet, but that's a different story). Use case 4.2 (WARs)
> in the RFP draft makes a lot of sense, though. There you don't usually
> have any service dynamics. Or a command-line application that uses some
> code that usually runs in a OSGi-enabled server. I have such a case that
> I might explore eventually. But frankly, OSGi Connect doesn't create too
> much attraction for me since I will usually want to work in a full OSGi
> environment. And when I can't do that I'm likely happy with plain
> META-INF/services. I guess I can't correctly imagine the possibilities
> that are mentioned in use case 4.3 (Application Frameworks).
>
> Cheers,
> Jeremias Maerki
>
>
> On 13.07.2012 16:07:58 David Bosschaert wrote:
>> Hi Jeremias,
>>
>> Just FYI OSGi RFP 143 has just been published which relates precisely
>> to the issue of using a Service Registry without going full-blown on
>> the modularity. Ultimately the idea is that there will be an OSGi
>> specification around this.
>> Your work might fit with this idea as well and I would be very
>> interested in your thoughts around this topic.
>>
>> See here: http://blog.osgi.org/2012/07/new-rfps-available-for-feedback.html
>> and here: https://www.osgi.org/bugzilla/show_bug.cgi?id=145
>>
>> Best regards,
>>
>> David
>>
>> On 13 June 2012 08:02, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
>> > Hi David
>> >
>> > Thanks a lot for your feedback! PojoSR is interesting. You could say
>> > that there is a certain overlap. If I understand this right, PojoSR is
>> > suggesting to detect not-quite-OSGi bundles via
>> > ClassLoader.getResources("META-INF/MANIFEST.MF") rather than to detect
>> > individual services via "META-INF/services/xy". It has a focus on
>> > maintaining a service registry that is based on OSGi principles (bundle
>> > activator and all) rather than working off the old JAR service providers.
>> > It brings OSGi to plain Java rather than plain Java to OSGi. ;-) As an
>> > OSGi addict, that is very appealing to me. The problem is selling it, I
>> > guess. Even selling OSGi compatibility in a plain Java project requires
>> > addressing things like: "no, you don't have to change your application
>> > to OSGi."
>> >
>> > So, both approaches have their strong points. Let's try to put them next
>> > to each other:
>> >
>> > PojoSR:
>> > - ability to work OSGi-like in plain Java, no changes running in real OSGi
>> > - runtime dependency on PojoSR, OSGi core and compendium in plain Java
>> > - existing applications using META-INF/services have to change their
>> > plug-in approach to OSGi-style services
>> > - existing plug-ins need to get OSGi metadata
>> >
>> > my approach:
>> > - developers are shielded from OSGi except for the build-time dependency
>> > (OSGi core) and the build changes for OSGi metadata
>> > - one runtime dependency in plain Java (the ServiceListener
>> > infrastructure)
>> > - existing applications have to switch from ServiceLoader (or Services
>> > in Apache XML Graphics) to a ServiceListener (ServiceTracker-like)
>> > for obtaining plug-ins
>> > - existing plug-ins need to add OSGi metadata as per RFC 167.
>> > - probably has a considerably lower learning curve for people that
>> > haven't had contact with OSGi, yet.
>> >
>> > I guess one question is whether PojoSR works with SPI-Fly in plain Java.
>> > That would make this very nice. But I suspect that might not be so
>> > simple. If it doesn't work, all plug-ins have to be changed to publish
>> > services through a BundleContext. That would make it impossible to
>> > retro-fit an older plug-in just by adding OSGi metadata to the JAR.
>> >
>> > Anyway, I'll put together a submission in the next few days (probably
>> > next week due to other obligations). We can then see where to go from
>> > there. I'd be happy to help with the spec however I can. I guess my code
>> > will at least be a useful additional discussion base.
>> >
>> > Thanks,
>> > Jeremias Maerki
>> >
>> >
>> > On 12.06.2012 14:47:01 David Bosschaert wrote:
>> >> Hi Jeremias,
>> >>
>> >> Many thanks for the suggestion. You are highlighting a valid point:
>> >> namely that people often have the need for services, like the ones
>> >> supported in OSGi, but are unable to (or don't want to) modularize
>> >> their project in order to be able to use OSGi.
>> >> There is currently some work underway in the OSGi expert groups that
>> >> relates to this.
>> >>
>> >> The PojoSR project (http://code.google.com/p/pojosr/) is a relatively
>> >> mature project that implements most of the OSGi Service Registry and
>> >> also supports things like the BundleActivator without doing the
>> >> modularity part of OSGi. So in a way it is similar to what you have
>> >> written, if I'm not mistaken.
>> >>
>> >> In the OSGi Core Platform Expert Group there is currently an effort
>> >> underway to create a specification inspired by PojoSR. I will ensure
>> >> that during the specification work your work is also considered as
>> >> input, if you wish [1].
>> >>
>> >> So in short - there will be a specification around this in the not too
>> >> distant future, your work can be considered a stepping stone to this
>> >> specification and it could even possibly become a compliant
>> >> implementation in the future. I assume that PojoSR will also become
>> >> compliant but I think that there is always room for multiple
>> >> implementations of a spec.
>> >>
>> >> If you are interested in updating your implementation to comply with
>> >> the spec in the future then I think that Apache Aries would be a good
>> >> place to put your implementation right now from where it can mature. I
>> >> think that it should not be a subcomponent of SPI-Fly but rather a
>> >> top-level component of its own, within Aries.
>> >>
>> >> Best regards,
>> >>
>> >> David
>> >>
>> >> [1] or, if you'd rather do that yourself, let me know :)
>> >>
>> >> On 8 June 2012 10:42, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
>> >> > Hi there,
>> >> >
>> >> > due to my involvement with the Apache XML Graphics project (FOP/Batik)
>> >> > where we make heavy use of META-INF/services, I've got a big interest
in
>> >> > how best to bring FOP and Batik into OSGi. My particular requirement
>> >> > here is that FOP and Batik have to continue working in plain Java but
>> >> > profit from the OSGi service registry for plug-in discovery when
>> >> > possible.
>> >> >
>> >> > So, two years ago I came up with this:
>> >> > http://www.jeremias-maerki.ch/development/osgi/jar-services.html
>> >> >
>> >> > That works half-way good enough although I've never felt comfortable
>> >> > enough to push it back to the XML Graphics project as I've had a few
>> >> > flaws in the above implementation. So, by now SPI Fly does a lot of
>> >> > things much better than my approach and it is following an RFC that
I
>> >> > find very useful.
>> >> >
>> >> > However, on the client side, RFC 167 is a bit heavy on J2SE-1.6's
>> >> > ServiceLoader. Apache XML Graphics is still on J2SE-1.5 (yes, I know,
I
>> >> > know) so it contains its own Services.java to find plug-ins via
>> >> > META-INF/services. Furthermore, with ServiceLoader you basically have
to
>> >> > poll for changes.
>> >> >
>> >> > Finally getting to my point: I'd like to offer a little API that brings
>> >> > some of the service dynamics you get with OSGi services. This can
>> >> > already be seen on the page indicated above although I've slightly
>> >> > modified the API. Essentially, to get notified about new or disappearing
>> >> > plug-ins/services, you can register a service listener. And that would
>> >> > look like this (client code):
>> >> >
>> >> >        ServiceTracker<ImageWriter> tracker = Plugins.getServiceTracker(ImageWriter.class);
>> >> >        tracker.addServiceListener(new ServiceListener<ImageWriter>()
{
>> >> >
>> >> >            public void added(ImageWriter writer) {
>> >> >                register(writer);
>> >> >            }
>> >> >
>> >> >            public void removed(ImageWriter writer) {
>> >> >                unregister(writer);
>> >> >            }
>> >> >
>> >> >        });
>> >> >
>> >> > Where Plugins is:
>> >> >
>> >> > public class Plugins {
>> >> >
>> >> >    /**
>> >> >     * This is the services singleton.
>> >> >     */
>> >> >    private static final Services SERVICES = new Services();
>> >> >
>> >> >    public static void setServicesBackend(ServicesBackend backend) {
>> >> >        SERVICES.setServicesBackend(backend);
>> >> >    }
>> >> >
>> >> >    public static <T> ServiceTracker<T> getServiceTracker(Class<T>
providerIntf) {
>> >> >        return SERVICES.getServiceTracker(providerIntf);
>> >> >    }
>> >> >
>> >> > }
>> >> >
>> >> > And the BundleActivator for the client looks like this:
>> >> >
>> >> > public class Activator implements BundleActivator {
>> >> >
>> >> >    private volatile ServicesOSGi services;
>> >> >
>> >> >    /** {@inheritDoc} */
>> >> >    public void start(BundleContext context) throws Exception {
>> >> >        this.services = new ServicesOSGi(context);
>> >> >        Plugins.setServicesBackend(this.services);
>> >> >    }
>> >> >
>> >> >    /** {@inheritDoc} */
>> >> >    public void stop(BundleContext context) throws Exception {
>> >> >        Plugins.setServicesBackend(null);
>> >> >        if (this.services != null) {
>> >> >            this.services.close();
>> >> >        }
>> >> >    }
>> >> >
>> >> > }
>> >> >
>> >> > What happens is this: by default "Services" starts up with a plain-Java
>> >> > backend that simply looks up services through classic means. When the
>> >> > BundleActivator is called, the backend is replaced by ServicesOSGi
that,
>> >> > instead, gets the plug-ins from the service registry. In the background,
>> >> > any previously discovered plug-ins are "removed()" and the new ones
from
>> >> > the registry "added()".
>> >> >
>> >> > In the case of classic Java, the "removed()" method is never called
>> >> > (probably doesn't ever need to be), i.e. no dynamics there.
>> >> >
>> >> > To conclude: the goal is to profit from OSGi service dynamics when
>> >> > discovering plug-ins while preserving the possibility to run without
>> >> > OSGi API runtime dependencies and still in J2SE-1.5. Furthermore, the
>> >> > OSGi-specific code shall be as minimal as possible to shield those
with
>> >> > no OSGi knowledge in the team from the learning curve.
>> >> >
>> >> > And now, I'm wondering if you're interested to adopt this as a new
part
>> >> > in SPI Fly as a useful alternative to using ServiceLoader. If you don't
>> >> > want it, I'm going to publish it under Apache Extras.
>> >> >
>> >> > Thanks,
>> >> > Jeremias Maerki
>> >> >
>> >
>

Mime
View raw message