STS deployment issue: conflicting package names

Last week had an issue with a delivery to a client from our offshore team. The application is a OSGI based application using Spring DM and Spring MVC.
The team delivered the changes and I tried to build the par using both maven and directly from eclipse using STS. Both gave me the same exception:

Caused by: com.springsource.kernel.osgi.framework.ImportMergeException: cannot merge imports of package 'com.foo.bar' from sources 'Import-Bundle 'MyApp-1.0-SNAPSHOT-0-securityservices' version '1.0.0', Import-Bundle 'MyApp-1.0-SNAPSHOT-0-myapp_api' version '1.0.0'' because of conflicting values 'MyApp-1.0-SNAPSHOT-0-myapp_api', 'MyApp-1.0-SNAPSHOT-0-securityservices' of attribute 'bundle-symbolic-name'


After some research it seemed that the problem was in the MANIFEST.MF files generated using Bundlor. The point is that the projects suddenly all exported the package: com.foo and com.foo.bar as part of the ‘Export-Package’ entry.
The reason was that the packages seemed empty but the weren’t. The developer working on the project was using a Mac which lead to the creation of .DS-store files in the com and foo folders. Since the developer also managed to commit these files into SVN, I got these files as well during a fresh checkout. The issue was also less apparent since the files are hidden.
Knowing this, I simple cleaned all .DS-store files and regenerated the MANIFEST files again. This solved the issue.

After a search on google, it seemed that the issue is already resolved and only affects Bundlor tool version 1.0.0.M6. The solution in the tool was to add .DS-store files in an ‘exclude-from-export’ list so these files were not added for export. The only thing that I didn’t find out yet is how to just update this component instead of the whole STS package. Open to suggestions

Hopefully this was helpfull for anyone who has the same issue.

OSGI DM Server to simple Jetty Webapp

I am working with Wicket Framework combined with OSGI, Spring DM and running on the DM server. Though everything is working fine, I am running into issues because the Springsourcetool plugin is synchronizing my changes to local server every time a change is saved. You can turn this off but you do need to see your changes on the server. Especially when you are tuning the layout.

You can also save the page as a local HTML page to experiment with some ui changes but still there is some merge work to be done afterwards.

Instead of doing that, I decided to switch over to Jetty during the ui development so there was less overhead for using DM server to redeploy all par bundles when saved.

The changes were very simple:

update the web.xml

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/jetty-applicationContext.xml</param-value>
</context-param>
<!--
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<context-param>
<param-name>contextClass</param-name>
<param-value>com.springsource.server.web.dm.ServerOsgiBundleXmlWebApplicationContext</param-value>
</context-param>
-->


Since I use spring DM to inject the beans using osgi:reference, I created an addtional jettyApplicationContext.xml where I replace the osgi:reference calls with standard bean definitions.

So originally I had:

<osgi:reference id="authenticationService" interface="com.componence.social.AuthenticationService"></osgi:reference>


in the jetty context file:

<bean id="iwinAuthenticationService" class="com.componence.social.services.impl.AuthenticationServiceMockImpl"></bean>


Now since Maven dependencies has caused that the project references are set, using a direct spring bean injection is a piece of cake.

Now you can use the Jetty plugin to start the web application as a standard server and changes are instantly shown within 2 seconds. This will definitely save you time and a lot of frustation!

Good luck!

Wicket using Spring Dynamic Modules on DM server

This is the third project I am using Spring Dynamic Modules on Spring DM server. Though I like the idea behind OSGI, I have been struggling with it for a couple of days before I got it up and running.

Hopefully with this blog entry, I can prevent some of the problems that you might run into when you try it.

Project software

• Maven 2
• Spring framework 3
• Spring DM
• Wicket 1.4.7
• Springsource DM server 2.0
• Eclipse with Springsource tool

Project structure

Standard maven structure:
- parent
|– Iwin (par)
|– IwinWeb (war)
|– IwinServices (jar)
|– IwinDomain (jar)
|– IwinIntegration (jar)

Springsource tool tips:

• Generate MANIFEST.MF file is supported using the a template.mf file. SST generates the manifest in the source folder /META-INF. This is not a problem for jars but for war application, you need the MANIFEST in the webapp/META-INF folder. When you setup the project using Maven eclipse:eclipse, the webapp is not part of the project source path. Because SST cannot find the manifest file, it will generate it always in the source folder. To solve this I had to add the webapp as a eclipse source folder. Then SST will scan and find an existing manifest file and generate the content in there.
• After initial setup with maven, you need to do some extra work to get is working in SST. First of all you need to add SST nature in the project and add OSGI bundle nature. If you also (like me) have create a maven project with type ‘par’, you cannot at par nature to the project any more. I could only solve that by removing the bundle nature and add ‘com.springsource.server.ide.facet.core.parnature’ in the .project file.
• Because of the manual updates on the eclipse project files, you cannot run eclipse:eclipse anymore since it will reset the settings of your project. (kinda weird because according to doc it shouldn’t happen unless you run eclipse:clear). For me this was a bit annoying since I always add dependencies in the pom and run eclipse:eclipse. To solve this, I have added the Maven Eclipse plugin which is running quite nicely. After updating the dependencies, you can manually select to regenerate the dependencies in eclipse (which basically just updates the classpath).
• You can add bundles to the par project by selecting the manifest file. You will see an extra tab on the bottom where you can add dependencies. This is needed if you deploy the par using SST. Don’t forget to add the bundle nature to the jar projects.
• Don’t forget to update the pom.xml file for the par because you would need it when you run a maven build command

Though there are somethings you need to get use to in SST, the tool in general works quite nice. There are miss matches when you use SST combined with Maven.
Dependencies for web applications in Maven are placed in the WEB-INF lib folder when you run the ‘package’ command. On your local environment the classpath is linking to the repository. This works well for WTP but if you need embedded libraries in your web application, you need to add Bundle-classpath to your manifest file. In my case I had to add wicket-spring-1.4.7.jar as embedded jar. In the classpath I added ‘/WEB-INF/lib/wicket-spring-1.4.7.jar’. When I packaged it and deployed it to DM server, it worked. When I start it from local dev, it didn’t work. Reason is that the libraries are not in WEB-INF/lib in the src/main/webapp. To solve this, I copied the embedded jars to src/main/webapp/WEB-INF/lib. Though this works, I don’t like this because now when I commit the source, the libs are included. If I don’t include, other developers will have to do it again before they can run from local SST. If any one knows a better solution, please leave a comment

Now probably you will be saying, embedding jars is a bad idea. You can add wicket as separate bundle. I thought the same thing. This thought has cost me another day of struggling. At first, I added wicket as bundle in DM server by copying it in the DM repository. Then I added in my manifest file, the import statement and my hello world wicket app was working. Great! Then I added Spring DM and used the <osgi:reference …. /> and <osgi:service …..> in the spring context files. The service was provided by my IwinServices project which is a osgi bundle. It was added to the par and it should work.

There were two main issues that I ran into:

1. bundle context was not found
2. interface is not visible for class loader

First issue eventually turned out to be that because I used ‘OsgiBundleXmlWebApplicationContext’ in the web.xml configuration as I followed nicely written tutorial http://cwiki.apache.org/CAMEL/tutorial-osgi-camel-part2c.html to setup my application. But it turned out that DM server is setting the application context in different attribute within the servlet context. To solve this, I have switched over to use the ‘com.springsource.server.web.dm.ServerOsgiBundleXmlWebApplicationContext’ as contextClass. This solved the context issue. One additional tip, if you have added ‘org.springframework.osgi.web’ artifact in your POM, you should remove it. If you keep it in the pom and package the par, the application doesn’t start up leaving you with some useless messages. I needed to add this reference because it is added to your manifest file if you refer to the OsgiBundleXmlWebApplicationContext in your web.xml.

