According to http://en.wikipedia.org/wiki/OSGi_Specification_Implementations there is actually a 4th implementation: the one from Prosyst.
Best regards, David On 24 September 2013 09:28, Peter Kriens <[email protected]> wrote: > I think it comes down to the same rule: measure ... There are only 3 impls I > think: Knopflerfish, Apache Felix, and Equinox. > > If you measure them, I think it would be great to have a blog about it ... > > Kind regards, > > Peter Kriens > > On 24 sep. 2013, at 10:03, Daniel McGreal wrote: > >> Incidentally, is it known which implementation is considered to use >> resources most conservatively? >> Many thanks, >> Dan. >> >> On 24 Sep 2013, at 08:52, Peter Kriens wrote: >> >>> The problem is that solving the DS problem (managing your dependencies etc) >>> is going to take space in your app code. So I can see it would be an >>> overhead for 1 bundle, but at a certain point you get a lot less >>> classes/space. And if you have only one bundle, OSGi does not make a lot of >>> sense :-) >>> >>> As always in these cases, you have to measure it ... >>> >>> Kind regards, >>> >>> Peter Kriens >>> >>> >>> On 21 sep. 2013, at 01:03, [email protected] wrote: >>> >>>>> Indeed. >>>>> The server guys in my team make fun of me :( >>>> >>>> Ignore them - they're just a bunch of quiche-eaters. ;-) >>>> >>>> Peter, it's not just the size of the jar file which counts (75k for >>>> knopflerfish SCR BTW), it's the memory usage at runtime - which is going >>>> to be more than that[1], and RAM is usually even scarcer than filesystem >>>> space. >>>> >>>> [1] To the extent that classes are loaded from the jarfile, the >>>> representation of these classes in memory will typically be somewhat >>>> larger than the jar entry after the later is decompressed. And while >>>> Daniel's "server guys" may quite often put some huge open-source library >>>> on their classpath just to use one class, OSGi services tend to have a >>>> high degree of cohesion so the chances are that pretty well all of the jar >>>> file gets loaded ... >>>> >>>> Which is not to deny that DS is mankind's coolest invention since OSGi >>>> itself ... >>>> >>>> Kind regards >>>> >>>> Chris Gray >>>> >>>>> On 20 Sep 2013, at 16:37, Peter Kriens wrote: >>>>> >>>>>> On 19 sep. 2013, at 20:25, Daniel McGreal wrote: >>>>>>> Space constraints. >>>>>> Wow! You must code in a tightly constrained embedded environment if 195k >>>>>> is too much for something soooo valuable .... :-) >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Peter Kriens >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On 19 Sep 2013, at 18:55, Peter Kriens <[email protected]> wrote: >>>>>>> >>>>>>>> Why not use DS? >>>>>>>> >>>>>>>> >>>>>>>> On 19 sep. 2013, at 18:02, Daniel McGreal wrote: >>>>>>>> >>>>>>>>> Hi OSGi-devs, >>>>>>>>> >>>>>>>>> I have a question about utilising ServiceTracker to manage a class's >>>>>>>>> dependencies and blocking during the call, which I confess is >>>>>>>>> probably well trodden ground but for which I can't apparently find >>>>>>>>> the right Google terminology. Perhaps because I've been, until now, >>>>>>>>> coddled by higher-level service dynamism, like Blueprint. >>>>>>>>> >>>>>>>>> I have a java.util.logging.Handler whose publish method needs a >>>>>>>>> couple of OSGi services to operate. Any LogRecords that are published >>>>>>>>> during a refresh of either of the dependencies should not be lost and >>>>>>>>> should be reattempted when services resume (which in practice might >>>>>>>>> be a long time, the device this application targets is incredibly >>>>>>>>> primitive). >>>>>>>>> >>>>>>>>> Currently I have the Activator and Handler in the same implementation >>>>>>>>> (which seems like it might be bad practice, if it is, I'd love to >>>>>>>>> know why). Here's a trimmed down version, with just one dependency: >>>>>>>>> >>>>>>>>> public class RemoteLoggingHandler extends Handler implements >>>>>>>>> BundleActivator { >>>>>>>>> private volatile Channel channel; >>>>>>>>> >>>>>>>>> private ServiceTracker<IAmqpChannelProvider, >>>>>>>>> IAmqpChannelProvider> >>>>>>>>> channelProviderTracker; >>>>>>>>> >>>>>>>>> @Override public void start(BundleContext context) throws >>>>>>>>> Exception >>>>>>>>> { >>>>>>>>> channelProviderTracker = new >>>>>>>>> ServiceTracker<IAmqpChannelProvider, >>>>>>>>> IAmqpChannelProvider>(context, IAmqpChannelProvider.class, null){ >>>>>>>>> @Override public IAmqpChannelProvider >>>>>>>>> addingService(ServiceReference<IAmqpChannelProvider> reference) { >>>>>>>>> IAmqpChannelProvider channelProvider = >>>>>>>>> super.addingService(reference); >>>>>>>>> try { >>>>>>>>> channel = >>>>>>>>> channelProvider.createChannel(); >>>>>>>>> //Some initialisation, can >>>>>>>>> happen once or multiple times, no >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> channel.exchangeDeclare(LoggingConstants.LOGGING_EXG_NAME, >>>>>>>>> "topic", true); >>>>>>>>> notifyAll(); >>>>>>>>> } catch (IOException e) { >>>>>>>>> e.printStackTrace(); >>>>>>>>> } >>>>>>>>> return channelProvider; >>>>>>>>> } >>>>>>>>> >>>>>>>>> @Override public synchronized void >>>>>>>>> modifiedService(ServiceReference<IAmqpChannelProvider> reference, >>>>>>>>> IAmqpChannelProvider service) { >>>>>>>>> removedService(reference, service); >>>>>>>>> addingService(reference); >>>>>>>>> } >>>>>>>>> >>>>>>>>> @Override public void >>>>>>>>> removedService(ServiceReference<IAmqpChannelProvider> reference, >>>>>>>>> IAmqpChannelProvider service) { >>>>>>>>> super.removedService(reference, >>>>>>>>> service); >>>>>>>>> channel = null; >>>>>>>>> } >>>>>>>>> }; >>>>>>>>> channelProviderTracker.open(); >>>>>>>>> >>>>>>>>> >>>>>>>>> LogManager.getLogManager().getLogger("").addHandler(this); >>>>>>>>> } >>>>>>>>> >>>>>>>>> @Override public void stop(BundleContext context) throws >>>>>>>>> Exception { >>>>>>>>> >>>>>>>>> LogManager.getLogManager().getLogger("").removeHandler(this); >>>>>>>>> } >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> public void publish(LogRecord record) { >>>>>>>>> try { >>>>>>>>> synchronized (channelProviderTracker) { >>>>>>>>> while(channel == null) >>>>>>>>> channelProviderTracker.wait(); >>>>>>>>> >>>>>>>>> >>>>>>>>> channel.basicPublish(LoggingConstants.LOGGING_EXG_NAME, >>>>>>>>> record.getLoggerName(), >>>>>>>>> null, >>>>>>>>> record.getMessage().getBytes()); >>>>>>>>> } >>>>>>>>> } catch (Exception e) { >>>>>>>>> reportError(null, e, ErrorManager.WRITE_FAILURE); >>>>>>>>> return; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> //Some boilerplate.... >>>>>>>>> >>>>>>>>> @Override public void flush() {} //Unnecessary. >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> public void close() throws SecurityException { >>>>>>>>> flush(); >>>>>>>>> try { >>>>>>>>> channel.close(); >>>>>>>>> } catch (IOException e) { >>>>>>>>> reportError("Amqp channel could not be >>>>>>>>> closed", e, >>>>>>>>> ErrorManager.CLOSE_FAILURE); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> I don't feel that I've been successful. The channel member field can >>>>>>>>> still go to null while it's being used in publish, and probably many >>>>>>>>> other problems I've missed! Can anyone point out to me either the >>>>>>>>> standard procedure for this, or any comments on my above attempt? >>>>>>>>> >>>>>>>>> Many thanks, >>>>>>>>> Dan. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OSGi Developer Mail List >>>>>>>>> [email protected] >>>>>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSGi Developer Mail List >>>>>>>> [email protected] >>>>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>>> _______________________________________________ >>>>>>> OSGi Developer Mail List >>>>>>> [email protected] >>>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>> >>>>>> _______________________________________________ >>>>>> OSGi Developer Mail List >>>>>> [email protected] >>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> [email protected] >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
