Using Workshop 10 for EJB 3.0 Development (from Greg Mally)


I'm not the author of this article. It's Greg Mally, former BEA Workshop specialist (now Principal Solutions Architect @ Oracle).

As Dev2Dev blogs vanished, I made a safe copy of his article and even if now, you've got the possiblity of developing EJB3 within Workshop 10.3 without "tricks",

it's still useful to know how to develop EJB3 with a workshop 10. So here it is.

Enjoy !


Workshop for WebLogic Platform 10.0, 10.1, and 10.2 rely on Web Tools Platform (WTP) 1.5 for Web and Java EE development.

This reliance introduces some challenges when trying to do Java Enterprise Edition 5 (JEE5/EE5) development since EE5 is not officially supported by WTP until the 2.0 release.

However, there are ways to "trick" WTP 1.5 into behaving nicely when doing certain types of EE5 development.

One area where WTP 1.5 and EE5 can coexist nicely is in the area of EJB 3.0.

This write-up is intended to demonstrate how to configure an EJB 2.1 project, which was created using the WTP 1.5 project creation wizard, for EJB 3.0 development.


Workshop for WebLogic version 10.0 or 10.1 is installed and you have a basic understanding of Workshop 10.x, the EJB 2.1 specification, and the EJB 3.0 specification.

Create a WTP EJB 2.1 Project

1. File > New > Project...

To access the WTP EJB 2.1 New Project wizard, be sure to select the Show All Wizards option in the New Project window:


2. Select the EJB Project to start the New EJB Project wizard.


3. Create the EJB Project with the appropriate values and facet configuration in the New EJB Project wizard.

All that is needed on page 1 of the wizard is the Project name:


Remove the WebLogic EJB Extensions facet on page 2 of the wizard because this facet is specific to WebLogic EJB 2.1 development:



At this point you can simply Finish creating the EJB Project.

Configure the EJB 2.1 Project for EJB 3.0 Support

1. Update the ejb-jar.xml file that was created by the wizard with the EJB 3.0 deployment descriptor Schema reference.

The ejb-jar.xml file that was created by the wizard is configured for EJB 2.1.
Although the EJB 3.0 specification states that the deployment descriptor is not necessary, WTP 1.5 requires that an ejb-jar.xml be present in the project.
To keep WTP 1.5 from complaining about a missing ejb-jar.xml, we can simply add an empty EJB 3.0 ejb-jar.xml.
The descriptor should be located in the ejbModule/META-INF directory of the project:



The contents of the ejb-jar.xml should look something like the following:

    xmlns="http://java.sun.com/xml/ns/javaee"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

2. Your project is now ready for EJB 3.0 Session & MDB development.

At this point, WTP is fine because it sees the deployment descriptor it is expecting. You can now use all of the EJB 3.0 annotations for creating your new EJBs.

Create a Simple EJB 3.0 Stateless Session Bean

1. Create Interface Class.

Create a new Interface class called EchoService in the ejb3.beans package with a method definition called echo that accepts and returns a String.
Your new interface should look something like the following:

package ejb3.beans;

