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
>>>

 <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.. .

But once SSL is configured and you have dis-abled the non-ssl port, you should make sure that the DefaultProtocol your WebLogic Server uses is SSL (either t3s, https or iiops). If you haven’t done this, your WebLogic Server will try to use “t3″ (default) for any outbound connections and since the ListenPort is disabled it will fail.

Here’s a simple wlst script to change the default protocol to t3s for all the servers in the domain.

# After connecting to the Admin Server

edit()

startEdit()

servers = cmo.getServers()

for i in servers:

i.setDefaultProtocol(“t3s”)

save()

activate()

java.lang.NoSuchMethodError: isEnabledFor
······at org.apache.commons.logging.impl.Log4JCategoryLog.isErrorEnabled(Log4JCategoryLog.java:189)
······at org.apache.beehive.netui.util.logging.Logger.isErrorEnabled(Logger.java:97)
······at org.apache.beehive.netui.pageflow.internal.AdapterManager.getServletContainerAdapter(AdapterManager.java:47)
······at org.apache.beehive.netui.pageflow.PageFlowUtils.createURLTemplatesFactory(PageFlowUtils.java:1716)

Well, initially I thought this is caused due to another version of commons-logging.jar lurking around somewhere in the system classpath and is being picked up by the application. But after carefully reviewing the classpath and other libraries in the application I did not find any foul play, this just drove me crazy. Thought I would instrument the Log4JCategoryLog class to see what methods it is seeing in “org.apache.log4j.Category” that is making it to fail with NSME. After compiling and re-packaging it in commons-logging.jar to my surprise everything worked as normal. I could see my debug output that I put in while instrumenting Log4jCategoryLog. At this point it made me think if the class file packaged in commons-logging.jar is erroneous. To prove that I had to isolate the problem to just commons-logging and log4j. Thanks to another colleague, this simple reproducer revealed the issue.

public class Foo {
···// Ensure that your classpath has commons-logging-1.0.4.jar and log4j-1.2.8.jar
···public static void main(String[] args) {
······org.apache.commons.logging.impl.Log4JCategoryLog x = new org.apache.commons.logging.impl.Log4JCategoryLog();
······x.isErrorEnabled();
···}
}

This simple client failed with the exact same error I was seeing while deploying the console. I believe the problem is the classes in commons-logging-1.0.4 that come from apache have been compiled with the wrong log4j Category class.
If you do javap -c org.apache.commons.logging.impl.Log4JCategoryLog with commons-logging-1.0.4.jar in classpath you will see that for isErrorEnabled method,

public boolean isErrorEnabled();
Code:
0: aload_0
1: getfield #7; //Field category:Lorg/apache/log4j/Category;
4: getstatic #14; //Field org/apache/log4j/Level.ERROR:Lorg/apache/log4j/Level;
7: invokevirtual #17; //Method org/apache/log4j/Category.isEnabledFor:(Lorg/apache/log4j/Level;)Z
10: ireturn

Here the log4j’s Category’s isEnabledFor takes Level as an argument, but Log4JCategoryLog is expecting an object of type Priority. If I re-compile Log4JCategoryLog and re-package it and do a javap -c on the class I get,

public boolean isErrorEnabled();
Code:
0: aload_0
1: getfield #2; //Field category:Lorg/apache/log4j/Category;
4: getstatic #9; //Field org/apache/log4j/Priority.ERROR:Lorg/apache/log4j/Priority;
7: invokevirtual #12; //Method org/apache/log4j/Category.isEnabledFor:(Lorg/apache/log4j/Priority;)Z
10: ireturn

As you see the log4j’s Category’s isEnabledFor method takes an object of type Priority as an argument which is right. After googling a little bit I found that this has been corrected with the new commons-logging jar available at http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.1-dev.jar.

_uacct = “UA-2684269-2″;
urchinTracker();