Hi,
you may hate me in the future due to my long mails but since the last year
lots of things came into my mind and I feel that this is the right place to
share. If it is not please let me know and I will move to some hidden blog
and talk to myself :).
As I came from the Spring world I was very happy when I saw the blueprint
specification and also a working implementation. That was the time that I
thought it was time to move to OSGI. However, I think in blueprint there is
much more that could come out. If we start developing some custom blueprint
container project based on one of the already existing ones it would be
very risky. Therefore I would be very happy to have any feedback from you
if we are going in a right way and if there could anything come out as a
specification later from our work. In that case I would feel that we have
the chance to create some long-living stuff.
I was thinking the following two topics:
- Service management improvement in blueprint
- Multiple BlueprintContainer for one bundle based on parameters
*Service management improvement in blueprint:*
- A reference could have the following two type
- proxy: The blueprint container and all components that need this
reference are instantiated although the service is not
available. Until the
service is not available a ServiceNotAvailableException is
thrown when any
of the functions on the service is called. The important thing here that
this solution handles when the service is not available anymore
in the OSGI
container or available again.
- hardwired: Blueprint container starts only when the reference is
available. However the Blueprint container stops when the service is
unregistered from the container.
The two types have the same importance. When bundles talking to each other
only by wiring to API bundle packages (that may not be updated for a longer
time) the bundles that use services based on the interfaces from the API
will not be refreshed when an implementation bundle changes. This would
solve this problem as in this case there would be Service based wirings and
not only package based wirings.
*Multiple BlueprintContainer for one bundle based on parameters*
- A bundle would have one blueprint part that works exactly the same way
as it works now based on the xml-s from OSGI-INF/blueprint
- There would be another folder like OSGI-INF/parameterized-blueprint
that would have the following differences:
- There are certain parameters sets that need to be available to
start up a BlueprintContainer
- If the parameter sets are provided more times (e.g. different
configuration bundles are dropped that provide this parameter sets) more
BlueprintContainers are started for the bundle
- When a parameter set is removed from the OSGI container (the
configuration bundle is removed) the BlueprintContainer is
stopped as well
that used the parameter set
- The blueprint files here have one of the following extra
possibilities
- Velocity like templating with the given parameter set (more
flexible for the programmer but not standard XML)
- New element to disable parts based on the parameters E.g.: <use
expression="#{param5 eq 'Hibernate'}"> (standard XML, that
can be parsed
so the XML may contain the interface part, very similar to
JSF composite
component logic)
This would let us forget the application-like projects where bundles are
packaged into bundles. One bundle could start up as many
BlueprintContainers (and therefore expose different services based on
different configurations) as many configuration is necessary. For example:
if there is a bundle that uses database than the interface of the blueprint
part could wait for DataSource or Persistence Unit name. If any of the
parameters is provided the BlueprintContainer will start working. Also the
bundles that are waiting for configuration from this bundle will start
their BlueprintContainers.
More detailed example.
We have bundle A, B, C. Bundle A uses B, B uses C and C uses database.
APP1 bundle is dropped in with configuration. BlueprintContainer starts for
C, than for B, than for A and Services will be provided with some
properties (e.g. id coming from APP1 bundle)
APP2 bundle is dropped in with configuration. Another BlueprintContainer
starts for C, than for B than for A and Services will be provided with some
properties (e.g. id coming from APP1 bundle)
Without this the following I can only imaging the followings (I do not like
any of them):
- Bundle A, B, C does not contain any blueprint but all packages are
exported and APP bundles contain all blueprint configuration that is
necessary (going back to WAR and Spring word)
- Package bundle C multiple times and create than package bundle A, B, C
into subsystems (Going back to War development again and losing
modularization)
If anyone reads this sentence than thanks so much for reading my long
mails! If you feel that there are already solutions to my problems and they
are implemented please direct me in the right way. I would like to save as
much time for myself as I can.
Regards
Balazs Zsoldos
Software Architect
Mobile: +36-70/594-92-34
Everit Kft.
https://www.everit.biz
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
