In my office we use exploded EAR's (and inside them exploded WAR directories) for our test environments, and then a packaged one for production. I've yet to find a good explanation of the reason behind this though. I understand it's easier from a deployment perspective to push out a single file during builds, but it prevents us from doing things like property file changes without doing complete rebuilds (we could skip the compiles, but our environment currently binds the compile and jar processes together).
What are the major advantages / disadvantages between these two configurations?
Even if you deploy a single .ear file, the appserver will unpack it before using it, as well as unpacking the WARs inside that, and sometimes even the JARs also.
So the only benefit of single .ear files is one of deployment convenience.
Exploded ear - easy to update and manipulate individual prop files, class files, jsps and make surgical changes. You do from time to time wonder if the latest production code has all the latest changes because you move each file individually and it would be easy to forget something. When you deploy, you know exactly what file is being changed with a packaged ear you are updating every single class, jar, jsp in one fell swoop.
Packaged ear - simple, easy to deploy, you know with each deployment you are move ALL the latest changes. prop files are really weird when using an ear, you have to put them on the server(container) and create some kind of absolute path so you know where they are and they are separate from your ear build.
I think I prefer the exploded ear.
Related
We are using JBoss 7.1, with an Apache upfront (proxying the requests to the right place).
I need to separate my EAR project into several WARs (and one JAR), because it is becoming too large.
I wonder whether I should use several EARs and duplicate the JAR, or use the same EAR with several WARs.
The second option seems best to me (no duplicate code), but I would like to be able to redeploy only one WAR. But when I modify one WAR folder inside the EAR, the whole EAR gets redeployed.
Is that normal?
What's the best practice for managing several WARs related to the same backend logic (same EJB/JAR).
Thanks!
I want my Ant build to take all Java sources from src/main/*, compile them, and place them inside bin/main/. I also want it to compile src/test/* sources to bin/test/. I wan this behavior because I want to package the binaries into different JARs, and if they all just go to a single bin/ directory it will be impossible* (extremely difficult!) to know which class files belong where.
When I go to configure my build path and then click the Source tab I see an area toward the bottom where it reads Default output folder: and then allows you to browser for its location.
I'm wondering how to create bin/main and bin/test in an existing project without "breaking" Eclipse (it happens). I'm also wondering that if I just have my Ant build make and delete those directories during the clean-n-build process, that Eclipse might not care what the default output is set to. But I can't find any documentation either way.
Thanks in advance for any help here.
In Eclipse, you can only have one output folder per project for your compiled Java files. So you cannot get Eclipse to do the split you want (i.e. compile src/main to bin/main and src/test to bin/test).
You can, if you want, create two Eclipse projects, one main project and one test project, where the test project depends on (and tests) the main project. However, in that case, each project should be in its own directory structure, which is not what you are asking for. But this is a common approach.
Another way, which I would recommend, would be to not mix Ant compilation and Eclipse's compilation. Make the Ant script the way you describe (i. e. compile the main and test directories separately and create two separate jar files). Change the Eclipse compile directory to something different, for instance bin/eclipse. Use the Ant script when making official builds or building for release. Use Eclipse's building only for development/debugging. This way, your two build systems will not get in each other's way and confuse each other.
Hope this answers your question and I understood it correctly. Good luck!
We are going from a single WAR to multiple WARs to be repackaged within an EAR file in JBoss. I would like to be able to do the following:
Move common libraries to under the root of the new EAR so that they don't have to be duplicated within each of the WARs (I suppose under $EAR_ROOT/lib?).
Move the *-ds.xml file from under $JBOSS_HOME/server//deploy to under the EAR so that the datasource is scoped to the application (at least from a packaging standpoint - I realize there is no preventing a JNDI lookup from other WAR, that's okay).
Repackage the Hibernate DAOs and dependencies to a new to-be-shared JAR file and put them in the common location as well (to be shared by both the WARs).
I have some sense on what needs to happen but could use some help so that I don't have to create all of this structure and the related Ant/Maven targets/goals from scratch. For instance, should the datasource file be referenced in jboss-app.xml or in application.xml directly?
There seem to be multiple ways of skinning this cat and I am looking for a nice, clean example to do this (in the interest of not having to reinvent the wheel).
Use JBoss Developer Studio, it does all that for you
At my company, we use Weblogic (depending upon the installation anywhere between versions 6.1 to 11g).
Right now, we embed environment specific variables into our ears, jars, and wars. This even includes the weblogic.xml file where we have something like this:
<working-dir>/opt/bea/wl61/server/domains/deploy/prod3/temp/work</working-dir>
That means we have to rebuild the same jars, ears, and wars for each and every environment. And, if there's a change in the environment, we have to rebuild and redeploy the wars, ears, and jars. You can imagine the issues and problems we have with build and release management (which is my job).
At my last position, we used JBoss, and somehow were able to create generic and deployable ears. I would have Hudson build an ear that the developers could use for their testing. This same ear could then be passed to our QA team in their environment, to UAT, staging, and into production.
We could do this amazing feat because we configured JBoss to look for properties files OUTSIDE or the ear itself. There was a config directory that was a sibling to the deploy directory that contained any needed properties files. Is it possible to setup Weblogic to do the same thing?
We need a way to do this with minimal code changes. I've already examined the source, and we don't specify the directory name when we specify loading the values in the properties files. Therefore, we might be able to do this with some sort of CLASSPATH idea.
I understand that these properties must live somewhere, but I would prefer if it could be configured in the environment, and maybe done by having the path relative to the deploy directory. I want to use the same ear, jar, and war files no matter what system you are on: Windows PC desktop, Linux, Mac, or Solaris server.
The toughest issue will be our weblogic.xml embedded path. Can that path be relative to the deploy directory and not from the root of the system?
As I stated before, I'm the build manager, so as far as everyone is concerned, this is my headache, and not their problem. If deployments don't go well, the Finger 'o Blame can point directly at me.
In order to get this to done I have to be able to find a solution that's simple for us to implement. We can't rewrite everything and change everything around. Otherwise, I can't get the other teams to do this. After all, it's my issue and not theirs. We need something with minimal coding changes (preferably none) and minimal changes in our Weblogic setup. I want something that in Version 3.4 of our software, we do it the old fashion environment specific way, but in Version 3.5, we can deploy in an environmentally neutral way and do that with minimal changes in our deployment environment.
I can feel your pain - I went through the same process at a couple of companies. You have a couple of options that would be a significant improvement from your current setup:
1) Modify the CLASSPATH to use an external directory / properties file that overrides everything that is in the ear file. This is easy to implement but can get out of hand without the proper standards/governance.
2) Use deployment plans to define environment specific variables. However, deployment plans were not introduced until the WebLogic 9.2.
3) Roll all of your environment specific files in to its own jar. All environments would be pointing to the same file but it would be building out different contents based on your build process. Advantages - Single file that contains all the props, easy to move, etc. Disadvantages - Cannot change properties on the fly and force a reload from the JVM.
There may be other options based on the repository. IMHO, all of these work more or less the same - It's the process and enforcing it that prevents issues.
Experts
When we redeploy any application from an IDE such as MYEclipse , it just redeploys the .class files. I want to customize the eclipse developer, so the deployer can also deploy the custom files (other than class files).
Should i write any custom ANT script for Myeclipse or any custom settings the My Eclipse provides us ?
IDEs along the classes and libraries usually deploy everything they find in the web / www-root folder (in the folder that contains the WEB-INF and META-INF).
So you can configure your deployed applications structure using the IDE by structuring the content of that folder.
If it still doesn't fit your needs, then ANT would be the best option.
In my opinion ANT is always the best option, but using the development environment's functionality is proven faster then writing an ant build file.
Say, if you're developing a web service, a web application consuming that service, and a library that both the service and the webapp uses, then with a single (and not even long or difficult) ant file you can build them, create the aar, war and jar files and deploy them all in their correct places, eg. under axis, inside the global lib folder, and in the webapps folder.
All these in one step.