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.
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 !!
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<[email protected]> 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: [email protected]
To: [email protected]
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 ?
