aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: [DISCUSS] WAB and blueprint
Date Fri, 19 Nov 2010 23:03:39 GMT


Alasdair Nottingham

On 19 Nov 2010, at 16:46, Guillaume Nodet <gnodet@gmail.com> wrote:

> On Fri, Nov 19, 2010 at 17:27, Charles Moulliard <cmoulliard@gmail.com> wrote:
>> I think that we should considering two different approaches :
>> 
>> 1) Existing WAR
>> For projects already deployed as WAR in a traditional Web Application
>> Server, this is technically possible today to deploy it on an OSGI platform
>> (ex : Apache Karaf) where we use PAX Web and PAX Web extender to emulate a
>> Web Container on OSGI platform without too much modifications except the
>> MANIFEST. Those WAR projects are deployed successfully even if they use
>> Spring. For an example, you can have a look to my Camel OSGI tutorial Part 2
>> where I have deployed a Apache Wicket Web Site and use Spring DM to have
>> access to the osgi:services -->
>> http://camel.apache.org/tutorial-osgi-camel-part2.html
>> I'm not afraid of the fact to place my blueprint xml config file in the same
>> directory as for the bundle (OSGI-INF) but just want that users can migrate
>> easily their WAR without having to make too much changes.
> 
> The point is that blueprint can't be used outside of OSGi, so if you
> want to use blueprint, you need to be OSGi aware in any case.
> 
>> 
>> 2) New project to be deployed as WAR on OSGI platform
>> I guess to your remark and for me too Blueprint should not be substituted to
>> the Web Container. Our concern is that we would like that a Web Application
>> deployed on an OSGI platform can have access to Blueprint like with Spring.
>> The idea to use @Resource annotation like with j2EE 6 spec is excellent and
>> avoid to create something new and different from an existing well accepted
>> specification but we should also support a blueprint XML file deployed in
>> the WAR or JAR bundle !!
> 
> I don't think anyone said otherwise.
> What I have in mind is exactly what the Spring guys did, i.e. make the
> ServletContext available in the blueprint beans, make the
> BlueprintContainer available in the ServletContext.   The only thing
> is to coordinate both which I think can be achieved without any
> requirement on the webapp if the web container is aware of blueprint,
> or by registering a known listener in the webapp and using a custom
> namespace in the blueprint xml.
> 
> I'm not convinced by using the @Resource for now as this is not yet
> supported by the OSGi Web Application spec afaik which only support
> Servlet 2.5 and not 3.0.

There is nothing in the OSGi spec to preclude this. A servlet 2.5 container can choose to
support @Resource annotations if it wishes. I think we would be better off finding a way to
support it's use via the servlet based injection mechanism rather than just exposing the blueprint
container in the servlet context. It doesn't feel like exposing the blueprint container directly
in the servlet context is that great of an improvement. It probably just removes three lines
of code.

> 
>> 
>> Regards,
>> 
>> Charles
>> 
>> 
>> On 19/11/10 11:37, Guillaume Nodet wrote:
>>> 
>>> Right, creating servelts is not really a good idea...
>>> I guess the problem of reusing the default blueprint location and
>>> headers is that you then need to have cooperation between both
>>> extenders, and you need to oreder both.   I suppose the web extender
>>> could wait for the blueprint container to be published...
>>> 
>>> On Friday, November 19, 2010, Timothy Ward<timothyjward@apache.org>
>>>  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I'm not sure I agree with the WEB-INF/ approach. I think we should stick
>>>> to the standard blueprint packaging model (OSGi-INF/blueprint or the
>>>> Bundle-Blueprint: header) to avoid confusion. The JPA container similarly
>>>> still uses the Meta-Persistence header when processing web applications,
>>>> only falling back to Java EE behaviour if there is no header specified.
>>>> Given that there is no existing Java EE behaviour for this I'm not sure we
>>>> should be inventing it.
>>>> 
>>>> I'm also not convinced that blueprint should be able to create the
>>>> servlets. The servlet lifecycle is managed by the web container, and I'm
>>>>  not sure how we could safely break that link without significantly
>>>> changing the behaviour of web applications. The last thing I want to do
>>>> is make web applications "different" when in OSGi, the main point of the
>>>>  original Web Applications specification was that Java EE web
>>>> applications are well
>>>> understood by developers and we want them to have access to the same
>>>> programming model in OSGi.
>>>> 
>>>> I definitely agree with the final point though. I would very much like to
>>>> enable injection of blueprint beans from the Web application's blueprint
>>>> into servlets. It would be really nice if we could re-use the @Resource
>>>> annotation, perhaps with a "blueprint:" URL scheme, but I don't know how
>>>> practical that is. Injecting blueprint beans into servlets would be an
>>>> excellent way to get dependency wiring and service damping and I'm 100% a
+1
>>>> for that part.
>>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Tim
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> 
>>>>> Date: Fri, 19 Nov 2010 10:24:43 +0100
>>>>> From: cmoulliard@gmail.com
>>>>> To: aries-dev@incubator.apache.org
>>>>> Subject: Re: [DISCUSS] WAB and blueprint
>>>>> 
>>>>> Why don't we follow the same approach as spring-dm
>>>>> 
>>>>> So all the blueprint.xml files placed in WEB-INF folder of the WAR (=
>>>>> bundle) will be loaded by the blueprint container at the bundle startup
>>>>> 
>>>>> On 18/11/10 21:37, Guillaume Nodet wrote:
>>>>>> 
>>>>>> I think having a web app packaged as a web application will become
>>>>>> more and more common in OSGi and we should provide an easy way to
>>>>>> leverage blueprint to create the servlets, do some injection of osgi
>>>>>> services into servlets, etc...
>>>>>> As anyone thought about anything in this area yet ?
>>>>>> 
>> 
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com

Mime
View raw message