public interface EchoService {
    String echo(String echoValue);

2. Create Class that Implements Interface Class.

Create a new class called EchoServiceBean in the ejb3.beans package that extends EchoService and Serializable. Your new class should look something like the following:

package ejb3.beans;

import java.io.Serializable;

public class EchoServiceBean implements EchoService, Serializable {
    public String echo(String echoValue) {
        // TODO Auto-generated method stub
        return null;

3. Add EJB Annotation to EJB 3.0 Bean class.

Add the @Stateless annotation with the name attribute of echoService to the EchoServiceBean class. Your EJB 3.0 Bean should look something like the following:

package ejb3.beans;

import java.io.Serializable;
import javax.ejb.Stateless;

public class EchoServiceBean implements EchoService, Serializable {
    public String echo(String echoValue) {
    // TODO Auto-generated method stub
    return null;

4. Add code to the body of the echo method that will echo the input parameter value.

Here's an example of what can be returned by the echo method:

public String echo(String echoValue) {
    return "Echo from - " + this.getClass().getName() + ": echoValue = " + echoValue;

Create Dynamic Web Project with EE5 Support

1. File > New > Project...

We are going to create a Dynamic Web Project called EJB3Servlet and a new EAR Application Project called EJB3ServletEAR.
(Note: the EAR can be created on the first page of the New Dynamic Web Project wizard).
Other than the Project name and EAR Project Name, you can use the defaults.

Once you have done this, we will configure the Dynamic Web Project for EE5 support. We will bundle the Web and EJB projects in the EJB3ServletEAR to test out our simple EJB 3.0 Bean.

2. Update the web.xml with the Servlet 2.5 deployment descriptor Schema reference.

Much like was done for the EJB Project, we are going to tweak the web.xml for Servlet 2.5.
This will tell WLS that resource injection can occur, which is necessary for accessing the new EJB via EJB 3.0 annotations in Servlets.
The tweak involves updating the descriptor with the Servlet 2.5 schema reference:

<web-app id="WebApp_ID"

3. Add a Module Dependency for the EAR Project to the EJB 3.0 Project

Make sure that the EAR project that was created in step 1 has the EJB 3.0 project as a Module Dependency. The project properties for the EAR should look something like the following:


Test the Simple EJB 3.0 Stateless Session Bean

1. Add Servlet to the Dynamic Web Project

Using the Create Servlet wizard (e.g., File > New > Other..., then Web/Servlet), specify a Class name of InvokeEJB. The wizard should look something like the following:


2. Annotate Servlet for EJB 3.0 Reference

Add the @EJB annotation to the new Servlet above a variable declaration to the EchoService Bean. The code should look like the following:

private EchoService echoService;

At deployment time, WebLogic Server will inject the EJB 3.0 reference into the local variable which will be used in the doGet method.

Best Practices/Performance Consideration: If you define your variable declaration as private or protected, then you should also define a setter and a getter for the variable because WLS will do setter injection vs. field injection. Setter injection performs better than field injection when using encapsulation good practices. Here's an example:

private EchoService echoService;   

public void setEchoService (EchoService value) {
    this.echoService = value;

public EchoService getEchoService() {
    return this.echoService;

3. Invoke the EJB 3.0 Bean in the doGet Servlet method using the following code:

ServletOutputStream outputStream = response.getOutputStream();
if(echoService != null) {
outputStream.println("Start EJB Invoke");
outputStream.println(echoService.echo("Servlet Request"));
outputStream.println("Invoke Complete");
} else {
outputStream.println("ERROR. EJB Reference is null");}

4. Run on Server to Invoke Servlet via Run As > Run on Server

5. Review Output

Assuming everything is configured correctly, the WebLogic Server will have done the EJB 3.0 injection into the Servlet and the results will look like the following when the Servlet is run:


Mots clés Technorati : ,


How to use the WebLogic® FilteringClassLoader mechanism ?

First of all, I'd like to point out some basic resources to understand how the class loading works.

If you're not comfortable with that, then you should first read Understanding WebLogic Server Application Classloading.

Classloader Order

First notice that the "APP-INF/lib" mechanism is not standard : until the arrival of Java EE 5, there was no default mechanism to load libraries in an EAR.

BEA decided to implement such a mechanism, copying the way libs are loaded in a web application.

Now, a default behavior has been introduced by Sun under "application-type > library-directory" in the application.xml. (http://java.sun.com/xml/ns/javaee/application_5.xsd)

The default lib directory, if no "library-directory" has been defined, is "lib".

Here's the order in which classes are loaded.

  1. « System classpath loader » (« Bootstrap classloader »)
  2. « WebLogic server classpath loader »
  3. « Application classpath loader (« library-directory » then « APP-INF/lib »)
  4. « EJB classpath loader »
  5. « Webapp classpath » (WEB-INF/lib)

Reminder on classloading

This behavior of classloading can be summed up in one sentence : "The first loaded is the one" :)

To make a quick summary on that, let's consider a web application, looking for a class "Sample".

Normal Way

That's the default way WLS loads classes.


  1. The demand is made in the LOW classloader
  2. The classloader asks for its parent if it has the class loaded
  3. If it's the case, the class is given. If not, this last step is repeated until the highest classloader has been reached.
  4. If the class is nowhere to be found, a ClassNotFoundException is raised.

You can see that even if the LOW classloader has the class, it will first ask the parents if they have it loaded.

From WebLogic Server 6.1

An interesting schema has been introduced in WLS 6.1 : the child-first-delegation model, embodied through the option "prefer-web-inf-classes" in the weblogic.xml file.


  1. The demand is made in the LOW classloader
  2. The classloader first looks for the class in its scope.
  3. If it finds it, the class is returned, else the classloader asks its parent for the class.
  4. The previous step is played again till it reaches the top classloader and if it didn't find the class, then a ClassNotFoundException is raised.

Well, it gives an answer to our problem, but brings some new potential issues.

Actually, the tree is entirely reversed which can cause some major trouble : considering that a classloader isn't aware of the class loaded by its children,

it can lead to some linkage errors ("Loader Constraints Violated").

You may take a look at an interesting doc from JBoss about linkage errors.

From WebLogic Server 9.2

BEA found another mechanism, much more clever : the filtering class loader.


  1. The demand is still made in the LOW classloader
  2. The classloader asks its parent for the class (like in the original mechanism) but this time the filter acts as the parent classloader
  3. The filter looks for the class package
  4. If the filter finds the package, it throws a ClassNotFoundException, simulating that the parent tree didn't find the class
  5. If no corresponding package is defined, then the filter let the request pass through and the original behavior is played.

This mechanism offers the advantages of both previous mechanisms.

It's the best way to isolate the classloaders.

How to declare a FilteringClassLoader

You simply have to add a declaration in your "weblogic-application.xml", such as :


<prefer-application- packages >





And that's all !

FilteringClassLoader in action :)

For my demonstration, I used Workshop 10.3 (excellent version which supports EJB3, JAX-WS webservice and much more, by the way !).

I have two Java projects (DomainLib & WebAppLib) which each contains a class fr.mbutton.filteringclassloader.SampleClass

As you may have guessed, I will use these classes to determine from which classloader the class is loaded.

I've got a simple WebApp project (ClassCallerWAR) with one JSP which makes the call for the class.

And an EAR project (ClassCallerEAR).


I first deployed my EAR on the server without any special configuration.


The result is as expected (class loaded from the web app, since it is not declared elsewhere).


Then I export the DomainLib project as a JAR file, and I place it in the domain/lib directory :


I restart the server to have the lib taken into account.

And when I access the JSP, this time I've got :


As expected, the class is loaded from the highest classloader.

To be able to get the class loaded by the web app classloader, I configure a filteringclassloader in the weblogic-application.xml, such as :


I resynchronize (= redeploy) the application and this time, I've got :


It works perfectly well ! It will save you some time thinking about mixing up your libraries, trust me ! :)

Book Review : Service Oriented Architecture with Java

This is the second book I read from Packt Publishing. The first one was very good but this one is really excellent.

It is split into 6 chapters :

Chapter 1: The Mantra of SOA
This chapter reviews basic tiered architecture, EA and the basic points of benefit of SOA including better integration, business agility, asset re-use, increase ROI
Chapter 2: Web Services and SOA
Practically all current SOA implementations now are built upon web services. XML over the Http protocol is covered. Representational State Transfer(REST) is covered.

Main java implementations of web services are introduced including JAX-WS 2, Axis2, Spring-WS, and XFire/CXF 2.0.
Chapter 3 : Web Service Implementations
Code is presented for getting a web service up and running in JAX-WS2, Axis2, Spring-WS, and XFire/CXF 2.0

The coded examples are very easy to follow and can get a developer up and running quickly.
Chapter 4: Data and Services – All Roads Lead to Enterprise Service Bus
This chapter reviews JDO(Java Data Objects) as an alternative to JDBC along with sample code and examples. Service Data Objects(SDO) are covered as a way to abstract data within and SOA.

Apache Tuscany DSO is covered with an example. Service Component Architecture(SCA) is described along with a Tuscany SCA java example
Benefits of MOM and ESB are also covered. OpenESB is covered as an open source option for implementing an ESB.
Chapter 5 – Traditional Integration Technology
2 Case Studies are presented showing the advantages of an SOA based architecture over that of EAI.
Chapter 6 – Goals We Can Achieve with SOA
Loose Coupling, Reusability, Seamless Integration, Return on Investment(ROI)

The complexity goes crescendo : in the beginning, the authors (they're three) write about the SOA concept, in a very general way, to make a good refresh about it.

Then some history about how SOA is implemented and why it's often through Webservices. And (that's the most concrete part) how to use available frameworks / norms to write Webservices.

I especially appreciated that part because it allows you to see in at a glance all the different (and most interesting) ways to build a webservice.

Then JDO & SCA are described and in a very good manner. No unnecessary complexity, to help you understand why these norms have a future.

And as a conclusion, two concrete use cases, to illustrate all what was previously described.

I won't say that every book should be like that, but not far away ...

To get a taste of it, feel free to download this free chapter (Chapter 4 Data & Services)

Recommended !



How to use a deployment plan ?

So far, I've been working with several clients who have a strong need to override some values, according to the target environment when they are deploying their archive.

BEA/Oracle offers such a mechanism from WebLogic Server 9, which is called "Deployment Plan".

It is quite well exposed in the official documentation : http://edocs.bea.com/wls/docs91/deployment/plan.html

You also may take a look at Understanding Deployment Plan Contents


How does it look like and how does it work ?

Here is a sample of a plan.xml :

<?xml version='1.0' encoding='UTF-8'?>


        <module-descriptor external="true">

        <module-descriptor external="false">
        <module-descriptor external="true">

The mechanism works by first defining a variable with a value (blue section) and then assigning it to an application (purple section).

As you can see XPath is used to qualify the path of the attribute to update. For instance, here it's "/weblogic-web-app/session-descriptor/timeout-secs".

You will notice that the XPath indicated is simply the path to that attribute in the following weblogic.xml deployment descriptor.

<?xml version="1.0" encoding="UTF-8"?>
        xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/920/weblogic-web-app.xsd">


How do I know if there's already a plan linked to my application ?

Well, that part is easy to answer. Either you have :


Or :


See the difference ? :)


How do I create a deployment plan ?


When you go on the console, on your deployment, you will see a tab called "Configuration > General".

Here you will be able to see some tuning values defined for your application.

If you did not configure your deployment descriptor accordingly, some default values will be displayed like :



Modifying these values will lead to the creation of a deployment plan.


Save you plan where you want to and you're done.



BEA offers a tool dedicated to plan creation. As every tool, you first have to set your classpath first to be able to use it.

(This can be done by executing the script setWLSEnv). Here is an example of how it works. 

java weblogic.PlanGenerator

-all // option exporting all the editable options

-plan samplePlan.xml // the name of the plan to be generated


Full Ex : java weblogic.PlanGenerator -all -plan mySamplePlan.xml D:\BEA_ROOT\user_projects\applications\sample\sample.war 


Then you should normally have the following message as a result : 

Generating plan for application D:\BEA_ROOT\user_projects\applications\sample\sample.war

Export option is: all Exporting properties...

Saving plan to C:\Documents and Settings\mbutton\samplePlan.xml...

<14 avr. 2008 15 h 07 CEST> <Info> <J2EE Deployment SPI> <BEA-260086>

<The descriptor information at D:\Temp\[...]\weblogic.xml was saved to configuration area.>

<14 avr. 2008 15 h 07 CEST> <Info> <J2EE Deployment SPI> <BEA-260072>

<Saved configuration for application, sample.war>


To better understand the different categories of options available, read the documentation : Understanding Deployment Property Classifications

Personnaly, I encountered some problems using it.

Actually, some attributes are considered as non-editable when generating the plan, but if you manually override them, it works ...

Then, I would advise you to use this tool for a first shot and then modify it with your values.

(So far, all the values I changed through a plan were successfully updated).


Hand :)

It's a xml file, then you may write it from the beginning. I wouldn't advise you to do so because the chances of getting an error are much higher.

But if you're really willing to do it yourself, take a look at http://www.bea.com/ns/weblogic/90/weblogic-deployment-plan.xsd, it should help.


How do I link it to my deployment ?


Unfortunately, through the console, when you deploy a new application, you cannot reference the deployment plan directly.

You will have to install your application and then update it. First, check the application then "Update" button :


Then change the plan path to reflect the actual location of your deployment plan and update the whole stuff.



Or there is another way to take the plan into account, but as I said earlier it's not visible from the console.

You'll have to respect a certain directory structure to have your deployment plan automatically bound to your application.

I will advise you to follow the best practices described by BEA : Steps for Creating an Application Installation Directory.

To sum up, your directory should look like :

----> V1
----> app
----> SampleApplication.war
----> plan
----> plan.xml
----> V2
----> app
----> SampleApplication.war
----> plan
----> plan.xml


And then when you will deploy the open directory V1 or V2, the sample application will be deployed as well as the associated deployment plan.



You may update your application and specify the plan to use : 

java weblogic.Deployer -username weblogic -password weblogic -adminurl t3://localhost:7001 -update-name SampleApplicationBis -plan SamplePlan.xml 

(If you're wondering why the action is 'update' and not 'redeploy', read Understanding Redeployment Behavior for Deployment Configuration Changes)

The result will be displayed like that : 

weblogic.Deployer invoked with options: -username weblogic -adminurl t3://localhost:7001 -update -name SampleApplicationBis -plan SamplePlan.xml
<21 aout 2008 08 h 55 CEST> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating update operation for application,

SampleApplicationBis [archive: null], to configured targets.>
Task 3 initiated: [Deployer:149026]update application SampleApplicationBis on AdminServer.
Task 3 completed: [Deployer:149026]update application SampleApplicationBis on AdminServer.
Target state: update completed on Server AdminServer

Or you may install your application for the very first time : 

java weblogic.Deployer -username weblogic -password weblogic -adminurl t3://localhost:7001 -deploy -name SampleApplicationBis -plan SamplePlan.xml  

You will have a similar result than when updating (see above). 


It is of course possible to use WLST to deploy the application and the deployment plan or simply to update an application.


How can I check that my values have been taken into account ?


Through the console, simply go to the "Configuration > General" tab of your deployment and check the new values

(if they belong to this section, else you will have to check thanks to WLST, described later in this section).



The console is fine, but you can't see all. Nor can you with WLST :) But it's much more complete.

For that, just connect to the server on which the application is deployed (if you're not in development mode, it is normally NOT your administration server).

For instance, let's assume we've got a admin server listening on port 7001 and a managed server listening on 7011.

You app is deployed on the managed server, then you will type : 

connect ('weblogic', 'weblogic', 't3://localhost:7011') // Using the same credentials than the admin

serverRuntime() // Allows you to switch to the runtime tree

cd ('ApplicationRuntimes') // You always will have to go in that directory

cd ('ApplicationSampleBis') // This is the name of our application (you may have to go in a directory representing the EAR prior to reach the WAR)

cd('ComponentRuntimes') // You always will have to go in that directory

cd ('AdminServer_/sample') // Change to the directory whose name is composed of your server name and the context root of you app (type ls() if you want to be sure)



And the result will show you the runtime values. For instance, before :



And after :




"My values are not updated : what am I missing ?" Well, I won't pretend I'm going to solve your problem, but let's try :)

First, check that your plan is defined in the console as stated in the "How do I know if there's already a plan linked to my application" section.

If it's the case, check that the name you defined in your plan, for the module is correct. WLST will give you the component name (in serverRuntime tree) :


And it must be the same in your plan : 


And last but not least, the values you want to override MUST have been defined in your deployment descriptor. It's an override, not a definition. 


If you're French, I would advise you to go the excellent post of my colleague Benoit Moussaud : http://blog.xebia.fr/2008/04/17/les-plans-de-deploiement-weblogic/


What is SCA in simple words ?

There's so many papers, articles and blogs about SCA that I'm not gonna write thirty pages about it.

I just to want to share what I understood from that norm and help people to quickly figure out what it's all about.


Let's start from the beginning : SCA stands for Service Component Architecture or architecture based on components, and each of them provides a service.

According to Wikipedia :

On March 21, 2007 the OSOA Collaboration released the V1.0 level of specification [3].

The specifications specify that an application designed with SCA should have the following advantages:

  • Decoupling of application business logic from the details of its invoked service calls including .
  • Target services in a multitude of languages including C++, Java, COBOL, and PHP as well as XML, BPEL, and XSLT.
  • The ability to seamlessly work with various communications constructs including One-Way, Asynchronous, Call-Return, and Notification.
  • The ability to "bind" to legacy components or services, accessed normally by technologies such as Web Services, EJB, JMS, JCA, RMI, RPC, CORBA and others.
  • The ability to declare (outside of business logic) the Quality of Service requirements, such as Security, Transactions and the use of Reliable Messaging.
  • Data could be represented in Service Data Objects.

The value proposition of SCA, therefore, is to offer the flexibility for true composite applications, flexibly incorporating reusable components in an SOA programming style.

The overhead of business logic programmer concerns regarding platforms, infrastructure, plumbing, policies and protocols are removed, enabling a high degree of programmer productivity


You know, SOA, or Service Oriented Architecture ! That is to say, instead of having all the objects responsible for their behavior, each and every object has a limited role,

seen as a service.

Just imagine your normal application which does everything from security to retrieving business data, is split into services.

One of the key advantages of that is that you can reuse your services through all your applications.

And when, for instance, your security policy changes, you only have one component to migrate, not all applications.

That's a simple example (explained in a simple way with simple words) of what SOA offers.

Composite pattern

Let's turn back to SCA. SCA is a norm which uses the composite pattern, that is to say the use and aggregation of different parts to build a much more complex part.

A composite is not a piece of code but just a configuration of several other services which all together brings a vision of another service.

It is often compared, in term of concept, to Spring, the Java EE framework because Spring uses injection and makes the connection between all the beans to offer a global service.

Simple Example based on POJOs (taken from BEA examples, based on fabric3 implementation) :


<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
    <component name="Loan-pojo">
        <implementation.java class="example.pojo.LoanServiceImpl"/>
        <property name="baseCreditScore">650</property>
        <property name="interestRate">5</property>
    <component name="Insurance-pojo">
       <implementation.java class="example.pojo.InsuranceServiceImpl"/>
    <component name="Dealer-pojo">
       <implementation.java class="example.pojo.AutoDealerImpl"/>
       <reference name="loan" target="Loan-pojo"/>
       <reference name="insurance" target="Insurance-pojo"/>
       <service name="AutoDealer"/>
    <service name="dealer-pojo" promote="Dealer-pojo/AutoDealer">
      <binding.rmi name="dealer" serviceName="autoDealerService"/>


Well now, you know enough to be able to read all the other articles on the Net !


I stil would advise you to go on the fabric3 website (implementation chosen by BEA) and on the Apache Tuscany project.

A recommended PDF about SCA http://www.davidchappell.com/articles/Introducing_SCA.pdf

Oracle will have its own SCA implementation, but unfortunately I can't say more since I'm not a BEA employee anymore but not yet an Oracle employee :)


Hope I helped you to get a basis on that topic :)


Mots clés Technorati : ,,

How does WebLogic handle socket muxers ?

Muxer ? What's that ?

Taken from the documentation (http://edocs.bea.com/wls/docs100/perform/WLSTuning.html#wp1152246) :

WebLogic Server uses software modules called muxers to read incoming requests on the server and incoming responses on the client.

These muxers are of two primary types: the Java muxer or native muxer. A Java muxer has the following characteristics:

    * Uses pure Java to read data from sockets.

    * It is also the only muxer available for RMI clients.

    * Blocks on reads until there is data to be read from a socket.

    (This behavior does not scale well when there are a large number of sockets and/or when data arrives infrequently at sockets.

    This is typically not an issue for clients, but it can create a huge bottleneck for a server. )

      Native muxers use platform-specific native binaries to read data from sockets. The majority of all platforms provide some mechanism to poll a socket for data.


      For example, Unix systems use the poll system and the Windows architecture uses completion ports.

      Native provide superior scalability because they implement a non-blocking thread model.

      When a native muxer is used, the server creates a fixed number of threads dedicated to reading incoming requests.


      BEA recommends using the default setting of selected for the Enable Native IO parameter which allows the server automatically selects the appropriate muxer for the server to use.

      If the Enable Native IO parameter is not selected, the server instance exclusively uses the Java muxer.

      This maybe acceptable if there are a small number of clients and the rate at which requests arrive at the server is fairly high.

      Under these conditions, the Java muxer performs as well as a native muxer and eliminate Java Native Interface (JNI) overhead. Unlike native muxers,

      the number of threads used to read requests is not fixed and is tunable for Java muxers by configuring the Percent Socket Readers parameter setting in the Administration Console.


      See Changing the Number of Available Socket Readers.

      Ideally, you should configure this parameter so the number of threads roughly equals the number of remote concurrently connected clients up to 50% of the total thread pool size.

      Each thread waits for a fixed amount of time for data to become available at a socket.

      If no data arrives, the thread moves to the next socket.

      Then, for those reasons, it is obviously better to use native muxers.


      How do you know that your muxers are native and not java ?

      Well, you've got two ways to know that.

      Log File

      First one, when you start your server, if the log level is high enough, you should see a line like this one :

      <Info> <Socket> <BEA-000446> <Native IO Enabled.>

      If you don't have the opportunity to check for that line in the logs, it is possible to see that information, thanks to thread dumps.
      To perform a thread dump, you've got to send a precise signal to the JVM (http://en.wikipedia.org/wiki/SIGQUIT).

      Thread dump

      Perform a thread dump

      If you're in a Windows environment and your server has been launched with a startup script, switch to the command line window and press CTRL + Break.

      That will display the thread dump in the console.

      If you're in a Windows environment, but in a service mode, use the beasvc tool to perform the dump. (beasvc -dump)

      If Unix is your playground, then you should use the following command "kill -3 PID" (PID is the process id of your JVM)

      Another way is to use WLST to perform the dump (quite useful in a AIX environment, trust me !). Take a look at one of my previous post to know more about it.

      Once you have your thread dump, you'll have to analyze it.

      Analyze a thread dump

      In the dump, look for a section in which you can find queue: 'weblogic.socket.Muxer'"

      Like that :

      "ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" id=25 idx=0x5c tid=2492 prio=5 alive, in native, daemon
          at weblogic/socket/NTSocketMuxer.getIoCompletionResult(Lweblogic/socket/NTSocketMuxer$IoCompletionData;)Z(Native Method)
          at weblogic/socket/NTSocketMuxer.processSockets(NTSocketMuxer.java:81)
          at weblogic/socket/SocketReaderRequest.run(SocketReaderRequest.java:29)
          at weblogic/socket/SocketReaderRequest.execute(SocketReaderRequest.java:42)
          at weblogic/kernel/ExecuteThread.execute(ExecuteThread.java:145)
          at weblogic/kernel/ExecuteThread.run(ExecuteThread.java:117)
          at jrockit/vm/RNI.c2java(IIIII)V(Native Method)
          -- end of trace

      Here you can see (in blue) that the muxer used is the NTSoketMuxer. As long as it is NOT the class weblogic.socket.SocketMuxer, you're using a native muxer.

      Else it's a java muxer.


      List of muxers

      Java Muxer

      As said above, a java muxer is embodied by the class weblogic.socket.SocketMuxer

      Native muxers

      Windows : weblogic.socket.NTSocketMuxer

      UNIX weblogic.socket.PosixSocketMuxer & weblogic.socket.DevPollSocketMuxer

      Note : On UNIX environments (such as Solaris and HP-UX), WebLogic Server uses DevPollSocketMuxer by default,

      which prints out unnecessary SocketExceptions errors to the server log.

      As a workaround, you can enable PosixSocketMuxer via the WebLogic Scripting Tool as follows:


      cd ('Servers/'MyServerName')





      Mots clés Technorati : ,,,,


      WebLogic 10.3 has been released ! What's new ?

      As stated in the official documentation (which can be found at http://edocs.bea.com/wls/docs103/index.html, I decided to make a quick summary of what's hot in WLS 10.3.

      JDK 1.6

      [EDIT] : This version is compatible with 1.5 clients but only runs with a JDK 1.6 and not JDK 1.5 (as it was supposed to, before it was released)

      On top of that, some interesting stuff has been shipped within :

      * Thread synchronization improvements thus delivering increased scaling in the number of concurrent users supported and more reliable/stable code.

      * Web container supports multiple scripting languages such as PHP, Groovy, and Ruby: Refer to http://jcp.org/en/jsr/detail?id=223.

      * Allows hotswap of classes (without bouncing the class loaders in development mode) assuming that the class profile (new methods, method names) have not changed

      (only code in the method changed).

      The benefit is that it reduces redeployment effort (for iterative development, redeployment and restart).

      * Clients for for this release require JDK5 or later for client JVMs and a server JVM on JDK6.

      WLS apps built using the development tools (eclipse, intelliJ, Workshop etc.) running in a separate JVM (such as JDK5) should work with this release.

      * Compiler support. In this release, the JSP compiler uses the Java Compiler API instead of Javelin

      (the JSP compiler will no longer depend on Javelin framework java class bytecode generation feature) to generate byte code.

      This replacement does not expose any new public features and should not impact JSP files in existing applications.

      The rationale was to deliver a highly performing and reliable JSP compiler. See [JSP199], Java compiler API http://jcp.org/en/jsr/detail?id=199.


      On-Demand Deployment

      It allows you to choose which of the following applications have to be deployed or not.

      • User interfaces: This group includes the console, UDDI explorer, and WLS test client.
      • All others: UDDI, Web Service async response, deployment service servlet, and management file distribution/Bootstrap servlet.

      For instance, while accessing the administration console, the first time :


      The inflight compilation is activated by default for development domains but it is not the case for production domains.



      WebLogic used to ship a mechanism to be notified of class changes.

      It was embodied in a ChangeAwareClassLoader but the main con was that is reloaded the ENTIRE classloader.

      Now, with FastSwap, Java classes are redefined in-place without reloading the ClassLoader thus having the huge advantage of fast turnaround times.

      This means that developers do not have to sit and wait for an application to redeploy and then navigate back to wherever they were in the Web page flow.

      They can make their changes, auto compile, and then see the effects immediately.

      To enable FastSwap in your application, edit the weblogic-application.xml and add the following element.


      FastSwap is only supported when the server is running in development mode. It is automatically disabled in production mode.
      Only changes to class files in exploded directories are supported.

      Modifications to class-files in archived applications as well as archived jars appearing in the application’s classpath are not supported.

      Examples are as follows:

      • When a web application is deployed as an archived war within an ear, modifications to any of the classes are not picked up by the FastSwap agent.
      • Within an exploded web application, modifications to Java classes are only supported in the WEB-INF/classes directory;

      HTML Compression

      If you want to reduce network traffic, you may use an option which will act like the Java trim function (removal of all extra spaces).

      Example :


      Can be compressed as:



      Got to see whether the source code is always displayed in a well-formatted manner.


      Lightweight Server Runtime (based on mSA or µService Architecture itself based on OSGi)

      Now you've got the choice to start your server in two configuration : WLS and WLX.

      You have to use the java option -DserverType=“wlx” or -DserverType=“wls” to choose your prefered mode.

      The main difference is in the number of µServices that are launched during startup.

      • WLS : EJB, JMS, Connector, Clustering, Deployment, Management, and Diagnostics
      • WLX : The µServices EJB, JMS & JCA are NOT loaded.


      New Administration Console

      Some improvments from a WLP point of view :

      • # Use of Portal tree optimization
      • # Use of new Portal look and feel structure
      • # Multi-threaded backing files
      • # Better sharing of string resource property files

      Else some enhancements :

      Security Configuration : WebLogic Server now supports the use of SAML2 security providers.

      The Console has been updated to provide new pages for SAML2 identity asserters and credential mappers, and new server-specific security configuration pages.
      New pages are also included to configure the new file based and RDBMS security store features of WebLogic Server.
      All pages which include an encrypted password field now also include confirmation fields for those passwords.
      Console pages which export security configuration information to external files now check for the existence of those files before overwriting.
      Credential mappings may now be edited from within the console.

      Server Control : the Servers link on the home page and domain navigation tree now link to two different server tables,

      the previous Configuration perspective page and a new Control perspective page.

      The Control page supports starting and stopping any server in a domain, and functions very similarly to the existing Control:Servers page for a domain.

      Migration : WebLogic Server now supports additional capabilities for automatically migrating failed servers and services from one server to another.

      The console pages for configuring MigratableTargets have been updated to reflect those changes.

      WebServices : new Console pages have been developed to support the configuration of Reliable Messaging settings for WebServices.

      SCA Deployments : the Administration Console now supports the deployment and control of SCA deployments.

      Spring Applications : the Administration Console now includes the ability to inspect and interact with Spring Applications.

      This feature has been packaged as a console extension named “spring-console-extension.jar” located in the $WL_HOME/server/lib/console-ext directory.

      This console extension is not automatically deployed by default, but may be included by copying this archive into the $WL_HOME/server/lib/console-ext/autodeploy directory.


      Server Control :



      A quick review about a book covering EJB 3 by Packt Publishing


      This book is the first one I read from Packt Publishing and I was surprised by its quality.
      It is split in well-defined chapters that allow you to go straight to the point.
      In spite of the fact I already knew about some topics covered, I still enjoyed reading those parts thanks to good and clear explanations.
      One of the problem I sometimes encoutered is the lack of ponctuation which can be misleading for non native english speakers.
      Else, it's a very good book !


      More information : http://www.packtpub.com/developer-guide-for-ejb3/book