After setting this all up, the application starts up. I was very happy for a moment just be see a wicket stacktrace page which told me that the osgi service interface was not visible in the class loader. I am using SpringBean annotation to inject the osgi:service in the Page compenent. To keep this story short, after several hours, it turns out that the Proxy used in Wicket to inject the beans in the page component is loading the class from his class loader. Since I deployed the Wicket bundle as a separate bundle in DM server, it had its own class loader. That’s why I cannot find the class within the Par package since DM server is shielding the par in its own context. To solve this, I have used the ‘discouraged osgi approach’ by embedding the jars in the web application. Since wicket is then loaded within the web applications classloader, it can successfully inject the service bean in the page component.

Though there were still many small things that went wrong, these were the main things that I ran into. I am not a very structured writer unless I spent a lot of time in writing so I will keep this post as it is now. Hopefully someone might find it useful.

Leave a comment if you have any information regarding this topic. I need the information to prevent myself from running into these issues while the deadline of the project is upcoming

If I have time I will strip a small sample app and add it as attachment to this post. If I haven’t done it because of lack of time (or simply to lazy ) and you would like to have it, you can leave a comment.

Groovy script to generate maven repository structure

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


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

Apache Camel namespaces

I am running into some weird issues when I integrate Camel 1.6.0 into my Spring project.

The project was started by my 6 months ago or so and I created a prototype complete with junit tests and mock implementations using Camel as main integration framework.

The structure of the project is as follows:

• Portal frontend (BEA weblogic 10.2)
• Spring Business layer (POJI & mock implementations & camel based implementations)
• Integration layer (Camel routing in & out transformations)
• Multiple endpoints (Webservices, CGI scripts, GET)

After the first proof of concept, the project was taken over by the developers and I was reallocated on a different project. Now all of a sudden, the project doesn’t seem to build anymore. The developer mentioned a schema problem.

I investigated the issue and my initial thought was that the camel-spring.jar was missing from the maven dependencies. Since we use Spring 2, the concepts of spring.handlers and spring.schemas were added so third party libs can ship the XSD files within the library. But of course, this would be too simple of this was the issue.

The dependencies seemed to be ok but I still got errors from eclipse mentioning:

Description    Resource    Path    Location    Type
cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element ‘camelContext’.

When looking into the details, I got the message:

expecting namespace ‘http://activemq.apache.org/camel/schema/spring’ but the target namespace of the schema document is ‘http://camel.apache.org/schema/spring’.

First problem was regarding the fact that camel namespace was not correctly loaded into the spring configurations. So I figured that by solving issue 2, the first would be resolved as well.

As the second problem already defines, the issue arises because camel has recently updated the namespaces to camel.apache.org/schema/spring. The strange thing is that I haven’t updated the dependencies since 1.6 should still be within the same namespace.

Checking the spring.handlers and spring.schemas content of camel-spring.jar, I saw the following content:

========================================================

http\://camel.apache.org/schema/spring=org.apache.camel.spring.handler.CamelNamespaceHandler

========================================================

========================================================

http\://activemq.apache.org/camel/schema/spring/camel-spring.xsd=camel-spring.xsd

http\://activemq.apache.org/camel/schema/spring/camel-spring-1.0.0.xsd=camel-spring.xsd
http\://activemq.apache.org/camel/schema/spring/camel-spring-1.1.0.xsd=camel-spring.xsd
http\://activemq.apache.org/camel/schema/spring/camel-spring-1.2.0.xsd=camel-spring.xsd
http\://activemq.apache.org/camel/schema/spring/camel-spring-1.3.0.xsd=camel-spring.xsd
http\://activemq.apache.org/camel/schema/spring/camel-spring-1.4.0.xsd=camel-spring.xsd
http\://activemq.apache.org/camel/schema/spring/camel-spring-1.5.0.xsd=camel-spring.xsd
http\://activemq.apache.org/camel/schema/spring/camel-spring-1.6.0.xsd=camel-spring.xsd

http\://activemq.apache.org/camel/schema/spring/camel-spring-1.6.1.xsd=camel-spring.xsd

========================================================

The handlers was refering to the Xml handler written for spring integration, the second should map all the xsd files to a classpath resource. In my case this should be refering to ‘camel-spring.xsd’.

