After every change in HTML(XHTML) page of a web project, either it is JSF or a simple WAR I need to perform a Full Publish to see the changes. After some googling I found the solution to change in Management Console - Publishing settings to Automatically publishing when resources change and set publishing interval to 0, but it doesns't help. What can I do more to resolve this issue?
I'm using WildFly 8.2 on Mac Maverick.
Thank you in advance.
you can deploy exploded war file instead of war archive. Only make sure that folder name has .war in its name e.g myApp.war.
After that you can configure wildfly deployment-scanner to auto deploy exploded content. This can be done in your config file e.g. standalone.xml.
See https://docs.jboss.org/author/display/WFLY8/Deployment+Scanner+configuration
Config example:
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir" path="deployments" auto-deploy-zipped="true" auto-deploy-exploded="true"/>
Had the same problem. In standalone.xml i added the attribute
auto-deploy-exploded="true"
and the problem started. After removing the attribute it returned to the same behaviour as before.
There was a bug in JBoss 7 which was about processing this attribute not properly (or at all) but its status is resolved and it should work now. Obviously it doesn't or i am doing something wrong.
After setting auto-deploy-exploded="true" I was't able to deploy application. Deployment copies stuff in "deployment" and then scanner triggers and starts another deployment of the same app witch results in error
Related
I am trying to use eclipse kepler for Java EE 7.I already installed JBoss Tools and added JBoss Wildfly successfully as a server. However my changes are not automatically deployed. Is there anyway the app can be deployed automatically just as when using glassfish?
Using Eclipse, click twice on your WildFly Server to edit the following properties:
Publishing: choose "Automatically publish after a build event". I like to change the publishing interval to 1 second too.
Application Reload Behavior: check the "Customize application reload ..." checkbox and edit the regex pattern to \.jar$|\.class$
That's it. Good luck!
Both #varantes and #Sean are essentially correct, but these answers are not full.
Unfortunately the only way in a Java server environment to have full, zero-downtime hot deployment is to use paid JRebel or free spring-loaded tool.
But for small project there are some ways to speed up work by partial hot-deployment. Essentially:
When enabled option Automatically publish when resource change
then changes inside *.html, *.xhtml files are immediately
reflected as soon as you refresh the browser.
To make hot deployment work for *.jsp files too, then you should
inside ${wildfly-home}/standalone/configuration/standalone.xml
make following change:
<jsp-config/>
replace with:
<jsp-config development="true"/>
restart the server and enjoy hot deployment of web files.
But when modifying *.java source files, then only partial hot deployment is possible. As #varantes stated in his answer, enabling Application Reload Behavior with regex pattern set to \.jar$|\.class$ is an option, but has serious downside: whole module is restarted, thus:
It takes some time (depending on how big is a module).
Whole application state is lost.
So personally, I discourage this solution. JVM supports (in debug mode) code-swapping for methods' bodies. So as long as you are modifying only bodies of existing methods, you are at home (zero downtime, changes are reflected immediately). But you have to disable automatic publishing inside server settings otherwise the application's state will still be destroyed by that republish.
But if you are heavily crafting Java code (adding classes, annotations, constructors) then unfortunately I can only recommend set publishing into Never publish automatically (or shutdown server) and when you finish your work in Java files, then restart by hand your module (or turn-on server). Up to you.
It works for small Java projects, but for bigger ones, JRebel is invaluable (or just spring-loaded), because all approaches described above are not sufficient. Also because of such problems, solutions like Rails/ Django /Play! Framework gained so huge popularity.
I am assuming you are using the latest version of Wildfly (8.0 Beta 1 as of writing).
In the standalone.xml config file, look for <jsp-config/>. Add the attribute development="true" and it should hot-deploy. The resulting config will look like this:
<jsp-config development="true"/>
Add attributes (development, check-interval, modification-test-interval, recompile-on-fail) in configuration file in xPath = //servlet-container/jsp-config/
<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
<jsp-config development="true" check-interval="1" modification-test-interval="1" recompile-on-fail="true"/>
</servlet-container>
(It works in WildFly-8.0.0.Final)
Start server in debug mode and It will track chances inside methods. Other changes It will ask to restart the server.
I upgraded from Spring Tool Suite (STS) 3.2 to STS 3.3 and it has brought a few issues with it.
When trying to download plugins, I get "Proxy Authentication Required.." errors.
I have my http proxy configured correctly (the same way as 3.2). I have even compared all the .ini files between the versions and cannot find a difference.
As many posts have suggestion, I have also cleared the SOCKS proxy, and even tried to specify in the .ini files that it is not to be used- but again without any luck.
I have tried configuring the HTTPS proxy and playing with the properties in the .ini files for both, restarts, running under different permissions, ect...
Could use some new ideas on this one.
Thanks a lot for reading.
I had the same problem. It turned out that this was caused by two plugins. To allow your STS to connect to the internet via proxy just delete this two plugins:
org.apache.httpcomponents.httpcore_4.2.4.v201305222326.jar
org.apache.httpcomponents.httpclient_4.2.5.v201305222326.jar
There should be older versions of this plugins so everything should be working fine.
The same thing just happened to me on installing STS 3.4. I could only get the proxy to work by switching my proxy provider to manual, editing the http schema and adding my proxy username and password. Less than ideal.
If I remove STS, the native proxy provider starts working again.
I had to add the following 2 lines to STS.ini file. The first line at the top of the file and the second line at the bottom of the STS.ini file:
-clean
...
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
Then on the following file, which exists in the STS (Eclipse) installation folder...
configuration\.settings\org.eclipse.core.net.prefs
...I had to enable proxies making sure that the following properties were set to true:
proxiesEnabled=true
systemProxiesEnabled=true
Only after doing this and rebooting STS, the proxy settings I had entered through the UI previously, took effect.
Edit (2020-01-30):
If the file org.eclipse.core.net.prefs doesn't exist, just create with the following basic content. Edit as needed.
eclipse.preferences.version=1
nonProxiedHosts=localhost|127.0.0.1|another-host-in-your-LAN
org.eclipse.core.net.hasMigrated=true
proxiesEnabled=true
systemProxiesEnabled=true
proxyData/HTTP/hasAuth=true
proxyData/HTTP/host=your-proxy
proxyData/HTTP/port=80
proxyData/HTTPS/hasAuth=true
proxyData/HTTPS/host=your-proxy
proxyData/HTTPS/port=80
There is an open issue: https://issuetracker.springsource.com/browse/STS-3647
It is recommended to download the latest nightly build.
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 had a bundle deployed in an Apache Felix (Sling, in fact) host. The bundle contained some configurable elements, and its version was 2.0.
I have updated the bundle to v2.0.1 for some small code changes, and now the bundle will not pick up its configuration correctly - it remains at the defaults set in code rather than picking up the values configured in the Felix Web Console.
There is an error message in the log: "[Configuration Updater] org.apache.felix.scr Cannot use configuration pid=com.mypackage.MyClass for bundle inputstream:my-bundle-2.0.1.jar because it belongs to bundle inputstream:my-bundle-1.0.jar" which sounds like the cause of the issue.
However:
I can't edit the inputstream value through the web interface - only by stopping the server, editing the config file manually, and restarting. Surely when I update the bundle, the config should be updated too?
Although the inputstream specifies v1.0, the bundle did not have a problem when it was upgraded to v2.0. What's made the difference here?
I have done the same thing (though perhaps not exactly!) on two servers, and one server seems to have the config specify inputstream=v2.0 (and the bundle at v2.0.1) and it works fine. What caused inputstream version to update on this server? (Presumably the same as the answer to 2 - I imagine it'll depend exactly which steps in the process have been executed and in what order.)
Any advice gratefully received - I haven't been able to find any documentation that gives instructions or troubleshooting suggestions for administering bundles through the Felix Web Console.
If at all possible, I would simply stop and remove the bundle altogether and install it using Sling , e.g. with the maven-sling-plugin or dropping it in the /apps/myapp/install folder using WebDAV .
I find it easiest to be consistent this way and the installation is nicely automated and it handles bundle upgrades properly.
Documentation says if you have a context file here:
$CATALINA_HOME/conf/Catalina/localhost/myapp.xml
it will NOT be replaced by a context file here:
mywebapp.war/META-INF/context.xml
It is written here: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
Only if a context file does not exist for the application in the $CATALINA_BASE/conf/[enginename]/[hostname]/, in an individual file at /META-INF/context.xml inside the application files.
But everytime I re-deploy the war it replaces this myapp.xml with the /META-INF/context.xml!
Why does it do it and how can I avoid it?
Thanx
Undeploy part of redeploy deletes app and the associated context.xml.
If you use maven tomcat plugin you can avoid deleting context.xml if you deploy your app with command like this:
mvn tomcat:deploy-only -Dmaven.tomcat.update=true
More info here: https://tomcat.apache.org/maven-plugin-2.0-beta-1/tomcat7-maven-plugin/deploy-only-mojo.html
You can use deploy-only with parameter mode to deploy the context.xml too.
The short answer:
Just make the TOMCATHOME/conf/Catalina/localhost dir read-only, and keep reading for more details:
For quick deployment mode (Eclipse dynamic web project, direct Tomcat
connection, etc.) on a local/non-shared Tomcat server you can just define your JDBC datasource (or any
other 'web resource') using the META-INF/context.xml file inside the
WAR file. Easy and fast in your local environment, but not suitable for staging, QA, or
production.
For build deployment mode (usually for staging, QA, or prod), JDBC
datasources and other 'web resources' details are defined by the
QA/production team, not the development team anymore. Therefore, they
must be specified in the Tomcat server, not inside the WAR file
anymore. In this case, specify them in the file
TOMCATHOME/conf/Catalina/localhost/CONTEXT.xml (change Catalina
by the engine, and localhost by the host, and CONTEXT by your context accordingly). However,
Tomcat will delete this file on each deployment. To prevent this
deletion, just make this dir read-only; in Linux you can type:
chmod a-w TOMCATHOME/conf/Catalina/localhost
Voila! Your welcome.
The long answer
For historical reasons Tomcat allows you to define web resources (JDBC datasources, and others) in four
different places (read four different files) in a very specific order of precedence, if you happen to define the same resource multiple times. The ones named in the
short answer above are the more suitable nowadays for each purpose, though you could still
use the others (nah... you probably don't want to). I'm not going to
discuss the other ones here unless someone asks for it.
On tomcat7, also woth autoDeploy=false the file will be deleted on undeploy. This is documented and not a bug (althought it avoids good automated deployments with server-side fixed configuration).
I found a workaround which solved the problem for me:
create a META-INF/context.xml file in your webapp that contains
on the Server create a second context "/config-context" in server.xml and put all your server-side configuration parameters there
on the application use context.getContext("/config-context").getInitParameter(...) to access the configuration there.
This allows a per-host configuration that is independent of the deployed war.
It should also be possible to add per-context configurations by adding contexts like "/config-context-MYPATH". In your app you can use the context path oth the app to calculate the context path of the config app.
According to the documentation (http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files) upon redeploy tomcat detects the deletion (undeploy) of your application. So it will start a cleanup process deleting the directory and xml also. This is independent of auto deployment - so it will happen upon redeployment through manager and modification of war also. There are 3 exceptions:
global resources are never deleted
external resources are never deleted
if the WAR or DIR has been modified then the XML file is only deleted
if copyXML is true and deployXML is true
I don't know why, but copyXML="false" deployXML="false" won't help.
Secondly: Making the directory read only just makes tomcat throwing an exception and won't start.
You can try merging your $CATALINA_BASE/conf/Catalina/localhost/myapp-1.xml, $CATALINA_BASE/conf/Catalina/localhost/myapp-2.xml, etc files into $CATALINA_BASE/conf/context.xml (that works only if you make sure your application won't deploy its own context configuration, like myapp-1.xml)
If someone could tell what is that "external resources" that would generally solve the problem.
The general issue as described by the title is covered by Re-deploy from war without deleting context which is still an open issue at this time.
There is an acknowledged distinction between re-deploy which does not delete the context, and deploy after un-deploy where the un-deploy deletes the context. The documentation was out of date, and the manager GUI still does not support re-deploy.
Redeployment means two parts: undeployment and deployment.
Undeployment removes the conf/Catalina/yourhost/yourapp.xml because the
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="true"> <!-- means autoUndeploy too!!! -->
</Host>
Change the autoDeploy="false" and Tomcat has no order anymore to remove the conf/Catalina/yourhost/yourapp.xml.
There is an feature that allowes us to make those steps (undeploy/deploy) as one single step (redeploy) that do not remove the context.xml. This feature is available via the manager-text-interface, but the option is not available using the manager-html-interface. You might have to wait until the bug in tomcat is fixed. You can use the method described in this answer as an workaround.