WebSphere Portal PUMA API

The details of our WebSphere Portal users are stored in IBM Tivoli LDAP server. This code prints what attributes of users are actually available and enables us to show them in a theme JSP. So our JSR 168 portlets have to further rely on IBM-specific code. Portability is really a lost cause.

try{

     javax.naming.Context ctx = new javax.naming.InitialContext();
     com.ibm.portal.um.PumaHome home = (com.ibm.portal.um.PumaHome)
     ctx.lookup("portal:service/usermanagement/Puma");
     PumaProfile profile = home.getProfile( request );
     List attributes = profile.getDefinedUserAttributeNames();
     User user = profile.getCurrentUser();
     Map map = profile.getAttributes(user, attributes);
     Iterator iterator = attributes.iterator();

      while (iterator.hasNext()) {
        String attribute = (String)iterator.next();
        System.out.println("["+ attribute +"][" +
                                  map.get(attribute) + "]");
     }

}catch( PumaSystemException pse ){
     System.out.println( "PumaSystemException" );
}catch( PumaModelException pme ){
     System.out.println( "PumaModelException" );
}catch( PumaMissingAccessRightsException pmare ){
     System.out.println( "PumaMissingAccessRightsException" );
}catch( Exception e ){
     System.out.println( "Exception" );
}

Java Regular Expression

Some of the requests from the client could be weird but they seem to serve their purpose. We have been using WebSphere portal and we were given the task of filtering the output rendered by the Portal. So I created a custom
HttpServletResponseWrapper and took a copy of the HTML before sending it to the browser. This part was easy.
A filter can be configured in the web.xml of wps.war since the Portal code itself is a WAR deployed on WAS. Stripping the HTML of certain tags and filtering it was more difficult.
I tried to use Java Regex. It worked for some cases but it was very hard to use it to massage nested HTML.

Regex is cool. The following code actually closes the ‘img’ tag. Regex can be used to close HTML tags easily if they are not nested too deeply and there no newlines .Nested HTML tags broken into separate lines are pretty hard to manipulate using Regex.

import java.util.regex.Matcher;
import java.util.regex.Pattern;


public class RegularExpression{


private String source =
"<img width=\"30\" height=\"18\" border=\"0\" src=\'/wps/images/dot.gif\' alt=\"\">";

public static void main( String[] argv ){
RegularExpression regex = new RegularExpression();
regex.changePattern();


}


public void changePattern(){
String content = source.replaceAll("<img[^>]+[>]", "$0</img> ");
System.out.println( content );

}

}

Experimenting with JSR 168 and WSRP

Experimenting with JSR 168 and WSRP

I recently started playing with portlets, mainly WSRP. It took me some time to figure out all the JSR 168 and WSRP terminology. It looked quite cool until I started using the tools. I used WebSphere portal UTE. My initial attempt to set up a WSRP channel between WebSphere and Liferay did not succeed because I assumed that it is going to be easy. It was not.

WebSphere portal UTE 5.0 does not have a complete GUI for enabling WSRP. So I pulled the WSRP4J code which uses maven 1.0 and not maven 2. I don’t know where this is specified and since I haven’t used maven before I wasted time trying to set it up with maven 2.

Now it looks like that I have to understand a slew of technology to really be very productive with WSRP and JSR 168. This could include Web service security, WSRP specification, JSR 168 specification, SOAP, WSDL and also the quirks of tools.

How do I understand this exception message if I don’t know the spec. ?

Consumer supplies a registrationHandle/registrationState pair that is not recognized by the Producer.

So I had to jump through several hoops just to view a simple WSRP portlet in the Swing consumer of WSRP4J.Aggregation of content using WSRP seems interesting. The following is the image of the WSRP4J Swing consumer showing a WebSphere portlet and its clone.

wsrp-portlet.JPG

WebSphere Portal and JSR 168

Initially we started migrating a project thinking that the JSR 168 standard is a totally portable way of writing portlets. After a few months of development we found that our code is sucked in by WebSphere portal. As much as we tried to, we coudn’t keep our code portable. All the navigation code including tag handlers became deeply embedded within the portal themes. Apart from that our authorization code now depends on the portal implementation.

We couldn’t figure out when WebSphere portal would support JSR 115. Our JSR 168 portlets are still portable but what use are they without the rest of the infrastructure provided by WebSphere Portal.

Annotations, Enum, AspectJ and the State pattern

The combination of annotations and AspectJ is a hot topic worth exploring when using JSE 5.0. Recently we were discussing if this combination can be used to implement part of the State pattern. Even though I couldn’t think of any practical value for this, I implemented this code. The following code has meta-data associated with methods and this meta-data has the next state hardcoded in it. I have used Enum,annotations and AspectJ but I haven’t checked this for bugs. The State pattern example is the one by Robert C. Martin. See Aspect-Oriented Design Pattern Implementations for implementations of the GOF patterns using AOP.

package com.state;

public class Turnstile {

public void lock(){
System.out.println( "Locking" );
}

public void unlock(){
System.out.println( "UnLocking" );
}

public void alarm(){
System.out.println( "Security Breach" );
}

}
package com.state;

