Michael Sikora on Java EE

Converting to Weblogic 10.3 - EJB3 Security

In this post I describe the conversion of examples of chapter 12, which deals with EJB 3 Security, from Glassfish to Weblogic 10.3. No source code changes were required, only deployment and configuration of users and assigned roles was different.

In Glassfish we used the asadmin utility to create a user and associated role as a task in the build.xml file as follows:

<target name="create-file-user">

<exec executable="${glassfish.home}/bin/asadmin"

failonerror="true"

vmlauncher="false">

<arg line="create-file-user --user admin --passwordfile userpassword --groups bankemployee scott"/>

</exec>

</target>

In Weblogic users and corresponding passwords were created using the administrator console. If an ejb is invoked by a Java client, users cannot be assigned to a role or roles in the administrator console. Instead user/role assignment is done at deployment. We need to create the weblogic-ejb-jar.xml file as follows:

<security-role-assignment>

<role-name>bankemployee</role-name>

<principal-name>scott</principal-name>

</security-role-assignment>

<security-role-assignment>

<role-name>bankcustomer</role-name>

<principal-name>ramon</principal-name>

</security-role-assignment>

</weblogic-ejb-jar>

 

In the wldeploy ant task we need to add the line securityModel="DDOnly" to indicate security role assignment is done at deployment:

<wldeploy

user="${admin.username}"

password="${admin.password}"

adminurl="t3://${weblogic.hostname}:${weblogic.port}"

securityModel="DDOnly"

debug="true"

action="deploy"

name="BankService"

source="${build.dir}/BankService.ear"

failonerror="${failondeploy}"/>

Rather than use a JAAS login which would entail creating additional source code such as a CallBackHandler, JNDI login was used instead. This entailed creating a jndi.properties file for each user with the username and password included. So for user scott the corresponding jndi.properties file is:

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory

java.naming.provider.url=t3://localhost:7001

java.naming.security.principal=scott

java.naming.security.credentials=xyz12345

In lab4 we invoke an ejb from a servlet so we use web-tier authentication. In this case we can specify user/role assignments in the administrator console. Then we need to set the Security Model default flag in the administrator console as follows:

Select security realm in navigation pane, then select myrealm (this is the default realm). For the "Security Model default" select "Custom Roles and Policies" from drop down list.

This is the last in the migrating EJB3 to Weblogic 10.3 series. All the source code should shortly be available for download from the book's website.

Converting to Weblogic 10.3 - EJB3 WebSevices

In this post I describe the conversion of examples of chapter 11, which deals with EJB 3 Web Services, from Glassfish to Weblogic 10.3. Apart from one minor exception described below no source code changes were required. The only modifications required were to the application server specific ant tasks which generate various web service artifacts. These ant tasks were all defined in the build.xml file.

The equivalent of the Glassfish wsgen tool in Weblogic is the jwsc ant task. jwsc takes as input a Java class file with embedded web service annotations and generates all the artifacts required to create a web service. In Glassfish explicit use of wsgen is optional as web service artifacts are generated as deployment time if they have not already been created by wsgen. In Weblogic we do need to explicitly invoke jwsc before deployment.

The wsdl file created by jwsc creates a "REPLACE_WITH_ACTUAL_URL" placeholder for the web service URL. Consequently we need to edit the wsdl file and specify the actual URL. For example in lab1 we must edit the build\webservice\ArithmeticService.wsdl file from:

<service name="ArithmeticService">

<port name="ArithmeticPort" binding="tns:ArithmeticPortBinding">

<soap:address location="REPLACE_WITH_ACTUAL_URL"/>

</port>

</service>

to:

<service name="ArithmeticService">

<port name="ArithmeticPort" binding="tns:ArithmeticPortBinding">

<soap:address location="http://localhost:7001/Arithmetic/Arithmetic"/>

</port>

</service>

The equivalent of the Glassfish wsimport tool in Weblogic is the clientgen ant task. clientgen generates from an existing wsdl file the client artifacts that client applications use to invoke Weblogic and non-Weblogic web services.

In Weblogic we cannot use @WebServiceRef annotation to define a reference to a Web Service from a stand-alone Java client. In Weblogic @WebServiceRef is only used to invoke a web service from another web service. Consequently in lab1 the source code for WebServiceClient was changed from

