So far it seems Felix's solution would indeed be the only viable
solution,
even though it would break the unified DS based architectures.
I fail to see how this breaks the DS architecture ... The reason DS
uses XML is only for lazyness, it required us to do the dependency
handling without creating a class loader. DS is not Blueprint or
Spring DM, where the dependency injection is at the heart of the
architecture. In DS, you want to do everything in Java as long as your
service dependencies are met.
A solution where you create a component when your service dependencies
are met, and then that component registering a Network service when
the network is active is perfectly ok and seems a lot less artificial
then some of the other solutions. DS is designed to handle service
dependencies, and it is very good at that. However, this architecture
requires that you have code that turns other dependencies like your
network into services, and you really need some Java code for that ...
Kind regards,
Peter Kriens
On 3 okt 2009, at 17:57, Luciana Alvite wrote:
Firstly I would like to thank you all for your responses.
@Felix and Simon:
Although this solution is viable, my Network component depend on other
services from other
bundles, so registering the service "by hand" in the connect method
would
not be very
practical, as Simon mentioned. I would rather use DS, if possible.
@Simon:
to 1) unfortunatelly the bundles are not in the same bundles (I
thought
about that too)
to 2) I am not sure I understand ur "factory component" suggestion.
my network component creates one and only one connection and all other
modules interact
with the network through one and only one network component (its a P2P
network, so each
node has an unique ID, based on its IP and port, which is created
when the
connection to
the network is established). Creating several connections would be the
equivalent of having
several nodes in the same machine, which would break the application.
to 3) see above
@ Marcel and Simon:
as I said im my first post, I have succesfully changed the component
properties through the
ConfigAdmin, but as I said, using this way the network method is
reactivated
when its
properties change and therefore its previous state is lost (incl the
connection state).
I am not really familiar with iPojo, but could I use the "requires
field"
(or sth similiar) to declare another component (Login in the example)
depends on a
"isConnected" field (from the Network component) whose value MUST be
true?
if yes, what
would happen when the value of the field changes? Would the
component that
declares it
(Network) be reactivated or does it maintain its state?
This seems very similar to the properties in OSGi, which when
changed using
the ConfigAdmin
will reactivate the component, thus losing its previous state.
I personally also tend to use DS as much as possible and currently
the whole
project (there
are several other modules besides these 2) is DS based, which allows
for an
easy extendible
architecture, even for people w.o. much knowledge of OSGi. I would
like to
maintain that
unified architecture if possible.
The Network and Login bundles provide the basic functions to access
the
network and all
other modules depend on then, as it would be expected (the user must
be
connected and
logged in to do virtually anything in the platform).
So far it seems Felix's solution would indeed be the only viable
solution,
even though it
would break the unified DS based architectures.
Since I plan on using the same mechanism to inform interested
bundles about
the login state
too, this would mean I would have to redesign both the Network and
Login
bundles using the
standard OSGi API, thus breaking the unified POJO architecture.
I will think about it a little longer.
Any other suggestions are highly appreciated.
thank you and regards,
Luciana
_______________________________________________
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
