Oxygen XML Forum

I am working on a plugin that connects to a small ecosystem of Spring microservices using Eureka and Feign. I am seeing an odd issue where I call an endpoint that uses the DELETE http method, and I see that Oxygen sends the correct request followed closely by a second request using the same URL, only with the GET method. This second request is then getting a 405 response from the remote server, which ends up throwing errors in my plugin. This does NOT happen when calling endpoints that use GET, PUT, or POST methods.

Attached a Wireshark screen grab to show that there are in fact 2 requests. They occur in 2 different TCP streams. Details:
We're using the Oxygen 26.1 SDK currently.
The plugin structure consists of a Workspace Access Plugin, which loads an independent Spring Boot module on application start.
The spring module runs in a separate thread, and there are wrapper classes to provide static access into the spring context and the feign client interfaces.
The component where I am seeing the issue is actually a custom LockHandler implementation, calling the unlock method, which then asks the Spring backend to make a request to the releaseLock endpoint.

I am wondering if this has anything to do with the HttpClient getting selected by Oxygen to build the feign client? For instance I noticed the WebdavHttpURLConnection in the trace below.

Stack Trace:

ro.sync.net.protocol.http.b.s.x(Unknown Source)
ro.sync.net.protocol.http.b.s.c(Unknown Source)
ro.sync.net.protocol.http.abstraction.n.r(Unknown Source)
ro.sync.net.protocol.http.abstraction.n.e(Unknown Source)
ro.sync.net.protocol.http.WebdavHttpURLConnection.obtainResponse(Unknown Source)
ro.sync.net.protocol.http.WebdavHttpURLConnection.getInputStream(Unknown Source)
feign.Client$Default.convertResponse(Client.java:135)
feign.Client$Default.execute(Client.java:107)
org.springframework.cloud.openfeign.loadbalancer.LoadBalancerUtils.executeWithLoadBalancerLifecycleProcessing(LoadBalancerUtils.java:56)
org.springframework.cloud.openfeign.loadbalancer.LoadBalancerUtils.executeWithLoadBalancerLifecycleProcessing(LoadBalancerUtils.java:91)
org.springframework.cloud.openfeign.loadbalancer.FeignBlockingLoadBalancerClient.execute(FeignBlockingLoadBalancerClient.java:134)
feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:100)
feign.SynchronousMethodHandler.invoke(SynchronousMethodHandler.java:70)
feign.ReflectiveFeign$FeignInvocationHandler.invoke(ReflectiveFeign.java:99)
jdk.proxy3/jdk.proxy3.$Proxy132.cmsReleaseLockById(Unknown Source)
com.gc.oxygenspringbackend.pluginaccess.CMSAccess.releaseLock(CMSAccess.java:32)
com.gc.oxygenplugin.protocolhandler.CustomLockHandler.unlock(CustomLockHandler.java:44)
ro.sync.exml.editor.kf.q(Unknown Source)
ro.sync.exml.editor.kf$1.bkg(Unknown Source)
ro.sync.ui.application.kb.run(Unknown Source)

Just wanted to add that I suspect this is happening in code outside of my control because when I run the exact same code using a POST method instead (literally only changing @DeleteMapping to @PostMapping in my feign client interface of the plugin backend, and adding a new POST endpoint to the external microservice), I only see a single request come across Wireshark. This is our workaround for the time being. I'm just stumped what to do if we ever need a DELETE request and don't have the ability to change the external microservice.

Hi,
Indeed Oxygen installs its own HTTP/HTTPS protocol handler internally and uses its own WebdavHttpURLConnection which may work a bit differently from the Java Oracle base URL connection handler.
I added an internal issue to explore this further on our side, pasting the issue ID below for future reference:

EXM-55359 WebdavHttpUrlConnection seems to issue extra GET request for DELETE request

We'll reply back on this thread if we manage to fix this in a future Oxygen version.
We do have this plugin extension point which would allow you for a certain host name to force using the SUN URL connection implementation for example:
https://www.oxygenxml.com/doc/versions/ ... lugin.html

Regards,
Radu

Hi,
As an update, we released Oxygen 27.1 which should have a fix for this reported problem.
Regards,
Radu