|
> From: Mark Phippard > > As for deployment, while it is true I use my tool, I was mainly referring > to the technique of copying the files in the IFS. I do not > understand why > you object to this method? IBM supports the concept, if they didn't then > they wouldn't have all of that documentation I pointed to. Mark, this is not support. Let's look at the IBM documentation: "Locate your expanded application files. The application files are in the directory you specified when installing the application or, if you did not specify a custom target directory, are in the default target directory, install_root/installedApps/cell_name. Your EAR file, ${APP_INSTALL_ROOT}/cell_name/application_name.ear, points to the target directory. The variables.xml file for the node defines ${APP_INSTALL_ROOT}." How do you figure out which objects need to be replaced using this method? For example, where does cell_name come from? Or $(APP_INSTALL_ROOT)? Where is variables.xml for the node? What the heck is a node? My point is that you can probably use this technique if you know exactly which files are being changed, and are very well versed in the structure of WebSphere. With WebSphere 3.5, and to a lesser extent Tomcat, you had complete control over these locations and could define the directory structure in a way that made sense to you, and then simply do a one-time configuration to configure you web application server instance to use it. Now, you have a very strange and cryptic deployment structure that is basically hard coded by somebody at IBM with no thought to your business. Again, the good news is that symbolic links can save the day for the most part. The biggest problem is when you want to draw from multiple locations (like a common area and a custom area). While this is easy to do in a real business environment like OS/400 (you simply add a library to your library list), in Unix it's quite a bit more difficult. There really is no concept of a library list for many objects in Unix, especially for web application objects. But this is a web thing, not necessarily a WebSphere thing. In any event, if this were truly supported, you would be able to select a subset of your web application in WDSC and "hot deploy" it to the iSeries with a single button. But since there's no such thing in J2EE, WDSC doesn't have it. That's my problem with J2EE and with the WDSC team adhering so tightly to the J2EE conventions. > Other than the quantity of files involved, how is this so different from > manually deploying some "normal" iSeries changes? You have to > copy source > from one source file to another, do recompiles etc... What does OS/400 > provide for deploying apps that isn't also provided by WebSphere? There > are CL commands for everything you need to do, just as there are for > normal OS/400 changes. I wish WebSphere came with some CL commands for > stopping and starting applications and servers, but at least they do have > a programming language that lets you script changes. I disagree completely with this statement. The concept of nested folders with hardcoded magic names like "WEB-INF" and "cell_name" is completely different from libraries and library lists. If you don't recognize the difference then you've been assimilated. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.