Will, iPojo is a great example of using inversion of control (AOP) to do tons of repetitive work from you.
Without iPojo you will end up re-coding may basic routines over-and-over within all your components as all components basically have to do the exact same things for startup, registration, dependency handling, etc. So, without iPojo you end up doing one of two things. Either, cutting and pasting the same code in many different places, and we all know the errors introduced by cut-and-paste pattern reuse ;), or you end up building a framework to handle the pattern... by some sort of abstract inheritance, or better by using IOC techniques like injection. Which would simply be silly because that's what iPojo gives you but with a much larger user base and therefore higher assurance of functionality. For me, and our organization using an annotation based IOC framework was a no-brainer. It was just a question of which one to use. Based on our preferred Felix OSGi implementation, the activity of the Felix users/dev groups (go Clement!) and the non-dependencies of extensions beyond OSGi like what is required for Spring DS and Equinox built systems, iPojo came out on top. - Joel PS - I have a full UDP bundle that supports UNI/MULTI and BROADCAST. Feel free to email me directly. -----Original Message----- From: Will Budic [mailto:[email protected]] Sent: Monday, June 28, 2010 5:17 PM To: [email protected] Subject: Re: @Requires in iPojo & ServiceListener Don't know why you rely or use annotations at all. I think by using a service listener will solve your problem. I've based also my interactions between threads to be eventful, aka MVC design pattern. So the running system and services can start and operate in their own right and timing. BTW I am very interested what you are doing with UDP? Was planning to use it as protocol for distributed services... :) On 29 June 2010 02:27, Joel Schuster <[email protected]> wrote: > ... > > @Requires > ServiceName[] allMyServices; > > I can't cast back to the other interface to do the job that I need. > > > Anyhow. I think there must be a better way that I'm doing it! One thought > was to use the ServiceListener interface and wait for everything I'm > dependant upon to come up before doing any work. > > It just seems to be a very non-ipojo way of going about things. > > Any thoughts would be welcome. > > - Joel > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
