We're currently figuring out how we can apply Subversion to our development cycle. It is apparent to us that each developer should have their own working copy (and another one for the acceptation environment). However, we don't want to have a local copy of the IIS server, tomcat and all the development and data files on each developer machine; we'd much rather keep them on our test server.

So we've been trying to set up our IIS6 server on Win2003 to host WebFOCUS on multiple ports (80 & 8081 respectively), but somehow we can't get it to work - files are served just fine, but anything depending on the WFServlet sends HTTP 404. This seems to indicate a problem with Tomcat, but everything's so hidden away from the user that I don't know where to start looking...

(Even worse, while trying out different things somehow a file in one of the web site configurations got "wedged" and IIS Manager comes with the message "The proces cannot access the file because it's being used by another proces" when trying to start that it - thanks for the detailed description Microsoft, do you employ many bald people?)

Is there a step-by-step guide of how to set something like this up?

This message has been edited. Last edited by: Wep5622,

It turns out that the port we were trying to use was in use after all, hence our troubles and the "helpful" error message.

It's working now, we got 3 development webfocus environments with each their own subversion working copy - great!

We thought we had this solved, but a new problem popped up...

It turns out that WebFOCUS and Developer Studio still use the single (old) environment, even though the web-server is serving us the new ones. I pointed Dev Studio to my new environment, which lives in my working copy D:\ibi\apps_hertroys_a at our server at port 8301, but if I edit files I see them change in our acceptation environment at D:\ibi\apps at port 80 on the same host instead!

That's not what we intended, and it makes version control difficult. Is there a setting we missed? IIS seems to do all the right things, but it would appear WebFOCUS isn't...

We do this. Check to make sure the ISS built the virtual directories correctly you should have a separate approot for each but ISS sometimes doesn't build them for you. And make sure in dev studio for the protocol for the web component that use default is unchecked and you have the right alias coded.

IBI put out a Tech Memo on this subject awhile back. It's for release 7.1 but everything still applies. It's tech memo 4595.

See if you can get to it with this url:

http://documentation.informati...pdf_wf_71/tm4595.pdf

Bob

Thank you very much, that seems to be what we're looking for.

One question though; the document explains how to install a second Apache Tomcat server in a different location on your hard drive. Wouldn't it be easier to just configure the existing Tomcat server to also listen on another port/hostname?

I'm pretty sure Tomcat is capable of doing that, but the last time I did any Tomcat configuration is a couple of years ago and I seem to have forgotten pretty much all about how that works... (it was the sysadmin at the company I was working for at the time who handled most of that anyway)
Or is there some problem with that on Windows? (Boohoo, I miss my shell!)

Yes, you can configure Tomcat to use a virtual host instead of installing the second Tomcat server. The document mentions it can be done be it doesn't get into details. I've always used the virtual host method in the past.

If you go to the Tomcat Admin screen, click on Service, and then under Service Actions you can Add a new host.

I think the basis for understanding this is to know how the WFServlet determines which files to serve. Does it get the files from IIS (through the ISAPI maybe?), or do we have to tell Tomcat where those files are? Or maybe we have to tell the servlet in some configuration file of its own?

I'm also not really sure why we'd even need multiple virtual hosts (or preferably ports, in our case) on tomcat. Is that to keep the different sessions apart?
We have several different "Web Sites" in IIS, listening on different ports, but with just that we don't seem to get the correct files served (both in our browsers and in Dev Studio). Apparently that doesn't suffice...?

quote:

Originally posted by CLH:
We do this. Check to make sure the ISS built the virtual directories correctly you should have a separate approot for each but ISS sometimes doesn't build them for you. And make sure in dev studio for the protocol for the web component that use default is unchecked and you have the right alias coded.

We don't use virtual directories, that would mess up our css and javascript includes. Instead we use different ports, so "Use default" should be okay.

The reason the document shows setting up multiple Tomcat installations is to allow you to recycle each Tomcat instance separately.

If you are fine with recycling Tomcat resulting in all instances being recycled, there is no reason why you can't simply use a single copy of Tomcat.

You can do this through adding additional listeners to Tomcat. Take a look at:
/Tomcat 5.5/conf/server-minimal.xml

Since it has a lot of the extra junk out of it, it makes it much more clear. If you use this file you will of course need to rename it to "server.xml" after making any modifications.

I haven't actually run this, but this should start a second listener on 9080, with a 9009 AJP listener:

