Weblogic 12.1.3 opens a transaction even with TransactionAttributeType.NEVER or NOT_SUPPORTED

The problem

An stateless EJB is used to process lot of records, one by one, without using a global transaction that envelopes everything.

Well, here the initial solution is to annotate the EJB with:


An example of this kind of class would be:

public class EJBThatProcessAll {
    private EJBThatProcessRecord ejbThatProcessRecord;

    public List<Result> processRecords(List<Record> records) {
        return records.parallelStream()

Then the method which process the records calls (for every record) another EJB that is anotated with:


So every record is processed in its own transaction.

public class EJBThatProcessRecord {
    public Result processRecord(Record record) {
        return doSomethingWithRecord(record);

Issues found

Even every call to process a record was less than 1 sec. at some moment I always got a TransactionTimeoutException. The container was complaining that some transaction lasted more than 60 s (which was the timeout set for this application).

Attempt 1

Well, I tried several things. The first one was changing TransactionAttriibuteType.NEVER by TransactionAttriibuteType.NOT_SUPPORTED. Failed with same error.

Attempt 2

Since I was not sure about the parallel processing, I tried to change parallelStream() to stream(). Failed with same error.

Attempt 3

A mate read somewhere that if the EJB was asynchronous, it could avoid the transaction, so I annotated the EJB with:


And changed the method to return a Future<List<Result>>. But the result was the same. Failed.

Good solution

Finally I changed the main EJB so the transactions were bean managed:


And it worked!. No need anything else but a good comment above the annotation about why I did it, because I know that sooner or later another developer will find it weird and would try to change it by the initial solution.


At the beginning the initial solution was tested through JUnit and it worked fine. I found the bug while testing the actual web application, so it’s clear that it’s the container that creates a transaction when the EJBThatProcessAll is called, even when it’s annotated to not use transactions at all. And it this case the application container was Weblogic 12.1.3 I don’t know what happens in other containers like JBoss.

Java OutOfMemoryError: unable to create new native thread

Another strange problem raised last week at work that finally I’ve solved. To be honest, the problem is not so strange, but the way it showed up and the errors we got were. As most of the problems, when you discover the roots or the reasons, they stop being rare and you think – “It’s obvious!” :-).


I like to be concise when explaining this kind of things, so to sum up, we have a Java server that acts as an authenticator for other applications. This authentication server uses the javax.security.auth.login Java package to connect and authenticate through an LDAP server.

Besides, an intesive process tries to get information from another application through a web service that needs authentication. To get authenticated, this process uses the authentication server described above but after 300 hundred calls or so in one or two minutes we start seeing this Java exception stacktrace:

04:13:07.682 [] ERROR com.xxxxx.xxxxx.server.services.XXXXXXXXServiceHelper.login(): 
Authentication error : java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:691)
at com.sun.jndi.ldap.Connection.(Connection.java:231)
at com.sun.jndi.ldap.LdapClient.(LdapClient.java:136)
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698)
at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:316)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:153)
at com.xxxxx.xxxxx.server.ldap.LdapConnection.open(LdapConnection.java:115)
at com.xxxxx.xxxxx.server.ldap.LdapConnection.open(LdapConnection.java:97)
at com.xxxxx.xxxxx.server.ldap.LdapLoginModule.attemptAuthentication(LdapLoginModule.java:325)
at com.xxxxx.xxxxx.server.ldap.LdapLoginModule.login(LdapLoginModule.java:175)
at sun.reflect.GeneratedMethodAccessor10194.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
at javax.security.auth.login.LoginContext.login(LoginContext.java:594)

At the beginning people thought that our authentication server application was running out of heap memory… but it doesn’t, because it didn’t stop working. After 3 or 4 minutes it worked fine and no errors were shown until the next execution of the intensive process. Then, one of the development teams involved in this issue called me to help them investigating the problem.

I was sure it wasn’t a problem of the heap memory of the authentication server because the OutOfMemoryError was shown in a java log trace of the application, not the application server where it is deployed, so the application worked… not really fine, but worked!. Another possible cause I thought was that the error source was LDAP, but our LDAP is not Java based, either the log files gave any error.

The key

The key to this problem was in front of our eyes, the message associated to the OutOfMemoryError: unable to create new native thread

The solution

After reading a bit on several pages, it’s possible that this problem could be solved using different solutions. But it’s sure it can’t be solved increasing the heap size of the JVM memory, because the JVM heap memory was fine.

I’m not a Linux system administration, but after investigating a bit, I discovered that it was the machine, where the application server with our authentication server was installed, which was running out of resources for creating system operating threads. Our system administrator realized that the Linux machine had a default configuration, so the running processes limit and the file descriptors limit was too low. Finally I asked the system administrator to increase those numbers. It can be done modifying the values for nofile and nproc from the file /etc/security/limits.conf:

