In that context, in the last few months I had inquiries from some users asking where they could find the original WLST that works with WebLogic 8.1 and 7.0, also WLST Script Generator and Console extension that work with WebLogic 9.x.

Now you can get these from the new google code project wlst-modules. WLST Script Generator 9.x can be downloaded from here. The zip contains a ReadMe.html that should walk you through the configurations steps. And for those unfortunate souls who are still using WebLogic 7.0 and 8.1, WLST jar can be downloaded from here.

Interview can be found here

I found JarScan, which actually works very well and the best part is it is free!. As an example, Under WebLogic 10.0 installation I wanted to find which jar contains the class javax.annotation.PostConstruct. With JarScan you will use,

java -jar /tmp/jarscan.jar -dir /opt/WLPlatform/10.2 -class javax.annotation.PostConstruct

This will return something like,

===============================================
Found: javax.annotation.PostConstruct
Class: javax.annotation.PostConstruct
Package: javax.annotation
Library Name: javax.annotation_1.0.jar
Library Path: /opt/WLPlatform/10.2/modules/javax.annotation_1.0.jar
===============================================

For a brief description on what’s new with Jython 2.2 see my old post here.

E:\WebLogic11g\Oracle\Middleware\wlserver_10.3\common\bin>java org.python.util.jython
Jython 2.2.1 on java1.6.0_05
>>>

Expired SSL Certificates!!!My initial reaction: You don’t have Monitoring? Hmm well, that led me to think, realistically how many environments have cert expiry monitoring? I haven’t seen any environments that have automated monitors that check the WebLogic Certificates. One of the reason why this may not have affected you is one, you are not using SSL and two, the certs you obtained have a life span of more than 10 years.

In our WebLogic environments we do not have monitoring specifically on the Cert’s, but we do have some monitoring that does warn us in-case  our Certs are about to expire. The way it works is, during boot time WebLogic Server logs a message if the certs configured are about to expire in the next 30 days. This message is logged with severity “Notice”. Our monitoring application listens on the Log BroadCaster (I will leave the details for another blog post), this listener will send an alert/EMail whenever a message is logged with severity “Notice”. The alert will contain the details of what is logged, in case of a Certificate that is about to expire it will contain the Date when it is going to expire and other Certificate details.

Please note, there is one problem to the above approach, i.e. we are relying on WebLogic Server to be started or restarted atleast once within this 30 days timeframe that your Certificate may expire. If not, you will never recieve the notification.

In one of my subsequent post I will write about an alternate simple approach to monitor your WebLogic Certificates.

 <Aug 3, 2009 12:38:48 PM EDT> <Notice> <Security> <BEA-090082> <Security initializing using security realm myrealm.>
<Aug 3, 2009 12:38:48 PM EDT> <Critical> <Security> <BEA-090402> <Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.>
<Aug 3, 2009 12:38:48 PM EDT> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.
weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.
        at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.doBootAuthorization(CommonSecurityServiceManagerDelegateImpl.java:941)
        at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(CommonSecurityServiceManagerDelegateImpl.java:1029)
        at weblogic.security.service.SecurityServiceManager.initialize(SecurityServiceManager.java:854)
        at weblogic.security.SecurityService.start(SecurityService.java:141)
        at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
        Truncated. see log file for complete stacktrace
>
<Aug 3, 2009 12:38:48 PM EDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED>
<Aug 3, 2009 12:38:48 PM EDT> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down>
<Aug 3, 2009 12:38:48 PM EDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN>

From the error message it looked like the boot.properties on the Managed Server does not have the right username and password, we made sure it was updated. Tried to re-start the server, same issue. We tried to delete the entire LDAP directory on the Managed Server side so that it syncs the latest from Admin Server which should not have any issues, but that didn’t work either.

Well, now we ran out of options and contacted Oracle Support, they looked at it and asked us to do a couple of other things which did not work either. Finally, before we escalated further Oracle Support Engineer asked us to try one more last thing that is to enable MasterFirst on EmbeddedLDAP. Honestly I never knew such attribute existed and the help for that attribute looks something like this.

MasterFirst-Specifies whether a Managed Server should always connect to the embedded LDAP server on the Administration Server, instead of connecting to the local replicated LDAP server.

Miraculously enabling this attribute did seem to work and the Managed Server started up happily without any issues. Now the question is, Why do we need to specifically enable this attribute when we do not have issues in other environments? The answer is we don’t know “yet”. We suspect its Network, but not entirely sure and we will find out very soon. But whatever it is “MasterFirst” did save my day and probably days!

*sys-package-mgr*: can’t create package cache dir, ‘/tmp/cachedir/packages’
Traceback (innermost last):
File “<iostream>”, line 12, in ?
ImportError: no module named java

When Jython initializes it scans all the jar files it can find at startup to build the package and class structure available to the JVM. This information is written to files in a directory named ‘cachedir’, WLST chooses your ‘java.io.tmpdir’ to store these files. There is a problem with this approach especially on Unix machines.

Problem:

Most Unix machines are shared across a number of users. Say “user1″ first logs into the machine and fired up ‘java weblogic.WLST’, Jython will create the ‘cachedir’ under ‘/var/tmp/’ and this directory will be owned by ‘user1′. This user will have no problems using WLST. Now ‘user2′ logs in and fires up WLST, this process will try to write to the same directory, ‘/var/tmp/cachedir’ which is now owned by ‘user1′ and hence fails with the above error message.

Solution:

There is a pretty simple and straight forward solution to this problem. Jython supports a System property (python.cachedir) that you can set which will determine the directory where this ‘cachedir’ is created. So in our case to start WLST you will use,

java -Dpython.cachedir=/home/user1 weblogic.WLST

This will create the cachedir under /home/user1, and this way all users can have their own cachedir’s without running into each other. For a more elegant solution you can create a simple unix script that wraps the call to WLST and adding the right cachedir location per user. Sample is shown below,

#!/bin/sh

# Setup classpath, probably execute setDomainEnv.sh

java -Dpython.cachedir=~ weblogic.WLST

As long as the ‘~’ resolves properly to the home directory for the user executing WLST you will never have to worry about this ‘cachedir’ related error messages..

• WebLogic Server 10.3 MP1 is part of Fusion Middleware 11g.
• WebLogic Portal is NOT part of the Oracle Fusion Middleware 11g. The portal product that is part of Fusion Middleware is Oracle WebCentre.
• Oracle will continue to develop and innovate on WebLogic Portal and planning to release 11g version by the end of the year.
• JRockit is the recommended JVM for Oracle Fusion Middleware 11g.
• Oracle does not have any plans to merge Sun’s JVM and JRockit into one, both these JVM’s will be independent of each other.
• JDeveloper is the recommeded IDE for all products in the Fusion Middleware suite.
• Oh lastly, Enterprise Manager is the mother of all Managers and will be able to control the Universe.. .

Checked with Oracle and offcially WebLogic 10.3 is NOT supported on either JDK 1.4 nor JDK 1.5.