Beehive Integration in BEA WebLogic Server

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Beehive System Controls

WARNING: This document is deprecated as of version 10.0 of WebLogic Server. This deprecation warning applies only to this documentation, and not to the underlying functionality it describes nor to the open-source Beehive project. Users who wish to develop and deploy Beehive applications should do so using Workshop for WebLogic, which offers support for all aspects of Beehive technology. Current documentation for integrating Beehive and WebLogic Server can be found at Workshop for WebLogic Platform User's Guide.

Beehive system controls in WebLogic Server are an implementation of the system controls in the Apache Beehive project. These sections describe the additional functionality provided by the WebLogic Server implementation.

For a detailed description of Beehive controls and their functionality, please see the Apache Beehive documentation at

Note: Beehive system controls are installed on your computer automatically during the BEA Products installation process. Because the system controls are pre-installed, the sections of the Apache Beehive documentation that describe how to download and install Beehive do not apply to WebLogic Server users.


JDBC Control

JDBC controls make it easy to access a relational database from your Java code using SQL commands. The JDBC controls automatically perform the translation from database queries to Java objects so that you can easily access query results.

A JDBC control can operate on any database for which an appropriate JDBC driver is available and for which a data source has been configured. When you add a new JDBC control to your application, you specify a data source for that control. The data source indicates which database the control is bound to.

The full functionality of Apache Beehive JDBC controls is available to you in WebLogic Server.


Web Service Control

The web service control gives your application easy access to web services. You use the web service control in an application just like any other Beehive control: (1) you declare the control using the @Control annotation on a class member field, and (2) you call the methods on the control. For code examples, please see Beehive Tutorial.

Web service controls are generated on a per-service basis. WebLogic Server provides a service control generation tool based on the target service’s WSDL file. For details on generating a web service control, see Building Web Service Controls.

Note: WebLogic Server does not ship with the Beehive implementation of the web service control. Instead, it ships with its own implementation of a web service control. In other words, generated service controls extend the class com.bea.control.ServiceControl, not the class org.apache.beehive.controls.system.webservice.ServiceControl.

Compiling a web service control is a multi-step process described in Building Web Service Controls.


EJB and JMS Controls

The EJB and JMS controls shipped with WebLogic Server 9.2 are identical to the Beehive versions. For detailed information on these controls, see the Apache Beehive documentation at


Control Security

For background information about the terms and concepts referred to in this section, please see the Java Authentication and Authorization Service documentation on the Sun website and the BEA WebLogic Server Security documentation.

WebLogic Server provides security for Beehive controls through the @Security annotation.

The com.bea.controls.Security annotation is used to decorate control methods. The @Security annotation interface has the following optional attributes:

@Security Attributes
Attribute Name
Optional. An Array of role-names allowed to run the annotated method. If the current principal calling the method has been granted one of the specified roles, then the method invocation will be granted. Otherwise, a will be thrown.
Optional. A role-name. The method will be run with the current principal being set to the role specified, unless runAsPrincipal is given.
Optional. A principal name. The method will run with the current principal as specified. Must be used in conjunction with runAs.

The @Security annotation can be placed on a method of a control interface. @Security is not allowed on @Control fields or control class declarations.

To use the @Security annotation in your control file, you must import the class com.bea.control.annotations.Security.

   import com.bea.control.annotations.Security;

You must also (1) define the referenced roles at the application-level using <security-role> in application.xml and (2) provide role mappings using <security-role-assignment> weblogic-application.xml.

For example, if you reference the manager role in the @Security annotation:

   @Security( rolesAllowed={"manager"} ) 
   public String getSalary();

then you must define the manager role using <security-role> in application.xml:


and you must provide role/principal mappings using <security-role-assignment> in weblogic-application.xml:


Supported Role Scopes

Only the “application” role scope is supported. Global, web-app, and EJB scopes are not supported. The application scoping is defined by the <security-role> and <security-role-assignment> elements in the application.xml and weblogic-application.xml files, respectively (see implementation details in Control Security).

The runAs attribute value (a role) is mapped to a principal as follows:

  1. If a <security-role-assignment> element with the <role-name> having the value id is defined in the weblogic-application.xml file, then the value of the first <principal-name> element is used as the principal if given.
  2. Otherwise, the id is assumed to be the name of a principal.

  Back to Top       Previous  Next