I checked the XSD content in the camel-spring jar and in the first line, it shows:

<xs:schema elementFormDefault=”qualified” version=”1.0″ targetNamespace=”http://activemq.apache.org/camel/schema/spring” xmlns:tns=”http://activemq.apache.org/camel/schema/spring” xmlns:xs=”http://www.w3.org/2001/XMLSchema”>

Having walked through multiple articles and forums, I still cannot explain why the problem exists. So basically my current solutions is to switch over the dependencies in maven to Camel version 2.0-M1. Since the xsd and spring properties are all using the same namespace, I have switched over to the new namespace in my configurations and this solved the issue. Though I cna live with the upgrade and a milestone release, I am puzzled what the cause is of the issue. My guess is that somehow, the camel-spring.xsd cannot be found in the classpath and it downloads the file from the public internet, refering to the latest version. This might cause the namespace problem.

But accoring to spring, the spring.schemas should solve this problem. Though I am very annoyed with issue, I decided to leave the matter as I already spent too much time investigating the issue (including blogging about it ). You know what caused this issue, let me know. It would really ease my troubled mind

Used maven dependencies:
<properties>
<spring.version>2.5.6</spring.version>
</properties>
……………

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<version>${spring.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>${spring.version}</version>
</dependency>

<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring</artifactId>
<version>1.6.0</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<version>1.6.0</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<version>1.6.0</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jms</artifactId>
<version>1.6.0</version>
</dependency>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-core</artifactId>
<version>5.1.0</version>
</dependency>

……….

Java 1.6 on Mac OS X 1.5

I have been using my macbook pro for almost 5 months now and I must say I am very satisfied with the performance. Though the machine gets quite hot when actively used, developing on the Mac is indeed very good.

But………

I find it frustrating that the amount of time that i need to put in for setting up a proper Java development environment takes so much time. There should be better support from Mac for this. But for the time being I will just blog my findings and hopefully someone else finds them usefull.

Environment variables:

As a Java developer, you always need to set the JAVA_HOME environment setting value to the home directory of you Java installation. Though a lot of application nowadays don’t check this variable, Java tools like maven and ant are depending on it. I have added this value on the normal linux way: /etc/profile. By adding this value in profile, the JAVA_HOME is set on startup for all users.

Path:

Second I needed to add the different applications executables to the PATH variable. Normally I always do this in the /etc/profile page. But I found out that for Mac this is done on a different place. In /etc you will find a directory paths.d. In this directory, you can just add a file with some ‘path values’ and it will be automatically added to the path. So this is quite easy. The only think is, you need to know this!

Java versions:

As a developer you need to work on different projects and it often requires us to run different versions of JDK. Normally I don’t have issues with it since I use Eclipse as main IDE. Eclipse installation includes different JDK versions, so you can easily switch it up in Eclipse. But for building purposes (example: running maven in terminal) I often use the terminal to run the build scripts. Now the big husttle is to get Mac use a 1.6 JDK since code depend on it. What I did was the following:

• install the Mac updates (1.5 update 4)
• open terminal
• go to /System/Library/Frameworks/JavaVM.framework/Versions
• unlink CurrentJDK (it was pointing to 1.5, seen via ls -la)
• ln -s 1.6 CurrentJDK

Now when I run ‘java -version’, I get the 1.6 64-bit version.

Eclipse memory settings:

Since I run applications in Eclipse that takes quite some memory, I needed to increase the max heapsize of the JVM. Now in Windows, this is done easily by editing the eclipse.ini file. In Mac version, this file seems to be missing. This is not true. Seems that the executable Eclipse file, can be opened as a directory. The eclipse.ini file, can be found inside the eclipse executable.

BEA weblogic

For the ones who are trying to get BEA weblogic running on the Mac. Well, to get the server running was not that big of an issue. You need to do some tricks but there are 2 articles written for this purpose. But to get BEA workshop going is a little different story. There is no IDE for this and I haven’t been successful in manually installing it. If I have it (or someone get’s it working), I will add comments.