public class WebServiceClient {

@WebServiceRef(wsdlLocation="http://localhost:8080/arithmetic-webservice/ArithmeticService?WSDL")

static ArithmeticService service;

public static void main(String[] args) {

try {

   ...

to

public class WebServiceClient {

public static void main(String[] args) {

try {

ArithmeticService service = new ArithmeticService();

   ...

It was not possible to have a Weblogic version of lab2. The glassfish version of lab2 has a MathematicsImpl implementation of the Mathematics interface:

@WebService(endpointInterface = "endpoint.Mathematics")

public class MathematicsImpl implements Mathematics {

   ...

We use the endpointInterface attribute to specify the interface. However in Weblogic we use the endpointInterface attribute to specify the service endpoint interface generated by the wsdlc ant task. The wsdlc ant task takes as input wsdl file and generates web service artifacts including the Java service endpoint interface (this is known as the top-down approach) .

In the next post I'll describe the conversion of chapter 12 examples which demonstrate EJB 3 security.

.

Converting to Weblogic 10.3 - Part 3

In previous posts I described converting the examples of chapters 2 and 3 of my book from Glassfish to Weblogic 10.3. In this post I describe the conversions of chapters 4 to 10.

The conversions of chapter4 (Object/Relational Mapping), chapter 5 (JPQL), chapter 6 (Entity Manager) and chapter 7 (Transactions) from Glassfish to Weblogic presented no problems at all.

However in chapter 8 (Messaging) the creation of JMS resources such as queues and topics is a bit different.

JMS resources can be configured using the administrator console or from the command line using the ant wlconfig task. It is also possible to configure JMS resources using the weblogic.Admin utility or the Weblogic scripting tool (WLST). I used the wlconfig task as it was closest to the approach I used with Glassfish.

JMS resources are configured using MBeans. An MBean is a Java class which is used for managing, controlling and monitoring a resource. MBeans form a hierarchy with the Weblogic server MBean being the parent of the JMS MBeans we create. First, nested within the wlconfig tag, we use the query tag to get a reference to the examplesServer MBean and store it in the examplesServer property; we will make use of this property shortly.

<query domain="wl_server" type="Server" name="examplesServer"

property="examplesServer"/>

Weblogic has two preconfigured domains: medrec and wl_server. We choose to use wl_server. Within wl_server is a preconfigured Weblogic server called examplesServer which we will use. A Weblogic server is a Weblogic instance running in its own JVM and with its own configuration. Next we create a JMSServer MBean and its dependent JMSQueue and JMSTopic MBeans using the create tag:

<create type="JMSServer" name="BankJMSServer">

   <set attribute="Targets" value="${examplesServer}"/>

   <create type="JMSQueue" name="BankServiceJMSQueue">

      <set attribute="JNDIName" value="BankServiceJMSQueue"/>

   </create>

   <create type="JMSTopic" name="BankServiceJMSTopic">

      <set attribute="JNDIName" value="BankServiceJMSTopic"/>

   </create>

</create>

We use the set tag and "Targets" attribute together with the examplesServer property we obtained from the earlier query tag to specify the Weblogic server.

Next we create a JMSConnectionFactory as follows:

<create type="JMSConnectionFactory" name="BankServiceConnectionFactory">

   <set attribute="Targets" value="${examplesServer}"/>

   <set attribute="JNDIName" value="BankServiceConnectionFactory"/>

   <set attribute="XAConnectionFactoryEnabled" value="true"/>

</create>

You don't always need to create a JMSConnectionFactory, you can just use the default JMSConnectionFactory preconfigured with Weblogic. However my existing Glassfish source code refers to the BankServiceConnectionFactory, so I included this step.

Chapter 9 (EJB Timer Service) again presented no problems.

However in chapter 10 (Interceptors) I did encounter an issue with Interceptor classes. Labs 2 and 3 use the following interceptor class:

public class Auditor {

   @PersistenceContext(unitName="BankService")

   private EntityManager em;

   @AroundInvoke

   public Object audit(InvocationContext invctx) throws Exception {

        . . .

The interceptor class is referred to in the BankServiceBean as follows:

@Stateless

@Interceptors(Auditor.class)

public class BankServiceBean implements BankService {

   @PersistenceContext(unitName="BankService")

   private EntityManager em;

       ...

This presented no problems in Glassfish. With Weblogic I got a runtime error on the lines of

" ... Dependency injection failure: can't find the bean definition about class interface javax.persistence.EntityManager. No unique bean of type javax.persistence.EntityManager is defined ... "

This was resolved by giving a JNDI name to the EntityManager in the BankServiceBean as follows:

@Stateless(mappedName="BankService")

@Interceptors(Auditor.class)

public class BankServiceBean implements BankService {

   @PersistenceContext(name = "BankPC", unitName="BankService")

   private EntityManager em;

      ...

We then use a JNDI lookup in the interceptor class to obtain the EntityManager as follows:

public class Auditor {

   @AroundInvoke

   public Object audit(InvocationContext invctx) throws Exception {

      try {

      InitialContext ctx = new InitialContext();      

      EntityManager em = (EntityManager)ctx.lookup("java:comp/env/BankPC");

            ...

That's it for now. In my next post I'll deal with the remaining chapters on EJB Web Services and Security respectively. Authentication in particular is somewhat application server specific so I expect difficulties in this area.