After arquilliian test for our project, in wildfly standalone.xml the following entry is created.
<deployments>
<deployment name="cfgtest.ear" runtime-name="cfgtest.ear">
<content sha1="b0f9e180aaa4e14ee9bab37b4368b6ce45b7b156"/>
</deployment>
<deployment name="pcuitest.ear" runtime-name="pcuitest.ear">
<content sha1="884d1333731f6ed58eb47cee7d7a98a20829d373"/>
</deployment>
</deployments>
Ideally the above should be removed once all tests are completed and server is stopped, but thats not happening anyway. Now if I run the test for the second time - at the time of server startup the above deployments gets started and it creates conflict with the new war files of the current test.
Is there any way I can remove the deployments entry from standalone.xml so that it wont get started when the server starts again. Any startup commands to server so it removes all the deployments or something like that would be helpful.
Note: I found that, If I run the test from eclipse, deployed ear's removed automatically while server stop. But if I run it from gradle, issue remains.
Related
I have a multi-maven war project that I'm trying to deploy in Wildfly. I'm using the JBoss Tools plugin in eclipse to do the deployment (incremental, full publish) and I can see the files being deployed, updated in wildfly's deployment directory. My problem is the xhtml file rendered in the browser is not updated. What I tried:
1.) clear the browser's cache - no effect
2.) open a private browser window - no effect
3.) added a no-cache filter in wildfly
<server name="default-server">
<host name="default-host" alias="localhost">
<filter-ref name="cache-control" predicate="path-suffix['.html'] or path-suffix['.jsf'] or path-suffix['.xhtml'] or path-suffix['.css'] or path-suffix['.js']"/>
</host>
</server>
<filters>
<response-header name="cache-control" header-name="Cache-Control" header-value="no-cache"/>
</filters>
Seems like Wildfly has some deep caching, because when you run incremental publish and then restart the server the changes are reflected.
Any idea?
For standalone:
When already connected to CLI:
deploy /path/to/application.war
Connecting and deploying in a single command:
jboss-cli.sh --connect command="deploy /path/to/application.war"
Connecting, deploying, and authenticating in a single command:
jboss-cli.sh --connect --user=admin --password=redhat command="deploy /path/to/application.war"
For domain:
Deploying to all groups:
deploy /path/to/application.war --all-server-groups
Deploying only to specified groups:
deploy /path/to/application.war --server-groups=server_group_1,server_group_2
These domain commands can also be used like above to connect and/or authenticate in a single command.
User can not deploy application to specific server/servers in domain mode.
The application.war should be an archived application (not an exploded war).
Problem was solved by adding param: javax.faces.FACELETS_REFRESH_PERIOD in web.xml.
<context-param>
<param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
<param-value>2</param-value> <!-- Should be -1 for production. -->
</context-param>
Trying to restart from command line weblogic server but it is picking up EAR file i deployed from Eclipse previously. Thought it was some kinda caching issue so opened/closed eclipse and cmd no help. Still picking up this EAR even when i delete it manually from the temp folder WL_User. Cant start weblogic from Eclipse as weblogic closes suddenly due to VM shutdown request and eclipse hangs on publishing state. Not sure why it does that too no error messages except BEA: VM requested Shutdown.
Very confusing how it is picking it up. Really want to understand why? Thanks for help in advance.
Your weblogic domain is in a bad state. Normally I would suggest removing a deployment by opening the weblogic admin console and navigating to Deployments and then deleting the problematic deployment. If you can't do that, try the following:
Navigate to <domain folder>/servers/<server causing problems>
Delete the tmp, data, cache, and logs folders
Restart your server.
Another option (you should only use if you are really stuck) is to edit the following file:
<domain folder>/config/config.xml
search for and remove your <app-deployment>
If it still doesn't work, you have other problems with your VM. Edit the question and add more info as necessary.
I was able to deploy my WAR the first time I placed it under domains/domain1/autodeploy dir. However, after making some changes and redeploying the WAR to the autodeploy dir, the changes were not picked up. I even deleted domains/domain1/applications/myapp (where myapp corresponds to the myapp.jar being deployed) but the WAR was not redeployed. The server was started and stopped via asadmin:
asadmin start-domain
asadmin stop-domain
What am I doing wrong so that the app does not get redeployed?
UPDATE: I tried manually (re)deploying (also using --force option) the WAR but got the following error in server.log:
[#|2013-03-17T20:47:36.177-0400|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=72;_ThreadName=Thread-2;|Application with name myprojectname is already registered. Either specify that redeployment must be forced, or redeploy the application. Or if this is a new deployment, pick a different name|#]
I do not know how to unregister/undeploy an app that's been once deployed. I tried removing all the references to my app in domain.xml but it didn't work. This seems like a very basic bug in the software.
I know this was answered long ago, but in case anyone else gets here via google like I did, I have another possible answer ...
After encountering this same issue, I found the following ... the autodeploy/.autodeploystatus directory still had a file referencing the application I was trying to redeploy by copying the war into the autodeploy directory. I had to delete the file in the autodeploy/.autodeploystatus directory, then my application was deployed when the war was copied into the autodeploy directory.
Hope that helps.
NOTE: Apparently, it is obvious to others who use glassfish that you have to delete all this stuff from the hidden .autodeploystatus directory to get your re-deploys to work. Why is it obvious to them? We may never know.
You can undeploy via asadamin with:
asadmin undeploy yourapplication
You can also visit the glassfish admin console http://localhost:4848 and undeploy via the graphical interface (look at Applications).
In general the re-autodeployment should work, but I would recommend using the normal deploy method or an incremental redeployment by some IDE like NetBeans...
Exactly the same problem reappears for an application running to be deployed in Payara 5.2021.10 (perhaps for other recent versions > 5.193) within a docker container.
The problem happens every time the docker container restarts - the deployment fails with a message:
Application with name {applicationName} is already registered. Either
specify that redeployment must be forced, or redeploy the application.
Or if this is a new deployment, pick a different name
The problem can be fixed by a forced redeploy. Place something like this into a Dockerfile of the application image:
ENV DEPLOY_PROPS="--force=true"
This environment variable allows to set custom parameters to asadmin's deploy command. How exactly is it applied can be seen in the script that generates the deploy commands, that is being run from within the container's entrypoint.
I've built a set of generic deployment scripts which work great for the majority of our stuff. We've just however introduced our largest project to the setup and we're now finding times are far too varied and long for our liking.
The project size as it stands is 33,226files at a size of 400Mb plus. Times are currently taking between 13mins & 55mins (the last deployments time) depending on certain decisions made by ANT ( more below ).
In terms of the steps we currently do the following on x2 servers:-
1) ANT exports the project from SVN to both servers (made up of 3 parts).
2) It begins to shutdown the Web Services on Server #1.
This was the workaround we put in to stop Windows (2003) file locking failing the deployment.
3) ANT runs a "move" task on the current version (all parts) into temporary folders & moves the exported new version into its place.
4) Customised deployment code is run - one part being to move permanant features from the temporary folder into the new (i.e system files / Web Server Admin tools).
5) Delete the temporary folder.
6) Bring the Web Services back online
... rinse and repeat for the 2nd server steps 2 -> 6.
7) Save the ANT logs.
The main issue I'm having is that the ANT move task seems to make one of two decisions. It either:
a) Very simply swaps the versions over and moves on - taking a minute or two to handling it or
b) Goes through some kind of integrity check that it moves every file and folder from one place to the other. This floods the logs and takes a fair length of time to complete. Hence the 40+ minutes extra added on.
I can't find anything online that explains what causes ANT/OS to make that decision. Option A would be the ideal full-time situation.
I've tried copy, delete separately. I've tried the sync task. All seem to have this slow performance.
So really I'm asking what others with more experienced than me do with deployments of this scale. Do you have any hints / tips on how I could improve / speed this process up? Any ideas what the move is doing and if there is maybe a better way of doing all this?
Thanks a lot,
James
Thanks for the input all.
Just to add an answer to this one I've made the following changes which seem to have knocked a few minutes of it.
The first one was I've changed how the swapping happens off the back of the comment I mentioned before. It seems that ANT will try and do the following :-
"If the target directory does not already exist, Ant will do a rename of the directory. But if the target directory exists, it instead does a copy into the directory and delete from the source directory instead."
I think what's happened is ANT is trying to put the new version in before the old version has been completely removed. So instead of trying to rename the old I've now moved it into a temporary folder and deleted this at the end of the build. That seems to have stabled things on that front.
A few other things I've added to make ANT a bit smart :-)
1) I've set it up so ANT will not deploy any part of the build that is the same as what currently exists. So if part 1 is selected and that's on the Test environment already then it's removed from the build and SVN exports.
2) With the service shutdown / startup I've got ANT reading the response that comes back. If a service tells it that it's already started when calls, as sometimes happens if a service relies on others Windows automatically boots them up, then I've told ANT to hang around and move onto the next one.
Little steps like that seem to have improved things by a fair bit. I'd like to still try and get more out of them but these certaintly have given them a big step.
Thanks again,
James
even we faced this problem of auto deployment script taking longer time in our organization. So initially we had our script running in sequential like cleaning, stopping tomcats, updating, starting tomcats and making sure that all webapps are properly deployed.
So we have done following things like:
1. parallely cleaning and stopping all tomcats
2. do svn swith
3. parallely start all tomcats
4. make sure all webapps are deployed properly using jmx
here is the piece of code :
<target name="all_clean_parallel">
<parallel>
<antcall target="x1_clean"/>
<antcall target="x2_clean"/>
<antcall target="x3_clean"/>
</parallel>
</target>
<target name="all_start_parallel">
<parallel>
<antcall target="x1_start"/>
<antcall target="x2_start"/>
<antcall target="x3_start"/>
</parallel>
</target>
And the piece of code to check whether webapp is deployed propely or not with jmx help :
<macrodef name="mStatus">
<attribute name="aModule" />
<attribute name="aHost" default="localhost"/>
<attribute name="aPort" default="9012"/>
<attribute name="aMaxWait" default="240"/>
<attribute name="aTomcat" default=""/>
<attribute name="aState" default="1"/>
<sequential>
<waitfor maxwait="#{aMaxWait}" maxwaitunit="second" timeoutproperty="#{aHost}.#{aTomcat}.#{aModule}.#{aPort}.server.timeout" >
<and>
<jmx:equals
host="#{aHost}"
port="#{aPort}"
ref="#{aHost}.#{aTomcat}.#{aModule}.#{aPort}"
name="Catalina:j2eeType=WebModule,name=//localhost/#{aModule},J2EEApplication=none,J2EEServer=none"
attribute="state"
value="#{aState}"
/>
</and>
</waitfor>
<if>
<equals arg1="${#{aHost}.#{aTomcat}.#{aModule}.#{aPort}.server.timeout}" arg2="true" />
<then>
<var name="failBuild" value="true"/>
<echo message="*************************Host.Tomcat.Module = #{aHost}.#{aTomcat}.#{aModule} is not deployed into the tomcat" />
</then>
<else>
<echo message="#{aHost}.#{aModule} is deployed into the tomcat" />
</else>
</if>
</sequential>
I need a windows shell script which will redeploy my .ear file. I wrote one:
net stop "JBAS50SVC"
copy /y O:\TEMP\app.ear C:\jboss-4.2.3.GA\server\default\deploy\app.ear
net start "JBAS50SVC"
But the problem is that when I try to stop the JBoss service it does not fully unload itself (my suggestion), so when I start it there's no app deployed in JBoss.
You mentioned that JBoss becomes very slow when you use autoDeploy and keep the server running for a month or more. That's likely to be because your permanent generation memory is filling up over time. See this related question.
I think you'd be best served by using the autoDeploy feature as other suggest, and restarting the entire server periodically to clear out PermGen. There's several ways to track PermGen utilization; I add the following to JAVA_OPTS in run.conf:
-XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -Xloggc:$LOGDIR/gc.log
Typically to redeploy an application that is self-contained in an ear in jboss just requires replacing the ear. If there is more to the application (such as classes that have to go in the jboss lib directory) then it may require a restart.
In terms of how to restart it, it depends what you are using to start jboss as a service. Some service starters do not actually control the jvm after they start it, so restarting the service just starts a second instance. You can shutdown jboss with the shutdown script in the JBOSS_HOME/bin directory (shutdown.bat) and then deploy and restart the service. Be sure to pause when you do this, as the shutdown command will issue the shutdown request, the server may still be running.
You can just COPY/RENAME the EAR file to deploy directory. JBoss will automatically take care of re-deployment for you.
As mentioned earlier jboss automatically deploys everything you copy into the deploy directory by default.
If not, check if you are working on a vhost that doesnt autodeploy ear files.
<Host name="vhost2" autoDeploy="false" .... />
other than that, I feel like this is a totally different error due to the fact that jboss takes care of deployment for you. Please check the log files for startup errors of your application.
You might want to check the JBoss community wiki on this, there are undoubtedly easier and more reliable methods than a batch file.
Stopping the server should not undeploy the application - that wouldn't make much sense.