You have received a WebSphere Portal VM that is setup to use security settings that don’t match your environment, and you need to go back to a simple config.

Running the recommended

does not work, because you have not got a working Portal environment in the first place, so it won’t start.

Overview of solution

Disable the security, then perform wp-restore-default-repository-configuration.

Files and Tools used

• security.xml
• ConfigEngine 
• wkplc.properties

Whenever you see some code with bold and italics that is something for you to change to match your environment 

Details:

1) disable security.

This involves directly editing the security.xml file for your node. Note that your portal instance will NOT work when security is disabled, so performing this step will disable your portal instance. You should not think about doing this in a production environment (you probably shouldn’t be passing around Portal VM’s for production environments anyway). (The security.xml will live in the config for your node. I’ll assume you know where this is, if not use the find command on your operating system).

To disable security, edit the security.xml, and change the enabled attribute on the root security element to be false ie change enabled=”true” to enabled=”true”

2) start up your portal instance using whatever commands are appropriate.

On linux you might find

useful.

3) Setup restore properties in your wkplc.properties file.

Profile/ConfigEngine/properties/wkplc.properties

# The realm name to be used. A realm with this name will be created.
restore.file.realm=New Unique Realm restore.file.delimiter=/

# Portal and WAS admin UID (short name) and password
restore.file.primaryAdminId=New Unique Admin ID 

restore.file.primaryAdminPassword=Password

# CN of portal admin group (short name)
restore.file.primaryPortalAdminGroup=adminGroupCN

4) run ConfigEngine.sh

Profile/ConfigEngine/ConfigEngine.sh wp-restore-default-repository-configuration

5) Turn on security (reversing step 1)

6) shutdown (or kill) portal

7) startup portal.

You should now see your portal server running without using LDAP.

The key step in doing this is to uninstall portlets that aren't needed. (see http://www-01.ibm.com/support/docview.wss?rs=899&uid=swg21213982&ca=lsall for a list). For the lazy developers (read me) there are a series of scripts that have been developed that do this. The article Installing and configuring WebSphere Portal V6.0 Servers for development with Rational Application Developer V7.0 and Rational Software Architect V7.0 includes these scripts in a zip file (search for StartupPerformanceConfig.zip in the article). The article also has some good suggestions for memory and jvm settings for your server.

I have known about the existence of this process for a little while, but it took me a little to find them just now (when tuning a development server). Google was have troubles pointing me to the right article, so I thought for my sake I'd try and help google find this in the future. (Even if google did find the right spots, the title of the developerworks article wouldn't have made me think that it had the nugget of information about IBM WebSphere Portal Startup performance).

What I was able to work out from trawling the net and poking around at the WebSphere portal installation is that the install history for iFixes and Fixpacks for Portal are stored in the directory %PORTAL_HOME%/version/history. This makes the process of finding the fix level a case of: 

1.  Lookup the Portal home. 
2. List the files in the version history directory.

Lookup the Portal Home

To lookup the portal home, use the fact that there is a WPS_HOME environment variable set in the WebSphere environment. Unfortunately looking up values in the WebSphere environment is non-trivial. The WebSphere environment is not made directly available, to access it you need to go through the WebSphere Admin service, and the WebSphere management mbeans.

The code to do this is:

com.ibm.websphere.management.AdminService as =
	com.ibm.websphere.management.AdminServiceFactory.getAdminService();
String server = as.getProcessName();
javax.management.ObjectName serverName =
    new javax.management.ObjectName("*:*,type=AdminOperations,process=" + server);
Set objectNames = as.queryNames(servName, null);
javax.management.ObjectName objectName =
    (javax.management.ObjectName) objectNames.iterator().next();
Object[] args = new Object[] {"${WPS_HOME}"};
String[] signature = new String[] {"java.lang.String"};
String wpsHome = as.invoke(objectName,"expandVariable",args, signature);

The wpsHome variable will contain the string path to the websphere portal home directory.

List the Files in the Version History Directory

