When adding / updating a response header after the request has been processed I get the following warning:
com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
I am trying to manipulate the header by calling httpServletResponse.setHeader() or httpServletResponse.addHeader() from within a servlet filter after filterChain.doFilter() or by postHandle code spring interceptor.
I have encountered this problem while running my webapp using spring 3.x on websphere 8.5.
The problem is not reproduced on tomcat 7.0 therefore my guess is that it is Websphere related.
The problem is not reproduced in a pure servlet app therefore my guess is that it is Spring related.
I am familiar with
ShallowEtagHeaderFilter does not work under WAS8 app server
and with
Cannot set header in JSP. Response already committed
but I am looking for a "cleaner" solution.
Can anybody help me on this?
Websphere strictly follows the J2EE standard, hence whatever works in Tomcat need not necessarily work in Websphere. In my project, I got a lot of exception/errors which are particular for Websphere, but works as a charm in Tomcat. I suggest you to set the header in the controller. One other alternate is not to flush the output stream in the controller (if you have done it explicitly).
Related
I'm trying to build a Java service that other services could call.
This service is not a WS, but is calling a RestfulWS.
I'm really just building a wrapper around this call. This would find the correct data it needs, set up the JSON for the call. Get a response and send it back up.
Was told to use Jersey for this. Trying to set up all the pom.xml to use Jersey.
Building code works fine, it is when the deploy to the server happens that things fail.
I get the error -- "JBAS011232: Only one JAX-RS Application Class allowed. "
I don't have a web.xml, which I guess is used to skip some ResetEasy files.
I do have exclusions in pom.xml and jboss-deployment-structure.xml.
I still get the error when deploy happens. Not really sure what else to check.
It looks like you have a problem with JAX-RS dependencies. JBoss already has its own implementation of JAX-RS and probably that’s causing the issue. Some solutions are already suggested here Jboss error: Only one JAX-RS Application Class allowed
When i call the context root of my spring-boot application "localhost:8080/api/players", which is mapped in a RestController method by the annotation #GetMapping(path= {"/",""}), undertow alway redirect (httpstatus: 307 Temporary redirect) to "localhost:8080/api/players/" adding trailing slash at the end.
My application context-root is indeed /api/players as defined in spring-boot application.properties file (server.servlet.context-path=/api/players)
I've tried with embedded-tomcat and it works correctly by setting the property server.tomcat.redirect-context-root=false
There is a way to configure undertow to act like tomcat?
Peering into the sourcecode for undertow a bit, it looks like the relevant code is here in ServletInitialHandler.java, which will issue a 307 redirect status code in the case that the request is an upgrade request... unless the request is an HTTP 2 upgrade request. This doesn't seem to be configurable by the server, although there is some attempt to avoid the redirect based on what the client does.
It's probably worthwhile to look at your HTTP requests, understand better if your HTTP client is actually making an upgrade request, and then consider either accepting this fact, or changing the client to make a different kind of request (possibly by making it send the HTTP2 upgrade request header).
Tried using DistributedObjectCache for sharing data between clusters in WAS liberty server.
I have configured things based on IBM Distributed Map
I used Method 5 from the link, my server version is 7 and web.xml version is 2.4
After the configurations on my "server.xml" and ibm-web-bnd.xmi, I have used the below code to get the map instance on the application start.
DistributedObjectCache dm1a =(DistributedObjectCache)ic.lookup("java:comp/env/dmap/LayoutCache");
the dm1a is always null
As the servlet cache is used for caching JSP pages. etc, I need to cache java object so I used DistributedObjectCache
I am not sure that the .xmi file is getting read by the server, because I have tested by changing the webapp reference in there which was different from web.xml, but no error was thrown on the server startup
Is there anything i am missing?
I'm running jboss-4.2.1.GA to generate WS requests.
I have created the WS client with the help of JWSDP-2.0/JAXRPC. I have deployed the client to Jboss and I am now trying to send requests.
When I try to initialise the client service: javax.xml.rpc.Service service = servicefactory.createService(new URL(wsdlURL), serviceQN), Jboss starts to complain.
The error that Jboss generates is:
ERROR [JBossXSErrorHandler]
JBossWS_targetnamespace1.com7796329154971783225.xsd[domain:http://www.w3.org/TR/xml-schema-1]::[key=src-resolve.4.2]::Message=src-resolve.4.2:
Error resolving component
'tns2:SimpleSerialiser'. It was
detected that 'tns2:SimpleSerialiser'
is in namespace
'http://targetnamespace2.com', but
components from this namespace are not
referenceable from schema document
'file:/home/jbossPath/jboss-4.2.1.GA/server/default/tmp/jbossws/JBossWS_targetnamespace1.com7796329154971783225.xsd'.
If this is the incorrect namespace,
perhaps the prefix of
'tns2:SimpleSerialiser' needs to be
changed. If this is the correct
namespace, then an appropriate
'import' tag should be added to
'file:/home/jbossPath/mobaq/jboss-4.2.1.GA/server/default/tmp/jbossws/JBossWS_targetnamespace1.com7796329154971783225.xsd'.
Followed by a warning:
WARN [WSDL11Reader] Encoding style
'http://schemas.xmlsoap.org/soap/encoding/'
not supported for:
{urn:namespace}doTask
Finally, the following error is displayed:
ERROR [STDERR]
org.jboss.ws.WSException: Cannot
obtain java type mapping for:
{urn:namespace}ArrayOf_tns2_TagType
ERROR [STDERR] at
org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.buildInputParameter(JAXRPCMetaDataBuilder.java:266)
...
...
I know that a similar error has been posted in community.jboss.org in the past but for a different task. I am not sure if the patch provided will solve my issue and I don't know how to implement the patch provided.
In addition to this, I have found someone having similar issues: JAX-RPC in JBoss 4.2.3 but the suggested solution does not work for me.
I also know that JbossWS does not support RPC/Encoded but I use jboss for my solution.
Is there a way for me to get around this issue, can I not get Jboss to create the client service to send requests? I'm not sure requesting a RPC/Literal WSDL file is a possibility so that's why I am asking.
Any suggestions will be greatly appreciated.
http://schemas.xmlsoap.org/soap/encoding/ is a legacy style used by very old web service stacks (it's so bad, even Microsoft recommend against it). It was seriously flawed, and so was excluded from the WS-I interoperability spec, which most modern Java web service stacks implement.
The only java stack that I know of that handles these old encoding is Axis 1, which is itself seriously flawed, but may be your only option. You should be able to run Axis as a client from inside JBoss.
I finally solved the issue by implementing the solution suggested from JAX-RPC in JBoss 4.2.3 post:
To jump to the chase, I simply put the following JARs from Axis 1.4 in my EAR's lib directory:
axis.jar, axit-ant.jar, commons-discovery-0.2.jar, jaxrpc.jar, saaj.jar, wsdl4j-1.5.1.jar
What I was doing was putting the above jars with my own WS Client jar file and that's why it didn't work. The solution was there, in front of me in black and white and I didn't implement it properly. That's the problem when looking too closely to an issue for too long.
I am a numpty.
I need to prevent Session Fixation, a particular type of session hijacking, in a Java web application running in JBoss. However, it appears that the standard idiom doesn't work in JBoss. Can this be worked around?
This defect (found here) points the way to the solution. The Tomcat instance that runs in JBoss is configured with emptySessionPath="true", rather than "false", which is the default. This can be modified in .../deploy/jboss-web.deployer/server.xml; both the HTTP and AJP connectors have this option.
The feature itself is used to eliminate the context path (eg. "foo" in http://example.com/foo) from being included in the JSESSIONID cookie. Setting it to false will break applications that rely on cross-application authentication, which includes stuff built using some portal frameworks. It didn't negatively affect the application in question, however.
This problem and the specific case in which it occurs is a problem in Tomcat as well as JBoss. Tomcat shares the emptySessionPath="true" effect (and actually JBoss inherits it from Tomcat).
This really seems like a bug in Tomcat and JBoss when you are trying to prevent session fixation attacks but the servlet spec (at least version 2.3) does not actually require the JSESSIONID to be defined or redefined according to any specific logic. Perhaps this has been cleaned up in later versions.
One workaround is to store the client address in the session. A response wrapper should validate the client address set in the session is same as the one accessing the session.
I came to know below code setting snippet from one of the forum. And I added below lines. But when I print the session ID after and before log in into the application it is same. How would I test session Fixation.
D:\jboss-5.1.0.GA\bin\run.cof file and add the below line.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false"
in each context.xml of the jboss applications.
D:\jboss-5.1.0.GA\server\default\deploy\jbossweb.sar\context.xml