Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Wed, 21 Nov 2012 10:19:23 +0100
From: Jeremias Maerki <dev@jeremias-maerki.ch>
To: dev@aries.apache.org
Subject: Re: [SPI Fly] Interest for a more dynamic plug-in/service discovery
 API?
In-Reply-To: 
 <CAKbW_r6dCNB1V+Pc8Wb0Zk9egMB+OB2vOOU6JLZ17OeHzNGuEw@mail.gmail.com>
References: 
 <CAMit8Sq3iK-D7S0N2aoqSHFV9now2Cs_FsNso2mMnr=dDPmZsg@mail.gmail.com>
 <CAKbW_r6dCNB1V+Pc8Wb0Zk9egMB+OB2vOOU6JLZ17OeHzNGuEw@mail.gmail.com>
Message-Id: <20121121101922.4DE1.60BA733C@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I guess I let the ball drop on this one. Busy month. Anyway, I ran into
serious problems with the package on a server with aggressive GC options.
It turned out that my use of WeakReferences let ServiceListeners drop
when the client code doesn't hold a hard reference on the
ServiceListener. Since I cannot always assume that the life-time of a
service discovery client equals that of the host bundle, I wanted to
release OSGi ServiceTrackers when possible. This is especially important
if the service discovery client doesn't know when it's no longer used 
(often the case in legacy code). So, I have to go back to the drawing
board and come up with a better approach.


Jeremias Maerki


