I'm using Tomcat 8.5.4 with myfaces 2.2.10 and primefaces 5.3. My local server works fine (tried to run it both standalone and eclipse) when I open the login screen and press the login button the following is visible in the logs:
...web.controller.LoginController] - <Validating login>
...AntPathRequestMatcher] - <Checking match of request : '/j_spring_security_check'; against '/external/**'>
After this a transaction started and the user is validated against the database as expected.
However when I copied the whole Tomcat distribution to a remote server and deployed the same application, j_spring_security_check is not executed anymore:
[org.springframework.faces.support.RequestLoggingPhaseListener] -
<Entering JSF Phase: RESTORE_VIEW(1)>
[org.springframework.faces.support.RequestLoggingPhaseListener] -
<Entering JSF Phase: RENDER_RESPONSE(6)>
[...web.controller.LoginController] - <No error messages during validation>
And after this the login screen is reloaded.
Can anyone help me why there is a difference in the behavior of the same servers and same applications? Any idea is appreciated!
I'm pretty sure that it does not have anything to do with myfaces or primefaces versions and I tried different versions but the behavior is the same...
for those who have the same issue I post my solution.
Of course there can be millions of reasons to cause this behavior but in my case it was the tomcat configuration... in Connector config in server.xml I've set
maxPostSize="0"
by mistake which I tought means no limit, however I should have set
maxPostSize="-1"
This resulted in the server cutting the post payload from the request... and causing me a lot of headache :)
Related
I am developing a simple web service using Eclipse Java EE IDE for Web Developers : Version: Kepler Service Release 2 Build id: 20140224-0627 and Wildfly-8.2.0.Final. I chose wildfly-javaee7-webapp-blank-archetype using Maven and started development. Firstly, there was no problem, I could add some simple jsp pages and also a simple html page with some images and javascript inclusion then I could deployed, launched and accessed those pages by browser. But all of a sudden, Wildfly (I guess Undertow maybe?) started to response with HTTP response 200 with no content... I really don't get what is going on. I also did rollback my sources to the very early simple pages only. But still the symptoms are the same. Also I have tried to use newer version of Wildfly-9.0.1.Final and deployed manually but I haven't seen any difference.
ex1) this is ok. (Of course browsers take care of this...)
ex2) this kind of contents won't be loaded and sent back as content 0...
I doubted local path issue but I haven't changed anything and it was loaded earlier.
It would be really appreciated if somebody could give me a solution.
Finally I have solved this problem. I have found a problem on a servlet I have added at last. Actually I was trying to migrate my web service running on glassfish and did migrate files one by one. I specified a URL to be handled by the servlet in Web.xml when it run on glassfish. But somehow, it's not working on Wildfly which means all URL request are unexpectedly handled by the servlet... Since I have no idea to specify url to be handled by the specific servlet in Web.xml for Wildfly, I decided to filter request URL in the servlet code. So it is working now. Thank you guys trying to help me...
I'm moving old GWT app from one server to another. Both in Eclipse and on old Tomcat everything is working OK, but on new server GWT app gets loaded (so the server is working and serving files), but fails on RPC call returning 404.
My admin and I have looked at possible differences in context paths, Tomcat and Java versions, and tried to recreate config on the new server as close as possible but it seems that we're missing something so I'm looking for fresh ideas.
As mentioned on this link under common pitfalls, it indicates that web.xml is misconfigured, but this is ruled out as the same web.xml works OK on old server. My #RemoteServiceRelativePath is "app.rpc" and in web.xml this is mapped to:
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>*.rpc</url-pattern>
</servlet-mapping>
...and in dispatcher servlet this is mapped to a correct controller. I can also give server.xml or any other part of config if needed, but I'm looking for other things that could be incorrect.
Solved it, but by going nuclear and copying the exact same Tomcat and Java version with the same paths and all settings as on the old server. What I do know is that it was not a network problem, and that the request was received by Tomcat but never got to GWT or application code; so either Tomcat (5.5 in original configuration, 6.0 in the) or Spring (2.0.2) is the culprit. This is the old application that won't be updated and is due to be replaced and I hope it dies a quick and painless death.
the glassfish application server provides a nice monitoring REST interface.
To use it u can enable several monitorable items in the admin console, for example the EJB container. The documentation says, you can retreive EJB-statistics for every deployed application.
If you request a URL like localhost:4848/monitoring/domain1/server/applications/APPNAME/EJBNAME you will get statistics for a given EJB of the application.
Further, there is a possibility to look more deeply into each bean-method of the ejb, for example the executiontime, about which the documentation says:
"Time, in milliseconds, spent executing the method for the last successful/unsuccessful attempt to run the operation. This is collected for stateless and stateful session beans and entity beans if monitoring is enabled on the EJB container."
The problem now is, monitoring is enabled on the EJB-container (Level set to HIGH), but nothing is sampled in any bean-method in any EJB in any deployed application.
Is there something special to do in the bean and/or the glassfish ?
Thanks in advance for help,
Chris
EDIT:
Ok, I noticed something more about that behaviour:
In the server log you get a log message for each deployed EJB like that:
INFO: EJB5181:Portable JNDI names for EJB DataFetcher // ...
If I set the ejb-container monitoring level to HIGH (which is what I want to do), I get the following warning for each deployed EJB, regardless which app I deploy:
WARNING: MNTG0201:Flashlight listener registration failed for listener class : com.sun.ejb.monitoring.stats.StatelessSessionBeanStatsProvider , will retry later
I googled the warning but none of the resulst really help me enabling EJB monitoring...
This seems to be a Bug in Glassfish.
EJB Monitoring is currently not working in 3.1.2.
JIRA issue is already raised: http://java.net/jira/browse/GLASSFISH-19677
There is nothing "special" to do.
http://docs.oracle.com/cd/E18930_01/html/821-2431/abeea.html
For me it seems as if you probably enabled the monitoring option on the wrong configuration. Please double check.
To get rid of this message you can disable the monitoring on ejb container option below in the image
From Monitor Data--->Configure monitoring--->make ejb container log off
When i am running my application it give me this exception:-
Exception sending context initialized event to listener instance of class
org.springframework.web.util.Log4jConfigListener
java.lang.ExceptionInInitializerError
But this problem is not permanent. If i remove the log4j entries from web.xml and restart p.c and then again add log4j entries and start the server, then the application works fine.
I noticed that when the application is deployed and when i undeploy and again deploy the same application, this problem emerge.
Please help me ........ i am facing this problem from 3 months...
I just investigated it a little and have found the similar issue:
It causes when multiple jar file for log4j is available to application.
From web/application server and from build path(Included from other
path rather than web/application server)
You can see the entire thread here:
http://www.coderanch.com/t/551933/Spring/Exception-sending-context-initialized-event
looks like this is your problem.
we have a WAR packaged web application which works on a development machine. It consists of Java EE 5 + Seam 2.2.1 + Hibernate 3.3.1. It uses an Oracle 10g XE database and runs on the latest Tomcat 6 using JDK 1.6.0_24. The system is a 64bit Windows 7 Pro and uses Firefox 6.
Now, we tried to migrate the application to Oracle WebLogic 10.3.5. We followed the Seam manual for specifying the datasource, deploying the JSF lib and configuring the necessary xml-Files. In parallel to that, we verified that a newly seam-gen generated application using the same datasource and having the xml files configured as stated works fine.
But if we try our own application on WebLogic, allthough the deployment works fine, when trying to open the web application in the browser, it shows that endless redirection occured. We don't see any stacktrace or log error, even when configuring log4j in WebLogic. When analyzing the request with Firebug, we see the get request to "login.seam" and then 20 times a get request for "error.seam" (or "debug.seam when setting debug mode) with the response "302 Moved Temporarily".
I worked on that all week now, trying to compare all configurations and couldn't solve it - so I hope to get any ideas what could cause that problem and how to solve it!
I could pin down the problem to starting a transaction on the JTA persistence context.
I still don't understand why I didn't see any log message or stacktrace and why this also happens on the debug/error page (that's why the endless redirect occured).
I ended up using RESOURCE_LOCAL so far, but I'm not sure if this is the right thing to do.
The alternative is disabling the seam transaction setting, but then it didn't work together with the development build which still runs on Tomcat.