Hi, I am not an Apache Aries developer but I a made some Jira issues for them as well (and sometimes sending patches as well) :). So my sentence meant that I will create an implementation based on Aries and not inside. I will hope than that they include my code into theirs.
Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz On Wed, May 9, 2012 at 12:53 PM, David Bosschaert < [email protected]> wrote: > Great to hear, Balazs! Looking forward to those proposed changes in > Apache Aries. > > The specification process in OSGi (which is often based off existing > implementations such as those done in Apache and Eclipse) is done in > the one of the OSGi Expert Groups. To participate in there you need to > be a member - any organization/company can become a member, see here > for more information: http://www.osgi.org/About/Join > > BTW - Yes, the specification of Blueprint Namespaces has been on the > table for a long time, but unfortunately it's not done yet. This is > another topic that given enough people to help we could focus on again > with the aim to create a spec. > > Best regards, > > David > > On 9 May 2012 11:39, Balázs Zsoldos <[email protected]> wrote: > > 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 > > _______________________________________________ > 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
