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
