Weblogic portal 10.2 integration

Today have been struggling with Weblogic 10.2 to get a custom authenticator to work. The couple of months I have been working on a Weblogic portal 10.2 project for a large energy supply company. The target was to create a new architecture using WLP as main presentation tier. The business tier is based on ALSB using ESB combined with BPM processes.

The business tier delivers the webservices connector jars which the portal uses to connect to the ALSB. The service connectors are created using Apache CFX, open source webservice framework. All jars provide a single DAO object which is fully unit tested and configurable to either return a mock object or connect to a real server.

The sounds a very good approach untill we tried to finally integrate the services on the client environment. We were not getting any results back from the ALSB though the configurations were all done correctly. The reason was the following:

Weblogic always loads the classes from the parent classloader before it uses the application classloaders. This means that resources provided by the parent classloader will always get precedence. Normally this is not a problem until XML is used. With all the great ideas of SAXParserFactories and DocumentBuilderFactories you basically don’t know what implementation is instanciated to support the factory calls. In weblogic case, the factories are provided in a weblogic specific package located at the parent classloader. Since Apache CFX is heavily using XML, it appears that the weblogic implementations are not compatible with Apache CFX. Though one can argue if Apache CFX is using the libraries wrong or weblogic’s implementation is not quite standard, that is a separate discussion.

For me this was quite a fuzzy problem. Since the issues were not rising on my local environment (as all developers say ). Finally I created a simple JSP file to print out the instances of the xml factories so I could see what the difference was:
Current XML implementations

• Saxparser factory implementation: <%= SAXParserFactory.newInstance().getClass().getName() %>
• Saxparser implementation: <%= SAXParserFactory.newInstance().newSAXParser().getClass().getName() %>
• DomBuilder factory implementation: <%= DocumentBuilderFactory.newInstance().getClass().getName() %>
• DomBuilder implementation: <%= DocumentBuilderFactory.newInstance().newDocumentBuilder().getClass().getName() %>

To solve this issue, you need to tell Weblogic to use the application class loader for the xml related packages. To do this, you need to add the following changes in the weblogic-application.xml file:

javax.jws.*
org.apache.xerces.*
org.apache.xalan.*

Having this in the weblogic-application.xml file, the classes are loaded from the application classloader. Running the jsp code again now, you will see that the implementation has changed. Of course the packages need to be available in your application libs. In my case, I got the xerces packages as the factory implementations. This solved the webservice integration part for now.

Second part is to integrate the RSA Access Manager to the portal authentication system. To support this, the client has created a custom authentication provider that encapsulates the authentication functionality that is specific for RSA. In the code we can simply use the standard Weblogic authentication api. Now the issue rises that we need to know if the RSA connector could not login the user what the specific exception was. Though the custom authentication provider is throwing typed exceptions, we were not getting them from the server.
After a search we found the following form link:

http://kr.forums.oracle.com/forums/thread.jspa?threadID=794043&tstart=75

This seemed to solve our issue since it was exactly the problem we were facing. We updated the setDomainEnv script with the property added as Java Options for the JVM startup.
%JAVA_OPTIONS% -Dwlp.propogate.login.exception.cause=true

But… as it always goes, we were still getting the same FailedLoginException. Finally it appears that we needed to put the custom authenticator on the first place so it would be the first one that throws an exception. Though by setting the type to ‘sufficient’ the custom authenticator was called but the failed login exception was already thrown by the SQLAuthenticator. Since we did see our custom exception in the logs coming back, we didn’t understand why it was not thrown in the controller code. After setting the authenticator to the first row, the exception was thrown as expected.

Both these issues cost me almost a week of full time troubleshooting. So if you have the same issues as I have, I hope this blog entry has saved you some time and frustration