What seems to be going on is that in order to use JSON with Axis2, it requires special tweaks to your services.xml file i.e. JSON support for Moshi is not on by default.
What I do in your situation, is start with the tutorial on enabling a full application based on JSON and then add Corba to that. Use the services.xml in the tutorial as a start, is my suggestion. From there, if you are stuck on Corba I can probably help. I never used Corba though I likely know enough about it to debug. https://axis.apache.org/axis2/java/core/docs/json-springboot-userguide.html On Tue, Aug 26, 2025 at 2:17 AM Serban Mihai <[email protected]> wrote: > Hi again, thanks for the response and sorry for my late reply. The problem > I'm having is that I would like to use Moshi (because of the simplified > JSON syntax) instead of Badgerfish, however I still haven't managed to > figure out how to make it work with a Corba service. > I attached the axis2.xml file and the SysM_axis_NOAdmin.xml file. > > Could a Corba service's xml file be handled differently than the usual > services.xml file? > As mentioned above, I tried the "mappings" parameter: > <parameter name="xmlToJsonNamespaceMap"> > <mappings> > <mapping xmlNamespace="http://SM/xsd"; jsonNamespace=""/> > </mappings> > </parameter> > > However I am still getting errors: > Request 1: > $ curl -H "Content-Type: application/json" -d '{"getMgrIPs": {"MgrIPs: > ""}}' https://<ip>/AXIS/services/SysM/*getMgrIPs* > {"Fault":{"faultcode":"soapenv:Server","faultstring":"Cannot invoke > \"org.apache.axiom.om.OMElement.getNamespace()\" because \"methodElement\" > is null","detail":""}} > > Request 2 (URL does not include operation): > $ curl -H "Content-Type: application/json" -d '{"getMgrIPs": {"MgrIPs: > ""}}' https://<ip>/AXIS/services/SysM > {"Fault":{"faultcode":"nsIDc08:Client","faultstring":"The endpoint > reference (EPR) for the Operation not found is https://<ip>/AXIS/services/SysM > and the WSA Action = null. If this EPR was previously reachable, please > contact the server administrator.","detail":""}} > > Some more context: > The service I am trying to reach is called SysM and is at > <ip>/AXIS/services/SysM. > The method I am trying to invoke is: (as defined in the IDL file) > > module SM { > /*...*/ > interface NOAdmin { > /*...*/ > short getMgrIPs(inout StringList MgrIPs) > raises (NOException); > }; > }; > > Is this a misconfiguration on my part or could a difference in service xml > handling be the cause of this issue? Do you have any insight on what I > could try next? > > On Wed, Jun 25, 2025 at 8:19 PM robertlazarski <[email protected]> > wrote: > >> Did you set up your axis2.xml file for badgerfish? Can you post it, if >> you edited it? The axis2.xml file is the place to customize optional >> features like these. >> >> I don't use badgerfish myself - but I read that doc a lot as I use the >> later introduced JSON support with GSON / Moshi quite a bit. >> >> Unless you have a reason to use Badgerfish, I suggest Moshi though the >> GSON support is nearly identical. >> >> >> >> >> On Wed, Jun 25, 2025 at 12:19 AM Serban Mihai <[email protected]> >> wrote: >> >>> Hello all, >>> >>> Over the past few weeks we have spent some time migrating our corba >>> services to webservices using Axis2. We managed to enable JSON support >>> using the Badgerfish convention and, since it does not require any >>> additional configuration, it worked as expected just by following the >>> documentation. However, due to the enhanced readability of the Mapped >>> convention in our use-case it would be preferrable - but we are facing some >>> issues. >>> >>> I have tried following the documentation: update axis2.xml, then add the >>> following to the "SysM.xml" file (which corresponds to the "SysM.idl" file): >>> <mappings> >>> <mapping xmlNamespace="http://SM/xsd <http://sm/xsd>" >>> jsonNamespace=""/> >>> </mappings> >>> >>> But this does not seem to have any effect, since on this request: >>> $ curl -H 'Content-Type: application/json' -d >>> '{"geMgrIPs":{"MgrIPs":""}}' https://<ip>/AXIS/services/SysM >>> >>> I am getting this error (see full error at the end of this email): >>> {"Fault":"<soapenv:Fault xmlns:soapenv=\" >>> http://schemas.xmlsoap.org/soap/envelope/\ >>> "><faultcode>soapenv:Server<\/faultcode><faultstring>*namespace >>> mismatch require http://SM/xsd <http://sm/xsd> found none* >>> <\/faultstring><detail>...<\/detail><\/soapenv:Fault>"} >>> >>> I notice that the error is related to the namespace and is returned in >>> JSON format - to me this would mean that JSON Mapped convention handling is >>> enabled, however the namespace is not mapped accordingly. It seems that the >>> SysM.xml file is not an equivalent of the "services.xml" file - does it >>> only handle the corba-specific fields? Is there a way to enable the Mapped >>> convention on corba services? >>> >>> Any insight on this issue would be much appreciated. >>> >>> Thank you, >>> Serban >>> >>> Maybe useful: >>> *Working example with Badgerfish convention:* >>> Request: >>> $ curl -H 'Content-Type: text/json' -d '{"xsl:getMgrIPs": {"@xmlns": >>> {"xsl": "http://SM/xsd <http://sm/xsd>"}, "MgrIPs": {"$":""}}}' https:// >>> <ip>/AXIS/services/SysM >>> >>> Response: >>> {"ns:getMgrIPsResponse":{"@xmlns":{"ns":"http://SM/xsd <http://sm/xsd> >>> "},"return":{"$":"0"},"MgrIPs":{"item":[{"@xmlns":{"$":"http://SM/xsd >>> <http://sm/xsd>"},"$":"<ip0>"},{"$":"<ip1>"},{"$":"<ip2>"}]}}} >>> >>> *The full error taken from the logs:* >>> ERROR [2025-06-23 14:28:48,614] [org.apache.axis2.util.OnDemandLogger] - >>> processAxisFault() on error message: namespace mismatch require >>> http://SM/xsd <http://sm/xsd> found none , found a null HTTP status >>> from the MessageContext instance, setting HttpServletResponse status to >>> HttpServletResponse.SC_INTERNAL_SERVER_ERROR >>> org.apache.axis2.AxisFault: namespace mismatch require http://SM/xsd >>> <http://sm/xsd> found none >>> at >>> org.apache.axis2.corba.receivers.CorbaMessageReceiver.invoke(CorbaMessageReceiver.java:102) >>> ~[axis2-corba-2.0.0.jar:2.0.0] >>> at >>> org.apache.axis2.corba.receivers.CorbaMessageReceiver.invokeBusinessLogic(CorbaMessageReceiver.java:53) >>> ~[axis2-corba-2.0.0.jar:2.0.0] >>> at >>> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40) >>> ~[axis2-kernel-2.0.0.jar:2.0.0] >>> at >>> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:106) >>> ~[axis2-kernel-2.0.0.jar:2.0.0] >>> at >>> org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:169) >>> ~[axis2-kernel-2.0.0.jar:2.0.0] >>> at >>> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:181) >>> ~[axis2-transport-http-2.0.0.jar:2.0.0] >>> at >>> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:175) >>> [axis2-transport-http-2.0.0.jar:2.0.0] >>> at >>> jakarta.servlet.http.HttpServlet.service(HttpServlet.java:590) >>> [tomcat-servlet-6.0-api.jar:6.0] >>> at >>> jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) >>> [tomcat-servlet-6.0-api.jar:6.0] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:195) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) >>> [tomcat-websocket.jar:10.1.34] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:164) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:483) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) >>> [catalina.jar:10.1.34] >>> at >>> org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:431) >>> [tomcat-coyote.jar:10.1.34] >>> at >>> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63) >>> [tomcat-coyote.jar:10.1.34] >>> at >>> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:905) >>> [tomcat-coyote.jar:10.1.34] >>> at >>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1741) >>> [tomcat-coyote.jar:10.1.34] >>> at >>> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52) >>> [tomcat-coyote.jar:10.1.34] >>> at >>> org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1190) >>> [tomcat-util.jar:10.1.34] >>> at >>> org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) >>> [tomcat-util.jar:10.1.34] >>> at >>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63) >>> [tomcat-util.jar:10.1.34] >>> at java.base/java.lang.Thread.run(Thread.java:858) [?:?] >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
