Simon, Kyle - help PLEASE!!!

[Mike Jones]

OK, it has turned into a two day effort trying to install the sample EAR from the WAS 4.0 Application Development Handbook (SG246134). If it's this hard every time, I'm going back to PowerBuilder.
Simon, do you work for IBM also? Judging by your previous post about the upcoming IBM classes, it looks like it.
Anyway, back to my issue of installing the EAR. It may very well be that the EAR they provide with the Redbook has a problem and doesn't run. A NOTE on the last page claims that the author's of the Redbook actually were never successful getting the EAR to run on WAS 4.0.1. Hell, if the experts couldn't do it, why would I expect to be able to do it. If one of you could check within IBM and find out what the problem is, or a link to how to modify the EAR to install it, I would VERY MUCH appreciate it.
OK, some information to share with anyone interested. In the previous two threads on this issue, I learned about the difference between the external HTTP server and the embedded one. The embedded one comes up automatically with the application server. What people may not be aware of, is that when you use an external HTTP server, the application server embedded HTTP server is still in play and manages I/O between the external HTTP server and the WebSphere application server. Check out
ftp://vadd1:[email protected]/1/wsdd/pdf/presents/WS40ST08.pdf
for a very good read on the plugin-cfg.xml file. I did end up with a question about transport definitions. The admin application seems to have a port 9090 http transport defined and a port 9080 http transport defined. Then in the same pdf... I think around pg. 9 or 10, they claim you can only have only one transport for a type (http or https). I think the statement was that WebSphere will ignore the extra definitions. That seems a conflict to me, since they do have two defined in the default installation, and both seem to work. ???
OK, some questions.
1) I think the plugin-cfg.xml file does not come into play when you make an embedded http server request. If you refer to the diagrams in the plugin pdf above, it looks like the embedded http server does not refer to it. This would be nice to know because you would quit spending time looking at it trying to figure out why your embedded server request is getting a page not found.
2) If you are working only with the embedded server, and the anwser above was that the plugin-cfg.xml file is not used in that instance, then I would assume that the discussion of transport definitions is also moot (i.e. only applicable to external HTTP servers). Is that correct?
3) Does the embedded server recognize the virtual hosts. I guess the answer to this must be yes since //localhost:9090/admin works.
4) When I look at the plugin-cfg.xml file, I see entries labled Uri Name. Do those entries have anything to do with the context-root from the application.xml file? I understand the context-root entry is an abstract declaration (thanks Simon). So the admin application declares the context-root to be /admin. Well, I also see /admin as a Uri Name entry in the plugin-cfg.xml file. Any connection?

PLEASE help. To repeat my attempted steps to install the EAR file so far:
1) created required DB2 tables
2) setup a new virtual host pigbank-host at 9081
3) installed EAR and selected pigbank-host during installation.
4) restarted WAS and tried //localhost:9081 and //localhost:9081/index.html. "Frickin Page not found". OK, I added the Fickin part.
By the way, for anyone following this topic (Prahanth ?), I did succeed in pulling up samples using the embedded server using the url //localhost:9080/webapp/examples/.
Now I have another question about the Uri Name entries in the plugin-cfg.xml file. I found the above url in the plugin file. Now to use the external http server, I get a hit on //localhost/WSsamples/index.html. But nowhere will you find that entry in the plugin-cfg.xml file. How can that be, and how does it find the examples?
Could it be anymore confusing?
Help.... PLEASE
Mike

[Simon Song]

Simon, do you work for IBM also?
--Not now, my manager is just going to sponsor me attend this year event also. I went there last year.

[Simon Song]

"Now I have another question about the Uri Name entries in the plugin-cfg.xml file. I found the above url in the plugin file. Now to use the external http server, I get a hit on //localhost/WSsamples/index.html. But nowhere will you find that entry in the plugin-cfg.xml file. How can that be, and how does it find the examples?"
--Yeah, you can find the config in external webserver directly.
For embedded HTTP server, I should say I haven't been able to deploy webapp with "/" context root and get welcome page working. But as long as your webapp has other context root, things should be fine.
Plug-in should apply to embedded HTTP Server also, you can configure your AppServer(go to service, choose web container, specify HTTP transport) to listen to other physical port number. Then you have to configure the Virtual Host to listen to that port also, the virtual host is the one webapp is associated with.
So, hopefully you can deploy the sample ear with a non "/" context root, and get it running.
Virtual Host plays a conduit role here, this is very different from WLS.

[Kyle Brown]

OK, the basic question I've got is why are you trying to create a virtual host? Also, did you at any time run GenPluginCfg and restart your external web server?
GenPluginCfg actually adds the entries from the App Server's database of URLs and virtual hosts into the plugin-cfg.xml file. The plugin should pick it up directly, but to be safe, I always restart it after regenerating the file.
Kyle

[Mike Jones]