After retrieving the portal home, it is possible to lookup the fixpacks in the ${WPS_HOME}/version/history directory.

The following code does this:

File f = new File(wpsHome + File.separatorChar +
    "version" + File.separatorChar + "history");
String[] children = f.list();
for (int i=0;i<children.length;i++){
	out.println(children[i]);
}

In summary the full code snippet for this is:

com.ibm.websphere.management.AdminService as =
	com.ibm.websphere.management.AdminServiceFactory.getAdminService();
String server = as.getProcessName();
javax.management.ObjectName serverName =
    new javax.management.ObjectName("*:*,type=AdminOperations,process=" + server);
Set objectNames = as.queryNames(servName, null);
javax.management.ObjectName objectName =
    (javax.management.ObjectName) objectNames.iterator().next();
Object[] args = new Object[] {"${WPS_HOME}"};
String[] signature = new String[] {"java.lang.String"};
String wpsHome = as.invoke(objectName,"expandVariable",args, signature);

File f = new File(wpsHome + File.separatorChar +
    "version" + File.separatorChar + "history");
String[] children = f.list();
for (int i=0;i<children.length;i++){
	out.println(children[i]);
}

The work of mapping file names to the installed fix packs/iFixes is left as an exercise for the reader.

Does anyone know if there is a better way of dong this?

After a friendly pointer from AJ to an article about automating websphere deployment, I decided that the time had come to revisit trying to automate the deployment of our EAR file for E2. I had done bits and pieces of thi in the past using a combination of the WebSphere scripting client, and the WebSphere ant tool (like ant but built with WebSphere bits and pieces). The killer constraint for me is that my client machine didn’t have access to any of the WebSphere binaries (perhaps unsuprisingly Apple and IBM have don’t perfectly interoperate).

In order to work around thi sproblem I ended up leveraging one of the classic protocols (telnet), the websphere scripting client, samba (to mount the application server drives), and a bit of ant to glue it all together. The process outlined below is focused around the deployment of the application E2Application to WebSphere portal.

Step 1: Enable telnet

In Windows Server 2003 this is relatively straightforward. Simply go to your control panel -> services -> Telnet go to the properties, make it automatic and start it.

Step 2: Write scripts to start and stop the app server

I did this using tcl and ended up with the following scripts (the pythonistas may like to use jython to do the same):

stopApplication.jacl

startApplication.jacl

Step 3: Write the ant code to compile and copy the application

After the series of standard building tasks, we used a simple copy task to copy the files to the exploded WAR directory on the server. (something like: ${portal.home}/WebSphere/profiles/wp_profile/installedApps/{cell}/{application}.ear/{app_war}.war). Since I develop on a laptop I added in a combination of available and fail task to stop me from accidently creating directories if I hadn’t mounted m

Step 4: use ant to telnet to the server

Make use of the telnet ant task1 to telnet into the server, and run the stop and start server jacl scripts. My Ant targets (passwords scrubbed) are below (excuse the duplication):

        <!– change to the IBM AppServer directory –>
        

        <!– Execute the jacl –>
        

        <!– wait for the connected to process message, which will occur on the successful completion of the script –>

        <!– change to the IBM AppServer directory –>
        

        <!– Execute the jacl –>
        

        <!– wait for the connected to process message, which will occur on the successful completion of the script –>

Step 5

mix ingredients and enjoying being able to have a one click deploy to WebSphere Portal.

Appendix

For security paranoid people with time on their hands, it is possible to do this using ssh and scp. The key parts will be step 3 and step 4. In step 3 we are using folder share and the ant copy task currently. It could be done with scp. In step 4 the use of telnet could be replaced with ssh.

1 – The telnet task depends on the availability of the commons-net jar on the classpath. (click here to download commons-net).↩

1. Ensure that the database is accessible using the Oracle SID (see the early post Oracle SID!=Service name)
2. Next you will need to increase the number of proceses that can be connected to the instance, as there are a large number of connection pools set up by the system, which the database will need to support. The following command worked in my environment:

       ALTER SYSTEM SET PROCESSES=150 SCOPE=SPFILE;

