[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Fwd: How to correctly set up another LifeCycleHandler
|
Hi,
First: THANKS AGAIN!
I've managed to implement solution 2) and it looks pretty nice :D.
Second: I'll just sum up things a bit to be sure to get in the right direction for the feature
I don't understand your first solution using fragments. But as this looks as the least flexible one, it's not our preferred solution.
Solution 1) seems to be the "OSGi" way of handling things (if I got it right). Its pretty flexible but enforces the consuming plugin
to also go the "OSGi" way and request the service properly.
As said above solution 2) seems to be the most flexible and works pretty good. The problem with our application (not your solution) is
that we went a completely wrong way from beginning of the project. None of our service interface plugins are implemented as part of
the application model. As we could not get DI working properly we used static factory methods to retrieve instances (now its clear why
DI didn't work as expected).
So, what we would do now (to get things right):
1. Change service plugins (those just hold a generic service, e. g. ContactService) to be an addon for application (this ensures that
service classes could be injected to the context using the first approach "@PostConstruct").
2. Change storage plugins (just the implementation, e. g. MySqlContactStorage) to OSGi services like solution 2. of your last email. (this way
we can easily change the used backend)
3. We then can request a storage implementation from the generic service class using DI and also use the service in the user interface using DI.
Last question is then how to dynamically enable / disable an installed backend. But that will be asked (if I don't find a solution myself) in
another email to not mix up topics..
Last:
One last time: thanks!
Ben