public class TurnstileMachine extends Turnstile {

private TurnstileState state;

public void coin() {
state.coin( this );

}

public void pass() {
state.pass( this );

}

public void setState(TurnstileState state) {
this.state = state;
System.out.println( "Changing state to " + state );
}

}
package com.state;

public abstract class TurnstileState {

public abstract void coin( TurnstileMachine t );

public abstract void pass( TurnstileMachine t );

}
package com.state;

public class UnlockedState extends TurnstileState {

@Override
public void coin(TurnstileMachine t) {

}

@Override
@StateChanger(EnumState.UNLOCK)
public void pass(TurnstileMachine t) {
//t.setState( this );
t.unlock();
}

}
package com.state;

public enum EnumState {

LOCK {
{ state = new LockedState(); }
},
UNLOCK {
{ state = new UnlockedState(); }
};

TurnstileState state;

}
package com.state;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention( RetentionPolicy.RUNTIME )
@Target({ ElementType.METHOD })
public @interface StateChanger {
public EnumState value() default EnumState.LOCK;

}
package com.state;

public aspect StateAspect {
pointcut stateChanger( TurnstileState t,
StateChanger sc,
TurnstileMachine m)
: execution( @StateChanger * *(..) )&& @annotation(sc) && this(t) && args(m);

void around( TurnstileState t,
StateChanger sc,
TurnstileMachine m ) : stateChanger( t,sc, m ){
proceed( t, sc, m );
m.setState( sc.value().state);
}
}

Compile-time resolution of Generic methods

The draft Java Language Specification has this to say about Overloading.

8.4.9 Overloading

When a method is invoked, the number of actual arguments (and any
explicit type arguments) and the compile-time types of the arguments are used, at
compile time, to determine the signature of the method that will be invoked.

The difference here is the extra rule within braces.

This is the JLS second edition.

When a method is invoked, the number of actual arguments and the compile-time types of the arguments are used, at compile time, to determine the signature of the method that will be invoked.

Now code written using JDK 5.0 relies on the type arguments to determine the correct method even if we have two methods with the same name and no parameters like the following code.

public class Overloading {

public static <A extends String> A test() {
System.out.println("String");
return null;
}

public static <B extends Integer> B test() {
System.out.println("Number");
return null;
}

public static void main(String[] args) {
Overloading.<Integer>test();
Overloading.<String>test();
}
}

What I cannot do with generics ?

I am still trying to understand the full benefits of generics. I picked up the following that you cannot do with Java generics from the Sun generics forum where sometime back a generics debate was raging.

Use constants.
Cannot perform compile-time recursion.
Cannot do compile-time loop unrolling.
Cannot create full or partial specializations.
Cannot work with primitive types.
Cannot create arrays of generic types.
Cannot check generic casts at compile time.
Cannot do type analysis at compile time.
Cannot do anything with generics that would create multiple instantiations of the generic code.
Though I am not a C++ programmer, I found this article http://www.langer.camelot.de/Articles/Cuj/ExpressionTemplates/ExpressionTemplates.htm that would support many of the above points. It looks like a serious drawback of the Java implementation of generics.

  It would be interesting to check how many of the above are possible using C#.

Overloading of Generic methods

The draft Java Language Specification has this to say about Overloading.
8.4.9 Overloading
When a method is invoked, the number of actual arguments (and any
explicit type arguments) and the compile-time types of the arguments are used, at
compile time, to determine the signature of the method that will be invoked.
The difference here is the extra rule within braces.
This is the JLS second edition.
When a method is invoked, the number of actual arguments and the compile-time types of the arguments are used, at compile time, to determine the signature of the method that will be invoked.
Now code written using JDK 5.0 relies on the type arguments to determine the correct method even if we have two methods with the same name and no parameters like the following code.
public class Overloading {

 public static &lt;A extends String> A test() {
     System.out.println(“String”);
     return null;
   }
  
 public static &lt;B extends Integer> B test() {
     System.out.println(“Number”);
     return null;
 }
 
 public static void main(String[] args) {
  Overloading.&lt;Integer>test();
  Overloading.&lt;String>test();
 }
}

What I cannot do with generics ?

My first brush with Java generics was around 3 years back when I found a prototype compiler from Gilad Bracha ( I think ). Though I never delved too deep into that, I recently realised that one way to learn generics is to check what java generics can’t do that C++ templates can.

I came across a “abstract subclass” that we can’t write using java. AFAIK this is not our regular
java subclass that is abstract. The “Curiously Recurring Template Pattern (CRTP)” is one such instance.

There is no point in trying this C++ template trick using generics because the type is erased. So the controversial type erasure can teach you a lot of things that you can do with Java generics.

Classic MVC

I found this noteworthy article on the reasons for the M-V-C split. Read http://www.objectmentor.com/resources/articles/taskmast.pdf. I feel that any decent Swing application could use this article for a cleaner separation of concerns.

This is my first post.