3. After having performed these base setup commands and options, you can run the IWWCM migration scripts to migrate existing data.
4. To ensure that the connection pooling works correctly, you will need to grant the following privileges to public:

   1	grant select on pending_trans$ to public;

   1	grant select on dba_2pc_pending to public;

   1	grant select on dba_pending_transactions to public;

5. Finally, grant the following privilege to each user to which connections are made from the application server.

       grant execute on dbms_system to <user>;

After having performed these steps you will have an Oracle XE database that will work happily with IWWCM.

For many years Oracle has been telling everyone Oracle SID != SERVICE_NAME.

Java Developers have always smiled and nodded with this statement as the oracle thin client jdbc url would always be something like:

jdbc:oracle:thin:@server:1521:SERVICE_NAME, or
jdbc:oracle:thin:@server:1521:SID 

which would work because databases always either had the SID and SERVICE_NAME as the same, or there was some magic that the Oracle listeners did to make this work.

Somewhere in the past couple of releases of Oracle this transparent mapping has ceased to exist. In particular Oracle 10G XE out of the box doesn’t support this sort of option.

It seems the new preferred way of doing Oracle JDBC URLs is:
jdbc:oracle:thin:@server:1521/SERVICE_NAME.

I discovered this information while working with making a WebSphere Portal instance use Oracle as it’s data repository. The documentation for doing this suggested using the old school SID style of url.  I tried this first as it felt familiar, but things didn't work.  Changing the url to use the PORT/SERVICE_NAME approach looked to mostly work, but didn’t quite spread the changes to everywhere required. I needed to run WPSConfig connect-database to update all the hidden bits of configuration around the portal installation. Unfortunately, this failed as the wpsconfig script calls out to programs that expect the url to follow the old school syntax (the stack trace show an index-out-of-bounds exception while parsing connect srings). I then had to go in and update the configuration on the database to enable connection via the old SID style approach.

This was done by working on the listener.ora file
(C:\oraclexe\app\oracle\product\10.2.0\server\NETWORK\ADMIN) to add in a SID_LIST_LISTENER entry for the database.

This was simply to add:
(SID_DESC =
    (GLOBAL_NAME = XE)
    (SID_NAME = XE)
    (ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
)

to the SID_LIST of the SID_LIST_LISTENER

I ended up with a SID_LIST_LISTENER that looks like this:

SID_LIST_LISTENER =
    (SID_LIST =
        (SID_DESC =
            (SID_NAME = PLSExtProc)
            (ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
            (PROGRAM = extproc)
        )
        (SID_DESC =
            (SID_NAME = CLRExtProc)
            (ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
            (PROGRAM = extproc)
        )
        (SID_DESC =
            (GLOBAL_NAME = XE)
            (SID_NAME = XE)
            (ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
        )
    )

This configuration works with an out of the box Oracle XE installation, and lets me use the jdbc:oracle:thin:@server:1521:SID.

When trying to find which WebSphere portal jar file contains the PortletServiceHome class (for the unitiated there are 225 jars in the portal shared directory), I was pushing my very rusty shell scripting skills.  I pulled in Doug for some advice, and we were working through various sledgehammer approaches and talking to google about what to do.  We were playing with various combinations of pipes and shell commands to get the output of the find (or ls) to play with the jar tvf and grep.

AJ then piped in with just use grep, and he really meant.. just use grep, and take advantage of the fact that the contents of the jar will be listed in plain text in the jar.

The command I ended up with was (running in PortalServer/shared/app):

grep PortletServiceHome *.jar

Which returns:
Binary file wp.pe.api.standard.jar matches
Binary file wp.pe.rt.impl.jar matches

Then running jar -tvf across the first jar shows that this is what I need to compile against and work with when developing.

The bulldozer of a grep across jars is the best way to find which jar contains a class that you are looking for1.

1 – While this feels really inefficient, it is actually better than having to spawn off multiple the jar processes which other approaches would involve. ↩