Simon,
"--Yeah, you can find the config in external webserver directly."
That makes sense, and that is what I got from the pdf I posted. I expect to find a plugin-cfg.xml file in the external HTTP server directories. However, I only have one, and it's in /WebSphere/Appserver/config. Is it under a different file name with the external server?
"For embedded HTTP server, I should say I haven't been able to deploy webapp with "/" context root and get welcome page working. But as long as your webapp has other context root, things should be fine."
Time for a rookie question. I tried this by using Earexpander and changing the context-root to "/pigbank". I then recreated the EAR and tried to install it. I got errors on the install... looked like it was during the process of creating deployment code.... maybe a compile error... not sure. My question is do I have to change anything other than the context-root entry in the application.xml file?
"Plug-in should apply to embedded HTTP Server also,"
I really want to understand this point. Check out the diagram on page 5 of 28 here:
ftp://vadd1:[email protected]/1/wsdd/pdf/presents/WS40ST08.pdf
I realize documentation can be in error, but according to this diagram, the embedded server doesn't look at the plugin-cfg.xml. I would be the first to admit that doesn't make sense. Why have two different ways to look up the info. I'm sure you are right. Kyle, would you care to confirm.
"you can configure your AppServer(go to service, choose web container, specify HTTP transport) to listen to other physical port number. Then you have to configure the Virtual Host to listen to that port also, the virtual host is the one webapp is associated with.
So, hopefully you can deploy the sample ear with a non "/" context root, and get it running.
Virtual Host plays a conduit role here, this is very different from WLS."
I had found where I would add another transport in AEs. It's under nodes/machine name/Application Servers/Default Server/Web Container/HTTP transports. Here is the question. Isn't the transport only for the external HTTP server? If I add a virtual host, and only intend to reference it from the embedded server, do I still need to add the transport? When I setup the new virtual host, I set it to port 9081.
Kyle,
"OK, the basic question I've got is why are you trying to create a virtual host? Also, did you at any time run GenPluginCfg and restart your external web server?
First, I am now trying to only use the embedded HTTP server (for this exercise of installing the EAR and running it). Do I still need to run GenPluginCfg for the embedded server. Note: see related question to you above in my response to Simon.
I was trying to create a virtual server for a couple of reasons. The first was, that according to the Redbook, if I ran the sample application under the default_host, I would need to disable the sample applications, because they also had a context-root of "/". Another reason was to force myself to learn the issues of setting up a virtual host (in hindsight, maybe not a good decision ). The redbook also suggested setting up a new virtual host would bypass the problem. I'm at the stage where I want / need to look at alot of sample code, so I would like to leave as many examples running as possible.
"GenPluginCfg actually adds the entries from the App Server's database of URLs and virtual hosts into the plugin-cfg.xml file. The plugin should pick it up directly, but to be safe, I always restart it after regenerating the file."
What does App Server's database of URLs mean? By the way, the new virtual host does appear to be in my plugin-cfg.xml file. I had asked earlier about the Uri Name entries in the file. I'm still confused about them, and if there is any connection with them and the context-root setting in the application.xml file. I probably need a good read on web application in WebSphere. If you know of a good place to start, I will be all over it.
I asked this above in the section to Simon, but let me ask it again to you. Does the embedded HTTP server in AEs use the plugin-cfg.xml file, and does it care about transports. I would think transports for sure or just for external servers.
Kyle, Simon... I really appreciate the help. J2EE education over a message board isn't easy. :roll:
Mike

[pjoisha]

Hi Kyle,
I'm should be waiting to ask you this question after I read up on the RedBook but was wondering if you could answer (since we are on this topic) a puzzling question ....
Lets say I just deployed my application into WAS AEs and at time of app installation (say via the Admin console) I select GenPlugIn config. I guess at this point what you said in the earlier post applies-"GenPluginCfg actually adds the entries from the App Server's database of URLs and virtual hosts into the plugin-cfg.xml file". Now after a restart of the front-end HTTP server and AppServer I should be able to access my application via the URL http://localhost/MyApplication.
Now my question is how does the access via the URL http://localhost:9080/MyApplication get disabled with both the external HTTP server and AppServer running?
Thanks in advance,
PJ
[ April 24, 2002: Message edited by: Prashanth Joisha ]

[Mike Jones]

Prashanth,
Which Redbook are you reading?

[pjoisha]

Mike,
I have not started reading that book as yet but I was told that chap 14 of Redbook SG246176.pdf (Advanced Edition Handbook) talks about it. My guess is that the approach applies to AEs as well.
HTH,
PJ

[Mike Jones]

Prashanth, Simon, Kyle, ....
OK, I read chapter 14 in the WAS AE Handbook. It definitely cleared up many things, including the Uri Name entries. I had to read pg. 485 several times where it was explaining the plugin-cfg.xml search rules based on the route tags. I think I get it... but this explanation is "begging" for a bunch of examples.
Prashanth,
I would have to say you are wrong assuming that this would clear up the AEs issues. It is geared for AE for sure. Anyone know of an AEs specific Redbook? I assume using AEs/AEd as the standard for your developer workstations is the way to go. ???
I gave up on the virtual host and got the application to run by changing the context-root to "/pigbank" and setting a Uri Name entry in the plugin-cfg.xml file to "/pigbank/*". Now the url //localhost:9080/pigbank/ works. I guess this answers the question on whether the embedded server uses the plugin-cfg.xml file. "Yes". For some reason, when the application comes up, I don't see the graphics. I guess I need to expand the war and work that one out.
Everything I read in chapter 14 about virtual hosts lead me to believe the steps I had taken were valid. I guess in J2EE land you need to figure out what is worth battling, and when to move on, or you will never get anything done.
I will still welcome any feedback from my question posted to Kyle and Simon above. At this point I believe the embedded HTTP server does use the plugin-cfg.xml file, but has nothing to do with the transport definitions. Transports are for external HTTP server to WebSphere application server communication (either HTTP or HTTPS).
I also think that with AEs, both the external and the embedded HTTP servers share the plugin-cfg.xml file at WASHOME\config\plugin-cfg.xml.
Mike
[ April 24, 2002: Message edited by: Mike Jones ]

[Simon Song]

At this point I believe the embedded HTTP server does use the plugin-cfg.xml file, but has nothing to do with the transport definitions. Transports are for external HTTP server to WebSphere application server communication (either HTTP or HTTPS).
--No, HTTP Transport setting also affect embedded webserver at least in AE. You can change it for your AppServer's web container.