Is it important how a war is called? Does it have any effect on whether it will work correctly? Let's say you're building a war with maven, naming it in one way and then manually rename it to some other name before deploying it somewhere on a server and running it, would it have any effect on working? Like deploy issues, etc?
Let's say with the maven war plugin you set it to generate something.war and later rename it to newfilename.war before deploying. What is your experience/knowledge there?
The name might matter depending on the servlet container: tomcat uses the name of the war file without the .war extension as the context path. This can be adjusted though using container-specific configuration files inside the .war file.
Obviously it would also matter in that case when you're trying to access it.
Related
I have an executable jar with a war file in it. Running the jar extracts the war file and creates a WebAppContext from it using webAppContext.setWar(warFile). Although that works, it seems that webAppContext.setWarResource(warResource) should work. I've tried it creating a resource using new PathResource("file.war") which shows a path like "jar:file:/Users/.../jetty-1.0.0-jar-with-dependencies.jar!/file.war". Sounds promising and conventional, but when I try it I get "java.lang.IllegalArgumentException: not file: scheme". Do I really have to extract the war file or is there a trick?
That would be a nested jar content reference and no Java program can do that.
Option 1: use a live-war (aka an executable-war) instead.
This would be a war file that can be deployed traditionally if you want to, but can also be used standalone from the java command line (and will start it's own server if it needs to).
An example project is maintained by the Eclipse Jetty project at ...
https://github.com/jetty-project/embedded-jetty-live-war
Note: the live-war concept was inspired by work done by the Jenkins project and their live-war.
Option 2: eliminate the WAR file layer entirely in your JAR
Don't package the WAR contents in your JAR as a filename.war, consider using it as an exploded WAR (or war directory) instead.
Just unpack the WAR into your JAR file somewhere safe (like /META-INF/webapps/<app-id>/) and then reference that directory location in your JAR file instead.
Option 3: eliminate the need for the WAR concepts entirely
This is the number one most popular choice.
You deconstruct your WAR file into a ServletContextHandler with configured Servlets and Filters, this also eliminates the need for things like annotation scanning / bytecode scanning (which is quite complicated), you'll also not have to wrangle the nested / isolate classloader (your uber JAR file contains all of the classes and downstream dependencies needed to run your webapp), and this approach will definitely speed up your startup time.
How I can set a war in an embedded jetty in a way that it can load from a classpath. Following is my current code snippet
webAppContext.setWar("hello.war");
Context :-
I want to secure my code other than obfuscation.so, I used Jetty to create a runnable jar and subsequently i used winrun4j to create an exe wrapper. The exe works fine when war file is found at same level but not otherwise even though i've embedded the war in winrun4j exe.
Problem:-
Is there any way that i can set the war in a way that it can pick it up from classpath rather than some pre-defined path.
Hope i communicated the problem statement in a lucid way.
Thankyou.
I came around the same and I always extract the war to a temporary location and then use the absolute path;
webAppContext.setWar("/path/to/temp/tmp262622522.war");
In any case Jetty will extract the war to a temporary location too, when starting the web app.
Is there a way to include environment specific properties or configuration file while building war.
QA
entity.url=http://qa.test..
prod
entity.url=http://prod...
I need to make around 5 to 6 REST calls. Url is different for each environment. Hence is there any way to configure environment specific conf file?
thanks in advance
The Play Framework has the concept of 'ids' that can be used for different modes see here:
http://www.playframework.org/documentation/1.2.4/ids
This allows you to do:
%qa.entity.url=http://qa.test..
%prod.entity.url=http://qa.test..
The one thing that might not be clear by their documentation is how to set this in a war. When running as a .war file, the play ID is set to 'war' by default. This can be changed in the web.xml of the .war file. You can do that or you can specify the ID when you create the war:
play war -o PATH --%prod
Not that I am aware of (and reading the python source for building the war does not indicate this is available). The war file simply builds up your Play application, as is. If you want to have a different configuration, then this may simply require the loading of it from an external resource (a property file that lives outside of the WAR, that you ship with your WAR file).
Alternatively, you could modify the python script that builds the WAR file to custom add additional properties to your file. Look in the directory framework/pym/commands/ and look at the war.py to read the source for the python war command.
I need some help figuring out how to make some changes to some .jsp pages that are contained inside of a .war package.
I am using jbilling opensource billing software and need to modify some elements/display and want to do it directly in the .jsp, so I unpacked the .war file and made a change, then packaged it back up and put it inside the webapps folder and restarted tomcat. But I noticed the filesize from the .war that I packaged was smaller than the original .war and it should have been larger because I added stuff to it. Needless to say, tomcat didn't start up properly, or at least there were errors in the logs..but they didn't help me and jbilling didn't work right. I reverted back to the orignal .war and it worked fine.
Is it possible for me to unpackage a .war and simply make some html changes, then repackage it up without having to recompile the whole source code with the java classes? Did I use the wronge "packaging" tool to compile it? Is there another way to accomplish what I'm trying to?
I did this in a FreeBSD box with using the following commands:
unpackage-->sudo jar cf ../billing.war *
repackage-->sudo jar -xvf billing.war
Thanks for your help.
Moreover, .WAR and .JAR (AFAIK all it goes for all .*AR) are basically glorified zip files conforming to some structural requirements (manifests, web app descriptors, etc.). The easiest way to do the changes you want are to handle the .WAR file as if it was a plain-simple ZIP file. The choice of the tools is all yours (archiver, pkzip, etc.).
You can simply open war file using archiver utility (seems you are using ubuntu).
Open jsp file from archiver util it self , make changes , and Archiver util will ask that jsp file has been modified you want to update your war file say yes there.
Note: If you are going to do only view changes than go for this tricky way otherwise if you are willing to change source java files than building the war will be strongly recommended
I basically want to be able to deploy multiple versions of the same EAR file to the same server (Glassfish instance?) , and have a unique path to each version separating them.
From my reading on this it appears that multiple EARs deploy to the root of the web server namespace so that they can coexist if they do not have colliding context-root's of WAR's.
In my case I'd rather have that instead of everything going under "/", I'd like to be able to brand a given EAR-file build to ALWAYS deploy under a given path like "/foo-20100319" or "/foo-CUSTOMER-20010101". This can easily be done with a single WAR file just by renaming it. I do not need or want them to disturb each other.
It is my understanding that this remapping is outside the scope of the application.xml file, so I found that http://docs.sun.com/app/docs/doc/820-7693/beayr?a=view says that I can specify web-uri and context-root, but I am not certain that what I wish to do, can be specified with these in Glassfish.
How should I approach this? I have full control over the build process.
(I have found Deploying multiple Java web apps to Glassfish in one go but I am not certain how to apply this to what I need).
The application.xml allows you to map a web app that is enclosed in an ear to the context root of your choice. You can also do this with the sun-application.xml.
Since you have full control over the build process, the choice is yours.
You may want to read about the --deploymentplan option of the deploy subcommand of GlassFish's asadmin utility. It allows you to mix additional files into the deployed archive before deployment processing... So, you can create a single 'generic' ear file and a number of shorter deploymentplan files, that 'mix-in' the sun-application.xml file necessary to create a customized deployment.