OK, I guess I'm starting to understand your scenario :)
well, Pax-Web does pretty much the same as a std. WebContainer, so if you
don't register your servlets in the web.xml they aren't found
and therefore it might work to just register those Servlets with DS.
Regarding the proprietary extensions by GlassFish, sounds interesting and
it maybe could be done, though I'm not sure if Pax Web should start to act
as a di implementation.
But maybe something the like can be done with blueprint and pax-web
2.0.0-SNAPSHOT. Pax Web 2.0.0-SNAPSHOT supports Servlet 3.0 annotations for
Servlets.
But this would require you to step back from DS and registering your
serlvets.
regards, Achim
2011/12/8 Gerard Maas <gerard.m...@gmail.com>
> Hi Achim,
>
> Thanks for your msg.
>
> We have "a bunch" of servlets doing the back-end work for a GWT
> application.
> A WAR is a good way to keep them all packed and have a coherent
> deployment. Some of them need to use other OSGi services, some not. The
> ones having dependencies on other OSGi services were looking them up using
> ServiceTracker.
>
> But now that I've moved most of the code from programmatic to DS, it seems
> to me like an acceptable use case to inject service dependencies on the
> servlets using DS, but then, I'm confronted with the PAX-WEB vs OSGi
> services lifecycle issues.
> In particular, when new instances of a servlet are created, DS should be
> used to inject the dependencies sothat non-singleton services can be
> correctly instantiated and thread safety can be then ensured without the
> use of synchronization primitives.
>
> Having some servlets on the WAR and some registering the HTTP service
> using DS would create configuration fragmentation in my app. I recon that
> having DS on some servlets is a lesser case of such configuration
> fragmentation as well, but I consider it the lesser of two evils compared
> to the overhead of the ServiceTracker boilerplate.
>
> For example, I've found that GlassFish Server provides some proprietary
> extensions to do exactly what we're discussing here [1]:
>
> @WebServlet
> public class MyServlet extends HttpServlet {
> @Inject @OSGiService(dynamic=true)
> FooService fooService;
> }
>
> My excuses if I'm missing some point. I'm rather new to OSGi as a back-end
> service platform.
>
> I'm running Equinox
>
> kr, Gerard.
>
> [1] http://docs.oracle.com/cd/E18930_01/html/821-2418/gkqff.html
>
> On Wed, Nov 30, 2011 at 9:07 PM, Achim Nierbeck
> <bcanh...@googlemail.com>wrote:
>
>> Hi Gerard,
>>
>> ok, one question for you, why do you need a war since you do seem to
>> register your Servlets throught the "HTTP-Service" way with DS?
>> If you do so I'm pretty sure a std. bundle is valid enough.
>>
>> regards, Achim
>>
>> 2011/11/29 Gerard Maas <gerard.m...@gmail.com>
>>
>>> Hi all,
>>>
>>> I've been looking for info on this topic with no avail.
>>> I'm currently using PAX-Web (Pax Web - WAR Extender) to run a number of
>>> servlets in a WAB. I'm working on Equinox. Legacy code used programmatic
>>> service lookup to access other OSGi services (Service Tracker) but I've
>>> refactored most of the code base to use Declarative Services instead. (that
>>> solved several start-up order issues in the process)
>>>
>>> My issue is that Declarative Services dependency injection is not
>>> working with PAX-Web loaded servlets. If I include a OSGI-INF/service.xml
>>> file declaring the servlet dependencies, the class is loaded twice: Once by
>>> DS and once by PAX-WEB. Logically, only the class loaded by DS is injected
>>> with any dependencies declared.
>>> DS:
>>> at org.eclipse.equinox.internal.ds.model.ServiceComponent.*
>>> createInstance*(ServiceComponent.java:480)
>>> at
>>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.createInstance(ServiceComponentProp.java:271)
>>> at
>>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:332)
>>> at
>>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588)
>>> at
>>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196)
>>> at
>>> org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:328)
>>> at
>>> org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:221
>>>
>>> PAX-WEB:
>>> at org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisitorHS.*
>>> newInstance*(RegisterWebAppVisitorHS.java:225)
>>> at
>>> org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisitorWC.visit(RegisterWebAppVisitorWC.java:202)
>>> at
>>> org.ops4j.pax.web.extender.war.internal.model.WebApp.accept(WebApp.java:583)
>>> at
>>> org.ops4j.pax.web.extender.war.internal.WebAppPublisher$HttpServiceListener.register(WebAppPublisher.java:170)
>>> at
>>> org.ops4j.pax.web.extender.war.internal.WebAppPublisher$HttpServiceListener.serviceChanged(WebAppPublisher.java:155)
>>> at
>>> org.ops4j.pax.web.extender.war.internal.WebAppPublisher$HttpServiceListener.serviceChanged(WebAppPublisher.java:119)
>>> at
>>> org.ops4j.pax.swissbox.tracker.ReplaceableService.setService(ReplaceableService.java:114)
>>> at
>>> org.ops4j.pax.swissbox.tracker.ReplaceableService.access$100(ReplaceableService.java:28)
>>> at
>>> org.ops4j.pax.swissbox.tracker.ReplaceableService$CollectionListener.serviceAdded(ReplaceableService.java:183)
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceCollection$Tracker.addingService(ServiceCollection.java:181)
>>>
>>> I worked around this situation by declaring the references to the
>>> services static and synchronizing the access (not very nice. Might impact
>>> performance),
>>>
>>> eg.
>>> public synchronized void onServiceUp(FooService svc) {
>>> ClassImpl.fooService = svc;
>>> }
>>>
>>>
>>> but I've a situation now where I do need an instance of a service
>>> injected for each servlet instance created, so the synchronized hack
>>> approach won't work.
>>>
>>> I also tried to declare the servlet and its dependecies using the OSGi
>>> way, by declaring this servlet to offer a javax.servlet.Servlet service:
>>> [ <property name="alias" type="String" value="/main/fooservice"/>
>>> <property name="servlet-name" type="String" value="FooServlet"/ -->
>>> <service>
>>> <provide interface="javax.servlet.Servlet"/>
>>> </service>]
>>>
>>> But given that the servlet is also in the WAR, PAX-Web finds it and
>>> tries to register it, resulting in a 'WAR: Http context already used' like
>>> described here:
>>> http://www.mail-archive.com/general@lists.ops4j.org/msg11221.html
>>>
>>> So, to summarize my question: Is there a correct/recommended way to use
>>> Declarative Services (DS) with Pax Web- War extender and if so, what are
>>> the best practices?
>>>
>>> Many thanks,
>>>
>>> Gerard.
>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general@lists.ops4j.org
>>> http://lists.ops4j.org/mailman/listinfo/general
>>>
>>>
>>
>>
>> --
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>>
>> _______________________________________________
>> general mailing list
>> general@lists.ops4j.org
>> http://lists.ops4j.org/mailman/listinfo/general
>>
>>
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
>
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