<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">

  <GlobalNamingResources>
    <!-- Used by Manager webapp -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
       description="User database that can be updated and saved"
           factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
          pathname="conf/tomcat-users.xml" />
  </GlobalNamingResources>

  <Service name="Catalina">
    <!-- If only connecting from IIS, you can actually omit this line -->
    <Connector port="8080" />

    <!-- This is here for IIS ISAPI filter to connect with. If not using IIS, its not needed -->
    <Connector port="8009" protocol="AJP/1.3" />

    <Engine name="Catalina" defaultHost="localhost">
      <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
             resourceName="UserDatabase" />
      <Host name="localhost" appBase="webapps" />
    </Engine>
    
  </Service>
  <Service name="Catalina2">
    <!-- If only connecting from IIS, you can actually omit this line -->
    <Connector port="9080" />

    <!-- This is here for IIS ISAPI filter to connect with. If not using IIS, its not needed -->
    <Connector port="9009" protocol="AJP/1.3" />

    <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost" appBase="webapps" />
    </Engine>
    
  </Service>
</Server>

Another option is to use HTTP Host Headers to separate the different installations. When doing this you would setup different DNS names that point to the WebFOCUS Client machine.

e.g. Assuming the following DNS names would send you to the WebFOCUS Client:
deva.webfocus.local
devb.webfocus.local
devc.webfocus.local

Your server.xml could look like the following:

<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">

  <GlobalNamingResources>
    <!-- Used by Manager webapp -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
       description="User database that can be updated and saved"
           factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
          pathname="conf/tomcat-users.xml" />
  </GlobalNamingResources>

  <Service name="Catalina">
    <Connector port="8080" />

    <!-- This is here for compatibility only, not required -->
    <Connector port="8009" protocol="AJP/1.3" />

    <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost" appBase="webapps/localhost" />
      <Host name="deva.webfocus.local" appBase="webapps/deva" />
      <Host name="devb.webfocus.local" appBase="webapps/devb" />
      <Host name="devc.webfocus.local" appBase="webapps/devc" />
    </Engine>
    
  </Service>
  
</Server>

The defaultHost entry above determines which Host will be run if the host header name passed does not match any of the names in the list. In this case it will run the "localhost" Host.

With the above server.xml to deploy a web application to "deva.webfocus.local" you would either copy the web application to:
/Tomcat 5.5/webapps/deva/

or you would create the context xml file under:
/Tomcat 5.5/conf/Catalina/deva.webfocus.local/

NOTE: You will likely have to create the above directory since it will not exist.

----

When using separate ports on IIS (first technique), you will define a separate "web site" for each instance of WebFOCUS which points to the appropriate approot and ibi_html folders for that instance, and the Jakarta ISAPI filter pointing to the proper AJP port. If you wish you can do the same thing in IIS with the host headers and have each host header in IIS redirect to a separate IIS web site, however, this is not required.

