aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <>
Subject Re: New Blueprint Web OSGI module and BlueprintExtenderService
Date Tue, 08 Oct 2013 13:24:27 GMT
Thanks Sergey,
sounds reasonable to me...



On 8 October 2013 11:01, Sergey Beryozkin <> 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]
>> On 7 October 2013 17:19, Sergey Beryozkin <> 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]
>>> [2]

View raw message