I wonder if this is a somewhat awkward way of thinking, but I couldn't really find any hint on the internet to my idea. Maybe I just did not phrase my question right, but anyhow, this is what I would like to do:
I have a complex application written in java with spring and quartz and a whole load of dependencies. The application is run inside an apache tomcat servlet container. Now I know, I can create a war file and deploy that to the productive server machine (after our internal IT has installed and configured the tomcat on that machine), but I would like to do this a bit different.
I would like maven to create a pre-packaged tomcat application server with all dependencies and configuration settings AND my application. In effect, all that would need to be done on the productive system is, copy the package (or zip or tar.gz or whatever is needed) to the server, unpack it in a directory of my or their choice and fire up this local isolated tomcat. It would only run my application (which poses enough load on the machine anyway) and I could even go so far and deploy a second variant, say for a different customer in the directory next to the first one. Neither of both could interfere with each other, even if they use different versions with different dependencies.
Is it possible to do that? Is it a desirable approach or am I on the completely wrong track here?
What I think would be a benefit of this approach (despite the thing with incompatible dependencies or settings between two or more different installations) is, that I can hand the whole package over to our administration guys and they can simply deploy it to a server without the need to configure anything in the tomcat after installing it and so on.
Any hint???
Create a Maven project as the parent project (type pom). Include your webapp as a module project (type war). Create another module project, maybe "myapp-standalone" (type jar) and include the Embeddable Tomcat as a dependency. Write a starter class to launch the internal Tomcat (see executable jar / überjar). When building the app, copy the created war file into the jar, into Tomcats webapp directoy.
Your launcher class needs to make sure, that the ports of the current Tomcat are not yet in use.
Related
I know that in Grails framework, you can build a war file using
grails war(builds a production war)
or you can build a environment-specific war file using
grails test war
Now, what I am having trouble understanding is, if I build a war file using grails war but deploy it to test environment (where -Dgrails.env=test), the war file built using grails war command runs happily by picking up **test ** environment settings(like pulling data from test urls instead of prod urls).
My question is: what is the point of building a war file using a environment-specific command (ie. why use grails test war when the war file built using grails war works everywhere?).
Am I missing something obvious?
The reason for using an environment is because you may code in your application that hooks into the build process and alters the resulting WAR based on the environment. Such as re configuring some filters in web.xml for instance. It's an extension point. You can use it if you need.
Grails holds three automatic environments: dev, test, prod. there are some
defaults for the various "scripts", e.g. run-app runs dev, test-app runs test,
war build a war for prod. these are there for convenience and make the most
sense from the daily usage patterns for developers. e.g. in testing the
default is an in-mem db.
You can also add more environments, as you see fit. E.g. having an staging
or integration environment is common, so by providing such an env (maybe
only some config or db changes) you can easily build a war file for the server
you use for your QA team.
Another use case is to just build a dev war, as there might be something odd
with the war on the production server and you just need to run the war against
that odd tomcat 6.x real-life environment, but with the dev setting against
your db.
That said, there still is the config you can add via config files, but the
environments give a rather sane setup for "all involved", as they are usually
within version control.
And as a final step you still have access to the environment in your own
scripts/_Events.groovy hooks, where you might e.g. drop or add something,
but that only makes sense for that exact environment (e.g. drop some jars, as
they are on the server already).
At the end, this features gives you some freedom to do what you want. Be glad, if you never have to use it. But once you need, you'll be glad it's there.
I am having war file deployment at customer site. War file contains lib folder which contains dependent jars e.g.
/lib/app-01.jar
/lib/spring-2.5.1.jar
/lib/somefile-1.2.jar
...
...
If we need to update lets say app-01.jar to app-02.jar, is there any elegant solution? how does these dependent jars are packaged into WAR file as industry standard?
Is it good idea to package those dependent jars without version number?
e.g.
/lib/app.jar
/lib/spring.jar
/lib/somefile.jar
...
...
EDIT NOTE:
Actually, War is deployed to Webshpere, WebLogic, Tomcat on Windows or Linux platform. And Customer's IT department is involved for deployment
Probably the most elegant solution is just to generate a new war, and deploy it.
Here are the reasons:
If you are worried about uptime, some application servers supports side by side deployment. It means that you can deploy a new version and have it up at the same time of the old one. And stop the old when no one is using it. (I've used that on WebLogic, like 5yrs ago, so I suppose that is a common feature now). But that kind of feature only works if you deploy a new .WAR version.
Probably the WAR was generated using Maven, Ant or Gradle, so changing the dependency version and do a mvn package is usually faster and less error prone than unzipping the WAR, change it, and zip it again.
All the application servers provides a "hot replace" feature, that works by refreshing the class loader. Its fine for development, but in production it can be problematic (class loader leaks can be common, and problems caused by incorrect initialization or bad programming practices can give you unexpected bugs like having two versions of a class)
About JAR file names: I recommend to keep the versions on the file name.
Most of the JARs contains version information inside META-INF/Manifest.mf. But if for some reason you have to know which versions are using your app... opening each JAR file to see the version in the manifest is a lot of work.
As a final advice. If you don't use any automatic build tool... adopt one (take a look to Gradle, which is nice). Updating a library version, usually consist on changing the version number on the build file and execute something like gradle deploy. Even if you are not the developer, but the one in charge of devops, having an automated build is going to help you with deployments and updates.
In Tomcat I don't think the war is relevant after the files have been uncompressed. You could just ignore the war and extract the new/changed files into the correct webapp's directory (The one with the same name as the war.)
In my GWT web app I am keeping all my jar files outside of my project and referencing them using classpath variables. This allows me to link to jars from other projects/teams without having to put a copy of the jar in my web app lib directory. Hosted mode kindly looks up the classes in this system classpath and then adds them to the web-app classpath warning me that it is doing so. When I deploy my build system pulls in only the jars I need to ship in my web app and is not a problem.
The issue I have is that some code uses dynamic lookups, searching the classpath for implementations. If a jar has not yet been added to the web app classpath beacuse no classes have yet benn loaded from the jar it is not included in the search.
The particular problem I am having is with Persistence - it looks up EntityManagerFactory implementations by searching for META-INF/services files. I have also had a similar problem with Rome and its module extensions.
I have got a workaround, in the dev/hosted mode I simply refer to a class I know is in a jar I want and this causes it to be added to my web app classpath. I do this my by calling
private void devModeClassPathHack() {
Class<?> gwtDevModeHack1 = EntityManagerImpl.class;
}
from my development mode Guice module.
My question is simple - is there a "nicer" way of doing this?
I don't think, there's a nicer way - using this makeshift "self-healing" mechanism of the GWT Jetty/dev mode is already a hack :) If you ever have the need to run the server side code on e. g. JBoss during development (together with GWT dev mode for the client side), this will stop working.
(As an additional problem, the order of classloading - and consequently the precedence in cases when there are multiple versions of a class in different jars - will depend on program flow. This can be very nasty to debug.)
You mention, that you pull in all the jars from outside. What I would do in that case, is to set .svnignore (or .gitignore/...) to "*.jar" in the WEB-INF/lib dir. Then I'd run the same build step which is used to create the production build to copy the jars into the lib dir before starting the server.
How we can define the term "deploy a package"?
Is correct to say that to deploy a package means to make a procedure
in which we create, put into a file system location and make them visible
to the compiler an VM with options like -classpath CLASSPATH etc????
How we can define the term "deploy a package"?
It depends on that kind of package you are talking about and what kind of deployment you are talking about.
For example, you probably wouldn't talk about deploying a Java package, because a Java package is not normally a sensible "unit of deployment". (Normally you would deploy a Java application or webapp, or possibly a Java library. And in the context of Maven, you would deploy an "artifact".)
If you are not talking about a Java package, what kind of package are you talking about?
Is correct to say that to deploy a package means to make a procedure in which we create, put into a file system location and make them visible to the compiler an VM with options like -classpath CLASSPATH etc????
That doesn't sound like a conventional definition of deployment to me. For a start, there is no standard file system location to deploy (for example) JAR files to.
I have become accustomed to the way maven uses the word deploy.
The deploy plugin is primarily used during the deploy phase, to add your artifact(s) to a remote repository for sharing with other developers and projects. This is usually done in an integration or release environment. It can also be used to deploy a particular artifact (e.g. a third party jar like Sun's non redistributable reference implementations).
I am not saying that your definition is incorrect, it just doesn't rhyme with my interpretation.
I would separate "build" from "deploy". Building would take source code and construct a deployable artefact. In this case we have some .java files, we compile them to .class files and (usually) put them in a JAR. The JAR is the thing that we deploy. In Java EE we might go a step further and put several JARs (and WARs ...) into an EAR and deploy that.
So deploying is making the deployable artefact executable in a runtime environment, in this case making the JAR visible to a chosen JVM. Quite possbly you might have many runtime environments, many customers, many machines. You build once, deploy many times.
In practice we often find that there's a little bit more to doing the deployment than just getting the JAR onto a Classpath. You often find you need to:
Remove previous versions of the JAR, possibly keeping then ready for to be reinstated if something bad happens.
Make other resources available, eg. databases
Do some environment specific configuration
Validate the deployment by running some kind of tests
Restart dependent components
Keep an audit trail ofthe deployment
In non-trivial cases it's often very useful to automate steps such as these using scripts.
I have a J2EE application that needs to be distributed to customers, who will have application servers of their own choice. What is the recommended way of writing a build script that would compile the J2EE application sources (at customer sites) so that they will eventually be able to deploy the application on their servers ?
Moreover, what JARs should one actually use during the compilation process ? Since this is meant to an application server agnostic script, is it recommended to use the JARs (say servlet.jar, jms.jar, ejb.jar etc.) from the application server, rather than having my customers download these JARs from a particular repository ? Is there any such repository that is recommended for such JARs (JARs of J2EE APIs) ?
PS: The EAR file cannot be built locally and shipped to customers, since additional development will be done at each installation to integrate with other systems, perform customizations on the application etc.
Build the application locally, and distribute the WAR/EAR files to the customer.
Edit:
The situation you describe is basically that you need to provide a code base for further development by the customer. In that case I would suggest that you look into creating maven modules of your work which are pushed to a private repository accessible by the customer. You then let them know that they need to depend on module X version Y in their pom.xml, and module X then pulls in all the libraries needed in the correct versions.
Note that if they don't use Maven, they might use Ant Ivy for the dependency resolving.
Some generic J2EE API jars can be found at Sun's site, however you might have to dig a lot to find them.
I would just use any JAR you have handy, bundle it with the source, but away from /WEB-INF/lib
Basically, don't include the container jars (servlet.jar, jms.jar, ejb.jar etc.) in your EAR or WAR file.
If you are just talking about servlet.jar, the web container provides that - you shouldn't include it in your war file.
If you are creating an EAR file, they you must be using an enterprise container and it will have a JMS.jar and EJB.jar.
JMS on Tomcat would be a little trickier - you'd need people to install something like activemq on their servers.