Archive

Archive for December, 2009

Groovy script to generate maven repository structure

December 15, 2009 Leave a comment

For a project we work with clients who are not working with Maven but deliver jars in our subversion. Since we work with Maven, we need the jars in our repository. Since the amount of libraries were growing and I didn’t want to place the jars manually in the repository, I thought it was time to give groovy scripts a try. I have read ‘Groovy in action’ and it seemed simple enough to try.

Though I am sure the code can be much cleaner and nicer using Groovy syntax, I am still putting my code online. Hopefully it might come in handy for you as well.

The script does the following:
- read a folder where all the jars are checked out
- create a dest folder where the structure will be created
- create the folder structure (jarname/version/jarname-version.jar)
- write the source jars in the same structure
- create pom.xml file for the jar

Next step should be to create a parent project linking all the jars as a package to manage the dependencies and to be able to call mvn deploy. This should deploy the everything automatically to the repository.


import java.util.ArrayList;

import java.io.File;
import java.io.FileWriter;

public class OipServiceTool {
private String sourcefolder;
private String destfolder;
private List list = new ArrayList();

public static void main(String[] args) {
System.out.println("========================================");
System.out.println("============ OipServiceTool ============");
System.out.println("========================================");

OipServiceTool tool = new OipServiceTool();
// set sourcefolder and destfolder
tool.sourcefolder = "/Users/john/Documents/workspace_3.5/ws/OipServices/wsclient-libs";
tool.destfolder = "/Users/john/Documents/workspace_3.5/roo-ws/OipServiceTool/dest";
tool.create();
System.out.println("========================================");
System.out.println("=============== finished ===============");
System.out.println("========================================");
}

public void create() {
File sourceFile = new File(sourcefolder);
if (sourceFile != null && sourceFile.exists() && sourceFile.isDirectory()) {
// run through all libs in webclient-libs
sourceFile.eachFile {
if (it.name.endsWith(".jar")) {
JarFile jarFile = new JarFile(it);
System.out.println("Created jar $jarFile");
list.add jarFile;
}
};
} else {
System.out.println("Source folder is not valid.");
}

File destFile = new File(destfolder);

// - create folder structure
// - create folder with service name
// - create folder with version number
// - copy jar in folder
// - create pom.xml file
def createFolder = {
String pomXML =
"\n" +
"\n" +
"\t4.0.0\n" +
"\tcom.componence.oip.services\n" +
"\t$it.serviceName\n" +
"\t$it.versionNumber\n" +
"\t\n" +
"\t\tcom.componence.oip.services\n" +
"\t\tOipWebservicesParent\n" +
"\t\t1.0\n" +
"\t\n" +
"\t\n" +
"\t\t\n" +
"\t\t\torg.apache.cxf\n" +
"\t\t\tcxf-bundle\n" +
"\t\t\t2.2.3\n" +
"\t\t\n" +
"\t\n" +
"";
String serviceFolder = destFile.getPath() + File.separator + it.serviceName;
String versionFolder = serviceFolder + File.separator + it.versionNumber;
File serviceFile = new File(serviceFolder);
File versionFile = new File(versionFolder);
if (!serviceFile.exists())
serviceFile.mkdir();
if (!versionFile.exists())
versionFile.mkdir();

String jarName = versionFolder + File.separator + it.fileName;
String pomName = versionFolder + File.separator + it.pom;

File jar = new File(jarName);
if (jar.exists()) {
jar.delete();
}

org.apache.commons.io.FileUtils.copyFile(it.file, jar);

if (!it.sources) {
FileWriter fw = new FileWriter(pomName);
fw.write(pomXML);
fw.close();
}
};

if (destFile != null && destFile.exists() && destFile.isDirectory()) {
list.each {createFolder(it)};
}
}

class JarFile {
private String serviceName;
private String versionNumber;
private String fileName;
private File file;
private String pom;
private boolean sources;

public JarFile(File file) throws Exception {
// split the filename '-' sign and check the length
this.file = file;
this.fileName = file.getName();
this.pom = file.getName().replace(".jar", ".pom", ".zip");

String[] nameParts = fileName.split("-");
if (nameParts.length < 1) {
throw new Exception("Name '" + fileName + "' is not supported. Will be ignored.");
}
if ("sources.jar".equals(nameParts[nameParts.length - 1])) {
sources = true;
}
this.versionNumber = nameParts[1].replaceAll(".jar", "");
this.serviceName = nameParts[0];
}

public String toString() {
return "Servicename " + serviceName + "; Version " + versionNumber + "; is source: " + sources;
}
}
}

Categories: Java, Misc Tags: , ,

Weblogic portal 10.2 integration

December 15, 2009 Leave a comment

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

Follow

Get every new post delivered to your Inbox.