The best explanation I can give is that, within a given webapp (a.k.a. the scope of a ServletContext), CXF typically thinks it's in total control. However, Aries JAX-RS Whiteboard (from now AJW) is based on HTTP Whiteboard. It is the whiteboard that is in control of all ServletContexts, therefore AJW has to play nice and work under those conditions.
Since AJW 2.x is what is bringing along CXF dependencies (as opposed to embedding them as it did in 1.x) it needs to ask CXF to not be so pedantic about its control. HTH On Fri, Jun 17, 2022 at 5:32 AM Alain Picard < apic...@benchmarkconsulting.com> wrote: > So far the best I found about the use of this setting is this: > https://www.mail-archive.com/dev@cxf.apache.org/msg16664.html but can't > find any follow up issue on CXF or details about what happened after. > > Alain > > > On Thu, Jun 16, 2022 at 5:50 PM Alain Picard < > apic...@benchmarkconsulting.com> wrote: > >> Raymond, >> >> It does something. The logged errors are gone and a few quick tests and >> so far all is working, and the endpoint resolved during debug matches >> expectations. >> >> What does it do? >> >> Alain >> >> >> >> On Thu, Jun 16, 2022 at 5:16 PM Raymond Augé <raymond.a...@liferay.com> >> wrote: >> >>> Hi Alan, >>> >>> Sorry you're having issues. >>> >>> Could you try setting this system property >>> `org.apache.cxf.osgi.http.transport.disable=true` and let me know if that >>> does anything? >>> >>> On Thu, Jun 16, 2022 at 3:17 PM Alain Picard < >>> apic...@benchmarkconsulting.com> wrote: >>> >>>> Hi, >>>> >>>> I attempted to upgrade our version of Aries JAX RS whiteboard and other >>>> related bundles from 1.0.1 to 2.0.1 (CXF mostly from 3.2.7 to 3.5.2) >>>> >>>> After the upgrade, I started getting a number of messages like this in >>>> my log: >>>> 15:05:32.387 [ConfigurationListener Event Queue] ::: WARN >>>> o.a.a.j.r.w.i.AriesJaxrsServiceRuntime - Resource CachingServiceReference >>>> { >>>> cachedProperties={osgi.jaxrs.application.select=(osgi.jaxrs.name=GeomapRestApp), >>>> service.scope=bundle, osgi.jaxrs.name=CommonGeoMapRESTService, >>>> osgi.jaxrs.extension.select=null (cached), >>>> osgi.jaxrs.whiteboard.target=null (cached)} >>>> serviceReference={com.castortech.iris.zk.geomap.service.rest.CommonGeoMapRESTService}={osgi.jaxrs.resource=true, >>>> service.id=2234, service.bundleid=9, service.scope=bundle, >>>> osgi.jaxrs.application.select=(osgi.jaxrs.name=GeomapRestApp), >>>> osgi.jaxrs.name=CommonGeoMapRESTService, >>>> osgi.ds.satisfying.condition.target=(osgi.condition.id=true), >>>> component.name=com.castortech.iris.zk.geomap.service.rest.CommonGeoMapRESTService, >>>> component.id=45} >>>> } is registered with error >>>> 15:05:32.388 [ConfigurationListener Event Queue] ::: ERROR >>>> o.a.a.j.r.w.internal.Whiteboard - ServiceReference CachingServiceReference >>>> { >>>> cachedProperties={osgi.jaxrs.application.select=(osgi.jaxrs.name=GeomapRestApp), >>>> service.scope=bundle, osgi.jaxrs.name=CommonGeoMapRESTService, >>>> osgi.jaxrs.extension.select=null (cached), >>>> osgi.jaxrs.whiteboard.target=null (cached)} >>>> serviceReference={com.castortech.iris.zk.geomap.service.rest.CommonGeoMapRESTService}={osgi.jaxrs.resource=true, >>>> service.id=2234, service.bundleid=9, service.scope=bundle, >>>> osgi.jaxrs.application.select=(osgi.jaxrs.name=GeomapRestApp), >>>> osgi.jaxrs.name=CommonGeoMapRESTService, >>>> osgi.ds.satisfying.condition.target=(osgi.condition.id=true), >>>> component.name=com.castortech.iris.zk.geomap.service.rest.CommonGeoMapRESTService, >>>> component.id=45} >>>> } for endpoint produced error: {} >>>> org.apache.cxf.service.factory.ServiceConstructionException: There is >>>> an endpoint already running on /. >>>> at >>>> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:89) >>>> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130) >>>> >>>> AFAICT, essentially one for each app/service that we have. >>>> >>>> I did inspect the runtimeDTO and it is different a bit, but it does >>>> list all of the expected services and is quite similar to the original one. >>>> >>>> I put some debugging at the authentication level, and when looking >>>> further up at the transport ServletController.invoke method, what I do see >>>> is that the destination resolution is quite similar, but the endpoint in >>>> the new one doesn't even match the calling service, which then wreak havoc >>>> all over the place. >>>> >>>> At this point I'm not sure where to look or what other details to >>>> include here to provide valuable input. So don't hesitate if I need to run >>>> other tests or supply additional information. >>>> >>>> Cheers, >>>> Alain >>>> >>>> >>> >>> -- >>> *Raymond Augé* (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* (@Liferay) >>> OSGi Fellow, Java Champion >>> >> -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
