Develop Reference

How to deploy simple JMS application on application server?

I need help here with the below issue. I am learning JMS and I am quite new to it. I came across a tutorial which I was following, however when I try to run this by selecting the project in eclipse I do not get an option to run on server. Is there a way we can run a simple java application on application servers?
Below is the link to the tutorial I am following
https://www.javatpoint.com/jms-tutorial
I have mostly worked with dynamic web projects for which the option is present to run on server.
I have not posted the code as it's the exact same as given in the tutorial.

For that you need to figure out which server(s) you want to deploy JMS. You can go with Weblogic or with ActiveMQ.
Below are the 2 reference links that would actually help you to resolve your query :
http://www.catgovind.com/java/test-weblogic-jms-java/
https://javainsider.wordpress.com/tag/jms-with-activemq-sample-example/

Yes, I would suggest you to go through spring-boot.
Here, you have an option to try a simple Hello World application
http://www.mastertheboss.com/jboss-frameworks/spring/your-first-jms-application-with-spring-boot
In the above example, you just have 2 java classes and one maven pom xml file to edit :)
Just try it out.
You can configure it to run from your eclipse too.
In/with spring-boot -
you don't have to do any web-server configuration on your own. Spring boot itself contains a web container.
It just creates a JAR file with which you can just run your application as "as your run a jar" which has your code + server.
And my last point is - you will get lots of support from different forums as spring boot is used widely.

Deployment of a J2EE web app

Is there a way to deploy apps without deploying it as a war file? At the moment I am repackaging and redeploying the war after every change. Is there a way to host it like IIS so changes can be done to an individual file without having to repackage and redeploy. Im using glassfish at the moment

Glassfish permits deploying applications and modules in an exploded directory format. It also supports automatic deployment and dynamic reloading.

You can hot deploy few things. By hot deploy I mean replacing the file not full app. Like hot deploying a jsp file, some static content there might be some more things. But then there are other things which may not work properly if you try to just replace a file.
Having said that it's not a recommended practice in most production environments. Most people would like to deploy a full war file.
But if you are simply looking for productivity in development environment you can use tools like JRebel. It works great. You don't have to keep deploying the war file again and again.

With Tomcat, you can configure the container to serve a webapp that is located in another directory (such as your build target directory) using a config file found under tomcat/conf/Catalina/localhost
But, you generally need to restart Tomcat if you make changes other than static content or JSP changes.
This sort of approach should be restricted to development environments only.

I agree with Laird Nelson that GlassFish can do that the reason is that Glassfish use Apache Felix which is an OSGI implementation (OSGi Framework and Service platform). Here you can find projects using felix. If you are using a simple Servlet Container like Tomcat there a lot of solutions.

Are geronimo-web.xml files required to deploy to Geronimo?

I have a servlet that I built and ran on Tomcat. I now need to deploy this servlet to Geronimo. Do I need to have a geronimo-web.xml file before I cam deploy to Geronimo? If so, does anyone know of good example online to build one?

I was only ever able to deploy with them, so I believe the answer is yes.

JBoss AS7 *.dodeploy files

We package our application as a .war file, we advertise support for JBoss AS5 and instruct our clients to copy the .war into their JBoss 'deploy' directory, and start up their application server in order to deploy the .war.
We are introducing support for JBoss AS7, so our deployment instructions for AS7 will have to change to something like
-copy the application.war to $JBOSS_HOME/standalone/deployments
-touch $JBOSS_HOME/standalone/deployments/application.war.dodeploy
-start JBoss AS7
This deployent method seems awkward to me, and possibly fragile, as failure to successfully create the *.dodeploy file would cause the deploy to fail. Also JBoss startup problems may cause the deploy to fail, causing the *.dodeploy file to be renamed *.failed - so it would have to be renamed back to *.dodeploy before attempting to redeploy. We are thinking the process seems a little awkward for some of our clients, who may not be familiar with JBoss AS7.
Is there any way to automate this deployment process so that it is smoother for deployers who may not be comfortable with how things work with JBoss AS7? How are other people handling this type of situation? thanks for any suggestions.

There is a web interface that's fairly easy to use. You can access it after JBoss AS7 has been started by going to http://localhost:8080. There is a link on that page that takes you to the administration console.
You could also write scripts for deployments using the CLI interface. There is some information here https://docs.jboss.org/author/display/AS7/Management+Clients about how to use it.
Lastly you can always write your own Java client to deploy applications. I wrote a blog post a while back on how to write a custom deployment CLI interface.

