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
