Thanks Raymond, it sure does help greatly. Alain
On Fri, Jun 17, 2022 at 11:11 AM Raymond Augé <raymond.a...@liferay.com> wrote: > 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 >
