I recently stated using IntelliJ + JRebel and like it so far.
There is just one thing which is kind of annoying. You can't see the content of the JBoss deployment directory as you can for Eclipse (where you see all files currently deployed).
As far as I understood IntelliJ is starting JBoss in a specific way that it points to the directory were the archive (ear/war/whatever) is compiled to.
But now I am facing a problem that IntelliJ seems to have an old version of my war somewhere (I can't find it in the target folder where the war is created), and tries to deploy my app twice.
I get the following error
14:10:55,111 INFO [org.jboss.as.server.deployment:66] JBAS015876: Starting deployment of "B-webapp.war"
14:10:55,111 INFO [org.jboss.as.server.deployment:66] JBAS015876: Starting deployment of "A-webapp.war"
14:10:55,113 INFO [org.jboss.as.server.deployment.scanner:266] JBAS015012: Started FileSystemDeploymentService for directory /Users/macbook15/jboss-as-7.1.1.Final/standalone/deployments
after that I get a failure that JBoss can't find the war for webapp B
14:10:55,159 ERROR [org.jboss.msc.service.fail:94] MSC00001: Failed to start service jboss.deployment.unit."CRF-webapp.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."CRF-webapp.war".STRUCTURE: Failed to process phase STRUCTURE of deployment "CRF-webapp.war"
pointing that it can't find the war file
Caused by: java.io.FileNotFoundException: /Users/macbook15/Downloads/repo.hg/naiis-webapp/target/CRF-webapp.war (No such file or directory)
Is there any cache held in IntelliJ or another place were this information (that there is another app to deploy) might be still stored.
Thanks for any help
Depending on standalone or deployment configuration that you are using, the war file may be sitting in the respective content directory. Check the question related to content directory here Also check the last segment stanalone.xml or domain.xml which will have information on the content directories.
Related
I have been struggling to get an example of a Message driven (inbound) resource adapter to deploy and interact with an EAR on Wildfly 8.2.0.
I used this Java EE 7 JCA sample as the basis of my application.
I can see in the log files that the Resource Adapter gets deployed
INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-2)
IJ020002: Deployed: file:/C:/Software/jboss/wildfly/8.2.0.Final/standalone/tmp/
vfs/deployment/deployment4490b91cd6391845/jca-ra.rar-86794a0699d3da23/contents/
but when the MDB gets initialised I get the following error:
Caused by: java.lang.IllegalStateException: JBAS014521: No message listener
of type org.javaee7.jca.filewatch.adapter.FileSystemWatcher found in
resource adapter jcaInflowApp.ear#jca-ra.rar
The message listener is definitely in the RAR and the RAR is embedded in that location in the EAR.
I've uploaded the code base that I've been working on up to github - hopefully somebody can peruse and see what the issue is?
EDIT for anybody that wants to see a working JBoss example please see the github repo
The issue is duplicate JAR's containing message listener within your EAR. Change the scope of JAR to provided so that it does not get bundled inside lib folder. I've sent you a PR with the fix.
I have a JBoss server whereby when I deploy my ear file from Eclipse, I'm ending up with a whole bunch of jar files missing from the lib/ directory. Upon further investigation, I have found these files - they're in the JBoss server's tmp/vfs-nested.tmp directory. The timestamps all confirm that they're "fresh" from the latest Eclipse server instance publish action I kick off, but I'm perplexed as to why they're residing in this tmp directory and not in the application's (failed) deployment to the server.
JBoss documentation indicates "The tmp directory is used by JBoss to store temporarily files such as unpacked deployments." but I'm unsure as to what the order is or why things are there but not in the deployed application.
Any help?
Dave
I try to deploy Seam Web Project and I have dwo errors:
135 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015010: The deployment scanner found a directory named META-INF that was not inside a directory whose name ends with .ear, .jar, .rar, .sar or .war. This is likely the result of unzipping an archive directly inside the D:\Karolina\programy\jboss-as-7.1.1.Final\standalone\deployments directory, which is a user error. The META-INF directory will not be scanned for deployments, but it is possible that the scanner mayfind other files from the unzipped archive and attempt to deploy them, leading to errors.
135 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015010: The deployment scanner found a directory named WEB-INF that was not inside a directory whose name ends with .ear, .jar, .rar, .sar or .war. This is likely the result of unzipping an archive directly inside the D:\Karolina\programy\jboss-as-7.1.1.Final\standalone\deployments directory, which is a user error. The WEB-INF directory will not be scanned for deployments, but it is possible that the scanner mayfind other files from the unzipped archive and attempt to deploy them, leading to errors.
Enyone know what it mean and what should I do to fix it?
I will glad for any answer.
The error message says that you are most likely trying to deploy a so called exploded archive, but exploded archive support has changed in JBossAS7.
Java EE 6 has made many xml deployment descriptors optional, which was a big win for devs, but app-server like JBoss had to change their way of identifying archive types, because now they can't rely on checking files/dirs for presence of xml descriptors.
You can find more details in docs.
I have created myProj.ear file and copied it into the deploy folder of the JBoss server.. How to run my project after starting the jBoss server?
I have been using war file and
deploying it in Tomcat till now to run
my project.... I am having a new
requirement to run the project in
JBoss. So, I converted my war file
into an ear file using the command Jar
-cvf myProj.ear ., Should I change anything in my project to run
the application in JBoss or just
copying my .ear file in to the jBoss
deploy folder is enough?
JBoss normally support hot deployment - meaning that if your application was deployed correctly (watch the console), it can be accessed via the browser (if you have a UI) or via web services, managed beans or any other interface you have provided.You can see the status of your application on the JBoss Admin Console. You can reach it by typing the URL of your JBoss installation. If you run your vanilla JBoss locally, you should be able to find the console under http://127.0.0.1:8080/admin-console
To reiterate: there is no explicit startup necessary, JBoss handles it for you.
Deploying an application in JBoss is pretty straightforward. You just have to copy the EAR file to the deploy directory in the 'server configuration' directory of your choice. Most people deploy it to the 'default' configuration, by copying the EAR file to the JBOSS_DIR/jboss-as/server/default/deploy directory.
Once copied, just run run.sh from bin, you can use the following params to bind it to an ip (-b) or binding it to anything other port (-Djboss.service.binding.set)
./run.sh -b 9.xxx.xxx.xxx -Djboss.service.binding.set=ports-01
Once you run it, Look at the console for error message. If everything goes fine you'd see "Started J2EE application" after couple of seconds.
If there are any errors or exceptions, make a note of the error message. Check that the EAR is complete and inspect the WAR file and the EJB jar files to make sure they contain all the necessary components (classes, descriptors,
jboss-deployment-structure.xml etc.).
You can safely redeploy the application if it is already deployed. To undeploy it you just have to remove the archive from the deploy directory. There’s no need to restart the server in either case. If everything seems to have gone OK, then point your browser at the application URL.
http://localhost:8080/xyz
I would like to collect some best-practices on deployment of a web-application to a running Tomcat. Not long ago I had to describe the deployment process of our web-application and the process appeared rather confusing.
Say, we have an application in a WAR file (foo.war) correctly configured and not requiring additional configuration. In this case, the deployment process is rather easy:
Copy the foo.war file to the $CATALINA_HOME/webapps directory. If the application starts correctly, the application will automatically deploy to $CATALINA_HOME/webapps/foo directory.
To undeploy the application:
Remove the foo.war file from the $CATALINA_HOME/webapps. If the application unloads correctly, it will be unloaded and the $CATALINA_HOME/webapps/foo will be removed.
Now I want to override some context parameters in my running application. Having read the docs, all I need to do:
Create a context.xml file called foo.xml
Copy the file to the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
Unfortunately, that did not work: the application would not restart. Empirically, we found out that the only working solution is when the war file is deployed to a location outside the $CATALINA_HOME/webapps.
Besides, the default values of the configurable context parameters in the WAR file should be specified in the web.xml, since context.xml in the WAR file is not read when there is a context.xml outside.
Here is an easy example of the foo.xml:
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="/path-to-deployment-directory/foo.war">
<Parameter name="myparam" value="newvalue" override="false"/>
</Context>
Be sure to specify override=false for the parameter if you want the 'newvalue' to override the value specified in the WAR's web.xml. This was not obvious for us.
Thus, to deploy an aplication to a running Tomcat:
Create a context.xml file called foo.xml
Copy the file to the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
Copy the foo.war to the location specified in the docBase of the foo.xml; the application will deploy automatically.
To apply new context parameters:
Add the parameter values to the foo.xml and save the file; the application will re-deploy automatically.
To undeploy the application:
Remove the foo.xml from the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory
Note that removing the foo.war will also work, but will remove the foo.xml as well.
By now, I have the following questions:
Is it a best-practice at all to deploy a web-application without stopping the tomcat? I heard an opinion that deployment to a running tomcat is never needed since people run each application in a separate tomcat.
Is it a good idea to copy WAR files to $CATALINA_HOME/webapps or they should better be kept in a separate location?
How can I configure an application deployed to $CATALINA_HOME/webapps
Why there is no INFO line in the catalina.out for deployment of an application and there is one for undeployment? Is it configurable?
On question (1), Tomcat works great for deploying servlets into a running server. There may be concerns w.r.t. security or possibly D.O.S. or provisioning reasons why you would have separate server instances.
You have the flexibility to do either way, but it is often more convenient to deploy to an already running server. This is a BUILT-IN feature in the servlet architecture. :)
For (2), again it is at your discretion where you you want to put WARs. It sounds like you already have it configured a non-standard (non-default I should say) way. Check your server.xml file for the settings in your server instance(s). Check for attributes like unpackWARs and autoDeploy.
For (3) and (4), plus your (1,2) questions, it might be a good idea to consult the Tomcat docs for your version of Tomcat on its deployment model. You should be able to use the same docs to figure out how your server has been configured.
See Tomcat Web Application Deployment in the Tomcat manual, adjusting for your version of Tomcat.
One solution would be to use the manager application. If you decide that is safe to use it, then you can easily deploy, start, stop and undeploy applications:
http://localhost:8080/manager/deploy?path=[context_path]
http://localhost:8080/manager/start?path=[context_path]
http://localhost:8080/manager/stop?path=[context_path]
http://localhost:8080/manager/undeploy?path=[context_path]
There are ant tasks that can help you with these.
I am guessing, but do not know for sure, that stopping and starting an application will make it reread the context.xml.
Regarding your second question, I believe it is better for maintenance reasons to keep the war files in the webapps directory.