On the Mobile Safari browser you can come across the error ‘Request header field DNT is not allowed by access-control-allow-headers’ . We’ll explain how to fix this easily.

When you’re doing an AJAX call to a different server (eg. api.javablog.be) then where the original page was loaded (eg. www.javablog.be); you’re essentially doing a cross domain AJAX call. This is blocked by browser due to security reasons.

To support mashup style websites, you can include a response header in the HTTP answer the server is sending:

Access-Control-Allow-Origin", "*"

The * means that any domain can send the AJAX call. It’s better to limit it to those domains which are allowed access.

Setting only this parameter is not enough to fix Request header field DNT is not allowed by access-control-allow-headers.

You’ll also need to set the following headers on the server side HTTP response object:

One of the problems you come across when using Weblogic are Weblogic classloader issues. These can regularly happen because Weblogic itself uses a lot of frameworks, some of which you’re also using in your application EAR/WAR file. Sometimes you want to use a newer version of the library then the one in Weblogic and that’s when the problems start because your library comes later on the classpath.

WLS CAT (Class Loader Analysis Tool)

Fortunately there is a Web app wls-cat available by default in Weblogic (you don’t see it deployed in the Weblogic console though).

Below you can find a screenshot of wls-cat in action. When you analyze conflicts, the tool will spit-out all classes which are in conflict – eg. more then one version is on the classpath (EAR/WAR classpath + Weblogic classpath), but only one can be loaded in the JVM.

Once you have a list of the packages/classes in conflict, you have two options: either you can remove the duplicate jar from your EAR application, or you can instruct Weblogic to choose your version over the one bundled in Weblogic.

The latter option is configured via the META-INF/weblogic-application.xml file in your EAR file:

Configuring the options happens on package level. Now the nice thing about wls-cat is, that it also generates a ready-to-use prefer-application-packages xml element so you don’t need to create this list fully by hand by inspecting all the packages inside a conflicting library jar

The WebLogic Scripting Tool or in short WLST, is a command-line tool that you can use to automate Weblogic server installs and configuration of domains. This post will explain how to setup your Eclipse WLST development environment so you can write the scripts with code completion.

WLST scripting environment

The WLST scripting environment is based on the Java scripting interpreter, Jython. To get access to the WebLogic scripting functions from your Eclipse IDE you’ll have to install the plugins Oracle has made available.

This file should be placed into META-INF/beans.xml or WEB-INF/beans.xml.
If you don’t include this file in your module archive, CDI injection will not be active for this archive as the container will not scan the archive.

There are a few reasons why the spec was done this way:

Performance: The container only has to scan the modules where you’ve added the beans.xml

When using CDI in some places, you have to use it everywhere

In CDI, the container manages the lifecycle of the objects it creates via the @Inject. What this means is that if you bundle a bean with an injected dependency into another object, the other object also has to be managed by CDI. Doing a new OtherObject() will not work; at least the @Inject will not be done.

In the following example Maven 3 will output a warning Maven version contains expression but should be a constant. This is because we use the expression ${project.parent.version} in the version tag of this Maven module.

So why is Maven complaining about Maven version contains an expression ?

It doesn’t make much sense to make this version non-static, because the maven-release-plugin will automatically update it when doing a release. (eg. when it will change). Make the pom.xml the master of the version tag, not some other file; this will make your life easier when you start eg. using the maven-release-plugin (no need for special configuration)

If you want to use the parent pom version in sub-modules, you can remove it, because the sub-module will automatically inherit the version of the parent if it is ommitted.

When updating a Maven project you can come accross the error Unsupported IClasspathEntry kind=4. This is due to a bug in m2e, which can manifest itself when using the m2e plugin on a project that has generated Eclipse project settings via the Maven maven-eclipse-plugin

Solving Unsupported IClasspathEntry kind=4

Install the latest version of the m2e plugin – which adds Maven functionality into Eclipse.

Unit test EJB3 without a container has become much easier since the EJB 3.1 spec with the introduction of the embeddable EJBContainer concept. An embeddable EJBContainer is a container for enterprise beans that does not require a Java EE server to run.

Interesting usage scenarios are:

EJB unit testing: you don’t need to install a JavaEE server for EJB development, unit testing and deployment to the container

Lightweight: the embeddable container has a much smaller footprint

Fast: starts faster than the full server, because it only initializes EJB-related components

Sample code

Below you can find a simple setup method for a JUnit test that configures the Embeddable EJBContainer.

So how does the EJBContainer start an embedded EJB container? You’ll need to provide an embedded EJB container on the classpath. Normally all Application servers supporting JavaEE6 have to provide such an embedded EJB container.

This example uses Apache TomEE as it provides an easy way to specify the correct dependencies via Maven.

Solving the Ambiguous dependencies for type problem

The problem is that there are two possible implementations to inject and the CDI container doesn’t know which one to choose. You can also see that there seems to be a proxied/generated class to be listed (in our example ABCImpl_7pbnr4_Impl).

In our case this generated class was created by the Weblogic appc tool which was run on our EAR file. This ear file includes a JAR with EJB 2.x beans and another one with EJB 3.x beans<.

We solved this problem by not letting Weblogic appc being run on our EJB3.x jar. You can do this by running the Weblogic appc on individual jar files instead of the ear file. As you probably know EJB3 style beans don’t need an ejb compiler anymore to generate the remote and local interfaces as everything can be done with annotations.