|
>> Yes. The WF tool has an option to bundle up the entire lot >> of converted panels as a WAR or EAR file, which WAS imports >> as a native Java app. > >This is one of the problems with WebFacing, IMHO. The >integrated WAR/EAR file does not coordinate very well >with the production environment of most shops, where >programs are independent entities to be modified, >tested and promoted. There is another option in the WF tool where you can export your objects individually. >This gets tricky. Normally, updating an application >means stopping and starting the web server for that >application, which brings down all sessions. Only if you deploy an EAR/WAR. If you deploy the individual objects (exported above) you are essentially replacing one panel at a time and not disrupting any other panels in the application (A/P, A/R, etc.) At this instant, I cannot speak to what happens to the users of that individual panel as I replace the various components that make it up. >Unless somebody can tell me different, I equate a >web module with an interactive subsystem - when you >bring it down, everything comes down. Sounds right to me. >And, as you might guess, PSC/400 doesn't have this problem. Neither does WebFacing. I updated many individual panels without having to restart the web module. In my "development/test" mode, I would re-face, export as a file system mapped to the iSeries and then run a CL program to move the newly deployed objects into the appropriate WAS directory tree. That's all there is to it. No restarting anything. I never got around to testing what happens if you replace a JSP while it's being served, but I suspect the user would simply see the new JSP when she returns to it. Better than replacing a display file! The only "tricky" part is replacing all the components at the same time. In PSC/400, that would mean replacing the JSP and XML together. If we managed to replace the JSP, then a request comes in and served, the XML is out of synch, not having been replaced yet. This problem is common to all multi-component applications on every platform regardless of vendor. --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.