If you have thousands of DS components in one bundle you are probably doing
something wrong. Clearly your bundle is not a cohesive unit of modularity.
The largest DS based bundles I've seen tend to max out at around 50
components (even that is extreme).
Our largest bundle, a bundle which provides a search engine implementation,
based on Elastic Search, which is a complex bundle due to tons of touch
points in configuring elastic search is 57 components. It can be argued
that this bundle is a case to be modularized even more... but alas the
problem is elastic search internals.
Of the hundreds and hundreds (i'm not even kidding) of bundles we produce
the vast majority contain about 3-5 components.
- Ray
On Mon, Jan 22, 2018 at 3:45 PM, Christian Schneider via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
> I always simply use slf4j and a suitable logger implementation.
> Pax logging works quite well. The main advantage is that your logging
> works exactly like outside of OSGi.
>
> Internally it is maybe not the cleanest way but as a user this works
> really nicely.
>
> Christian
>
> 2018-01-22 7:06 GMT+01:00 Tanvir via osgi-dev <osgi-dev@mail.osgi.org>:
>
>>
>> In DS, for accessing a service reference, the class has to be a
>> Component. That means to access common services, such as log service,
>> all classes becomes Components. In the following example, to access log
>> service all classes in Emp bundle became Components.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *@Component public class Emp implements EmpService { LogService log
>> @Reference (cardinality = ReferenceCardinality.MANDATORY) void
>> setLogService(LogService log) { this.log = log; } } @Component public
>> class EmpAddress { LogService log @Reference (cardinality =
>> ReferenceCardinality.MANDATORY) void setLogService(LogService log) {
>> this.log = log; } } @Component public class EmpPayroll { LogService log
>> @Reference (cardinality = ReferenceCardinality.MANDATORY) void
>> setLogService(LogService log) { this.log = log; } }*
>> ....
>>
>> *Question: *Is there a way to solve this proliferation of DS Components
>> and References?
>>
>> *Solution A*: We can factor out reference code and move them to a
>> RefManager Component. Also maintain a shared static variable to LogService
>> for all other classes.
>>
>> @Component
>> public class RefManager {
>> *static *LogService log
>> @Reference (cardinality = ReferenceCardinality.MANDATORY)
>> void setLogService(LogService log) { this.log = log; }
>> *static* LogService getLogger() { return log;}}
>>
>> @Component
>> public class Emp implements EmpService {
>> ..
>> RefManager. getLogger.log();
>> }
>>
>> public class EmpAddress {
>> ..
>> RefManager. getLogger.log();
>> }
>> public class EmpPayroll {
>> ..
>> RefManager. getLogger.log();
>> }
>>
>>
>> *Problem:* Now we can end up with null LogService reference even though
>> LogService ref is MANDATORY . E.g. if EmpService is activated before
>> RefManager or LogService, it gets null LogService ref.
>>
>> *Question:* If we set LogService and RefManager as immediate components
>> (RefManager is immediate by default for being a Component), is it
>> guaranteed that they will be activated before EmpService?
>>
>> *Solution B: *
>> Another solution for the above problem is to view LogService as OPTIONAL.
>> However, an optional reference can be null requiring a null check. That
>> means each use of Log Service api require the following null check.
>>
>> If (log!=null) log.log(..);
>>
>> *Problem: * Considering that log apis are heavily used, this seems
>> tedious and error-prone. Is there a better way of using OPTIONAL reference?
>>
>>
>>
>>
>> --
>> Best,
>> Tanvir
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
