My new article – WebLogic RESTful Management Services: From Command Line to JavaFX

Check it out:

Oracle WebLogic Server 12c is a major release and includes several new features, including Java EE 6, Maven integration, and JDK 7 support. This release also includes additional features that are important for administration and monitoring of an Oracle WebLogic domain. This article will focus on one such feature: RESTful Management Services

You can read the complete article on here ->

How to add third-party JDBC drivers on WebLogic

Oracle WebLogic data sources supports many databases types by default and also comes with some JDBC drivers for most of them.

But, not very often, you are working with third-party databases (non-Oracle) and endup needing to download the JDBC drivers from the database provider and doing the setup on WebLogic by yourself. The steps are pretty simple, but some still have questions on how to do it and I will try to create a step-by-step guide on this post.

In this example, the environment is Oracle WebLogic 12c running on a Mac OS X and doing the simulation of a Microsoft SQL Server JDBC Driver installation.

To simulate the issue of a missing driver, try to create a new Data Source selecting the following parameters on a default installation:

  • Database Type: MS SQL Server
  • Database Driver: Microsoft’s SQL Server Driver (Type 4) Version: 2005 and later

Complete the wizard with your database access information (host, port, username, password) and try to Test the Connection before saving. You should see the error below stating that you don’t have the driver classes on the classpath.


Ok, let’s setup the JDBC driver:

      1. Download the JDBC Driver – MS SQL Server JDBC drivers are currently hosted on this link:
      2. Unpack the zip or tarball with the JDBC driver jar file and copy the specified file to the WebLogic installation directory, under the ${WL_HOME}/server/lib folder.
        (markito@luke)$ tar -xzvpf sqljdbc_4.0.2206.100_enu.tar.gz
        (markito@luke)$ cd sqljdbc_4.0/enu/
        (markito@luke)$ cp sqljdbc.jar ${WL_HOME}/server/lib/
      3. Now, modify the script. This script sets common environment variables for WebLogic and set the WebLogic classpath with some base libraries from the WebLogic installation directory.
        The file is located under: ${WL_HOME}/common/bin/commEnv.shBefore:

        # set up WebLogic Server's class path


        # set up WebLogic Server's class path
      4. Now restart the WebLogic server and repeat the process to create a new MS SQL Server data source.

There is a bonus step which is not always required – Since you’re using a new JDBC driver, sometimes you don’t have the entry under WebLogic database drivers list. To update this list modify the ${WL_HOME}/server/lib/jdbcdrivers.xml file accordingly, the description of the file is very explanatory:

<!-- This xml file contains meta information regarding JDBC Driver's and making connections to the DBMS.
It is designed to hold information so that UI can gather information from a user and configure
The Driver classname, The Driver URL and the driver Properties to make a connection to the DBMS

