Those pesky templates

Well, as it turns out, you can put the templates somewhere which isn't in the repository. You can fetch them from a URL.

That's not so bad - you can use the URL form during development, then when you transition from development to deployment, you change the template definition to the repository form (for easy deployment). Unfortunately, I think you need to re-create the template when you do this, which is a little annoying.

What would have been ideal would be an option to "convert" a URL-based template to a repository based template.

Initial Thoughts of TIBCO Portal Builder 5.1

The main impression that I have regarding TIBCO Portal Builder 5.1 is that it has an extremely steep learning curve.

Why do I say this? Well, it appears to me that the entire product is built in such a way that it is extremely difficult to make experimental changes. I am only in the initial stages of investigation, however after a day's worth of digging, I have yet to work out how to change a single portlet, window, skin or page layout template - something one would expect to be a relatively simple thing to do!

In the previous portal product from TIBCO (4.5.3) the templates resided on the file system. This made it a simple matter to make modifications and test them quickly. On the downside, this did mean that the management of template changes in a multi-host deployment were cumbersome. It appears to me that TIBCO have now gone to the other end of the spectrum - deploying enterprise-wide changes seems well managed through the TIBCO Administrator, but a first glance the debug cycle looks incredibly slow and tedious. Template changes seem to require packaging as ZIP files, then uploading into the portal. Sure, this is great for a site-wide change, but for development, it sucks.

I shall now don my super-optimistic-engineering-hat and see if there isn't a better way of doing template development.

Ciao!

How to disable Oracle XDB (XML Database)

As of Oracle 9i, the database now grabs port 8080 and port 2100 for the XML database.

To disable it, basically you need to set the port configuration for ftp-port and http-port to 0.

I found that it was not possible (for some unknown reason) to configure these items from the Oracle Enterprise Manager Console, even if I connected as the sys user in the sysdba mode. It was similarly not possible to change the values using SQL*Plus as detailed here.

I eventually had to drop and recreate the XML database.

The procedure was as follows (windows example given).

1. Get a command window


2. Change to the SQL*Plus script directory (usually it is C:\Oracle\ora92\rdbms\admin)


3. Use SQL*Plus to connect to the database as sysdba:
   

   C:\Oracle\ora92\rdbms\admin> sqlplus
    ...
    Enter user-name: sys as sysdba
    Enter password:
    ...



4. Find out the default tablespace for the XML database:
   

   SQL> select default_tablespace from dba_users where username='XDB';
    DEFAULT_TABLESPACE
    ------------------------------------
    XDB



5. Uninstall the XML database.
   

   SQL> drop user xdb cascade;
   
    ...



6. Re-create the XML database.
   

   SQL> @catqm.sql xdb_pass XDB_TS_NAME TEMP_TS_NAME

   
   where:
   
   • xdb_pass is the password for the XDB user
   
   
   • XDB_TS_NAME is the tablespace name for the XDB user
   
   
   • TEMP_TS_NAME is the temporary tablespace name for the XDB user
   
   For example:
   

   SQL> @catqm.sql XDB XDB TEMP



7. Commit and disconnect.
   

   SQL> commit;
   SQL> quit;



8. Use SQL*Plus to connect to the database as sysdba:
   

   C:\Oracle\ora92\rdbms\admin> sqlplus
    ...
    Enter user-name: sys as sysdba
    Enter password:
    ...



9. Load the java libraries:
   

   SQL> @catxdbj.sql



10. Commit and disconnect.
    

    SQL> commit;
    SQL> quit;

After this had been done, you should be able to modify the ftp-port and
http-port parameters to 0 using the Enterprise Manager Console. Note that
you will need to connect as the sys user in sysdba mode.

Logging in TIBCO PortalBuilder 5.1

If you are like me, you believe that logging is a crucial part of application development. Good logging should be inserted during development, not added as an afterthought.

As I'm currently developing portlets, for eventual deployment into the TIBCO portal, I wanted to use Log4J within a JSR-168 portlet.

Initially, I tried to log information using the default portlet logger. That is:

getPortletContext().log("Interesting filth down here!");

This worked OK once I found out that the Portlet Role option must be checked in the Portal Builder Console for the Portal Item. To do this, go to the Portal tab, select the service link enclosing your portlet(s) (e.g. helloWorldPortletService), select Edit Service Configuration from the drop-down list and check Portlet Role in the Logging Settings page.

The big problem with log configuration under Log4J is configuring the log file name. I really dislike hard-coding file paths into the configuration files, particularly in this case where the portlet can be deployed by the TIBCO administrator into many different locations. I was looking for a way to generate a file path which would be in a "nice" location - for example, under the servlet context associated with the portlet, or in the portal log directory.

Log4J does allow access to the java system properties. So if the following property is set:

foo.bar

you can use the following in your log4j.properties to set the file:

log4j.appender.LOGFILE.file: ${foo.bar}/my.log

If I could get an appropriate system property set before the Log4J auto-configuration happens, then everything would be fine.

One potential method for setting the system property was to specify the directory on the JVM runtime (i.e. when the servlet engine starts), however I would prefer to avoid modifying the scripts installed with the product.

Investigation showed that the following interesting variable was present:

TIBCO_PS_HOME=C:\TIBCO\portal\5.1

which is pretty much what I needed.

Ideally, I would like to place the logs under the specific servlet instance logging directory, just as the portal does itself. If I could do it, this would mean that multiple instances of a servlet engine on the same host with the same portlet deployed to it would not share a log file. Alas, I have found no way to get this information (yet).

An Idea

I've decided to start this blog for one basic reasons. In the course of my work, I stumble over interesting tid-bits of information that might be of use to others, so it would be a good idea to record these somewhere. Over the years, I have made extensive use of information on the internet, so it is only fair that I make an effort to return the favour.