I'm wrestling with a strange problem: When I make a change to a POJO or Seam Component in my localhost JBoss instance, restart it, and load the page, the change is visible. However, on our server, running the same version of JBoss, when I stop the instance, delete the WAR file, upload the latest version, and restart JBoss, it won't show some of the new server-side functionality.
Specifically, the change is to a POJO class which implements javax.faces.validator.Validator class. It's then used in the XHTML Facelet like this:
<h:inputText value="#{outsideaccount.accountOrganizationEmail}" maxlength="50"
id="txtOrganizationSupportEmail"
validatorMessage="Organization Support Email is not valid. It must be in the pattern 'some_id#some_domain.com'.">
<f:validator validatorId="AnyEmailValidator"/>
</h:inputText>
I'm able to use the email validator on my localhost JBoss correctly; on the development server, it throws a validation error using the same email on the same page. Very strange. Is JBoss caching the class files somewhere? How do I clear everything out of the JBoss development server cache?
I'm using Win XP Pro locally; the development server is using JBoss 4.2.3.GA on JVM Version 1.5.0_16-b02, with Unix SunOS 5.10. Thanks.
JBoss has work and tmp directories that you can delete to make sure everything is clean. Things can get cached there, so you can clear them out on deploy if you are having problems. There is also a setting to force that to happen automatically on JBoss's end. If your problem is a cache clearing problem, this will help solve it.
Another possibility is that you have two copies of that war deployed on JBoss, although that should give you some errors when you deploy in production.
Related
I have a filter used for authorization. It's the first step entering application. Without it is not possible to do anything in the application.
I set a systemout on the very first line of doFilter method to monitor the behaviour, so comparing websphere server log files I'm sure that filter (same Ear deployed) on Test environment works and on Production environment not.
Maybe it's server configuration issue...?
I have access to read and modify WAS Console of test environment.
I have access only to read WAS Console of production environment.
So I can compare them, and maybe test some change on test environment to replicate the behavior and say to production administrator what exactly setup....
Any suggestion on which setting I can check (Was console, maybe in relation with Web.xml, etc...)?
Thx a lot for any suggestion.
EDIT
I was able to retrieve via FTP the EAR in InstalledApps of Production environment. I noted a file named "web_merged.xml" in which is missing the entry of the filter.
Maybe the problem is here? When is created and why? Why could be missing the entry there? How let WAS to create the right file (if the problem is there)?
The problem was the one on the EDIT in the question, webmerged.xml was wrong. We weren't able to understand why WAS generated this file in wrong way.
What I understand is generated during deploy and is a mix of web.xml of the applicatin with application server configuration.
That's a WebSphere issue, we guessed it has to do with application server cache. We asked to System Administrator to:
Uninstall the application
Stop the server in which the application was installed
Clear the cache
Restart the server
Reinstall application
From this point the file was generated in the right manner, as the application bahaviour.
Websphere version is 8.5
I have a problem where every time I redeploy my app, any existing sessions are broken and the requests result in a ViewExpiredException. None of the advice in related questions or outside mailing list / forum posts seems to fix this issue. I can redeploy the same WAR file completely unchanged and the behavior is the same.
I'm using Apache MyFaces 2.2.0, Tomcat 7.0.56 and Primefaces 5.0.
The message of the exception is No saved view state could be found for the view identifier: with whatever page would be requested. Primefaces' menubar is used for navigation, which seems to be implemented as a <form> with POST requests. These messages occur both with those navigation options and other AJAX that uses POST.
I have tried:
Setting explicit org.apache.myfaces.SECRET and org.apache.myfaces.MAC_SECRET values, as seen in this document.
Both client and server values for the javax.faces.STATE_SAVING_METHOD parameter.
Ensuring all beans and their transitive fields are serializable. No serialization errors are reported in the logs.
Using a filter to add no-cache headers, e.g. as suggested in this answer.
Session persistence is not disabled, that is my context.xml has <Manager pathname="" /> commented out.
try with:
<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="true"/>
It seems that losing sessions is a "feature" of Tomcat since at least version 6 and continuing to version 7 when deploying via WAR file. We have to copy an unpacked directory to avoid losing the sessions, because WAR changes cause an undeploy followed by a deploy, as opposed to a reload.
This bug report states:
There are ways to achieve an update to an application without dropping the sessions. The simplest is probably:
- deploy as an exploded directory rather than a WAR
- update the files
- touch web.xml to trigger a reload
The reason for the current behaviour is to prevent problems when WARs are updated in incompatible ways and anything other than a full undeploy followed by (essentially) a new deployment causes conflicts.
This is still the case in the current Tomcat 7.0 documentation:
Currently, application reloading (to pick up changes to the classes or web.xml file) is not supported when a web application is deployed directly from a WAR file. It only works when the web application is deployed from an unpacked directory.
Let me give a little background to give context to this question. Over the course of time, the application I have been assigned to work on lost the ability to be built and deployed as a full application. By that I mean the previous developer compiled the code in his local IDE, and dropped single class files, as opposed to building out proper JARs and WARs to be deployed out to tomcat. So I have been tasked to clean up the project so it is a standard deployable app again. So to sum up the important part, the application exists in a working format on a windows tomcat environment, that hasn't had a clean deploy in a long time, my goal is to make the app buildable and deployable via a jenkins CI server to a tomcat instance running on a Linux server. Now on to the problem. I get the following toplink exception in one application module.
Local Exception Stack:
Exception [TOPLINK-6007] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.QueryException
Exception Description: Missing descriptor for [class edu.cornell.finsys.datamodel.AccountDTO].
Query: ReadObjectQuery(edu.cornell.finsys.datamodel.AccountDTO)
I have verified that the toplink mapping file has been loaded by tomcat, and the AccountDTO is mapped in the file. To double check that, I have moved the mapping file out, and I get a completly different error at load time. I know the file mapping is correct, as it worked correctly on the old server. I don't know what else could be causing the toplink exception.
For more information, I am on tomcat version 6.0.37, Java version 1.6.0_45, toplink version 9.0.4.031126
Any ideas?
This may be it; right from Metalink:
Cause:
This is an issue with loading the sessions.xml file, once when the application was first deployed using that application's classloader and then not reloading the session when the application was redeployed and a new XMLContext was created. The caused us to attempt to use a session that had been loaded with a different classloader than the current application.
Possible solution:
The issue occurs when TopLink is part of the main classpath (Eg: Applib directory rather than stored in the ear file). When this happens, the static SessionManager has trouble finding descriptors the second and subsequent times an application is deployed. Basically the descriptors are indexed by class. When the application is redeployed, the classes used for the indexing are unloaded and new versions of those classes appear. This causes "Descriptor not found" exceptions.
Potential Workarounds
Put the toplink.jar file in the ear.
Write some code to manually clean up when the toplink application is torn down.
For certain architectures they may be able to use the version sessionManager.getSession() that allows the session to be refreshed.
Workaround 3 is best and very feasible. The session has to be lazily
obtained from the SessionManager and held in an application code
variable. When the application is restarted its handle on the TopLink
session will be null. The session can then be obtained from the
SesssionManager using the getSession(XMLLoader xmlLoader, String
sessionName, ClassLoader objectClassLoader, boolean
shouldLoginSession, boolean shouldRefreshSession) API with
shouldRefreshSession set to true. This will ensure that the old
session (if any) is logged out and removed from the SessionManager
before a new one is created.
Did any of the workarounds help?
I have a seam project (you should not be blocked to answer just because it's seam, consider it beeing a jsf one) and all works great with jboss 5.1 until I add this to the faces-config.xml
<faces-config>
<validator>
<validator-id>passwordValidator</validator-id>
<validator-class>com.mydomain.seam_icefaces_test.action.PasswordValidator</validator-class>
</validator>
.....
</faces-config>
to configure a validator (I know I can use a seam validator but I just want to use a jsf one).
At this moment jboss continuously deploy and undeploy my app automatically - which is very strange of course...
Do you know why?
Is this happening when you deploy using a local server in Eclipse? I used to get this issue of constant deploying & undeploying - it was caused by an Eclipse versioning file in the deployment.
Every time you change a config file (like faces-config.xml) Eclipse creates a versioning file, to revert to if necessary. This screws up JBoss. Simply delete this file - it'll be called faces-config.xxxxx where xxxx is something other than xml.
I'm developing a Flex 3.4 app that interops with a Java EE backend running on a JBoss-4.2.2 server, through the most recent release of BlazeDS. When I ran the Flex app from Flash Builder 4 beta 2 on Tomcat, everything was fine, the Flex app was able to make the remote call needed. But my production environment is on JBoss, and when I moved the app to JBoss (with services-config.xml updated to fit JBoss), the Flex app keeps complaining Client.Error.MessageSend upon remote calls.
At first, when I manually deployed the app to JBoss, the faultDetail was "Channel.Security.Error error Error #2048 ... "; later I tried to run the app from Flash Builder, and then faultDetail became "Channel.Connect.Failed error NetConnection.Call.BadVersion".
In services-config.xml, under <security>, was:
<login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"/>
when moving to JBoss, I updated it to:
<login-command class="flex.messaging.security.TomcatLoginCommand" server="JBoss"/>
I have a crossdomain.xml placed in JBoss' deploy folder, as follows:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy
SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
But looks like it doesn't work. I've also tried to put crossdomain.xml in deploy/xxxxx.war folder, and the problem remains.
I'm using http://, not https://, so I guess it's not about security channel.
Tried to search for a solution, but most solutions were PHP related, which wasn't really helpful. Any one got any clues?
You have
<login-command class="**flex.messaging.security.TomcatLoginCommand**" server="Tomcat"/>
Where the class indicates that security is of tomcat you should change it to a class that implements the interface flex.messaging.security.LoginCommand or any security interface blaze.
If you browse to http://your.application.root/crossdomain.xml, does the file load? The simplest configuration is to put the file at the root of the domain.