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



Hi,

Apart from all these rules and restrictions where to install and put certain 
things, the problem only gets worse when you have an existing application 
writter in CGI technology.

If you're modernizing such a web application step by step, you can NOT keep the 
same directory structure (which is a nightmare owning a website that has a 
massive number of very valuable external links to it).

I tried various things with rewriterules in Apache, but I just can't get it to 
work (IBM remains silent on this as well).  In all these issue, what I can miss 
is that a application is forcing me a naming convention.

Kind regards,
Paul

------------------------
 Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx> wrote:
------------------------
        
>Joe,
>
>As usual, I disagree with you on this issue.
>
>First, the WebSphere documentation is simply trying to explain the default 
>location where WebSphere will install applications.  It is trying to 
>explain it in a platforn independent way since these docs apply to all of 
>the WebSphere platforms which use very different file system structures. 
>When you install an application in WebSphere you are free to install it to 
>your own root location.  There is some forced structure below that, but I 
>just do not find that the hard-ship that you do.
>
>I wish that WAS Express did not carry with it the extra things like nodes 
>and cells that are only needed in the higher-end versions of WAS, but I 
>can certainly understand the budget issues that go into making these 
>products and having a single code base is probably worth some of these 
>extraneous items being there.
>
>I really liked WAS 3.5 once I learned it and when WAS 4.0 came out I was 
>at first upset about the changes, just as I am upset about virtually all 
>changes.  Once I learned it, I came to appreciate it, and in my opinion it 
>makes installing an application much easier.  In WAS 3.5 having control of 
>the CLASSPATH and other settings was great, but it was easy to make 
>mistakes.  If you just had one server you controlled, then the flexibility 
>was worth it.  If you are someone that is providing applications for other 
>people to install, as is my situation, then WAS 4.0 + is much better 
>because the user cannot make a mistake.  My EAR/WAR file has everything in 
>the right location and the application automatically installs itself 
>perfectly every time - regardless of the platform.  In fact, it doesn't 
>even have to be WebSphere.
>
>I believe that a lot of these benefits could only be provided by using a 
>handful of magic filenames, like application.xml and web.xml and magic 
>folders like ./WEB-INF/classes and ./WEB-INF/lib.  Could those magic names 
>have been better?  Probably.  Who cares?  You learn it and move on.
>
>I do not think this is drastically different then install a normal OS/400 
>application and it is certainly much easier than installing a Windows 
>application.
>
>Mark
>
>
>
>
>
>_______________________________________________
>This is the Websphere Development Studio Client for iSeries  (WDSCI-L) mailing 
>list
>To post a message email: WDSCI-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
>or email: WDSCI-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/wdsci-l.
>



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.