We have pretty much decided to use the mod_proxy_html module for apache with SunONE as our platform. This means that the apache module will parse and rewrite the HTML generated by the portal, fixing up the URLs as appropriate.
Why? Well the production environment is using Novell iChain, and it does basically the same thing. Thus, developing and testing with this parsing overhead is a reasonable way to proceed.
Hopefully this will work properly!
Friday, May 12, 2006
Thursday, May 11, 2006
Hard to find a place in the SunONE
As the TIBCO Portal doesn't support Tomcat in a production installation, we are using SunONE 6.1 SP4 as the web container.
Getting SunONE to install with the portal has been frought with difficulty. What we had wanted to do was to install SunONE on port 80. We want port 80 since the infrastructure already allows access to this port in the demo rooms.
After much work, we discovered that it is basically not possible to install the web server in this manner without having setuid-root shell scripts. This is because the deployment process in TIBCO Administrator relies on being able to programmatically restart the web server. Needless to say, we're not precisely keen on this.
As a side item, if you want to install SunONE for use with the portal, you actually have to install TRA, Administrator, SunONE and the Portal as the same non-root user. The documentation suggests that having these products share the same group is sufficient, but that isn't true.
Eventually we have got to the stage of having a reverse proxy in front of our web server. This works great with Tomcat, but not so well with SunONE.
The basic problem with the Portal and the reverse proxy is that the portal generates some absolute links in it's HTML markup. These links must have the host:port of the reverse proxy and not that of the portal web server if they are going to work properly.
Under Tomcat, this is simple - set the proxyHost and proxyPort properties of the <Connector> in the server.xml and voila! it works. Unfortunately SunONE provides no such mechanisim that we can determine. From what I can see, there is no way to configure SunONE to operate transparently behind a proxy!
Getting SunONE to install with the portal has been frought with difficulty. What we had wanted to do was to install SunONE on port 80. We want port 80 since the infrastructure already allows access to this port in the demo rooms.
After much work, we discovered that it is basically not possible to install the web server in this manner without having setuid-root shell scripts. This is because the deployment process in TIBCO Administrator relies on being able to programmatically restart the web server. Needless to say, we're not precisely keen on this.
As a side item, if you want to install SunONE for use with the portal, you actually have to install TRA, Administrator, SunONE and the Portal as the same non-root user. The documentation suggests that having these products share the same group is sufficient, but that isn't true.
Eventually we have got to the stage of having a reverse proxy in front of our web server. This works great with Tomcat, but not so well with SunONE.
The basic problem with the Portal and the reverse proxy is that the portal generates some absolute links in it's HTML markup. These links must have the host:port of the reverse proxy and not that of the portal web server if they are going to work properly.
Under Tomcat, this is simple - set the proxyHost and proxyPort properties of the <Connector> in the server.xml and voila! it works. Unfortunately SunONE provides no such mechanisim that we can determine. From what I can see, there is no way to configure SunONE to operate transparently behind a proxy!
Deployment and the TIBCO Administrator
If you have used the TIBCO PortalBuilder product, you will know that the 5.x release is now integrated with the TIBCO Administrator. Deployment of components of the portal, or new JSR 168 portlets is done by creating EAR files and deploying them under the Administrator.
The way deployment works is like this:
So, to watch the deployment proceed on Unix you need to:
Another key item that you need to do is reset the timeouts for the Hawk agent and the Administrator.
The Hawk agent timeout (i.e. the amount of time the Hawk agent will wait for one the activities it does to complete) is specified in hawkagent.cfg (located in the TRA domain directory).
The Administrator timeout (i.e. the amount of time the Administrator will wait for the Hawk agent to complete) is specified in tibcoadmin_DOMAINNAME.tra (located in the Administrator domain directory).
These two values are in seconds and should be set to something between 600 and 720000. Values higher than 720000 are ignored (and 600 will be used instead.) I use a value of at least 3600.
The other item that is crucial is to know when the hawk agent should be restarted. As the hawk agent (through the deployment plugin) scans files and looks up classes, it must be able to find any classes referenced in the configuration. For example, if you set an authentication wrapper class or other plugin class, this class must be known to the hawk agent, or the deployment will fail. Now, as the hawk agent establishes it's class path and loader essentially on startup, JAR files added to the path won't be found after startup, and modified JAR files won't be re-read.
Basically, you should restart the hawk agent whenever you add a new JAR file to the system.
Finally, the plugin directory PORTAL_HOME/5.1/lib/extensions is not present (by default) in the class path used by Hawk, so any JAR files placed here won't be found. You have to add this directory manually to the hawk configuration:
If you get all of the above right, then deployment should just work for you!
The way deployment works is like this:
- The Administrator tells the Hawk agent (not the hma) to deploy the EAR
- The EAR is unpacked into a scratch area by the Hawk agent's deploy plugin
- The unpacked EAR is examined by the deploy plugin and XML files modified to set up the configuration as was specified in the Administrator console
- The unpacked EAR is copied to the nominated web server by the deploy plugin
- The nominated web server is restarted
- The deploy plugin waits for the server to start
So, to watch the deployment proceed on Unix you need to:
- Use nohup to start the Hawk agent so a log file is kept (nohup.out)
- Use prstat to monitor the running processes (will show you the start/stop scripts running)
- Use tail -f nohup.out on the Hawk agent nohup output to watch the reconfiguration happening
- Use tail -f on the server log file (catalina.out for Tomcat, errors for SunONE)
Another key item that you need to do is reset the timeouts for the Hawk agent and the Administrator.
The Hawk agent timeout (i.e. the amount of time the Hawk agent will wait for one the activities it does to complete) is specified in hawkagent.cfg (located in the TRA domain directory).
The Administrator timeout (i.e. the amount of time the Administrator will wait for the Hawk agent to complete) is specified in tibcoadmin_DOMAINNAME.tra (located in the Administrator domain directory).
These two values are in seconds and should be set to something between 600 and 720000. Values higher than 720000 are ignored (and 600 will be used instead.) I use a value of at least 3600.
The other item that is crucial is to know when the hawk agent should be restarted. As the hawk agent (through the deployment plugin) scans files and looks up classes, it must be able to find any classes referenced in the configuration. For example, if you set an authentication wrapper class or other plugin class, this class must be known to the hawk agent, or the deployment will fail. Now, as the hawk agent establishes it's class path and loader essentially on startup, JAR files added to the path won't be found after startup, and modified JAR files won't be re-read.
Basically, you should restart the hawk agent whenever you add a new JAR file to the system.
Finally, the plugin directory PORTAL_HOME/5.1/lib/extensions is not present (by default) in the class path used by Hawk, so any JAR files placed here won't be found. You have to add this directory manually to the hawk configuration:
- Open the TRA_HOME\domain\DOMAINNAME\hawkagent_DOMAINNAME.tra file for editing.
- In the java properties section, add the following to the tibco.class.path.extended path:PORTAL_HOME/5.1/lib/extensions.
- Restart the Hawk agent.
If you get all of the above right, then deployment should just work for you!
A long time...
Yes, it's a long time and no posts! This has been in part due to my wanting to spend more time on other things (i.e. my girlfriend) and on my reluctance to post to this blog while at work.
I don't know about you, but I just don't feel like doing "computing" things when I get home anymore. Perhaps it's a sign of old age, or perhaps I'm becoming more work-life balanced.
I am still fighting with the TIBCO Portal suite, which I will post upon shortly.
In other news, Laura (my girlfriend) and I are now engaged and due to be married in August 2007!
Hasta luego!
I don't know about you, but I just don't feel like doing "computing" things when I get home anymore. Perhaps it's a sign of old age, or perhaps I'm becoming more work-life balanced.
I am still fighting with the TIBCO Portal suite, which I will post upon shortly.
In other news, Laura (my girlfriend) and I are now engaged and due to be married in August 2007!
Hasta luego!
Subscribe to:
Posts (Atom)