If you're aware of the marker files then you might have made a conscious choice to disable the automatic deployment mode for the deployment folder, which ships enabled by default. Autodeploy is great for everything but exploded files, and removes the need to manually manage the marker files. With autodeploy enabled, you can use the "touch" command on the application itself, which will update the timstamp and trigger the application for deployment (or redeployment). So you can still script if need be, but focus on the file rather than the marker files.
Just for reference, there are five ways to deploy files, of which three will be common to the typical administration setup. These are the graphical Management Console, the Management Command Line Interface (CLI) and the deployment folder you mention. The other two are via an IDE (such as JBoss Developer Studio or Eclipse with JBoss Tools), and even via Maven.
For people that may not be comfortable with the scripting as you say, then you can't go past the Manage Deployments section in the Console GUI. The Console deployment does not move/copy the application to the deployment folder, so using both the Console and the Deployment folder can make for some effort in file management.
For bash-savvy users, the CLI is great, and is often recommended by the AS7 team as a preferred method of deploying and managing applications. The user guide section on the CLI is located here: https://docs.jboss.org/author/display/AS7/Admin+Guide#AdminGuide-RunningtheCLI.
An example of all deployment methods can be found on this YouTube video by one of the developers: "5 ways to deploy your application to JBoss AS 7". Hope that helps.

You only need .dodeploy for exploded deployments. If your deployment is a zipped war,ear,etc. then it will be picked up automatically.

Change your deployment mode from manual to auto which does this deployment automatically.
Steps :
1) Open your jboss configuration file : standalone.xml.
2) Look for deployment-scanner and add auto-deploy-zipped="true"
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir"
path="deployments" auto-deploy-zipped="true" auto-deploy-exploded="false"/>
3) Restart your Jboss.
Now it will automatically pick your zipped version of ear/war/jar/sar files for deployment.

You can still use your old scripts without using any markers.
This can be changed in the standalone.xml by changing the "auto-deploy" attributes on the deployment-scanner element in the standalone.xml configuration file.
More details can be found in the deployments folder README.

Problem migrating Spring Web App from tomcat 5.5 to tomcat 6.0

I have a spring web application which has been working fine on tomcat 5.5. I've attempted to deploy the same web app to a tomcat 6 container and come up against some issues.
The main two problems I've had are relating to configuring the container for jstl and getting the spring security login to work properly.
I believe I've solved the jstl configuration issue by including the jstl-1.2.jar lib from here in the $CATALINA_HOME/lib directory (although it really does appear to be strange that it is so difficult to find out how to get this working).
The main problem now is that when I attempt to log in using form based authentication, I get an HTTP 404 error when the login form is submitted to "j_spring_security_check".
I have set up the filter in the web.xml file as per the spring security documentation but it appears that tomcat isn't invoking this as expected.
I hope someone can share their experience here as I'm certainly missing something fundamental in my configuration.
Thanks.
Update: While trouble-shooting based on responses here, one of the things I ended up doing was downloading a fresh copy of tomcat 6.0.18 and ensured that I had the jstl-1.2.jar file in the WEB-INF/lib dir. Funnily enough, now the app seems to be working fine.
I'm a little stumped but I'll now try to track down the difference in the two tomcat installs that was causing the error and post a further update here.
Thanks for the responses to this guys.

if you use maven, you need for jstl :
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
<scope>runtime</scope>
</dependency>

It's too hard to tell what's wrong, based on the information you provided.
Common shared libraries used to go in common/lib in Tomcat 5.x and earlier; now they belong in the /lib directory.
Personally, I prefer putting as much as I can in the WEB-INF/lib of my deployments, because I don't want to have to depend on having a server set up in a particular way. If the classloader can find all the JARs it needs in my WAR file, I'm happy.
Both Tomcat 5.x and 6.x use the JSTL version 1.2 JAR, so that's common. It's the location that's changed. I'd recommend building your WAR file with the JARs you need in WEB-INF/lib.
If you're using Spring Security, the module formerly known as ACEGI, make sure you have those JARs available, too.
An HTTP 404 - sure it's not just a deployment or URL issue?
Try turning Spring security off by commenting it out of the configuration file and restarting. Your app should just come right up if everything else is well. Then you'll know that you have to concentrate on. If not, you can continue to search for what else is awry.

I agree w/ duffymo, not enough info. Try turning on verbose logging in your application and see if there's anything obvious in the logs.