Hi Again
The other thing I've been thinking a lot about is whether it makes sense
to wait with introducing blueprint-web-osgi [2] to the trunk or wait
till some later time.
As I said earlier and as you can see from the patch it is a very light
weight module; what it does now I can easily do in meantime in Apache
CXF Blueprint servlet (or indeed one can do the same in any other custom
servlet which would need such a feature).
That said, given that Dan is now working on other few releases, I wonder
if it is an opportunity to miss. For example, adding it now would let
Karaf 3.0 introduce a blueprint-web (osgi) feature, it will all work out
quite neatly really.
Basically, I'm for merging it tomorrow morning, please review that patch
again, hope you all are OK with it. It's already been up for the review
for the last 2 weeks.
I'd also like the team to appreciate that I'm not trying to push this
feature too fast; I honestly think it is a simple yet useful
enhancement, but I'm also going to some extra length to justify it given
that I've not been active on this list at all
Thanks, Sergey
[2] https://issues.apache.org/jira/browse/ARIES-1122
On 21/10/13 17:13, Sergey Beryozkin wrote:
Hi All,
I've committed an initial code for addressing [1], please review it
again now that it is in the code, if you have any additional comments
then let me know please, also, if someone would like to tune JavaDocs a
bit - please go ahead.
Thanks, Sergey
[1] https://issues.apache.org/jira/browse/ARIES-1121
On 08/10/13 14:24, David Bosschaert wrote:
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
