× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



>> 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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.