Java

These are the articles I really like. Just enough sample code and lots of configuration completely and extensively documented to the last custom property that is needed (with screenshots).

Resource Environment Providers are very useful. It's a good help in configuring your application, for one reason because it's more dynamic than using deployment descriptors. Oh, just read the introduction of the article. I wanted to use one myself and then I came across this article. And yes, I made one, my very own Resource Environment Provider, well, I almost completely copied the example with the names changed to protect... All worked quite well, but when you look at the code in the article, there are two things that you might notice to be a bit strange.

First of all, the sample ConfigFactory in listing 1 only generates one static Config object. It fills it, and reuses that same object every time the function is called. Some sort of smart caching eh? I'm sure that reading those attributes must take forever. But not likely. So I changed that to create a new object each time the function is called.

Secondly, you might notice that there is something strange going on with the value of the custom property. It's casted to a String in the ConfigFactory, but the Config object stores it as an Object and also returns it as an Object. And as you can see further on in figure 18, a custom property can be of a couple of types (like string, integer etc). So why do we need to cast? It only seems to limit the possibilities, because obviously it can also return other objects. So I changed that too.

What you would expect now is that you can use any type of custom property and if you change them those changes are immediately reflected in your application. Right? Maybe I should send the author of the article my improved code.

But what makes life interesting is that things are not always what you expect them to be. Very often sample code is just the only way it can work. When I used my resource environment provider I had to restart the application before I could see the changes I made to the custom properties. Before that, it just returns the old values. And when you set a custom property to type Integer, it still returns a String object with that value. Actually it always returns strings, so I can't see any need for that type field...

Also, if you have any of those field names contain the word 'password', it becomes a password and WebSphere encrypts it. If you try to get those properties they will look something like this: {xor}LDo8LTor. I found out can decrypt those with this function:

com.ibm.ws.security.util.PasswordUtil.decode("{xor}LDo8LTor")

The resource environment providers are very flexible object factories. I think there are a lot of uses for them other than just return those custom properties. But I will stick to this one for now.

For something I was working on I needed to replace URLs in a body of text. I wanted to do that in a JSP so I used a BodyTagSupport for that. The text contained URLs in the form of "/uniqueName", in which uniqueName is the unique name of a content node. I had to create a portal url to a node for each of those unique names. Of course I used Java's powerful regular expression routines to replace them (very useful if you know how they work). And for creating the URLs I could have settled with just the CreateUrlCommand, but I gave it an extra touch by adding a title attribute to the <a> element containing the title of the content node the URL is pointing to. Nice huh? I think you should always give the stuff you make an extra touch. Anyway, here's the code!

Continue reading "Portal URLs and a regular expression"

The last couple of weeks I have been testing a lot of Java libraries that convert PDFs to images. I wanted to use it to display small thumbnails of the first page of a lot of PDF files. There are some open source initiatives in this field, like PDFBox, but I just couldn't settle for this one because, basically, the result was just too plain ugly. The rendering was terrible which I couldn't change at all, and it couldn't handle a lot of the fonts (which is very understandable by the way).

Of all the closed source products I tested (Big faceless, Ice Soft, Snow Bound Software and some more), I ended up with this one. It was the fastest of them all, and it was also the best deal. The thing they do well at Qoppa is that they not try to sell one big application that can do everything, but they sell small products for specific purposes. This way you don't pay the whole deal for a lot of stuff you are not going to need anyway.

And no, I don't work there, I've just seen a lot of PDF converters that I didn't like, that's all.

Oh.. and here's an example of the code I used:

PDFDocument pdf = new PDFDocument(file.getContent(),null);
PDFPage page = pdf.getPage(0);
double size = 600 / page.getPaperWidth() * 18;
BufferedImage image = page.getImage(size);

Notice the free style hard coded resizing of the page.

Where will this end? Looking at SystemOut.log for any problems after the installation of the WebSphere Portal 6.0.0.1 fix pack, there were some exceptions I could easily fix. Let's start with those.

The first one was CWLAG0450W, which I could safely ignore.

The second problem was a bit more tough. IBM named them CWSIV0954E and CWSIP0301E which both relate to the Workflow application. I have been struggling with the process server some time ago, and it didn't surprise me at all that it causes problems now that I finally start to use it. The problem seemed to be a simple authentication issue. The easy solution to that is to disable global security, but I won't settle for that.

The thing that doesn't work is a SCA module. You can find those under the menu item Applications in the WebSphere Administrative Console. In my configuration there was only one, the workflow stuff. To make it work you need to go to JAAS Configuration at the Global Security page of the Admin Console and select J2C Authentication data. There you'll find the SCA_Auth_Alias, and you have to provide a name and password with sufficient rights. I used wasadmin and his password.

