We Keep Coding

Response already committed when using Spring 3.x on Websphere 8.5

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).

Is there any attribute or option available in weblogic to restrict number of servlets?

I'm working on java project, which is using weblogic 10 as an application server. In this project there are around 11 servlets added in web.xml descriptor with url mapping. Whenever i'm adding new servlet, its not getting mapped to the url as wel as not getting invoked. What may be the problem. As, if I add the same logic in any of the existing servlet, its working fine.
Thanks in advance.

How is the question in the title of your post going to help you solve this problem?
Maybe you have another servlet that maps to the same URL pattern, or you have ambiguous URL patterns for your new servlet and already existing servlets (so that WebLogic doesn't know which one to call). Check the servlet mappings in your web.xml file.
Check the WebLogic management console to see if your servlet is deployed successfully, and check the logs of WebLogic for any deployment errors. Carefully read the error messages to find out what's wrong. If you don't understand them, add them to your post above, so that someone here can explain you what they mean.
If you go to an URL that's supposed to map to your servlet, then what do you get? An error message, or is it going to another servlet? If it's an error, then again, post the error message.

Deploying Struts2 Application without ContextPath

I've got a struts2 application running under a contextpath "/path" on my local tomcat without problems. When I deploy it on a webserver (using a proxy to redirect from "http://www.domain.com" to "myserver:8080/path/") Struts does all kinds of strange things.
First, it includes the context in -tags. That can be turned off by an attribute. But sadly, it also includes the path in the action attributes of my forms, so a login form points to "http://www.domain.com/path/login.action" instead of "http://www.domain.com/login.action" ...
Is there a possibility so somehow change the default context that is added here or turn this off for forms? (I'd like to keep the -tags, only way round seems to be to use default HTML forms.) Thanks in advance!

I found that others also had the problem, but the framework makers don't seem to think that this is an issue. My solutions:
use includeContext="false" in all s:url-tags
instead of the s:form tag, use a usual form, set the action to "actionname.action" and include a simple table with tablerows () for each field. You still can use s:textfield and such.
sadly HTTP sessions won't work anymore as they get set for the path "/path" (the ApplicationPath). This is due to the cookie that saves the JSESSIONID being set to /path. This means that your visitors will only get session variables stored when they're at http://www.domain.com/path/login.action and that those will be lost when they get redirected back to http://www.domain.com/interestingstuff.action ... my solution is a hack that requires setting the JSESSIONID cookie clientside via JavaScript as described here: Struts2: Session Problem (after reverse proxy)
Hope this helps someone ... if you find nicer solutions, please let me know. :-)

Though am answering very late to this question, but I reached this page recently when I was facing the same problem.
The application that I was working upon was appending the context-root viz. 'myContextRoot' to my url on localhost and it was working perfectly there. For eg., as mentioned above the action 'myAction' was becoming
http://localhost:8050/myContextRoot/myAction.action
But the moment I deployed it on a server, it stopped working, then after searching like hell, I found a solution for me. I am deploying an EAR file on glassfish and there we have a file application.xml. In application.xml I had a tag 'context-root' whose value was 'myContextRoot' which I changed to '/' and after that I got my url as on localhost and
Hope it may help :)

RPC/Encoded Jboss problem

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.

Servlet spring-servlet is not available (Spring+BlazeDS Integration)

I'm trying to setup a Flex project using the Spring + BlazeDS integration by working through the refcard kindly posted by James Ward on refcards.dzone.com.
Some problems/challenges are sticking their heads out. The Tomcat deployment is going well, all the files are on the server and I can summon main.swf through the browser.
I get the following ActionScript exception when trying to make the AMF request to Spring/BlazeDS:
RPC Fault faultString="Send failed"
faultCode="Client.Error.MessageSend"
faultDetail="Channel.Connect.Failed
error NetConnection.Call.Failed: HTTP:
Failed: url:
'http://localhost:8080/blazeds/spring/messagebroker/amf'"
When placing the "Failed: url:" URL directly in the browser, Tomcat displays the following error message:
HTTP Status 404 - Servlet Spring MVC
Dispatcher Servlet is not available
I've setup all the files like James Ward instructed on his refcard, application-config.xml, web.xml and services-config.xml are all in order as far as I can see.
Any ideas as to what I'm messing up?
PS: I'm noticing small changes in terms of James' refcard and the stable release of the integration. Is there something that changed after the M2 release that might be biting me in the behind?

I have the same problem and I fixed it by adding backport-util-concurrent.jar and cfgatewayadapter.jar from test-drive-sample of flex-spring integration , thank you josamoto for your post , finally the integration works good .
regards

If you follow along the reference card your URL would be http://localhost:8080/dzone-server/spring/messagebroker/amf. The context-root in the reference card is dzone-server.
The key step is to make sure the URL above matches the endpoint url defined in the services-config.xml. So the matching endpoint for the above URL would be:
<endpoint url="http://{server.name}:{server.port}/{context.root}/spring/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/>
Note: this is almost the default added by creating a new flex project in Flex Builder except it has spring added to the endpoint URL.

I'm going to answer my own question, it all boils down to me being the dummy. There where some .jars that I did not include in my WEB-INF/lib folder. I copied them accross from the blazeds+spring integration testdrive and that fixed my problem!