Thanks Sergey, sounds reasonable to me... Cheers,
David On 8 October 2013 11:01, Sergey Beryozkin <[email protected]> wrote: > Hi David > > Thanks for the feedback, > > On 08/10/13 09:34, David Bosschaert wrote: > >> Hi Sergey, >> >> I think I understand what you are proposing for [1]. A programmatic >> API to create Blueprint Containers. Once you have such container, can >> you then also programmatically add beans etc? In other words will you >> be able to do via code all the things that you would normally do in a >> blueprint.xml? > > > Not really. This enhancement is simply about making it possible to use > BlueprintExtender to get BlueprintContainer this Extender may've already > created for a given bundle or request Extender to create a new container if > the bundle metadata has no Blueprint-specific instructions or annotations, > example, when a Blueprint context path is set as ServletContext parameter. > > Once the consumer gets BlueprintContainer it will get from it a component it > needs. > > >> >> Regarding [2] I'm not seeing the full picture here yet. One thing that >> is being worked on in the OSGi Alliance is whiteboard pattern support >> for the HTTP Service, which means that you can register Servlets in >> the service registry to make them part of your webapp. This should >> make it a lot easier as well to create webapps using blueprint. I >> believe that Apache Felix has already an implementation of such a HTTP >> Service... But then, maybe your are trying to do something completely >> different... > > > I'd like to do a "webbundle:" protocol deployment where a bundle containing > only WEB-INF/web.xml and Blueprint contexts is deployed (with no embedded > libs). > > AFAIK it is supported by Pax-Web, possibly by other stacks too. Internally > Pax-Web registers a custom servlet referenced in web.xml with HttpService > under a context path specified via Web-ContextPath bundle instruction. > > We like this option because it lets us support the same light-weight bundle > deployment we work with but still get a War-aware/full ServletContext. > AFAIK, the default ServletContext created via the white-board pattern will > be limited in its capabilities, example it won't support Servlet > RequestDispatcher, etc. > > Right now I can do it with Spring DM but not with Blueprint. The new > blueprint-web-osgi is very light-weight and will simply adds another option > for utilizing Blueptint contexts. > > FYI, I've linked an Apache CXF issue to Aries-1122, please have a look there > at CXFBlueprintServlet code and a custom web.xml. > To be honest I can even push the code which I hope will actually live in > blueprint-web-osgi to CXFBlueprintServlet, it will work just fine, I'd still > need Aries-1121 done. > > However blueprint-web-osgi does some boiler-plate code to do with getting > the right BlueprintContainer, so IMHO it may be of help to other Aries users > > Thanks, > Sergey > > >> >> Cheers, >> >> David >> >> [3] https://github.com/osgi/design/tree/master/rfcs/rfc0189 >> >> On 7 October 2013 17:19, Sergey Beryozkin <[email protected]> wrote: >>> >>> Hi All, >>> >>> I did some initial work on enhancing BlueprintExtender to make it easier >>> to >>> deal with BlueprintContainers externally [1] and introducing a new >>> blueprint-web-osgi module [2]. >>> >>> I've commented at [1] & [2] so hopefully the reason behind these minor >>> but >>> also IMHO useful enhancements is clear. >>> We'd like to be able to use Blueprint contexts within light-weight war >>> bundles, examples, in those installed via a "webbundle:" protocol and >>> drive >>> the creation of web context paths from custom servlets; I believe it can >>> be >>> of general use for OSGI Blueprint developers too. >>> >>> Comments to the proposed patches are welcome >>> >>> Thanks, Sergey >>> >>> >>> [1] https://issues.apache.org/jira/browse/ARIES-1121 >>> [2] https://issues.apache.org/jira/browse/ARIES-1122 >>> >
