Great suggestions so far. So, it is time for me to make a naive observation or two and hopefully have someone hit me with a clue-by-four. Things like Spring DM and Peaberry use dynamic proxies when passing around services. I have not had a chance to carefully see how this relates to what happens when I have a proxy to a service that has gone away (perhaps it is different depending on the system) but I am imagining they expect me to handle this situation and really I just want my services to shutdown. I need to investigate this though. The other thing that annoys me about proxies is the difficultly in debugging and tracing or reading tracebacks which involve them (if anyone has a protip here on how to make it easier please let me know). For those reasons, I would prefer to avoid things that create proxies all over the place.
I also am not a fan of XML based services configurations (or non-code based really) since I find that it means I invariably make a change to a class name and then face a lovely runtime failure as a result. It has hit me often enough that I really would prefer to avoid it if possible. As a result, I don't think I want to use iPOJO either (or Spring DM again). It seems like felix DM and eclipse SAT are probably the best options for me based on what I currently know but I don't know that much yet so... :-) Anyone know of a site that compares these? -AZ On Thu, Apr 16, 2009 at 4:32 PM, Stuart McCulloch <mccu...@gmail.com> wrote: > 2009/4/16 Aaron Zeckoski <aar...@vt.edu> > >> The spring stuff seems a bit heavyweight but that is just my >> experience from other projects (not OSGi related) so maybe I am >> operating on old info. >> > > just for completeness, there's also: > > Apache Felix Dependency Manager (uses a builder-style API) > http://felix.apache.org/site/apache-felix-dependency-manager.html > > Service Activator Toolkit (tooling is primarily Eclipse based) > > http://www.kevindog.com/sat/help/topic/org.eclipse.soda.sat.plugin.doc/books/book.html > > peaberry (Guice extension, can also work with non-OSGi service > registries) > http://code.google.com/p/peaberry/ > > so there's quite a choice out there, and all of them can co-operate via the > service registry :) > > I will take a look at the DS and iPOJO stuff. Thanks for the pointers! >> :-) >> -AZ >> >> On Thu, Apr 16, 2009 at 2:15 PM, Filippo Diotalevi >> <filippo.diotal...@gmail.com> wrote: >> > Hi, >> > >> > On Thu, Apr 16, 2009 at 3:08 PM, Aaron Zeckoski <aar...@vt.edu> wrote: >> >> So, this is really more of a general OSGi question so I apologize >> >> up-front for not asking a Felix specific question. >> > >> > (I think that's the right mailing list, anyway) >> > >> >> I basically want to simply avoid starting my services until the ones I >> >> require are availabe, shut mine down when the ones I require go away, >> >> react to changes in the required services (S1 is replaced by S2), and >> >> track services which are optional but used by me (like extensions for >> >> example). I also want it to be easy to get services and take advantage >> >> of generics where possible to avoid constant casting. >> > >> > As you realized, the ServiceTracker is a very powerful tool but it >> > requires quite a lot of code, especially when you need to track a lot >> > of services in the same time. >> > Some pointers: >> > >> > - to do what you want to do, I use atm Spring DM >> > http://www.springsource.org/osgi >> > - if I could change (too late now for my current project), I'd >> > probably use OSGi DS >> > http://felix.apache.org/site/apache-felix-service-component-runtime.html >> > - it may be worth looking at iPOJO (I don't know it but Clement here >> > is the expert & developer) >> > http://felix.apache.org/site/apache-felix-ipojo.html >> > >> > Hope this helps >> > -- >> > Filippo Diotalevi >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> > For additional commands, e-mail: users-h...@felix.apache.org >> > >> > >> >> >> >> -- >> Aaron Zeckoski (aar...@vt.edu) >> Senior Research Engineer - CARET - Cambridge University >> [http://bugs.sakaiproject.org/confluence/display/~aaronz/<http://bugs.sakaiproject.org/confluence/display/%7Eaaronz/> >> ] >> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > -- > Cheers, Stuart > -- Aaron Zeckoski (aar...@vt.edu) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/] --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
