I have more than 20 ears files and I take a lot of time to deploy each ear alone using Websphere portal, so I'm looking for a solution to deploy all ears only one time.
You can try wsadmin scripting http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.0.0/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/trun_app_set_dragdrop.html
I never tried it, but it seems you can create special directory, copy ears into and all ears will be deployed automatically
WebSphere Portal has a packaging formate for many artefacts and it includes ear files as well. If you package your files based on the Portal Application Archive (PAA) definition you can use the Solution Installer to have them all installed in one shot and do more.
The ear file deployment would be simple by putting all ear files into a directory inside of the PAA named installableApps/ear. You need to follow some configuration steps but at the end you have a method to install and remove your full solution at once (or build multiple packages and install them as you want)
For reference the Infocenter link
http://www-01.ibm.com/support/knowledgecenter/SSYJ99_8.5.0/config/si_paa_spec_compdir.dita
Related
As part of cost cutting, management want to cease usage of websphere application servers in developer systems.
I was given task to convert the EAR file to one fat OSGI bundle and deploy it in equinox container. if successful, this set up will be shared among developers and will only be used in developer machines and not in higher enviroments.
I have searched many websites but didn't find any concrete solution.
Kindly share your ideas if any to solve the problem.
I strongly encourage you look at Open Liberty: https://openliberty.io
Open Liberty is an open source project launched by IBM last year at Java One. The goal of the project is simple: get awesome Java EE technology into the hands of developers.
Open Liberty supports Java EE 7 and MicroProfile as well as other technologies.
Unless you have a strong technical reason to convert the EAR into an OSGi bundle, you can use Open Liberty in your development environment. The install is easy:
unzip openliberty-18.0.0.1.zip
Give it a try. I think you'll be pleasantly surprised.
If you have questions, Open Liberty has a very active community and twitter or hit me up on twitter #barecode.
An EAR file is simply a JAR file that contains nested JAR files. Those nested JARs form the classpath of the application.
Converting to an OSGi bundle should be as simple as writing a META-INF/MANIFEST.MF for the top-level JAR containing the header Bundle-ClassPath header that lists the contained JARs, e.g.:
Bundle-ClassPath: a.jar, b.jar, c.jar, ...
If the EAR file also directly contains classes that are part of the application classpath, then the new bundle's JAR file should be prepended to the Bundle-ClassPath as an entry named '.' (dot), e.g.:
Bundle-ClassPath: ., a.jar, b.jar, c.jar, ...
Note that the manifest also needs to contain the mandatory OSGi headers, Bundle-Manifest: 2 and Bundle-SymbolicName: .... There is plenty of information available about this online.
I came across a curious discovery a few days ago with my windows file system, which uses NTFS.
I have a folder within my file system my gradle projects use as a cache. Within this folder, are many different folders containing java .jar files used as dependencies for my project. Typically, these jar files are downloaded from the cloud storage system our project uses for storing these jars. There are three different ways I update these jar files.
I can do a complete refresh through my gradle project, in which every jar in my cache is updated. This takes alot of time and is only done when absolutely necessary
When I want to get the most recent version of a single jar, I will delete the jar file, and refresh my project. The project internally reaches out to the cloud storage system and downloads a new jar.
When I do local development and want to test my changes, sometimes I will replace these jars(overwriting the previous jar) with a jar I developed locally for testing.
However, if any of my java applications using these jars are open, I can only replace the jars, I am unable to delete them. If I attempt to delete them, I receive a The action can't be completed because the file is open in Java(TM) Platform SE binary. To delete the jar for following step 2, I have to close my entire project before deleting.
I have read here, here, & here on why this is the case, however I cannot find a concrete answer on why Microsoft NTFS will allow me to overwrite the jar with another when it is in use, however I cannot delete the jar while it is in use. Why is this the case?
We are using some library that doesn't work for some reason if the WAR is expanded under the apps folder. When the eclipse tooling publishes the WAR to a remote server, the WAR is expanded. How do I prevent the server from unzipping the published WAR?
If an app doesn't work when expanded, but the exact same app works as a binary, then that indicates something wrong in the server. I'm not aware of specific cases where we wouldn't support an expanded EAR instead of an EAR binary.
It sounds like you're this far already, but the first thing to check is if you're using resources inside of the workspace or inside of the server. You can check this by looking at the server on disk and seeing if the apps directory has either something like TestWar.war.xml or TestWar.war (directory).
To move the resources to the server, if you are using something like WDT (the Eclipse tooling you get from dragging the icon on wasdev.net into your Eclipse workspace) you can modify the Liberty server settings to do this.
In the Servers tab, double-click the WebSphere Application Server Liberty entry and you should see the Overview configuration screen. Uncheck Run applications directly from the workspace and now if you look at the server on disk you will see the files directly inside of the server.
But, to answer your question, it's not so much that we're unzipping the published WAR so much as we're not zipping it to begin with. If you right-click the EAR project and go to Export that's a one-off way to make an EAR binary, but otherwise you may want to look at a simple build description system through Ant or Gradle or Maven along with similar standards to build the archives.
We're working with a very large EJB application that is built and deployed using Maven to a TomEE server. Currently we pack everything into one EAR file, but this means even minor changes by our developers require extensive build and deploy times to try out.
Is it possible to split an EJB application into multiple EAR files (I assume it must be) and if so how can we have TomEE know which EAR files to load?
Splitting up large EAR application to smaller EAR application doesn't have anything to do with "TomEE knowing which EAR files to load" . Basically it deploys EARs that you have published to the container.
If your application is already modularized then you can think of making each/set of modules to be a EAR. Only catch is you'll have to modify the EJB look-up in the code to include module name.
If this is purely about packaging and deployment issue then it should be easy to do. If it is about highly coupled application with lot of inter-dependencies then you are standing at the point of re-organizing/re factoring your "big" application
I'm currently working on a project that consists of several services written in Java that are accessed by a Ruby/Rails front-end. In an attempt to simplify local development, I've created a separate project that adds all of our service WAR projects as dependencies, and uses the cargo-maven-plugin to deploy each of these as a deployable inside of a single embedded Jetty instance.
The issue I'm having is that I'd like to be able to tell cargo to re-deploy a single WAR out of the several that are being run at a time. Starting the entire set of services from scratch takes a bit, and is really unnecessary when only one deployable has actually changed. As far as I can tell, the cargo:redeploy goal only works for non-standalone containers, and I also haven't been able to find any documentation that its possible to specify what you want to re-deploy on the command line.
Is there a way to tell cargo to re-deploy a single deployable from the command line? I'm thinking of something along the lines of mvn cargo:redeploy -DgroupId=com.foo.bar -DartifactId=baz
Apologies if this isn't clear, or if there is a different approach that I should be taking entirely - I'm relatively new to Java development and Maven.
Thanks for any help.
Download the latest war file to your local machine, then redeploy using the following pattern:
mvn install:install-file -DgroupId=com.foo.bar -DartifactId=baz -Dversion=1.x -Dpackaging=war -Dfile=C:/cargo.jar