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
