I think Peter's solution is a nice one, as spring (and blueprint) has the ability to wait until all services are satisfied before actually creating the full spring app. That would only work if you need it that way though (i.e. spring app started after the web app).
On Mon, Jun 25, 2012 at 4:14 PM, Raman Gupta <rocketra...@gmail.com> wrote: > Thanks Guillaume and Achim... I will investigate the manual > synchronization route. Does Pax-web initialize each servlet > synchronously? If so, I can create a dummy servlet that initializes > before the main servlet that can wait for the initialization of the > Spring context. > > I also found this post by Peter Krien's responding to a similar query > from someone on the Felix mailing list, and suggesting a similar solution: > > http://mail-archives.apache.org/mod_mbox/felix-users/201004.mbox/%3cf5b8b3e9-5602-4caf-9d4f-904fb947b...@aqute.biz%3E > > In Krien's solution, rather than manually detecting when a Spring bean > has been initialized, I believe he his suggesting exposes the servlet > itself as a service from the Spring context. When this service is > available, the dummy servlet being initialized by the web extender > "sees" it and proceeds (I guess this would depend on Pax-Web > processing the dummy servlet first and synchronously). > > If that approach works, that would be some functionality that Pax-Web > could use to manage this issue with requiring changes in other > extenders. A manifest header could control whether Pax-Web waits for > some service to be available before proceeding with the servlet > initialization. This would skip the need to manually create the dummy > servlet. > > Regards, > Raman > > > On 06/25/2012 04:12 AM, Achim Nierbeck wrote: >> Hi >> >> I just can second Guillaume here, there is only one more thing that >> crosses my mind. >> Pax Web needs to support Injecting OSGi Services into the Servlets, >> see also [1]. >> But as usual this kind of stuff is needed much earlier then implemented :) >> >> regards, >> >> [1] - http://team.ops4j.org/browse/PAXWEB-367 >> >> 2012/6/25 Guillaume Nodet <gno...@gmail.com>: >>> That's a quite big problem and I'm not really aware of any way to >>> control the extender execution order. >>> The reason is that each extender can work synchronously or >>> asynchronously and there's no coordination between them, there's not >>> even a way to specify such a thing. >>> I can only see two ways out: >>> * enhance the extenders to better cooperate, but this would require >>> enhancing all the extenders and defining some metadata to control such >>> an order (given anyone can write an extender, this would be better if >>> we had a spec for that) >>> * do the synchronization on your own, i.e. you can detect using a >>> spring bean when the spring app will be processed and from a servlet >>> when the web app stuff will be kicked, then make sure one is waiting >>> for the other. >>> >>> The last option is the easiest one to achieve obviously, but will be >>> really tied to the extenders your using and how they behave, as if >>> both are started synchronously, you won't really have any way to do >>> some synchronization here, but iirc that's not the case here. >>> >>> On Mon, Jun 25, 2012 at 6:21 AM, Raman Gupta <rocketra...@gmail.com> wrote: >>>> I just upgraded to Karaf 2.2.7 from Karaf 2.2.4 and noticed that now >>>> the Spring DM web extender and pax web extender's no longer run in the >>>> correct order. >>>> >>>> The Spring-DM extender needs to process the bundle *before* the PaxWeb >>>> extender, since until the app context is created by Spring-DM it is a >>>> non-functional web bundle. If Pax Web attempts to process it first, >>>> there is an error about the Spring context not existing when the >>>> servlet tries to initialize. >>>> >>>> A manual refresh of the bundle is required to fix the problem. >>>> >>>> One difference I can see between 2.2.4 and 2.2.7 is that the start >>>> level of the pax bundles is different. In Karaf 2.2.4, the pax bundles >>>> started at the default start level which was 60, but in 2.2.7 the war >>>> feature specifies they start at the same level as the Spring-DM >>>> bundles, which is 30. I don't know if that is the underlying problem >>>> though. >>>> >>>> Is there a way to control the order of the extender execution? If not, >>>> what is the best work-around? >>>> >>>> Regards, >>>> Raman >>> >>> >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> FuseSource, Integration everywhere >>> http://fusesource.com >> >> >> -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
