Hi Balazs, Thanks for sharing your feedback. The timing is good because we are planning to work on some extensions to the Blueprint Specification within the EEG in the near future. I'll make sure your suggestions are taken into account.
Best regards, David Bosschaert BTW if you are interested in helping out with this specification work, let us know! On 9 May 2012 01:10, Balázs Zsoldos <[email protected]> wrote: > 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 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
