For Knopflerfish the ambition is to keep it small and lean, both the framework and the compendium services. There is also a set of options where you can fine tune the behavior especially for embedded devices.
Regards, Christer -- Christer Larsson Makewave, http://www.makewave.com VP EMEA OSGi Alliance, http://www.osgi.org Knopflerfish OSGi, http://www.knopflerfish.org On 2013-09-24, at 13:01, Pavlin Dobrev wrote: > Not exactly because Equinox implementation is based on the ProSyst one. > > I did the changes in the ProSyst implementation during the contribution to > the Eclipse five years ago. Most of the changes was deoptimizations related > to removing usage of ProSyst specific utilities like Objects and Thread > pools, usage of an embedded database for configuration information etc. > So the behavior Eclipse implementation is very similar to the ProSyst one, > except usage of more temporary objects and memory. We still maintain separate > implementation mainly because of requirement to support embedded environments. > > -Pavlin Dobrev > > > On 9/24/2013 12:59 PM, David Bosschaert wrote: >> 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 > > _______________________________________________ > 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
