JDK1.5 and Pluto

Today I was installing Pluto on my home PC. I built and deployed the sample RSS Portlet from the POST site. It didn't work :(

So, I looked into the logs and found:

14-Jan-2006 19:01:18 org.apache.pluto.portalImpl.services.log.LoggerImpl error
SEVERE: PortletInvokerImpl.render() - Error while dispatching portlet.
javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found
 at javax.xml.transform.TransformerFactory.newInstance(Unknown Source)
 at com.plumtree.portlet.portlets.RssPortlet.init(RssPortlet.java:98)
 at javax.portlet.GenericPortlet.init(GenericPortlet.java:100)

A little googling showed this was another instance of the JDK 1.5 XSL parser change. To fix, you just need to download and install Xalan into TOMCAT-HOME/common/endorsed and everything works fine.

Pluto is the bomb!

Yesterday I was stuck with a not-working TIBCO Portal, by virtue of the database settings (see my previous post!). While the portal wasn't working, I thought there's gotta be a better way to test this stuff - the install time into the TIBCO Portal is just tooooo long and cumbersome.

So, I downloaded Pluto and tried out deploying into the Portal Driver.

In summary - it's magic. Startup for the bundled Tomcat server is a few seconds, and you can run the shebang under Eclipse which makes debugging a breeze! I wish I'd discovered it sooner!

One thing that did cause me a bit of grief is the portlet.xml format. Make sure that you get the namespace and schema declarations correct (see the Troubleshooting part of the help view in Pluto's Admin Portlet for the correct one) and that you validate your XML before deploying. Some errors are not detected until portlet run time, so if your portlet is not working, check the portlet.xml first!

...and back working

Got it fixed, after a call to tech support. It turns out that I'd run out of database connections! That fixed, and all is working again.

Boom! Ground to a halt

Today my productivity ground to a halt... why? Because deployment of my portlet EAR files has ground to a halt :-) The TIBCO Administrator now refuses to deploy any portlet EAR file into the domain!

CreatePASEAR weirdness

Yesterday I encountered a weird problem. My creation of an EAR file using the CreatePASEAR tool stopped working, generating an ANT error 'Unable to delete file':

Unable to delete file C:\Temp\cps\cps_source.ear
        at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:449)
        at com.tibco.ps.anttasks.utils.AntTaskUtils.deleteFile(AntTaskUtils.java
:129)
        at com.tibco.ps.anttasks.deployment.GenericPSBasedEARTask.execute(Unknow
n Source)
        at org.apache.tools.ant.Task.perform(Task.java:341)
        at org.apache.tools.ant.Target.execute(Target.java:309)
        at org.apache.tools.ant.Target.performTasks(Target.java:336)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1339)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1255)
        at com.tibco.ps.anttasks.TIBCOMain.a(TIBCOMain.java:618)
        at com.tibco.ps.anttasks.TIBCOMain.start(TIBCOMain.java:186)
        at com.tibco.ps.anttasks.TIBCOMain.main(TIBCOMain.java:225)

After much investigation, it turns out the this error is bogus - it is generated by the tool during clean-up operations after the real error has happened. The actual error was malformed XML in my web.xml file (the CreatePASEAR file rewrites the web.xml during EAR generation).

The real error can be found in the TIBCO_HOME/portal/5.1/logs/utils/PortalUtils.log, for example:

[createPASEAR] Caused by: Failed to parse descriptor: Next character must be ">" terminating comment .
[createPASEAR]  at org.apache.cactus.integration.ant.WebXmlMergeTask.execute(WebXmlMergeTask.java:142)
[createPASEAR]  at com.tibco.ps.anttasks.deployment.TIBCOWebXmlMergeTask.execute(Unknown Source)
[createPASEAR]  ... 17 more
[createPASEAR] Caused by: org.xml.sax.SAXParseException: Next character must be ">" terminating comment .
[createPASEAR]  at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3376)
[createPASEAR]  at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3370)

I hope this helps someone from enduring the hours of frustration I had trying to find a bogus file permission/locking problem!

TIBCO Spring portlet issues solved

Well, I have succesfully deployed the Spring sample portlets into TIBCO PortalBuilder! The final problem was a my mistake - somehow the incorrect configuration file was getting packaged into the WAR, so my custom bean for handling the charset problem was not getting instantiated! With this fixed, everything is fine.

Here's the summary of my findings with using Spring under TIBCO PortalBuilder 5.1.

1. DOCTYPE is removed from all XML files under WEB-INF.


2. As a result, any Spring class which validates XML files when reading won't work (that's all of them that I have seen so far)


3. You need to extend at the XmlWebApplicationContext class to disable validation on XML file load. This is done by overriding the initBeanDefinitionReader() method and calling setValidating(false).


4. You need to add a new context-param definition to the context in web.xml to force your non-validating context implementation to be used. The name of this parameter is contextClass.


5. You need to extend at the XmlPortletApplicationContext class to disable validation on XML file load. This is done by overriding the initBeanDefinitionReader() method and calling setValidating(false).


6. You need to add a new init-param to each Spring portlet defined in portlet.xml to force your non-validating context implementation to be used. The name of this parameter is contextClass.


7. You need to ensure that the content type for your views does not include a charset. In other words, text/html is OK, but text/html;charset=UTF-8 is not. The TIBCO implementation does not ignore the charset.

Even with the above changes, I've been unable to deploy the Spring Portlet Sample sample application into TIBCO Portal Builder 5.1.

The final issue appears to be due to the view resolver implementation in Spring - my customised view class isn't being instantiated, so the removal of the charset definition isn't happening. I'm going to post on the spring forums for help on this one - I'm stumped.

Spring and TIBCO

I've decided to use Spring as a framework for writing Portlets within TIBCO Portal Builder 5.1. The reasons are:

• Has support for Portlets as of 2.0M1


• Doesn't require a bridge layer (unlike Struts)


• Can be used with JSPs


• Has a MVC implementation that is supported in 2.0M1

So, I build and attempt to deploy the Spring Portlet Sample sample application. Naturally, it fails, and the debugging begins.

The logging output from Tomcat shows that the applicationContext.xml file is not valid. Examination of the deployed EAR in Tomcat shows that the DOCTYPE definition has been removed from all XML files in the EAR (except for web.xml). By default, the bean configuration reader for Spring has validation enabled, so having the DOCTYPE missing causes the parse of the bean definition XML file to fail.

Initially, I had thought that TIBCO's EAR creation tool was the culprit (used to build the deployable EAR from the portlet WAR), but it turns out the TIBCO Administrator modifies the EAR during deployment to the application servers in the administrative domain.

The next step is to use a custom XmlWebApplicationContext class which disables validation on the XmlBeanDefinitionReader before loading the bean definition files.

Hopefully with this work-around a Spring portlet can be deployed in TIBCO PortalBuilder 5.1.