This XML entry is a required peice of data that could be required in the URL or in the properties object

       There are 5 well known property names:

       Properties that don't match the well know ones above, will be passed as name=value pairs to either
       the URL or the properties object (based on InURL=false or true.

       Then the UI would prompt:
       Please Enter
       Database Type : normal
       This is required to Indicate your DB type.
       And after the user providing it the UI would stuff it into the JDBCDriverInfo object and the JDBCURLHelper would do the right thing with it
       stick it in the URL or in the properties object

Remember that although you can add or update third-party drivers, you should still follow the supported database list provided by the WebLogic Certification Matrix in order to keep with a supported installation.


CDI Events – Synchronous x Asynchronous

Context Dependency Injection or CDI (JSR-220 / JSR-330) is one of the greatest features of Java EE 6.  It brings simplicity to a lot of areas where previous version of Java EE required tons of Interfaces, XML’s and a lot of boilerplate code to create simple things.

This post is going to show some simple examples on how to use Java EE 6 and CDI Events with synchronous and asynchronous patterns, which is also part of the new specifications.

First, let’s define what synchronous and asynchronous means in this context:

Synchronous – Execution or processing that happens on the same thread and need immediate response or process completion to continue. It also means that a call to a synchronous method will block (wait) the caller until it’s completion. Example: A traditional HTTP Request.

Asynchronous – Execution or processing that doesn’t need immediate or any response and will be processed on a different thread than the caller’s thread. This means that an asynchronous caller doesn’t need to be waiting for the process to complete and may receive a callback when the work is done. Example: Sending a JMS message, Performing an AJAX call on a web page.

Thread Pools

Thread Pools are one of the most efficient patterns when dealing with Threads. Conceptually it works as a pool of workers and a queue of tasks which get’s executed by different threads. When those threads finishes processing the task, it will automatically get the next one on the queue to process until the queue is empty. The thread lifecycle is also managed by the pool, so a well managed pool can save a lot of resources keeping the number of threads to a good level maintaining the balance between number of threads and tasks on the queue.

Application Servers have to deal with several (thousands, millions..) of requests and different services like JDBC, JMS, EJB and JCA, each of theses tasks consumes threads to complete their work. So, internally most application servers create thread pools to isolate the resource consumption of these tasks and make a better usage of hardware threads according to the applications needs.

Synchronous Events

The default strategy for CDI events is synchronous, which is very simple to implement.

// imports omitted for brevity
public ShoppingCart {

  Event<String> eventService;

  public void checkout(OrderEvent event) {;

And to receive/observe the event:

// imports omitted for brevity
public PaymentHandler {

 public void onNewOrder(@Observers OrderEvent event) {"Event captured - " + event)

It’s also possible to use Qualifiers and perform kind of “selector” (for reference check this) and filter the events based on the qualifiers.

When you deploy an application with these beans and consume them from a JSF page or a Servlet, the request will be processed consuming a Thread from the HTTP Thread Pool that will stay in use until the response is committed.  Let’s assume you have multiple @Observers for the same event. In this case, all the work done by the @Observers will occur on the same Thread as the request, which is in this case the HTTP request.

Depending on the scenario, this behavior is acceptable, but if your @Observers are performing long-running tasks and you have users waiting for their request to complete on a web application, it may not be the case.

This can be easily addressed with a real Asynchronous processing for events and observers.

Asynchronous Events

Asynchronous events can be implemented using CDI and EJB with the help of @Asynchronous annotation.

First, let’s write a Stateless EJB that will be responsible for dispatching the events:

// imports omitted for brevity
public class EventDispatcherBean {

     private static final Logger logger = Logger.getLogger(EventDispatcherBean.class.getCanonicalName());

    Event<OrderEvent> eventManager;

    public void publish(OrderEvent event) {
        logger.log(Level.FINEST, "{0} Sending event from EJB", Thread.currentThread().getName());;

Please note the usage of the @Asynchronous annotation on the publish method, this will decouple the Thread from the HTTP request and pass the processing context to the EJB Thread pool and since the return is set as void, this will be processed as a fire-and-forget call, where no return is expected. (off-topic: I do appreciate the reference to fire-n-forget missiles)

// imports omitted for brevity
public class DeliveryHandler implements Serializable {

    private static final Logger logger = Logger.getLogger(DeliveryHandler.class.getCanonicalName());

    OrderBean orderBean;

    public void onNewOrder(@Observes OrderEvent event) {

        logger.log(Level.FINEST, "{0} Event being processed by DeliveryHandler", Thread.currentThread().getName());

        try {
            logger.log(Level.INFO, "Order #{0} has been paid amount of {1}. Order ready to delivery!", new Object[]{event.getOrderID(), event.getAmount()});

            orderBean.setOrderStatus(event.getOrderID(), OrderBean.Status.READY_TO_SHIP);

        } catch (Exception jex) {
            logger.log(Level.SEVERE, null, jex);

Then, there is the event observer and as you can see it also uses the @Asynchronous annotation, which will decouple the event processing from the event publisher as this bean is also an EJB, so it will only consume Threads from the EJB Thread pool.

With this modification, we should be able to get a higher throughput on the web application since we’re not sharing threads to process HTTP requests and CDI events, each of them with it’s own Thread Pool.

For more details, check the complete implementation of this application available as part of the Java EE 6 Tutorial case study – Duke’s Forest.

Adding global exception handling using JSF 2.x ExceptionHandler

This a great feature of JSF 2.x: A generic API to manipulate application exception in a global manner. In order to implement this you must implement (extend) two different classes:

ExceptionHandlerWrapper – Provides a simple implementation of ExceptionHandler that can be subclassed by developers wishing to provide specialized behavior to an existing ExceptionHandler instance. The default implementation of all methods is to call through to the wrapped ExceptionHandler instance.

ExceptionHandlerFactory – A factory object that creates (if needed) and returns a new ExceptionHandler instance.

On Duke’s Forest this is the implementation:

package com.forest.exception;

public class CustomExceptionHandlerFactory extends ExceptionHandlerFactory {
   private ExceptionHandlerFactory parent;

   // this injection handles jsf
   public CustomExceptionHandlerFactory(ExceptionHandlerFactory parent) {
    this.parent = parent;

    public ExceptionHandler getExceptionHandler() {

        ExceptionHandler handler = new            CustomExceptionHandler(parent.getExceptionHandler());

        return handler;


package com.forest.exception;

public class CustomExceptionHandler extends ExceptionHandlerWrapper {
    private static final Logger log = Logger.getLogger(CustomExceptionHandler.class.getCanonicalName());
    private ExceptionHandler wrapped;

    CustomExceptionHandler(ExceptionHandler exception) {
        this.wrapped = exception;

    public ExceptionHandler getWrapped() {
        return wrapped;

    public void handle() throws FacesException {

        final Iterator<ExceptionQueuedEvent> i = getUnhandledExceptionQueuedEvents().iterator();
        while (i.hasNext()) {
            ExceptionQueuedEvent event =;
            ExceptionQueuedEventContext context =
                    (ExceptionQueuedEventContext) event.getSource();

            // get the exception from context
            Throwable t = context.getException();

            final FacesContext fc = FacesContext.getCurrentInstance();
            final Map<String, Object> requestMap = fc.getExternalContext().getRequestMap();
            final NavigationHandler nav = fc.getApplication().getNavigationHandler();

            //here you do what ever you want with exception
            try {

                //log error ?
                log.log(Level.SEVERE, "Critical Exception!", t);

                //redirect error page
                requestMap.put("exceptionMessage", t.getMessage());
                nav.handleNavigation(fc, null, "/error");

                // remove the comment below if you want to report the error in a jsf error message

            } finally {
                //remove it from queue
        //parent hanle

And add the following lines to your faces-config.xml:


In the try-finally block you can cast the Throwable to any specific exception and do  any special treatment that you want. For example: ViewExpiredException can be redirected to a “Session Expired” page and on the other hand, NullPointerException can use the common generic page just saying that “An unexpected situation occurred, please try again later.”

In line 40 I’m redirecting to a common error page (/error) which can read error information from the request map.

Please note that when dealing with exceptions and web development, you must ensure that you are not sharing any unwanted sensitive information when returning the error to the web page.

To see the complete running example please check The Java EE 6 Tutorial and check Duke’s Forest case study.


New OTN Article – Oracle Enterprise Gateway: Integration with OSB and OWSM

OEG, OSB and OWSM - Integration example
Just published another article at Oracle Technology Network. This one shows the basics of Oracle Enterprise Gateway and a walk through example of how it can be integrated with Oracle Service Bus and Oracle Web Services Manager.  To read the complete article click here and feel free to give any feedback.

A great partnership with my pal Fabio Mazanatti to produce the article!

Absent time…

Hey guys,

After a long (very long) absent time of my blog, I’m finally writing something here. There are so many things that I’d like to share and that happened on the past months that I’ll probably make a quick brief on this post and talk a little bit more of each item on separate posts.

One of the main reasons of my absence was the Java EE Tutorial.  It’s almost two years that I’m working on the Java EE Tutorial doing some small write ups and code examples but last year the group gave a great assignment, write a complete case study.  The case study (Duke’s Forest) was finally pushed into the latest update of the tutorial this month and if you want to view some of the latest Java EE 6 technologies running along (CDI, JSF 2, JAX-RS, JAX-WS, Events) you can check it out.  Hopefully this will be also part of the Java EE 6 Tutorial – 4th Edition – Advanced Topics book to be released “soon”.

Last year Oracle launched Weblogic 12c with finally supporting for Java EE 6 APIs.  This was a great update for the product but we still have updates for Weblogic 11g, which is the only version support for Oracle Fusion Middleware and Oracle Fusion Apps.   So, hopefully we will have Oracle FMW running on Weblogic 12c and then get a real move to use the product.  The great thing here also is that I stayed at Oracle Open World Latin America Demoground doing the demo for Weblogic 12c and showing some of the new features like Maven 2.0, NetBeans Integration and more.

Oracle also release last month a new Oracle Fusion Middleware  release, PS5 ( and here is a link to the new features.  IMHO the greatest features are more BPEL 2.0 functionality, updated Service Bus version and some bug fixes at Oracle CEP.  Of course that there are much more than that, but this is only my opinion…

I’ve also worked with some Oracle partners (Latin America) on the Exastack Program, which made me play a little bit with those machines, install some applications and setup their environment, which was a good exercise btw…

There are a couple of articles that should get published at OTN soon…  Anyhow, although it’s not an excuse I was very busy mostly working and now I’m planning to write at least some small notes here regularly….

Best regards,

My Article at OTN: Oracle Service Bus and Coherence caching example

Today I’ve published an article at Oracle Technology Network (OTN) about Oracle Service Bus and Oracle Coherence integration. It shows a case study example and how you can use caching strategies for  Web Services.

It’s a step-by-step tutorial on how to setup a Coherence Server with Weblogic, how to access this server with Coherence console and how to use out-of-process caching strategy to scale your caching with no impact on the Enterprise Service Bus.

To read the full article click here.