The third thing portal started complaining about was that it couldn't find DefaultUserCalendarHome in the JNDI (javax.naming.NameNotFoundException). This involves nothing more than installing SchedulerCalendars.ear from the <WAS>/installableApps directory. You can do that from the admin console. During step 2 make sure the Calendars module maps to WebSphere_Portal. Leave everything as default (you'll notice that it picks com/ibm/websphere/scheduler/calendar/DefaultUserCalendarHome as its default JDNI name). Click finish and check if the application has started.

At this point I really felt like I was installing way too many things to make this work in a simple development environment. Was I on the correct path? Especially now the whole setup is beginning to need loads of cpu power.

Moving forward and trying to actually use the workflow I quickly ran into this one:

java.lang.IncompatibleClassChangeError:
class com.ibm.task.core.CallContextImpl does not implement interface com.ibm.task.core.CallContext.

Ok, that's it. That expection sounds like really freaked out installation. Maybe I did something wrong somewhere. Luckily I documented every single step. Maybe I'll start over or maybe I'll have a go with classfinder to get to the root of this.

Now that I've started using jQuery to submit forms I bumped into a little problem with my jQuery-optimism today.

I wanted to test a form I made by submitting random data to it, with in the end the application storing it in a CLOB field of an Oracle database. And because the application is quite international I went for some Russian and Chinese characters. Everything in the app seemed to work well, except that every time there was nothing readable left over from the original text (as far as I could read the original anyway), but instead there were these paragraphs of experimental Ascii art.

So I went diving into the documentation of Oracle, looking for a secret property I might have overlooked, checking the JDBC driver for patches, examining my code for weird constructions that were out of the ordinary, but I couldn't find anything. You can probably imagine the growing frustration and the ridiculous amount of time it took me to realize that it wasn't the Oracle database that was at fault, but it was already the incoming data that was messed up. How come, you might ask?

You have to put this at the beginning of the ajax servlet:

request.setCharacterEncoding("UTF-8");

Otherwise, the request object chooses the default encoding. Check this out for more details.

Two weeks ago I did an upgrade of WPS 6 on Solaris to 6.0.0.1 at work. And now I'll apply this fixpack on my linux box. I use Kubuntu edgy and earlier I documented how to install WPS 6 on ubuntu. I think that upgrades on other platforms will go the same way for the most part. Continue reading "Installing WebSphere Portal fix pack 6.0.0.1 on Ubuntu"

We're getting close. Ok, I tested it, and the things I did weren't enough. Looking into it a bit further I learned I had to do some additional stuff. In the admin console of the AppServer I saw that the business process choreographer and the human task manager were not installed. I had to run their installation wizard to manage that. I also read somewhere that you have to run this command:

ulimit -n 10240

...before going ahead, otherwise it'll stop with a 'Too many files open' exception eventually.

I did that and started server1, then started the wizard in the admin console. To get there select Servers/Application servers and select WebSphere Portal, then select Business process container settings/Business process container and then click the wizard.

On the first page, I selected Cloudscape 5.1. On the second page I selected the default messaging provider and these settings:
Queue manager: BPECF
JMS user ID: <wasadmin>
JMS password: <password>
JMS API User ID: <wasadmin>
JMS API password: <password>
Administrator security role mapping: wpsadmins
System monitor security role mapping: wpsadmins
Leave everything as it is on page 3, check the summary on page 4, and GO!

Next thing.. the human task container. Select it from the page you were before, the settings page of the WebSphere Portal application server. If you go there, you can select the wizard. Use the same settings as described above (the same settings as on the second page of the business process container wizard). Check the e-mail option on the second page, and finish.

Don't forget to save to the master configuration. If you made a mistake and want to start again, read this.

You must create the Cloudscape database and the tables yourself. After the business process container was installed, I went to <WAS>/profiles/wp_profile/databases and ran this command:

java -Djava.ext.dirs=<WAS>/cloudscape/lib -Dij.protocol=jdbc:db2j: com.ibm.db2j.tools.ij <WAS>/ProcessChoreographer/createDatabaseCloudscape.ddl
(<WAS> is the WAS installation directory)

You can find a description of this step in the createDatabaseCloudscape.ddl file itself.

Now that I'm diving a bit more into WebSphere Portal 6, I found out that the process server wasn't installed. You can check this by running versionInfo.sh and if it's not there then it's not there. And it wasn't there. And I think either I did something wrong (which I doubt of course) or something didn't go well during the install. I checked the log files again if there was anything about a failed install in there, and they didn't shed any light on this. In the end there wasn't much else to do than try to install the process server manually (or try a complete re-install of course, but I can always try that if everything fails).

