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.
Related
I've been trying to come up with a clean way to include and display in a webpage build information from an EAR (containing the web app war).
My first instinct is to put the bulls metadata in the ear META-INF/MANIFEST.MF file. But the chance I have with that is that the ear's manifest is not part of the classpath and consequently there is no way to read it without using file operations - generally a no no in a JEE container.
Another option is to add the bulls info to the war manifest, but that isn't giving me the necessary info on the EAR.
Lastly, I could have the build process create a properties file in a jar in the EAR/lib folder, but that feels very wrong as well... Creating a lib on the fly like that screams poor practice.
Is there a clean/property way to do this?
In Java EE 6 and newer you can place <env-entry> elements in the EAR's application.xml file.
Therefore you can place whatever additional metadata you need into one or more <env-entry> sections and then load the values either via #Resource injection or good old fashioned JNDI lookups.
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.
I need to create 2 war applications deployed on tomcat server.
One of the applications have the exact same logic and code as the other application but with added changes to the view and controllers.
Then App1 and App2 will have the same code to access data and I don't want to duplicate code.
My idea is create 2 WARs and these WAR files should use a library or other project (I don't know) that has access to the database.
Which solution is the best for performance?
Option 1
If you are sharing code (and it's a big piece of code, which drives you crazy while uploading the war-files) it may be an option to create a jar containing the code and add the jar file to tomcats library-folder, which is ${CATALINA_BASE}/lib/
Note that this is usually not something you want to do lightly, because that jar file will be available to ALL war-files on the tomcat, creating possible namespace-problems.
Option 2
If sharing the code with all the projects on the application-server is not an option you'll have to add the jar-file to the projects and add it into it's classpath (which happens automatically within eclipse if you add the jar into ${PROJECT_ROOT}/WebContent/WEB-INF/lib).
Preformance-wise this doesn't really make a difference since tomcat will load the class-files, which are not very big. The instances might be, but the type of deployment doesn't really have an impact upon instances.
If you want to use the same classes for both projects just simple create one .jar file which will contain those classes. Then add that .jar into your web projects' classpath and use it in both.
You can extract the common part out, and make it as a jar. And then two wars use this jar as library.
If you used maven for building your wars, it would be easier to build a project hierarchy.
something like:
parent
|_common(jar)
|_war1
|_war2
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 would like to know what are the pros and cons, if any, of injecting or dropping java class files into an exploded ear file that is deployed in WAS 7.
When we install the packaged ear file it gets exploded into a certain temp directory and we can actually go into the folder location of the class file and replace it with our new class file and restart the server to load it.
If we are doing it for every node in WAS 7 and restarting them one by one for HA. would there be an issue.
Thanks.
Syed...
Here's another con to worry about. If you replace the file on the node and DMGR doesn't know about it, if you do a full sync the file from the DMGR will be pushed out to the nodes.
The recommended way to do this is to properly get the new file in the EAR and do another deployment.
You might encounter problems if the class contains annotations since application deployment caches the result of annotation scanning. Otherwise, you might be able to get it to work, but I doubt you would get support from IBM if something breaks. The supported mechanism for what you're trying to do is available via AdminApp.update in wsadmin.