IMHO there is a line there somewhere where code is just code. A base 64
encoder could just be a mess of statics on a class somewhere. Should Arrays be
a service? Do we need a HashMapFactory service? How you draw the line is up to
your and your expected user's requirements. If you think that someone might
actually have a better base 64 encoder or somehow not want to use yours in
their deployment, then services are likely good for you. Otherwise, just write
the code and use it.
Jeff
On 2010-11-18, at 9:14 AM, Jean-Baptiste Onofré wrote:
> Hi Alexander,
>
> I prefer to use service because your bundle is completely decoupled from the
> interface.
>
> As the service is identified by an interface, you can change your
> implementation without changing your bundle.
>
> If you use Import/Export, changing the implementation means that you have to
> update your bundle, which is not the case using a service.
>
> Regards
> JB
>
> On 11/18/2010 09:01 AM, Alexander Shutyaev wrote:
>> I have a very general question concerning usage of services versus
>> Import/Export package. What would be the main principles in choosing
>> between one of these schemes?
>>
>> Let's say I want to write a BASE64 encode/decode utility. Plain old java
>> way would be to write a class like
>>
>> public class Base64Utility
>> {
>> public static String encode(byte[] data) {}
>> public static byte[] decode(String encodedData) {}
>> }
>>
>> To use it I would Import the package it resides in and then write
>> something like
>>
>> String s = Base64Utility.encode(mydata);
>>
>> On the other hand I could register an OSGi service under an interface
>> similar to the class shown above. That would require some extra actions.
>> But is it right to create service for such a primitive class? How do I
>> know when to use a service and when to just Import/Export the class
>> (sorry, package) I need?
>>
>>
>>
>> _______________________________________________
>> 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
