Hi, BTW if you are interested in helping out with this specification work, let us know!
I let you know than. This is my dream to talk to colleagues who are interested in the same topic and try finding the best solution together :) In a couple of days I can prepare an XSD with descriptions based on the current blueprint and you could decide if you want to use anything from it. As soon as the new draft XSD is created with some specification I think I will try having a working solution based on the Aries implementation as we would really need these features for our project. Also I forgot to mention in my last mail that it would be really helpful if the implementation of a namespace handler would be part of the next specification. Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz On Wed, May 9, 2012 at 9:04 AM, David Bosschaert <[email protected] > wrote: > 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 >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