#        - nofile - max number of open files
#        - nproc - max number of processes

The safest way would be limiting the values only for the user involved, not the whole machine, but that’s must be a system administration decision.


Android – GoogleAuthUtil.getToken Exception error: Unknown

There are a lot of guides out there to do OAuth2 authentication through Google on an Android application. I’ve been reading several of them, javadocs, Stackoverflow questions and so on, trust me. Finally, after got connected to Google I wanted to retrieve the token for the user connected. For that I used the GoogleAuthUtil class. Here is a snippet of the code I’ve written to get the token:

     * Request code for auto Google Play Services error resolution.
    private static final int REQUEST_CODE_RESOLUTION = 89898;

     * User connected token.
    private String mToken;

     * Task for retrieving the token of the connected user
    private class GetTokenTask extends AsyncTask<String, Integer, String> {
        protected String doInBackground(String... userAccount) {
            String token = null;
            try {
                Log.d(TAG, "Retrieving token for [" + userAccount[0] + "]");
                token = GoogleAuthUtil.getToken(getActivity(), userAccount[0], Scopes.PROFILE, new Bundle());
            } catch (UserRecoverableAuthException e) {
                Log.w(TAG, "Error retrieving the token: " + e.getMessage());
                Log.d(TAG, "Trying to solve the problem...");
                startActivityForResult(e.getIntent(), REQUEST_CODE_RESOLUTION);
            } catch (IOException e) {
                Log.e(TAG, "Unrecoverable I/O exception: " + e.getMessage(), e);
            } catch (GoogleAuthException e) {
                Log.e(TAG, "Unrecoverable authentication exception: " + e.getMessage(), e);
            return token;

        protected void onPostExecute(String token) {
            if (token != null) {
                mToken = token;
                Log.d(TAG, "We have a token!: " + token);
            } else {
                Log.d(TAG, "Can't retrieve any token");

But always got the same error:

09-05 13:07:19.109  23577-25973/com.xxxxx E/Login﹕ Unrecoverable authentication exception: Unknown
    com.google.android.gms.auth.GoogleAuthException: Unknown
            at com.google.android.gms.auth.GoogleAuthUtil.getToken(Unknown Source)
            at com.xxxxx.views.LoginFragment$GetTokenTask.doInBackground(LoginFragment.java:232)
            at com.xxxxx.views.LoginFragment$GetTokenTask.doInBackground(LoginFragment.java:225)
            at android.os.AsyncTask$2.call(AsyncTask.java:288)
            at java.util.concurrent.FutureTask.run(FutureTask.java:237)
            at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:231)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
            at java.lang.Thread.run(Thread.java:841)

The error is all but descriptive. After browsing lot of pages I discovered the trick, the scope was wrong!. Well, the scope seems right, but it lacks a string header with the value ‘oauth2:’:

final String scope = "oauth2:" + Scopes.PROFILE;
token = GoogleAuthUtil.getToken(getActivity(), userAccount[0], scope, new Bundle());

After that, everything went right. Hope this helps!

Redirect after AJAX request / Control authentication failure after AJAX request

Last two days I’ve been dealing with a problem I’ve had with some of the projects I work on. For our Java web apps we use an authentication/authorization filter that redirects to a login page after an authentication/authorization error. This error can be a login error, a session timeout or other things.

Redirect calls are managed by browsers without problems, they do the request for the new location and the login page is presented to you. But if your app does AJAX requests, as every app nowadays does, you’ll get into troubles, the browser won’t do any redirection, so your app will stay in the same page as before the request, and probably the user will be annoyed because your app doesn’t respond or does strange things. The login page won’t be shown until the user clicks on a non AJAX component (menu, link or so), or does a refresh.

Usually the authentication filter does a sendRedirect to the login page when there is an authentication problem:


So after some research I found that doing a manual redirect should solve the problem with AJAX calls. Really I didn’t know why doing this would solve the problem, but I tried it:

if (isAjax(request)) {
    StringBuilder sb = new StringBuilder();
    sb.append("<?xml version='1.0' encoding='UTF-8'?>");
    sb.append("<partial-response><redirect url=\"").append(response.encodeRedirectURL(url.toString())).append("\"/></partial-response>");

private boolean isAjax(HttpServletRequest request) {
    return "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));

Even I tried to send a redirect HTTP’s 302 code or adding a Location header… without any succeed:

if (isAjax(request)) {
    response.setHeader("Location", response.encodeRedirectURL(url.toString()));
    StringBuilder sb = new StringBuilder();
    sb.append("<?xml version='1.0' encoding='UTF-8'?>");
    sb.append("<partial-response><redirect url=\"").append(response.encodeRedirectURL(url.toString())).append("\"/></partial-response>");

private boolean isAjax(HttpServletRequest request) {
    return "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));

Then I tried to solve it from the other side, thus is, the client. I didn’t like it, because it is easier to distribute a JAR file with the authentication filter solution than telling people what they must do in every app they are developing. Although we have projects with JSP/JQuery or Seam 2, the last apps we’re working on use Primefaces, so I tried to find a solution related to this framework. First I tried to catch onComplete events within ajaxStatus Primefaces tag, but this component doesn’t pass the XMLHttpRequest argument to the callbacks, also I tried to bind a callback to onComplete events at body or document level, but any result was good.

Finally I went for a more drastic and I think the most secure solution: Setting up every AJAX call that could be made within our apps to do what I want when an authentication error raised. For this, JQuery has a solution, the $.ajaxSetup function. With it you can define at a global level how AJAX calls behave, and when I say at a global level I mean that every AJAX call from your code, or from whatever library or framework you are using will do what you define with this function. So first of all I changed the HTTP code the filter was sending, instead of a 302 now it sends a 401 (unauthorized), then I defined the behaviour of AJAX calls after receiving this code:

First the changes in the Java code:

if (isAjax(request)) {
    response.setHeader("Location", response.encodeRedirectURL(url.toString()));
private boolean isAjax(HttpServletRequest request) {
    return "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));

Now the Javascript code:

function requestUnauthorized(xhr) {
    window.location.href = xhr.getResponseHeader("Location");
(function($) {
        statusCode: {
            401: requestUnauthorized,

The syntax…


…means that you’re defining an anonymous function with an parameter called $, that will be self-executed with window.jQuery as value. It’s better to use window.jQuery because some libraries or frameworks rename jQuery to $, $$ or whatever they want.

And that’s all, you have to put the Javascript code somewhere that is visible for the whole app.

iText: Adding web links at an absolute position in Java

A problem I have had to solve recently has been adding links within PDFs. At work we use a private library to create PDFs. This library uses iText (obvious) to work, and one of the users’ requirements is the possibility of having fields that are links to a web site. The links must look like web links (underlined and blue text) and must be positioned in specific places, so absolute positioning is a must.

After searching and trying different solutions, I have finally figured out how to do it. As always, it’s an easy solution.
This code is based on iText 2.1.7, I know there are some new methods that do some of this things in shorter ways, but this version doesn’t have them. First of all I create the link in an underlined and blue font:

// Underlined, courier and 10px font size
Font font = FontFactory.getFont(FontFactory.COURIER, 10, Font.UNDERLINE);
// Blue
font.setColor(0, 0, 255);
// We need a Chunk in order to have a font's style
Chunk chunk = new Chunk("Google", font);
Anchor anchor = new Anchor(chunk);
// Link

Then the paragraph is positioned in some coordinates X and Y:

// I take the coordinates from a text field which is defined within a
// PDF template, but you can position the link wherever you want.
float[] coords = form.getFieldPositions("field.name");
// In my case I center the link vertically
float coordY = coords[2] + ((coords[4] - coords[2]) / 2);
// Show the link
// You need to get the PdfContentByte object
// It depends on how you are working with the PDF document
PdfContentByte cb = ... 
ColumnText.showTextAligned(cb, Element.ALIGN_LEFT, anchor, coords[1], coordY, 0);

SerfJ 0.4.0 released!

A new major version of SerfJ has been released with new features that makes the framework more powerful and flexible:

  • Feature: Default FileSerializer implementation, now is possible to serve files for downloading.
  • Feature: New default extension (.file) for serving files.
  • Feature: Within functional style you are able to implement generic serializers for whatever model you have.
  • Feature: Now javax.servlet.ServletContext, javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse are accessible from controllers.
  • Patch: Instead of implementing net.sf.serfj.serializers.Serializer developers must implement net.sf.serfj.serializers.ObjectSerializer for serializing objects.
  • Patch: RestController.addObject2request is deprecated in favour of RestController.putParam

The English documentation (reference, examples and Javadoc) has been updated, now I’m working on the Spanish reference.

Enjoy, and remember that any feedback will be welcome.


SerfJ 0.3.2 released!

Hello, at my spare time I sometimes work on a little Java framework, SerfJ, which provides an MVC architecture and REST capabilities. Is not a great one, but it’s simple and easy to use.

A new version has been released. This time another user, Christian Kasper, has contributed to fix some problems he discovered while using SerfJ.

* Extension .64 in requests didn’t work as expected, SerfJ never found a Base64Serializer to attend those requests. The easiest way to solve the problem has been changing the extension to .base64.
* Other problem found by Christian was that the singular of ‘signatures’ didn’t return ‘signatures’ but ‘signatur’, so an exception for this word has been added to SerfJ.
* Now identifiers, which must start with a number, can contain alphabetic chars.
* Binaries are compiled on Java 6.
* Dependencies has been updated their versions.

You can read the complete release notes at the website.

Enjoy, and remember that any feedback will be welcome.