In the documentation it said: “When running the WebSphere Process Server installation manually from CD *-2, users should run the install.bat or install.sh script instead of running the executable”. So for this I needed the IL-2 disk and go to the linux/ia32/WBI directory. I ran install.sh and half way I selected 'Use an existing installation of WebSphere Application Server Network Deployment, Version 6', and selected the WAS of portal.

Then this profile creation wizard popped up (after I agreed that it was ok to run it), and I didn't know exactly what to fill in. So I made a backup of the wp_profile first. Then I chose to augment the existing profile, and left all check boxes unchecked. I filled in the credentials of the WAS admin when the wizard asked for MQ credentials. That should work fine.

The wizard made the changes to the profile. I can see the process server when I run versionInfo.sh now, portal still functions and hopefully, I can use the process server from portal. I'll have to test that.

Update: part 4

Now that I have WebSphere Portal 6 running on my laptop, I can go ahead and do something with it. Unfortunately I have the problem that I don't have a proper test environment of portal 6 in RSA 7 (as do others), but I won't let that stop me. I want to build one of those composite applications that IBM is raving about. I'm going to try and create a sample application just to see what the possibilities and limitations of this new thing are. And of course I will write on this blog about my progress with it.

I'll be creating a bar application. That's right, an application for a business that sells beer, whiskey, and coffee (and maybe some sandwiches or something). It won't be useful at all when it is been created, but hopefully I will learn a lot during the making of it.

First off, I created an application template. Templates can be found right from the welcome page of portal. I saved it as 'Bar template' and by using 'Manager roles' on the template I added three roles: Customers, Bar tenders and Bar managers. Then I created a page in the template and called it 'First page', just to test, and I put three (almost at random) portlets on it. So now I could assign how users with specific roles can use those portlets. You can do that again by 'Manage roles'. I made some of the portlets accessible and not accessible to some of the roles, just to test again.

(I ran into a couple of exceptions (CLYAF0024E: Could not find key null
for CDO_CDO and CLFFC0074E: CDO ERROR: {0}. com.ibm.workplace.cdo.exception.CdoException at this point. The reason was that I logged in twice and had another browser window open to see if that link to those templates were really there on the front page. In firefox those sessions will interfer.)

Then I created three users (Jake Jackson, Mike Jackson and Steve Jackson) and I wanted to assign them to the roles in a new Bar application. Before I did that, I assigned to them user access to the application template and template category using the Resource Permissions portlet (in Administration). Then I needed an application and I created one using the Bar template (called it Jake's Bar). I clicked on it, and that took me to the 'First page'. The page has a lot of options in the drop down box, and I needed to select the 'Assign application members'. Then I could add the user I wanted as Bar manager (Jake), Bar tender (Steve) and Customer (Mike). B.t.w. for some ridiculous reason, the pop up for searching users was case-sensitive.

Well, the only thing left to do was to make sure that all the three users could access the Applications portlet as a user. After that I logged in as each of those users, put the Applications portlet on the welcome page, and saw that it all worked just as I thought it would. I think I'm getting the hang of it.

Nice thing about this is that when you make changes to the application, you can save those changes back to a template again. Quite useful when you are developing something.

Today I was busy upgrading a WebSphere Portal development box to its newest flavour (6.0.0.1), when I realized that it was the perfect time (long waits) to have a look at something I intended to have a look at for a long time now: the backport of the 'new' concurrent package. WPS 6.0 still uses Java 1.4 and it won't be until WPS 6.1 they will use Java 5. Why wait until WPS 6.1 when you can have some of the stuff right now? I could use it to have complicated and time consuming processes grinding along in the background, while the front-end makes some Ajax calls now and then to monitor how things progress, without the fuss of complicated thread handling.

Unfortunately, you can't just go and roll out some threads in a web container. The number of threads it uses is managed by the container and adding some as needed may have a huge impact on the scalability of your application. People who've been there and have done that created a solution to this problem: the WorkManager. Fortunally they made it a standard (commonj). It's quite easy to use and lots of fun (sure it is). There are a number of implementations like the ones in WebSphere and in WebLogic, but also Geronimo and JBoss. You can use those, but you can also build one yourself. In either case you should be able to handle the number of threads in a sane way.

So that's the correct way to do it. Does that mean that we can't use a servlet and use some Ajax to wait for it to finish? Of course we can do that, as long as we know what we're doing. Shouldn't we use the concurrent package at all in a managed environment? No, you can use it, because there are also some nice classes like for example the ConcurrentHashMap that may come in use some day. I'm not sure when exactly though.