With the Host Headers technique you can have a single "Default Website" and have it redirect to the single AJP port, and Tomcat will send the request to the appropriate web application based on the host header. If you do this and want each WebFOCUS Client instance to have a different approot folder, simply don't define approot on IIS, but instead add:
/approot/*=ajp13w

to:
C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\conf\uriworkermap.properties

This will make Tomcat handle the requests for "approot", allowing you to define approot just like any other context in Tomcat.

Thanks for the explanation.

It looks like requesting multiple CNAME's for our dev-server and using those to set up multiple WebFOCUS environments will be a lot easier than those obtuse port numbers we were planning to use originally. Even though we'll have to poke our sysadmins to configure those CNAME's for us, it looks like it's a lot less of a hassle to get it all done, and the end result is easier to remember as well.

I suppose that's the "proper" way of doing things. I like that both servers will automatically know which files to serve based on which hostname they got the request for, I hadn't realised those hostnames would be so useful for configuring the different components of the server. Definitely a lot easier than using port numbers.

I'll let you know if we run into any more problems setting things up, but I expect not.

Do I understand correctly that we need to copy all 140MB that is the webapps/webfocus76 app to (in our case) a webapps/testfocus1 directory and then change the ibi-apps.xml in the tomcat/conf/testfocus1 to point to that directory?

I get the feeling that there is a more efficient approach, copying 140MB around for every virtual host seems a bit heavy-handed...
Of course if this would have been a UNIX machine I could have simply made a symbolic link (or a hard link even) instead of copying. I don't suppose Windows shortcuts would cut it?

Or is there a better solution?

-----

Copying the webapp doesn't seem to make any difference... I get the correct HTML files from IIS for my virtual host, but everything that's calling the WFServlet still returns files from localhost. The same for developer studio. This is getting really frustrating!

server.xml contains:

    <Engine
        defaultHost="localhost"
        name="Catalina">
      <Realm className="org.apache.catalina.realm.UserDatabaseRealm"/>
      <Host
          appBase="webapps"
          name="localhost">
      </Host>
      <Host
          appBase="webapps_2"
          name="testfocus1">
      </Host>
    </Engine>

I have these directories in C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\Catalina:
localhost
testfocus1

Both directories contain the same files, with ibi_apps.xml in testfocus1/ modified as follows:

<?xml version="1.0" encoding="UTF-8"?>
<Context
    docBase="D:/apps/ibi/WebFOCUS768/webapps/testfocus1">
</Context>

In D:\apps\ibi\WebFOCUS768\webapps I have directories:
webfocus76/ (as installed by the installer)
testfocus1/

The contents of testfocus1/ are an exact copy of the contents of webfocus76/.

In IIS I have two websites, each with one of the above directories set as Home Directory. The ISAPI application is the same executable for both.

What am I missing?

This message has been edited. Last edited by: Wep5622,

As long as you don't mind the WebFOCUS Client portion using the same file system, you can have all instances reference the same web application location.

There are references in the web.xml that locate the basedir and other files, however. As a result if you're trying to keep this all separate you'll actually want to run the WebFOCUS installer for each instance.

If its fine for them to share MR and other info, you can use the same web app.

quote:

Originally posted by dlogan:
As long as you don't mind the WebFOCUS Client portion using the same file system, you can have all instances reference the same web application location.

There are references in the web.xml that locate the basedir and other files, however. As a result if you're trying to keep this all separate you'll actually want to run the WebFOCUS installer for each instance.

If its fine for them to share MR and other info, you can use the same web app.

I'm trying the opposite of keeping it all separate, I want to re-use as much of our existing WebFOCUS installation as possible, except for which fex-files are served per vhost.

It appears the references are not so much in the web.xml, but rather the approotConfig.xml high up in the WebFOCUS directory tree. That doesn't look promising for what we're trying to achieve...

Is there some way to override the approot per vhost (for example, in the web.xml)?

Yeah, its simple.

Have ibi_apps.xml and rcaster.xml point to the same two web applications.

Have ibi_html.xml point to the same file structure.

Have the approot.xml within each environment point to a different file path.

(All of these are talking about the Tomcat context XML files under conf/Catalina/HOST_NAME/

Well, it took me all morning, but I managed to figure out what you were talking about... sort of. It didn't help though.
What it did give me was an opportunity to check whether I get the correct fex-files back from each host, as HTTP requests using the (configured as per your suggestion) approot context now give me their sources.

I think you misunderstood my requirement about overriding approot. I was talking about overriding this portion of the approotConfig.xml file in the WebFOCUS config directory:

<document-root>
  <document-root-uri>approot</document-root-uri> 
  <document-root-dir>D:\apps\ibi\apps</document-root-dir> 
  </document-root>

The effect I want is what you would get by assigning that parameter a different value for each virtual host. As I understand it, this is the parameter that WFServlet uses to figure out where to get its fex-files from, which is what we're having trouble with right now.

I don't understand why it would be so hard to set up multiple development environments on a single WebFOCUS host. That should be a fairly common requirement, isn't it?

Further investigation seems to turn up that the above parameter isn't relevant to WFServlet.

What is it that determines where WFServlet looks for fex files? How can I change that?
And is that same setting used to initialise &APPROOT?

All of this of course per virtual host.

WFServlet looks for its approot environment to the path that has been set in the cgivars.wfs file. You can find this file in the drive:\ibi\webfocusxx\client\wfc\etc directory. It is the very first variable in this file. You can also change it from within the webfocus administration console (option General).

I found that file. What is unclear to me is what runs the WebFOCUS client and if/how it's possible to have that depend on the virtual hosts that host the focus files?

(Fixed a grammar error that may have made my question less clear)

This message has been edited. Last edited by: Wep5622,

Not exactly sure what you're asking here. But I'll give it a go:
There are three areas/products/pieces that need to know where approot is.
1. the web server - hence the alias approot for either IIS or tomcat.
2. the webfocus client - that is what the cgivars.wfs file is for.
3. the reporting server - it gets the approot value from the edaserve.cfg file in x:\ibi\srv77\wfs\bin
These three areas need to point to the same directory structure for things to work ok. If you need/want a different approot for each installation on your pc, then these three areas have to be configured the same, otherwise you may end up with mixed paths.

I get the impression I didn't make our problem clear enough. Let's try to be a bit clearer (which I can be now that I know a little more about what's actually happening).

The situation we desire is as follows:

We have a webserver (IIS->ISAPI->Tomcat) with a number of virtual hosts. Each virtual host has:

• its own document root, with its own copies of the HTML, style, fex, foc, ftm, etc. files
  
• a virtual directory pointing to ibi_html (hosted by IIS)
  
• a virtual directory pointing to the approot (hosted by IIS, but Tomcat is possible - we don't really care)
  
• a virtual directory pointing to the ISAPI dll (named "jakarta")
  

If in any of those vhosts there's a request for /ibi_apps/WFServlet, then the specified foc file in the vhost's respective document root should be executed.

What we get, however, is this:

Each of these vhosts executes requests to /ibi_apps/WFServlet, but that servlet always executes foc files from a single document root - usually not the same document root that the vhost is using.

Apparently we have one WebFOCUS client, configured to use only one of those virtual hosts' document roots. It seems that WFServlet always calls that single WebFOCUS client instance in order to execute the focus executables that are supposed to be from its document root, but the client has its own idea of what the document root should be and is always serving the same files, independant of which vhost it was called from.

It appears we'll need a client for each vhost (bummer!), but how do you set up something like that? That's what my question was about.
Or, and I hope that's true, is there some parameter that can be set to tell each WFServlet which directory the client should be using as its approot?

I think we need to "run" multiple instances of the client, one per vhost, each with its own configuration (pointing to one virtual hosts' document root each). But how do you "run" a WebFOCUS client? What starts it? Is it run inside a webserver (my guess from the fact it has a CGI directory), or standalone? Is it a Windows service maybe?
It is some kind of application, it doesn't magically run by itself - we need to do something to make it run, but what?

If we do indeed need to run multiple clients, the next question in chain is: how do we configure each virtual host so that its WFServlet talks to the right client?

OK.

I think the answer to all your questions has already been provided, but it is sometimes a bit hard to get everything in a row.
You have IIS with a number of virtual hosts. Each host needs to have its own DNS entry with its own DNS name. This name has to be entered in IIS as the host-header for that instance. If you do not have DNS access, you can sort of fake it (at least temporary until it all works) by entering the chosen name(s) in your hosts file in your windows system32/drivers/etc directory. IIS has to know all the aliases for each instance, so you have set that up correctly.
When a request comes in for a certain host, IIS checks to see what host is called and what alias is used. If it starts with /ibi_apps it finds out it does not have that alias but has to send it to the isapi redirector. That piece redirects the request to tomcat. By registering the dns names you used in the tomcat xml config files, tomcat knows for which host it has to do something. It searches for the ibi_apps alias within the given host and when it finds it, it will start to load the servlets that belong to that host. This will only happen once, since the servlets are memory resident. The servlets make up the webfocus client. This piece, when started, loads all config files into memory (the so-called wfs files and cfg files in the client/wfc/etc directory) which it then uses to find out where all the stuff it needs can be found. One of these files is the odin.cfg file which tells it what server to use. If needed it will send the request to that server. This again is another separate program that has its own config.
All these elements have to be interconnected and set up within their own enviroments for things to work ok. There is no such thing as a simple switch that can be set to magically select one environment or the other. You really have to look at multiple instances on the same machine as if it were multiple machines.

Hope this helps a bit and did not confuse things more...

quote:

Originally posted by GamP:
You have IIS with a number of virtual hosts. Each host needs to have its own DNS entry with its own DNS name. This name has to be entered in IIS as the host-header for that instance. If you do not have DNS access, you can sort of fake it (at least temporary until it all works) by entering the chosen name(s) in your hosts file in your windows system32/drivers/etc directory. IIS has to know all the aliases for each instance, so you have set that up correctly.
When a request comes in for a certain host, IIS checks to see what host is called and what alias is used. If it starts with /ibi_apps it finds out it does not have that alias but has to send it to the isapi redirector. That piece redirects the request to tomcat. By registering the dns names you used in the tomcat xml config files, tomcat knows for which host it has to do something. It searches for the ibi_apps alias within the given host and when it finds it, it will start to load the servlets that belong to that host. This will only happen once, since the servlets are memory resident.

We have this part working as far as I can tell; multiple DNS entries with a host line each in tomcat's server.xml. As long as you leave WFServlet out of the picture, we get different files back from different virtual hosts. That part works, the WFServlet/client part doesn't.

quote:

Originally posted by GamP:
The servlets make up the webfocus client. This piece, when started, loads all config files into memory (the so-called wfs files and cfg files in the client/wfc/etc directory) which it then uses to find out where all the stuff it needs can be found. One of these files is the odin.cfg file which tells it what server to use. If needed it will send the request to that server. This again is another separate program that has its own config.

The problem here is that there is only one relevant config file for the client (cgivars.wfs) where you can set the approot. There doesn't appear to be a facility to specify different directories for different virtual hosts in that file.

That's why I came to the conclusion that we need to install multiple versions of the client, in which case we would also need some way to tell the WFServlet (or ibi_apps) - in each virtual host - which client installation to use. That requires some kind of switch, "magical" or not.

That, or I must have missed how you specify hostnames in cgivars.wfs. It must be either of these two, I don't think there are any other possibilities.

Yes, you do need a separate install for each client. The way to point to these clients is by the definition of the alias /ibi_apps for the respective hostnames within tomcat. Eahc hostname must have its own aliases, so if you need to install 3 environments, you'll have 3 ibi_html aliases in IIS, 3 approot aliases in IIS and 3 ibi_apps aliases in tomcat. Each separate ibi_apps alias points to the client for its own environment. The first one might for instance point to c:\ibi\webfocus77prod\webapps\webfocus, the second to c:\ibi\webfocus77dev\webapps\webfocus and the third to c:\ibi\webfocus77test\webapps\webfocus. Each env has its own cgivars that will point to its own approot.

I think I found how to reach the cgivars file you mentioned and how to separate those clients. I wrote down below how I think to solve the final piece of the puzzle, for future reference. I haven't tested this yet though!
Thanks for the help, it's been an interesting trip!

In the meantime I found out that it does matter whether IIS or Tomcat serves /approot.
IIS handles the request URI's in a case-insensitive manner, similar to the underlying file-system, whereas Tomcat refuses to do that because it's apparently a security risk (rubbish!).
There is an option to make Tomcat less stubborn about this, but the general advice seems to be to not use that option - go figure...

In the end it was easier to just have IIS handle those paths.


To the guys at IBI; I think it would be a good idea to have an easy-to-find document that explains this architecture. I know you have guides about how to install multiple copies of WebFOCUS to handle multiple virtual hosts and such, but those documents are a step-by-step guide to an end-result that you decided on. Those documents neither allow people to diverge from the path you predetermined, nor do they provide people understanding of what they are doing.

In general, I find documentation is often very hard to find and (once you find it) often doesn't answer the question you're having. These forums do provide the missing help, but it depends on people offering their valuable time and especially the virtuoso's and up tend to give rather cryptic answers (which is probably because they have better things to do).


The promised explanation of the last piece of the puzzle:

It appears the "client" is actually made up of two parts: a web-client (the WFServlet), and a CGI executable that gets called from the web-client (and possibly several other WebFOCUS components).

In each vhost we have an ibi_apps.xml Context file (aka an alias) pointing to a separate copy of the web-client directory (I think this provides the WFServlet).

We have these:
localhost:

<?xml version="1.0" encoding="UTF-8"?>
<Context
    docBase="D:/apps/ibi/WebFOCUS768/webapps/webfocus76">
</Context>

testfocus1:

<?xml version="1.0" encoding="UTF-8"?>
<Context
    docBase="D:/apps/ibi/TestFOCUS1/webapps/webfocus76">
</Context>

Now in each of the directories that are specified by these contexts, there is a file WEB-INF/web.xml that contains the necessary bits to tell where the CGI client lives.
The most relevant parts in that file are probably these:

  <context-param>
   <param-name>webfocus_client_root</param-name>
     <param-value>D:\apps\ibi\WebFOCUS768\client\wfc</param-value>
  </context-param>

  <context-param>
   <param-name>webfocus_connection_path</param-name>
     <param-value>D:\apps\ibi\WebFOCUS768\client\wfc\etc</param-value>
  </context-param>

Each vhost has it's own version of that web.xml file (they're in different paths after all). It's probably best to replace every path reference to reflect the path to your vhosts' (web-)client copies.

In that directory referenced by $webfocus_connection_path there's a cgivars.wfs file that contains a parameter APPROOT that needs to be pointed to the correct approot path.

As a final note; I don't think it matters from which directory ibi_html gets served. It's static content, a single copy of that directory would probably be able to provide those files for every vhost, as long as it gets referenced in the clients and webapps for each vhost.

For approot, ibi_apps and WFServlet you will really need different copies of their web-apps.

quote:

IIS handles the request URI's in a case-insensitive manner, similar to the underlying file-system, whereas Tomcat refuses to do that because it's apparently a security risk (rubbish!).

rubbish, indeed.
It is just because IIS is windows based, therefor case insensitive, and tomcat is java based therefor case sensitive. Since tomcat (or apache webserver) is also used a lot in the unix environment, it HAS to be case sensitive, because unix is.

I can't believe it! I thought I had everything set up so that all the different WebFOCUS components know where to look for each other and yet the WFServlet running on http://testfocus1 is still executing the fexes from the one at http://testfocus! WTF?!?

There's been improvement though - if I enter the administration console on either host, I get all the settings relevant to that specific host. I used to get the same settings for both.
Is there some way to see which client is running for a given host, or even better, why it is running that specific client?

If I knew what parameters to check for, I could probably write a simple JSP-page to see the information I need - the thing is, if I were able to do that I wouldn't be having this problem... Nice catch22.

quote:

Originally posted by GamP:

quote:

IIS handles the request URI's in a case-insensitive manner, similar to the underlying file-system, whereas Tomcat refuses to do that because it's apparently a security risk (rubbish!).

rubbish, indeed.
It is just because IIS is windows based, therefor case insensitive, and tomcat is java based therefor case sensitive. Since tomcat (or apache webserver) is also used a lot in the unix environment, it HAS to be case sensitive, because unix is.

Sort of true, but "proper" software would have some means to determine that it's reading from a case-insensitive file-system and thus ignore the case of the files it requests. In fact, it almost looks like they went through some extra trouble to read Windows' case-insensitive file-system in a case-sensitive way! If they'd just ask for a file named 'A', windows would happily return one named 'a', but they manage to see the difference somehow and, worse, consider it an error.
So no, it doesn't have to be case-sensitive - they should have just left that to the underlying file-system. Windows is not the only OS that has a case-insensitive file-system, HFS+ is by default case-insensitive as well, for example.

Wep5622,
Sorry on the delay, I've been tied up with things.

If you're making pure WFServlet calls and they're going to the wrong approot, this is likely because of the Reporting Server.

You might be able to do things with different Reporting Server profiles. Open a case and see if someone can assist in setting a different approot location from the Reporting Server based on a user profile.

On the note of cgivars.wfs files you want to override, you could also have overridden this using WFS logic.

Run a WFServlet trace of a request from one of the vhost, and search for the host name to determine which WebFOCUS Variable its in. (I think its HOST, but I don't have time to check right now).

You can then do something like:
HOST.upper EQ "LOCALHOST"
APPROOT=C:/ibi/apps1/


You could of course stack these to account for all the vhosts, and it will likely get rid of the need for the completely separate configs.

WF 71.x, 76.x, 7701, 8.0 Beta OS: Linux, Win2k3, Win2k, Win2k8, WinXP

quote:

Windows is not the only OS that has a case-insensitive file-system

Windows is case insensitive towards the files that it stores/reads. The filesystem itself is case-sensitive. That is illustrated by the fact that you can rename a lower cased file to the same name but then upper cased. This is also why tomcat sees the filesystem as case sensitive - which it is.

About the client stuff - you have that configured nicely and correctly as far as the client goes. That is demonstrated by the fact that you get the admin console for each client separately. Now the last step is, as dlogan points out, probably the reporting server.

How does the client go to the server? By means of the odin.cfg file. This file is present in each client install and it contains all information on the servers it can reach. Important to keep in mind is that each environment has its own client, but also its own server. And that should be reflected in the port number allocated to the server. For instance, your localhost server listens on port 8121, while your testfocus1 server listens on port 9121. This is configured when installing the server. And it should be reflected in the odin cfg for that environment. So in this scenario, localhost should communicate with server on port 8121, testfocus1 should communicate with server on port 9121. And then each server should point to the correct approot - set in the edaserve.cfg of each server.