On 08.11.2012 11:16:19 Jeremy Hughes wrote:
> Maybe I misread Jeremias' email. When he said:
> 
> "I'd argue that IP clearance is absolutely necessary in this case"
> 
> I thought he was saying he was going to do the s/w grant form. Now
> I've reread his email, it does seem a bit mixed up.
> 
> Patch to JIRA, with code acceptance vote fine with me.
> 
> Cheers,
> Jeremy
> 
> On 1 November 2012 10:49, David Bosschaert <david.bosschaert@gmail.com> wrote:
> > Just wondering what the status is with this contribution... Since
> > Jemerias doesn't think IP clearance is necessary, will we simply go
> > ahead with an acceptance vote, which Jemerias can kick off himself,
> > IIUC?
> >
> > Cheers,
> >
> > David
> >
> > On 23 October 2012 07:25, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> >> Thanks for your feedback, Jeremy! I'd argue that IP clearance is
> >> absolutely necessary in this case since it's a clean-room development
> >> entirely by me, it's a relatively small codebase and I'm an Apache
> >> member with an ICLA on file. But I have no problem going through with it
> >> if this is preferred. After all, I've guided a larger contribution
> >> through back in 2006 already.
> >>
> >>
> >> Jeremias Maerki
> >>
> >>
> >> On 22.10.2012 17:26:12 Jeremy Hughes wrote:
> >>> On 22 October 2012 11:01, David Bosschaert <david.bosschaert@gmail.com> wrote:
> >>> > I'm not sure what the rules are here but if you can't propose it as a
> >>> > non-committer I would be happy to propose it for you.
> >>> >
> >>> > Anyone else any thoughts?
> >>>
> >>> Sure. The voting process dictates whose votes are binding and I would
> >>> expect one of those people to commit the code if the vote is
> >>> successful.
> >>>
> >>> Jeremias, I support you bringing this to Aries. Thank you (in fact I
> >>> already mentioned it our last  board report that you had contributed
> >>> it :-) Since you developed your code outside the ASF you should look
> >>> at: http://incubator.apache.org/ip-clearance/index.html
> >>>
> >>> Thanks you!
> >>>
> >>> >
> >>> > Cheers,
> >>> >
> >>> > David
> >>> >
> >>> > On 22 October 2012 08:04, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> >>> >> Dear gods of war, ;-)
> >>> >>
> >>> >> would it be ill taken if I started an acceptance vote on this as a
> >>> >> non-committer? I'd like to get a decision since I need to know soon if
> >>> >> this will live on under org.apache package names or not. It doesn't
> >>> >> really matter to me which way in the end.
> >>> >>
> >>> >> Thanks!
> >>> >> Jeremias Maerki
> >>> >>
> >>> >>
> >>> >> On 09.10.2012 17:00:21 Jeremias Maerki wrote:
> >>> >>> Thanks for the additional proposal! Spire is quite nice, but in the end
> >>> >>> I went with SPI Catch for now as it emphasizes the relationship with SPI
> >>> >>> Fly. I have no problem renaming it, though.
> >>> >>>
> >>> >>> I've opened https://issues.apache.org/jira/browse/ARIES-938 and attached
> >>> >>> the initial submission.
> >>> >>>
> >>> >>> You're absolutely right about the possible confusion with distributed
> >>> >>> discovery. I have a little such component of my own that has "discovery"
> >>> >>> in its name. Sticking with a reference to "SPI" is certainly a good
> >>> >>> thing.
> >>> >>>
> >>> >>> There is a little snag that currently, the OSGI-side integration test
> >>> >>> doesn't work for some reason when running from within the Maven build.
> >>> >>> It works for me inside Eclipse. I've spent more than half my day
> >>> >>> tracking this down but so far to no avail (suggestions welcome). But I
> >>> >>> don't think this should block an acceptance vote.
> >>> >>>
> >>> >>> So, any questions, objections or other comments on this proposal?
> >>> >>>
> >>> >>> If not I'd be grateful if the Aries committership would vote on the
> >>> >>> acceptance of the new component. Please note that this is not intended
> >>> >>> as a code drop. I plan to make further live tests and to publish the
> >>> >>> necessary changes to Apache FOP and Batik to apply SPI Catch and make
> >>> >>> those projects first-class OSGi citizens. The bundles are going into a
> >>> >>> a test environment of an application that is planned to go live in
> >>> >>> January 2013. However, I don't expect SPI Catch to gain considerably
> >>> >>> more functionality in the future since its scope is rather narrowly
> >>> >>> defined. But I'm dedicated to hanging around here to help anyone who
> >>> >>> finds this useful. If it can help flesh out OSGi Connect, all the better.
> >>> >>> I'll also try to help out with SPI Fly and other topics.
> >>> >>>
> >>> >>> Thanks,
> >>> >>> Jeremias Maerki
> >>> >>>
> >>> >>>
> >>> >>> On 08.10.2012 11:44:00 David Bosschaert wrote:
> >>> >>> > Hi Jeremias,
> >>> >>> >
> >>> >>> > I wouldn't take the discovery one as discovery in the OSGi context is
> >>> >>> > often associated with distributed discovery in the context of the
> >>> >>> > Remote Services and Remote Service Admin specs.
> >>> >>> >
> >>> >>> > I just came up with one other name suggestion: Spire (where SPI stands
> >>> >>> > for SPI and 'RE' stands for reuse both inside and outside of OSGi
> >>> >>> > contexts :-)
> >>> >>> >
> >>> >>> > In any case the name is probably not super important right now. Just
> >>> >>> > pick one that you like for the submission proposal. Refactoring tools
> >>> >>> > in IDEs like Eclipse should make it easy enough to rename later if
> >>> >>> > someone comes up with a better name.
> >>> >>> >
> >>> >>> > Cheers,
> >>> >>> >
> >>> >>> > David
> >>> >>> >
> >>> >>> > On 8 October 2012 10:34, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> >>> >>> > > Agreed. So, let's narrow down the name suggestions to two:
> >>> >>> > >
> >>> >>> > > - org.apache.aries.discovery
> >>> >>> > > - org.apache.aries.spicatch (SPI Catch, i.e. the opposite of SPI Fly)
> >>> >>> > >
> >>> >>> > > I prefer the latter since it has a cheeky touch and still retains the
> >>> >>> > > relationship with SPI Fly.
> >>> >>> > >
> >>> >>> > > WDYT? Better ideas?
> >>> >>> > >
> >>> >>> > > Cheers,
> >>> >>> > > Jeremias Maerki
> >>> >>> > >
> >>> >>> > >
> >>> >>> > > On 08.10.2012 11:03:30 David Bosschaert wrote:
> >>> >>> > >> Sounds good to me.
> >>> >>> > >>
> >>> >>> > >> Just one note, I think it should not necessarily be a sub-component of
> >>> >>> > >> SPI Fly. Yes, it uses that for some of its functionality, but I think
> >>> >>> > >> that's really an implementation detail. I think it should be a
> >>> >>> > >> top-level component in its own right.
> >>> >>> > >> Just to compare, there are other components that depend on the Aries
> >>> >>> > >> proxy functionality, but still they are not sub-components of
> >>> >>> > >> aries-proxy.
> >>> >>> > >>
> >>> >>> > >> Cheers,
> >>> >>> > >>
> >>> >>> > >> David
> >>> >>> > >>
> >>> >>> > >> On 8 October 2012 09:47, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> >>> >>> > >> > Hi David
> >>> >>> > >> >
> >>> >>> > >> > Great! I think the process should be easy:
> >>> >>> > >> > - We decide on a (package) name.
> >>> >>> > >> > - I change the package structure after that decision.
> >>> >>> > >> > - I'll try to come up with a POM (I'm no big Mavener)
> >>> >>> > >> > - I put together a submission which I'll upload to JIRA.
> >>> >>> > >> > - It is debatable whether I need to file a code grant but I have
> >>> >>> > >> > developed that all by myself and I'm an ASF member (with an ICLA on file).
> >>> >>> > >> > It's also not that big a contribution. So I don't think this is
> >>> >>> > >> > necessary.
> >>> >>> > >> > - The Aries committership votes on acceptance.
> >>> >>> > >> >
> >>> >>> > >> > So, back to naming. What shall it be?
> >>> >>> > >> > - org.apache.aries.spifly.consumer
> >>> >>> > >> > - org.apache.aries.spifly.discovery
> >>> >>> > >> > - org.apache.aries.discovery
> >>> >>> > >> > - org.apache.aries.plugin.discovery
> >>> >>> > >> > - org.apache.aries.spi.catch ;-)
> >>> >>> > >> > - other ideas?
> >>> >>> > >> >
> >>> >>> > >> > Cheers,
> >>> >>> > >> > Jeremias Maerki
> >>> >>> > >> >
> >>> >>> > >> >
> >>> >>> > >> > On 08.10.2012 10:02:32 David Bosschaert wrote:
> >>> >>> > >> >> Hi Jeremias,
> >>> >>> > >> >>
> >>> >>> > >> >> On 5 October 2012 14:58, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> >>> >>> > >> >> >> Next question is would it make sense to add this functionality to Aries?
> >>> >>> > >> >> >> I think it does. To me many of the ideas in here match with the OSGi
> >>> >>> > >> >> >> Connect RFP 145 (http://www.osgi.org/bugzilla/show_bug.cgi?id=145) and
> >>> >>> > >> >> >> I think that, besides its practical use today, this code could be a
> >>> >>> > >> >> >> valuable input to the standardization process of OSGi Connect. Overall
> >>> >>> > >> >> >> the charter of OSGi Connect is to create a dynamic services
> >>> >>> > >> >> >> environment that works both inside OSGi and out. To me the overall
> >>> >>> > >> >> >> goal of your code seems similar.
> >>> >>> > >> >> >> If we all agree that it would be suitable for this component to reside
> >>> >>> > >> >> >> in Aries, I think we should strive to make it ultimately compliant
> >>> >>> > >> >> >> with the OSGi Connect spec, when that's available.
> >>> >>> > >> >> >>
> >>> >>> > >> >> >> Does this make sense to you?
> >>> >>> > >> >> >
> >>> >>> > >> >> > As I understand it OSGi Connect's goal is to use a subset of the OSGi
> >>> >>> > >> >> > framework (most importantly the service layer but not the module layer).
> >>> >>> > >> >> > So you can use the OSGi ServiceTracker to lookup services. In that case,
> >>> >>> > >> >> > my library isn't needed and probably not very useful, since it actually
> >>> >>> > >> >> > strives not to use OSGi APIs at all. So, I'm not quite getting your
> >>> >>> > >> >> > point here. I got about one too many hints that some people may have
> >>> >>> > >> >> > reservations when introducing OSGi to a plain Java project ("Do we all
> >>> >>> > >> >> > have to learn OSGi? Can I still use X in plain Java? etc."). OSGi,
> >>> >>> > >> >> > unfortunately, is still not as widely adopted as I would like. I've
> >>> >>> > >> >> > noticed how a low-level ServiceTracker can provoke reactions like: "Does
> >>> >>> > >> >> > it have to be that complicated?" At least, until they get the power of
> >>> >>> > >> >> > it. So, my main goal was to really just shield everyone from OSGi as
> >>> >>> > >> >> > much as possible. Basically, I just wanted to provide an easy migration
> >>> >>> > >> >> > path without the requirement to learn about OSGi beyond including
> >>> >>> > >> >> > manifest metadata. If my thingy helps OSGi Connect, that's great but I
> >>> >>> > >> >> > frankly don't see how. I'm probably still missing something.
> >>> >>> > >> >>
> >>> >>> > >> >> I get your point. From a very high level both OSGi Connect and your
> >>> >>> > >> >> project aim at getting to use OSGi easier, however OSGi Connect
> >>> >>> > >> >> strives to do this by introducing the OSGi APIs early (before the
> >>> >>> > >> >> modularity layer) whereas your approach strives to do this by
> >>> >>> > >> >> introducing the OSGi APIs late (or not at all, even).
> >>> >>> > >> >>
> >>> >>> > >> >> Personally I think choice is good and it's up to the users to really
> >>> >>> > >> >> decide what technology they want to use. I think your technology would
> >>> >>> > >> >> be at the right place in Apache Aries, so if you're happy to donate it
> >>> >>> > >> >> I would be happy to support that and I can find out the process by
> >>> >>> > >> >> which this should be done.
> >>> >>> > >> >>
> >>> >>> > >> >> All the best,
> >>> >>> > >> >>
> >>> >>> > >> >> David
> >>> >>> > >> >
> >>> >>> > >
> >>> >>
> >>