Our application sends file attachment to a web service using SOAP. The service is running on Oracle Service Bus 11g. We are using Spring WS + SAAJ + MTOM on client to send the request.
The application works fine on local and tomcat server, however, when we move the application to weblogic 12c server (war deployed), we see the following error when we hit the service.
BEA-382120 Error: Mixing of XOP/MTOM and attachments is not allowed!
It seems when it is deployed on the WebLogic the message no longer has MTOM enabled.
========================
Some additional information that might be helpful:
Spring WS configuration, libs used:
spring-ws-1.5.8.jar
commons-httpclient-3.1.jar
Thanks in advance.
After more investigation, it seems that weblogic overrides some of the classes or somehow confuses the classpath. In our case it was Saaj implementation. We had to add the saaj-impl-1.3.20.jar into our class-path and it worked. We also upgraded to spring-ws 2.2.0 and set the mtom to enable on the marshaller from the xml file.
You can also add this jar in your setDomainEnv.cmd file of your weblogic folder
set EXT_PRE_CLASSPATH=%DOMAIN_HOME%\lib\saaj-impl-1.3.20.jar
Related
I have configured and running a weblogic12C server (12.2.1.4.0) on my computer, and I am working with eclipe, where I have a spring boot application with java 1.8.
I need to configure ecplipse to deploy and debug on my local weblogic server.
The problem is that when trying to create the server in Eclipse and indicate what the server will be, its domain and the WAR to deploy, the wizzard says "The server does not support version 4.0 of the J2EE Web module specification."
The strange thing is that my client has a 12C weblogic server (12.2.1.3.0) and I can deploy there without problems via console (ip: 7001 / console).
Any ideas? Will it be a problem with the domain configuration?
Grateful for the answers !!
Some images speak more than a thousand words:
Configuration server weblogic wizzard
Selecting the domain
Indicating that it is a local domain
When trying to move the resource, the wizard tells me that it is not compatible
Checking the domain settings, I don't see anything wrong
According to this document
https://docs.oracle.com/en/middleware/fusion-middleware/weblogic-server/12.2.1.4/wbapp/basics.html#GUID-62B6050D-6DD3-4028-B863-4CD0B5692E7F
WebLogic Server fully supports HTTP servlets as defined in the Servlet 3.1 specification at http://jcp.org/en/jsr/detail?id=340. HTTP servlets form an integral part of the Java EE standard.
It looks like your Eclipse installation is trying to use Java EE version 4, which is not supported by Oracle Weblogic 12.2.1.*
Furthermore, I have found the below post, which I think could be useful to fix your issue.
Project facet Dynamic Web Module 4.0 is not supported by this server
That post explains the issue with Servlet-API version 4.0 and how to configure your IDE to use the version supported by Oracle Weblogic 12.2.1.*
Currently working an application that is moving from JBOSS 4 (java 6) to JBOSS 7.1 (Java 8). It had no REST WS - only SOAP and worked with Servlets.
I added my WAR containing a basic REST Service (ApplicationPath class with 1 resource class and a web.xml (empty since I'm using RESTEasy implementation which should scan my classes)) to the main EAR.
During deployment, I see no errors in my logs and it says my .war has been deployed and my web context registered.
However, whenever I call one of my resource's endpoint I get the default JBOSS response for Error 404 Not Found (the url is correct though) and when I try to call the same URL but by using PUT or POST I get the message "Http Method POST is not supported by this URL" which is typically an error from Custom Servlets.
Is it possible that another Servlet is listening to my path or taking over things? Even if outside of my web context? How could I investigate/debug this?
The problem came from the old RESTeasy Version - 3.0.7-Final that was being used, which has some known bugs with the #ApplicationPath annotation and web.xml configuration. After using the provided version of RESTeasy from the JBOSS 7 (version 3.6.1-SP2), everything worked like a charm.
I'm deploying a .war file built from one of the Spring Boot Getting Started projects, built with Spring Tool Suite. It's a simple RESTful webservice that works on the Tomcat server provided in the Spring Tool Suite running on my PC. The service responds with a string property on a get operation, so it's simple.
I added the Web Fragment Module facet in order to generate a war file. I'm deploying this war to a Weblogic 10.3.5 managed server instance on a test host. The deployment is successful. However, when I use the test URL provided from the Weblogic admin console, I get a 403 forbidden error.
This basic war does not have a web.xml. Should I have one? Should it contain a welcome file reference?
Is there additional configuration that I should do on Weblogic? I am reading the Weblogic documentation.
Summary: I have an SAAJ Client that calls a remote Web Service over HTTPS. Both Client and Server authentication via certificates is required. I can successfully invoke the service when running a JUnit test in my IDE, but fail to connect when running in JBoss.
Keystore/Truststore Configuration Details: In both the IDE and JBoss, I'm setting the keystore and truststore via system properties: javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword, javax.net.ssl.trustStore, javax.net.ssl.trustStorePassword
Logging Configuration: In JBoss, I've enabled SSL Debug logging via the system property: javax.net.debug=SSL. I've also enabled CXF logging via a logging.properties file.
JBoss SSL Logging Output Summary:
SSL logging shows no WARN or ERROR logs
SSL logging shows a session is established at the time of the call to the remote service
JBoss CXF Logging Output Summary:
CXF logging shows that the POST is sent to the service via Conduit null.http-conduit
CXF logging shows this conduit is "configured for plain http", has "No Trust Decider", and has "No Auth Supplier" (I'm not entirely sure what all of this means, but it sounds relevant)
Stack Trace: Here's the actual stack trace I'm getting
Caused by: javax.xml.soap.SOAPException: JBWS024004: SOAP message could not be sent
at org.jboss.wsf.stack.cxf.saaj.SOAPConnectionImpl.call(SOAPConnectionImpl.java:124)
at my.client.soap.MySAAJClient.invoke(MySAAJClient.java:37) [my-client-0.0.1-SNAPSHOT.jar:]
... 17 more
Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '403: Forbidden' when communicating with https://remote.service.url.here/
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1542)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1502)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1309)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627)
at org.jboss.wsf.stack.cxf.saaj.SOAPConnectionImpl.call(SOAPConnectionImpl.java:120)
... 19 more
Other Information
I don't have direct access to the logs of the remote web service, but I'm told that they "don't show anything"
CXF comes into play because it is used by JBoss. I don't have any CXF dependencies included in my project and it's not in play when I run the code in my IDE.
What I've Tried: I've been focused on CXF because again, this all runs fine when executed in my IDE where CXF is not in play and the CXF log that says the conduit has been "configured for plain http" scares me. I've tried including a jboss-cxf.xml, jbossws-cxf.xml, or cxf.xml configuration file in my WAR that includes the keystore and truststore configuration. This has not worked and I can't even tell that CXF is seeing these files.
My Questions (Updated)
Is there any way to get JBoss/CXF to see that this is a secure connection and use the keystore/truststore configured via system properties?
Is there any way for me to direct JBoss (via jboss-deployment-structur.xml maybe?) to use a different SAAJ implementation for my deployment?
Do you have any thoughts on other things I should be looking into?
Update 1
I believe I've confirmed that the JBoss-CXF integration is the issue. I was able to remove JBoss's SOAPConnectionImpl by modifying the file {JBOSS_HOME}/modules/system/layers/base/org/jboss/ws/saaj-impl/main/module.xml. I commented out the module dependency <module name="org.jboss.ws.jaxws-client" services="import"/>.
After making this change, my application was able to connect to the remote service with no issues.
Although this shows that the JBoss-CXF integration is this issue, I can't modify the deployment environment in this way. I need to identify another solution.
I'd go for system properties (or at least knowing the configuration of the system) as they might override whatever you specify in your deployment.
What version of cxf is used on the deployment environment? Do you have any info on the configuration of cxf on your deployment environment? From the documentation (http://cxf.apache.org/docs/ws-security.html), I can see you need to configure WSS4J interceptors for cxf 2.0.x or earlier, so you could check if this is okay on your deployment environment.
I have an application tomcat + apache + mod_jk + spring mvc deployed on remote server. After making request to the controller I am having jsp source code in the response. It is not related with spring config cause locally it is working. After debugging mod_jk I see that tomcat returns jsp source.
I think the problem is related with remote tomcat or apache (cause it was configured by our it department). Is it possible to dissalow jsp execution on tomcat or apache (maybe httpd conf)? Plese suggest how can resolve this problem.
Apache Web Server does not execute JSPs, so you're probably getting your JSP from there.
Normally, static files are deployed on Apache Web Server, and dynamic files (JSPs, Custom Tags, classes, etc.) are deployed on Apache Tomcat (where Apache Web server redirects the corresponding requests). Check if your app is deployed this way.
Try to send an HTTP request directly to the Apache Tomcat (without intervention of Apache Web Server, and see what happens)
The reason was that jsp compiler was disabled see org.apache.jasper.servlet.JspServlet, in the tomcat\conf\web.xml. It-team says that it is recommend option for production)