The example is to show reference management nightmare even for a single
service. Lets assume there will be 50+ services, 1000+ classes.
*Problems: * Even with each classes using @Reference, we do not have a
single synchronization point when these references are available for
all classes of a bundle. Referenced services can be dynamic due to
recovery, patching etc. Code has to keep on validating the reference.
Hence we also need @activate for each class for mandatory refs, or unset
method for optional refs.
Is this an incomplete design in part of DS for handling dynamic
services? Blueprint seems to address this service dynamism with "timeout".
How do we solve consistent reference behavior for all classes (now
Components) of a bundle in DS?
On 1/22/2018 3:03 AM, Tim Ward wrote:
Hi Tanvir,
I would strongly recommend that you do not use solution A. Static
variables are a very bad thing for many reasons, not least (as you
have discovered) because they completely bypass the lifecycle
management of your component. In answer to the question:
/"*Question:*If we set LogService and RefManager as immediate
components (RefManager is immediate by default forbeing a
Component), is it guaranteed that they will be activated before
EmpService?"/
No - this will not help you. You are stepping totally outside the
design of Declarative Services and the result will be an inconsistent
mess.
/"Another solution for the above problem is to view LogService as
OPTIONAL"/
This is actually something different, as it’s saying that you want
your code to work both with and without a log service, in this case
you do need to be able to handle there being no log service to log to.
To go back to your original question:
/"Is there a way to solve this proliferation of DS Components and
References?"/
Having lots of DS components is a good thing! They are lightweight and
they manage your service dependencies.
You could use field injection to avoid some boilerplate:
/@Component/
/public class Emp implements EmpService {/
///@Reference/
/ LogService log;/
/}/
If you really are allergic to using DS for injecting the Log service
then an alternative is to use something like SLF4J instead. This can
be configured to log to the Log Service (by installing the correct
SLF4J back end) and then you can configure the Log service to log
somewhere else if you desire.
Regards,
Tim
On 22 Jan 2018, at 06:06, Tanvir via osgi-dev <osgi-dev@mail.osgi.org
<mailto:osgi-dev@mail.osgi.org>> wrote:
In DS, for accessing a service reference, the class has to be a
Component. That means to access commonservices, 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 <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Best,
Tanvir
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
