Using the WebLogic EJB Deployment Wizard
- I. Introduction
- How the EJB Deployment Wizard works
- II. Using the Wizard
- Opening and setting the EJB Deployment Wizard
- Loading EJBeans
- Main window
- Options window
- Configuration window
- Creating a new deployment descriptor
- III. Configuring EJBeans
- Common properties
- EJBean
- Access control
- Control descriptors
- Clustering
- Environment
- Entity-specific properties
- EJBean
- Entity environment
- Container-managed
- Persistence
- JDBC Finders
- Session-specific properties
- Reviewing the deployment descriptor settings
- Specifying the tasks to complete
- Completing tasks and deploying the EJBean
- IV. Text file format and index
- Format for text deployment descriptor files
- Index of deployment descriptor properties
- V. Change history
- Other related documents
- Overview of WebLogic Enterprise JavaBeans
- Using WebLogic Enterprise JavaBeans
- Designing a WebLogic EJB application
- Example EJBeans
I. Introduction
The WebLogic EJB Deployment Wizard allows you to configure and deploy
Enterprise JavaBeans (EJBeans) for use with your WebLogic server. You
can use it to:
- Examine existing EJBeans and their deployment descriptor's configurable
properties
- Modify the properties and save the changes to either an existing .jar, .ser
or as a text file
- Generate EJBean interface classes for a particular WebLogic environment
This document details how to use the WebLogic EJB Deployment Wizard. It
also describes the parameters that can be set in a deployment descriptor
and how to write deployment descriptors as
text files that can be serialized with either
the EJB Deployment Wizard or the WebLogic EJB utility program DDCreator.
An index (Index of deployment descriptor properties)
lists all properties alphabetically.
Additional information on Enterprise JavaBeans can be found in Using WebLogic Enterprise
JavaBeans, the Developers Guide that covers in general the
Enterprise JavaBean service within WebLogic.
How the EJB Deployment Wizard works
Here are the basic steps for deploying an EJBean:
- Open the EJB Deployment Wizard
- Load an EJBean deployment descriptor: either
a .jar, .ser or .txt (text) file
- Configure the EJBean deployment descriptor
properties
- Review the deployment descriptor settings
- Specify the tasks to complete -- updating the descriptor,
generating WebLogic interfaces, writing to a text or .ser file
- Complete the tasks
- Update your weblogic.properties
file and restart WebLogic for changes to take effect
II. Using the Wizard
Opening and setting the EJB Deployment Wizard
You can start the EJB Deployment Wizard by:
where options are:
- -help
- Prints the help message
- -s [DD source]
- Starts with a particular deployment descriptor
- -laf [basic | metal | motif | win]
- Sets the look and feel of the wizard; defaults to system-native
An example of an EJB deployment using the Wizard is shown for
container-managed persistence.
Loading EJBeans
Main window
When you start up the EJB Deployment Wizard, the first window that
appears after the start-up window is the Main window. You use this
window to load EJBeans into the Wizard; after that you can configure
and deploy them.
The list shows all the EJBeans that the Wizard knows about, and their
type and source file name. The Deployed column indicates if you
have -- in the current session of using the Wizard -- used the Wizard
to generate the interfaces for deployment.
You can add EJBeans to the list, either in the form of .jar, .ser or .txt
(text) files. The Wizard will read the contents of a .jar file and load
any EJBeans that it finds.
The buttons Add to list... and Remove from list... add
and remove entries to the list. The contents of the list are retained
between sessions. If a source file can't be found when the Wizard is
started, a message will appear below the list and the entry removed
from the list.
Clicking on a row in either in the EJB name or Source
columns will show you the EJB class or the full path of the source in
the message area below the list.
Options window
From the Main window's menu bar, you can select Edit ¬ Options
to bring up the Options window:
You can specify:
- the compiler to use for generating wrapper classes
- any directories or .jar files that need to be added to the Java system classpath
when either opening a deployment descriptor or when generating container classes
- the location of the temporary, writable directory for use by the Wizard
- under Display, set the colors used to show invalid, modified and valid information.
Configuration window
Selecting a deployment descriptor in the Main window and either double-clicking the row
or clicking the Configure descriptor... button will open the
Configuration window for that EJBean, allowing you to edit, generate
interfaces and update it.
The Configuration window is a four page window, with buttons to switch
between the different pages. You start on the first page, and proceed
in order. You can cancel at any time, which will close the
Configuration window.
- Configuration page
This page has a tabbed display for setting the configurable properties
of the EJBean.
- Review page
You can review your settings of the configurable properties to make
sure they're correct.
- Task specification page
Specify which tasks you want the Wizard to complete.
- Task completion page
The Wizard completes the tasks, and reports on its success or failure.
Creating a new deployment descriptor
The steps for creating a new deployment descriptor are slightly
different than the ones for editing an existing descriptor.
You will need to have all of the files for your EJBean written and
compiled before you create the deployment descriptor. That way, you
can use the Wizard to check that you have entered all the classnames
correctly.
You can start a new descriptor from either the
File ¬ New descriptor... menu item or by pressing
the New descriptor... button.
You will then be prompted to save the new descriptor. Save it as a .ser
file in an appropriate location in your file hierarchy.
When you enter a class name, the label for the text entry area will
appear in red until the class name
matches that of a class in the classpath of the Deployment Wizard.
When it matches, the label color will revert to black.
After have completed configuring the deployment descriptor, you will
move to the next page, where you will review your configuration.
On the following page, you will set the the tasks to be completed. Make
sure that the checkbox Update deployment descriptor is checked
so that your configuration is saved when you generate the WebLogic
interfaces for the EJBean.
You can then generate the interfaces. Once complete, do not forget to
edit your weblogic.properties file to
complete the deployment of your new EJBean.
III. Configuring EJBeans
- Common properties
- EJBean
- Access control
- Control descriptors
- Clustering
- Environment
- Application-specific
- Entity-specific properties
- EJBean
- Entity environment
- Container-managed
- Persistence
- JDBC Finders
- Session-specific properties
To configure the different types of EJBean properties, a tabbed display
is provided. The number of tabbed panels depends on whether you are editing
an entity or session EJBean.
These next sections describe the different properties and their settings.
As deployment descriptors can also be entered into a correctly configured
text file and then loaded into the EJB Deployment
Wizard, after each property's descriptive name is the equivalent name
in italics that's to be used in a text file.
When you enter a class name, the label for the text entry area will
appear in red until the class name matches
that of a class in the classpath of the Deployment Wizard.
When it matches, the label color will be black.
Many sections have scrolling lists containing either popdown menus or
edit text fields to change the properties.
To popdown a menu in a scrolling list, double-click the text area.
Items shown in italic in popdown lists are disabled; usually this
is because only one of that item can be present in the list and that selection
is already present.
To edit a text area in a scrolling list, double-click the text area.
When you are finished editing
in an edit text field, press the Enter key to end editing.
If you are creating a new deployment descriptor (as versus editing an
existing one) see the section Creating a new deployment
descriptor.
Common properties
Both entity and session EJBeans have a common set of configurable properties.
The first five tabs deal with these:
EJBean (EntityDescriptor or SessionDescriptor)
Once the EJBean has been defined and saved, this tab has the name of the EJBean.
- EJB class (enterpriseBeanClassName)
- The classname of the EJBean itself.
Home interface class (homeInterfaceClassName)
-
- The home interface implemented by a class generated by the EJB compiler
(ejbc). See the property home
classname (homeClassName) below to plug in your own home
class.
Remote interface class (remoteInterfaceClassName)
-
- This interface is implemented by an "EJBObject", a wrapper class that
is generated by the EJB compiler (ejbc). This wrapper interposes between a caller and the EJBean,
and deals with concurrency, transactions and security. See the property
EJBObject classname (ejbObjectClassName)
below to plug in your own EJBObject class.
EJB home name (beanHomeName)
-
- The JNDI name of the EJBean.
Reentrant transactions (isReentrant)
-
- Either "true" or "false". If true, the same transaction is allowed
to revisit an EJBean. If the EJBean does not support transactions or
if a transaction is not active, a lock is taken out on behalf of the
EJBObject. Session EJBeans cannot be reentrant; this property must be
"false".
There are entity
specific and session specific properties
for this section.
Access control specifies security access control for the EJBean as a whole
(under the DEFAULT entry), and can provide method-specific access control
entries.
Names in the entries should represent role names.
As per the JavaSoft EJB specification,
you should not define a single user for access control;
instead, use a role.
Roles map to groups. You can then change the users on the
ACL without having to recompile your EJBean.
Example:
DEFAULT [admin managers]
deposit [everyone]
"withdraw(double)" [admin managers]
"withdraw(int)" [admin "Account Managers"]
Example: (from EJB Deployment Wizard)
Note:
- The method name is that of the corresponding home or remote interface,
or of the EJBean itself. It must be a business method, an
ejbCreate()
method, a finder method, or the ejbRemove() method.
- Methods with the same name but with different signatures can be distinguished
by supplying the complete method signature.
- In text files, method names that are not single words must be enclosed
in double quotes(").
For additional information on WebLogic security, please see the WebLogic
Developer Guide Using
WebLogic ACLs (Access Control Lists).
For information on setting up users and groups,
see Using WebLogic ACLs:
Setting up ACLs in the WebLogic realm.
This section decides the run-time properties when a method is called. The
DEFAULT entry applies to all methods, but can be overridden on a per-method
basis, as described for the Access control.
- Transaction isolation level
(isolationLevel)
- Sets the JDBC transaction isolation level.
TRANSACTION_READ_UNCOMMITTED
Dirty reads, non-repeatable
reads and phantom reads can occur
TRANSACTION_READ_COMMITTED
Dirty reads prevented;
non-repeatable and phantom reads possible
TRANSACTION_REPEATABLE_READ
Dirty and non-repeatable
reads prevented; phantom reads possible
TRANSACTION_SERIALIZABLE
The strictest isolation
level; all of the above problems avoided
Transaction
attribute (transactionAttribute)
-
TX_BEAN_MANAGED
EJBean starts and
ends transaction
TX_MANDATORY
Caller must start
transaction
TX_REQUIRES_NEW
WebLogic starts and
ends a new transaction with each invocation; any caller's transaction
is suspended
TX_REQUIRED
EJBean requires
a transaction, WebLogic will start one if caller hasn't already
done so
TX_NOT_SUPPORTED
WebLogic suspends
caller's transaction before calling EJBean
Run-as mode
(runAsMode)
-
- This property sets the effective user identity; options are:
CLIENT_IDENTITY
The caller's identity
is passed to the EJBean
SPECIFIED_IDENTITY
See Run-as
identity below
SYSTEM_IDENTITY
"system" in the
weblogic realm
Run-as
identity (runAsIdentity)
-
- If Run-as mode is set to
SPECIFIED_IDENTITY,
assume the identity given by run-as identity before passing the
call to the EJBean.
Examples for a specific method buy():
(buy
; control descriptor override
; for a specific remote method
;
isolationLevel TRANSACTION_SERIALIZABLE
transactionAttribute TX_REQUIRED
runAsMode CLIENT_IDENTITY
); end buy
or
(buy
; control descriptor override
; for a specific remote method
;
isolationLevel TRANSACTION_SERIALIZABLE
transactionAttribute TX_REQUIRED
runAsMode SPECIFIED_IDENTITY
runAsIdentity paul
); end buy
Example: (from EJB Deployment Wizard)
This section specifies the properties that control bean
deployment in a cluster. These properties are not required for EJBeans
that are only deployed on a single server.
Home call router class name
(homeCallRouterClassName)
-
Specifies a custom class to be used for routing home method
calls. This class must implement
weblogic.rmi.extensions.CallRouter().
If specified, an instance of
this class will be called before each method call and be given the
opportunity to choose a server to route to based on the method
parameters. It either returns a server name or null indicating
that the current load algorithm should be used to pick the server.
Home is clusterable
(homeIsClusterable)
- Either "true" or "false".
If "true", this bean can be deployed from multiple servers
in a cluster. Calls to the home stub will be load-balanced
between the servers on which this bean is deployed, and if
a server hosting the bean is unreachable, the call will
automatically failover to another server hosting the bean.
See the list of failover exceptions below.
Home load algorithm
(homeLoadAlgorithm)
- Specifies the algorithm to be used for load balancing between
replicas of this home. If this is not specified
the algorithm specified by the server property
weblogic.cluster.defaultLoadAlgorithm
will be used. May be any of:
- round-robin
- random
- weight-based
Home stub is replica aware
(homeStubIsReplicaAware)
- This descriptor has been deprecated. Please use
homeIsClusterable.
Home stub replica handler
(homeStubReplicaHandler)
- This descriptor has been deprecated. Please use
homeLoadAlgorithm.
Stateless bean call router class name
(statelessBeanCallRouterClassName)
-
Specifies a custom class to be used for routing bean method
calls. This class must implement
weblogic.rmi.extensions.CallRouter().
If specified, an instance of
this class will be called before each method call and be given the
opportunity to choose a server to route to based on the method
parameters. It either returns a server name or null indicating
that the current load algorithm should be used to pick the server.
Stateless bean is clusterable
(statelessBeanIsClusterable)
- Either "true" or "false".
If homeIsClusterable is "true" and
this property is "true", each call to the bean stub will be
load-balanced between the servers that are hosting the bean.
If a call to the bean fails due to a communication failure,
the call will failover to another server hosting the bean.
See the list of failover exceptions below.
Applicable only to stateless session EJBeans (ie, with a
stateManagementType of
STATELESS_SESSION).
Stateless bean load algorithm
(statelessBeanLoadAlgorithm)
- Specifies the algorithm to be used for load balancing between
replicas of this bean. If this is not specified
the algorithm specified by the server property
weblogic.cluster.defaultLoadAlgorithm
will be used. May be any of:
- round-robin
- random
- weight-based
Stateless bean methods are idempotent
(statelessBeanMethodsAreIdempotent)
- Either "true" or "false".
This should be set to "true" only if the bean is written such that
repeated calls to the same method with the same arguments has
exactly the same effect as a single call. This allows the
failover handler to retry a failed call without knowing whether
the call actually completed on the failed server. Setting this
property to "true" makes it possible for the bean stub to
automatically recover from any failure as long as another server
hosting the bean can be reached.
See the list of failover exceptions below.
Applicable only to stateless session EJBeans (ie, with a
stateManagementType of
STATELESS_SESSION).
Stateless bean stub is replica aware
(statelessBeanStubIsReplicaAware)
- This descriptor has been deprecated. Please use
statelessBeanIsClusterable.
Failover exceptions
If the methods are not idempotent, the call will failover on these exceptions,
all of which occur before a method is called:
- UnknownHostException()
- ConnectException()
- ConnectIOException()
- NoSuchObjectException()
If the methods are idempotent, the call will failover on all of the above
exceptions, and on an UnmarshalException().
EJBHomes, if set to clusterable,
will failover on all these exceptions.
Example cluster properties
From a text deployment descriptor
(note that in a text deployment descriptor, they are listed as a sub-section of
environmentProperties):
(environmentProperties
(clusterProperties
; Cluster-specific environment properties
homeIsClusterable true
; homeLoadAlgorithm
statelessBeanIsClusterable true
statelessBeanMethodsAreIdempotent false
); end clusterProperties
); end environmentProperties
From EJB Deployment Wizard:
Environment properties can set by supplying a property name
(shown in italics in the list below) and a
property value. In addition to the properties listed below,
there are entity- and
session-specific environment properties, and
application-specific
properties can be defined and retrieved at run-time.
These properties are specific to the WebLogic implementation.
Home classname (homeClassName)
- For a home interface called "Foo", the EJB compiler (ejbc)
generates an implementation called "FooHomeImpl". You can inherit from
it and override or provide new methods in a custom class, by specifying
that class's name for this property.
EJBObject classname (ejbObjectClassName)
- For a remote interface called "Foo", the EJB compiler (ejbc)
generates an implementation called "FooEOImpl". You can inherit from
it and override or provide new methods in a custom class, by specifying
that class's name for this property.
Maximum EJBeans in free pool
(maxBeansInFreePool)
- WebLogic EJB maintains a free pool of beans for every bean class. This
property decides the size of the pool. See the
See the discussion on pooling
in the Developers Guide
Using WebLogic Enterprise JavaBeans.
Maximum
EJBeans in cache (maxBeansInCache)
- Maximum number of objects of this class that are allowed in memory.
Objects are kept in an LRU chain, and the ones dropped from the end
of the chain are passivated.
See the discussion on pooling
in the Developers Guide
Using WebLogic Enterprise JavaBeans.
Idle timeout (idleTimeoutSeconds)
- The LRU chain (see maxBeansInCache
above) is scrubbed of inactive objects after at least this many seconds.
See the discussion on pooling
in the Developers Guide
Using WebLogic Enterprise JavaBeans.
Note: Setting idleTimeoutSeconds to zero inhibits WebLogic Server from passivating EJBeans at regular intervals. If idleTimeoutSeconds is set to zero, WebLogic Server passivates beans only when maxBeansInCache has been reached and a new EJBean must enter the cache. If WebLogic Server cannot passivate a bean when the cache is full, it throws a CacheFullException.
Is modified method
(isModifiedMethodName)
- This is applicable only to entity EJBeans.
The Is modified method name is the EJBean
method that's called when the EJBean is stored. If this method is not
specified, WebLogic always assumes that the EJBean has been modified and
always saves it. Providing a method and setting it as appropriate will
improve performance. This is described in
Using
WebLogic Enterprise JavaBeans: EJB and persistence.
Persistent directory root
(persistentDirectoryRoot)
- This is applicable only to stateful session beans.
The location for storing passivated stateful session beans
using file persistence.
The default file is "/pstore/example_bean.dat",
where the directory "pstore" is located in the directory
which the WebLogic Server was launched, and example_bean
is the fully-qualified name of the EJBean with underscores ("_") replacing the
periods (".") in the name.
For example, if the persistentDirectoryRoot
is "c:\weblogic\mystore", all passivated instances of the EJBean
"examples.ejb.SessionBean" will be stored in a single file
"c:\weblogic\mystore\examples_ejb_SessionBean.dat".
Application-specific properties
- In addition to the properties listed above, application-specific environment
properties may be included:
Example:
; Application-specific environment properties
(StockPrices
; Stock prices is a nested hash table
WEBL 10.0
INTL 15.0
); end Stock Prices
tradeLimit 500
; end Application-specific environment properties
Example environment properties: (from EJB Deployment Wizard)
Entity-specific properties
For entity EJBeans you must specify the primary key class and the
container-managed fields.
EJBean (EntityDescriptor)
- Primary key classname (primaryKeyClassName)
- Note that for container-managed persistence (according to the EJB
1.0 spec) you must have a custom class for the primary key -- java.lang.String
will not do. For EJBean-managed persistence, it can be any class.
This property can be added to the environment properties,
though it affects only entity beans.
- Container-managed fields
(delayUpdatesUntilEndOfTx)
- For container-managed persistence only.
This optional optimization affects when changes
to a bean's state are propogated to the persistent store. If the property
is set to "true" (the default), updates of the persistent store of
all beans in the transaction will be performed at the end of the
transaction. If this is set to "false", the update of a bean's persistent store will be
performed at the conclusion of each method invoke.
Previously, this optimization was enabled automatically which can
cause problems in applications that utilize integrity constraints
on the underlying database tables.
- Container-managed fields (containerManagedFields)
- For container-managed persistence only. The list of public non-transient
fields of the EJBean that are to be made persistent.
In text deployment descriptor files, to include all EJBean fields
without having to enumerate them by name, use:
containerManagedFields *
This section specifies the persistent store properties for entity EJBeans
with container-managed persistence.
For entity EJBeans with EJBean-managed persistence (ie, no container-managed fields), this section is
ignored and the tab is disabled in the Wizard.
- Persistent store type (persistentStoreType)
- Either "file" or "jdbc". The type is used to identify the specific
section below that provides additional information for setting up the
appropriate persistent storage. The value of the persistentStoreType
must be lowercase in text files.
In a future release of WebLogic, you will be able to use a custom persistent
storage type. Currently this is not supported.
File
persistence (file)
- If the "persistentStoreType" is "file", the following property is
applied:
- Persistent directory root (persistentDirectoryRoot)
- If specified, all instances of an EJBean are stored under the persistentDirectoryRoot
with the name of the EJBean converted to a directory name. Defaults
to a directory "pstore" in the directory where WebLogic was started.
For example, if the persistentDirectoryRoot
is "c:\weblogic\mystore", all instances of the EJBean "examples.ejb.AccountBean"
will be stored in a single file "c:\weblogic\mystore\examples_ejb_AccountBean.dat".
Note that file persistence is intended for development and prototyping only, and is not
intended for production, as it does not have transactional integrity.
JDBC persistent store type (jdbc)
- If the "persistentStoreType" is "jdbc", the following object-relational
mapping information is applied:
- Table Name (tableName)
- Name of the SQL table in the persistent storage.
- Shared database (dbIsShared)
- Either "true" or "false". If this is true, caching is turned off,
because WebLogic knows it doesn't "own" the table.
If you directly edit the dbIsShared property in the deployment
descriptor file, note that the syntax for specifying the property is
different for bean-managed and container-managed entity EJBeans. For
container-managed beans, dbIsShared is defined in within the
jdbc property. For example:
(environmentProperties
(persistentStoreProperties
persistentStoreType jdbc
(jdbc
dbIsShared false
. . .
); end jdbc
); end persistentStoreProperties
)
For bean-managed entity EJBeans, dbIsShared is defined within
persistentStoreProperties. For example:
(environmentProperties
(persistentStoreProperties
dbIsShared false
); end persistentStoreProperties
)
Connection pool name (poolName)
The connection pool to be used for JDBC persistence. A pool is used
for performance reasons; it must be setup in the weblogic.properties
file.
Attribute map (attributeMap)
Maps the EJBean fields to database column names
entered in the last column.
Example:
(attributeMap
; Maps the EJBean fields to database column names
; EJBean field Database column name
; -----------------------------------------
accountId id
balance bal
); end attributeMap
JTS login (weblogicJTSConnPoolProperties)
- Specifies the username and password to use for connecting to the
database via JTS. Example:
...
(weblogicJTSConnPoolProperties
user username
password password
); end weblogicJTSConnPoolProperties
); end jdbc
Note: The
weblogicJTSConnPoolProperties property must be manually added
to the deployment description. Example: (from EJB Deployment
Wizard)
This property applies to JDBC persistent storage.
Finder properties are WebLogic's implementation of the EJB find methods.
The finder properties are pairs of method signatures and expressions.
The methods can be used to find EJBeans and always return an enumeration
of EJBeans.
There are two steps to using the finder descriptors:
- Define method signatures in the home interface.
The method names must always start with the prefix "find".
The Wizard will list all the finder methods in the home interface.
- Using the Wizard, define the expression for each method signature.
Notes:
- If you use a non-primitive data type in a finder descriptor,
you need to use a fully qualified name, such as
java.sql.Timestamp.
- Finder descriptors always use EJB field names, not column names,
excpet as shown below for the ordering of the returned beans.
The syntax of the expression is not fixed, and will change in the future.
Syntax
Expression prefix notation of [operator operand1 operand2]
where:
- operators:
( ) = < > <= >= / ! & | like
isNull isNotNull orderBy
! is the Boolean not, & is the Boolean
and, | is the Boolean or
- operands:
- another expression;
- an EJBean field or
- when preceded by "$", a finder method parameter.
Examples
- Here is an expression that tests if balance > amount:
"(> balance $amount)"
- Compound expressions can be used; note use of single quotes (') to distinguish strings:
"(& (> bal $amount) (! (=
accountType 'checking')))"
- This example is a method signature and an expression that is
converted to a findBigAccounts
method in the generated persistent storage class. The method returns
an enumeration of beans of this class that satisfy this expression.
"findBigAccounts(double amount)"
"(> balance $amount)"
- Here is a method that finds all the EJBeans in a table:
"findAll()" "(= 1 1)"
- Here is a method that finds all EJBeans whose
lastName field
starts with "M":
"findNamesStartingWithM()" "(like lastName M%)"
- Here is a method that finds all EJBeans whose firstName
field is null (you can use isNotNull for the opposite):
"findNullFirstNames()" "(isNull firstName)"
- Here is a method that finds all EJBeans whose
balance field
is greater than balanceGreaterThan,
and returns the beans ordered by the
database column 'id'.
Notice that this should all be on one line, and that no
column mapping is performed -- the database column must be specified directly:
"findOrderedAccounts(double balanceGreaterThan)"
"(orderBy 'id' (> balance $balanceGreaterThan))"
- Identical to the previous, but returns the beans in descending order:
"findOrderedAccounts(double balanceGreaterThan)"
"(orderBy 'id desc' (> balance $balanceGreaterThan))"
Example: (from EJB Deployment Wizard)
This shows editing the expression for a finder "findBigAccounts".
Session-specific properties
Some properties are session bean-specific.
In the EJBean section:
- Stateful or stateless
(stateManagementType)
- This is the type of session EJBean; valid values are either
STATELESS_SESSION or STATEFUL_SESSION.
Timeout (sessionTimeout)
- The transaction timeout for container-managed transactions of this EJBean.
Note that by definition all session EJBeans cannot be reentrant and
the property Reentrant must be false.
In the Environment section:
- Stateful only
(persistentDirectoryRoot)
- The location for storing passivated stateful session beans
using file persistence.
In the Clustering section:
- Stateless
bean stub is clusterable (statelessBeanIsClusterable)
- Stateless
bean methods are idempotent
(statelessBeanMethodsAreIdempotent)
Reviewing the deployment descriptor settings
On this page, a list of all the deployment descriptor settings is
shown for your review.
Check that everything has been entered correctly before proceeding to
the next step of specifying the list of tasks to complete.
Specifying the tasks to complete
On this page you specify the tasks that you want the Wizard to complete.
There are three different tasks that the Wizard will perform:
- Update descriptor source
This will update the source of the deployment descriptor.
- Generate WebLogic interfaces for this bean
This will take all the files and generate the WebLogic interfaces for
this bean using the WebLogic EJB compiler ejbc. You need
to specify the destination directory for the interface class files;
typically, this is the point in your directory structure from where
you want to deploy your EJBean. If you specify "Keep generated
sources", the intermediate Java files generated by the compiler will
be retained.
- Create ASCII description file
You can also write out the deployment descriptor to an ASCII file.
This file can be input into the WebLogic EJB utility program DDCreator to create a serialized deployment descriptor.
Once you have specified the tasks, press Done to begin
processing of the tasks by the Wizard.
Completing tasks and deploying the EJBean
On this final page, the Wizard performs the tasks you specified in the
previous section. It will complete each task in order; the status for
each task is shown to the right of the task name.
Note: when you are done and all tasks have successfully
completed, you will still need to edit your weblogic.properties file to complete the deployment of
your EJBean.
If any task fails, the entire task list is canceled. If there are any
errors for a task, you can see messages and stack traces for that task
by selecting the name of the task and then clicking the Error tab. You
can then use the Back button to move to an earlier step, make
changes, and then try the task list again.
You can also cancel the task list by pressing the Cancel button
before the task list completes. Any changes to the deployment
descriptor will be discarded and the temporary files deleted. You can
then use the Back button to move to an earlier step, make
changes, and then redeploy the EJBean.
IV. Text file format and index
Format for text deployment descriptor files
An alternative method for creating deployment descriptors is to enter
the information into a text file and then use the WebLogic EJB utility DDCreator to
create a serialized deployment descriptor that's to be
included in the EJB-JAR (.jar) file. You specify that .jar file in the
weblogic.ejb.deploy property
in your weblogic.properties file.
You can use the textual description file to maintain a persistent form
of your EJB deployment information.
The format of the text file is a series of nested sections that list
the different properties that you are setting. A section begins with an
opening parenthesis and ends with a closing parenthesis. Comments may be
included in the text file; anything that appears after a
semicolon (";") on a line is considered a comment.
The properties that you can use depend on whether you are describing
an Entity EJBean or a Session EJBean. Examples for both entity and session beans are shown below.
- Comments are used to indicate the end of each section
- The examples show which sections are to be included
- At any level of nesting, the order of the sections doesn't matter
- Certain properties are included but have been commented out as not
applicable
- The start of each section is show in bold face
- An index of different properties is included
Entity Descriptor
(EntityDescriptor
; For entity EJBeans, this file
; must start with "(EntityDescriptor"
beanHomeName entity.AccountHome
enterpriseBeanClassName example.entity.AccountBean
homeInterfaceClassName example.entity.AccountHome
remoteInterfaceClassName example.entity.Account
isReentrant false
(accessControlEntries
DEFAULT [admin managers]
); end accessControlEntries
(controlDescriptors
(DEFAULT
isolationLevel TRANSACTION_SERIALIZABLE
transactionAttribute TX_REQUIRED
runAsMode CLIENT_IDENTITY
runAsIdentity admin
); end DEFAULT
); end controlDescriptors
(environmentProperties
; homeClassName
; ejbObjectClassName
maxBeansInFreePool 20
maxBeansInCache 100
idleTimeoutSeconds 10
isModifiedMethodName isModified
(finderDescriptors
"findBigAccounts(double amount)" "> balance $amount"
); end finderDescriptors
(clusterProperties
; Cluster-specific environment properties
homeIsClusterable true
; homeLoadAlgorithm
statelessBeanIsClusterable true
statelessBeanMethodsAreIdempotent false
); end clusterProperties
(persistentStoreProperties
persistentStoreType jdbc
(jdbc
tableName ejbAccounts
dbIsShared false
poolName ejbPool
(attributeMap
; EJBean field Database column name
; -----------------------------------------
accountId id
balance bal
); end attributeMap
); end jdbc
); end persistentStoreProperties
); end environmentProperties
; Entity EJBean-specific properties:
primaryKeyClassName example.entity.AccountPK
containerManagedFields [accountId balance]
; end entity EJBean-specific properties
); end EntityDescriptor
Session Descriptor
(SessionDescriptor
; For session EJBeans, this file
; must start with "(SessionDescriptor"
beanHomeName session.TraderHome
enterpriseBeanClassName example.session.TraderBean
homeInterfaceClassName example.session.TraderHome
remoteInterfaceClassName example.session.Trader
isReentrant false
; Session EJBean-specific properties:
stateManagementType STATEFUL_SESSION
sessionTimeout 5; seconds
; end session EJBean-specific properties
(accessControlEntries
DEFAULT [admin traderAdmin]
); end accessControlEntries
(controlDescriptors
(DEFAULT
isolationLevel TRANSACTION_SERIALIZABLE
transactionAttribute TX_REQUIRED
runAsMode CLIENT_IDENTITY
runAsIdentity traderAdmin
); end DEFAULT
(buy
isolationLevel TRANSACTION_SERIALIZABLE
transactionAttribute TX_REQUIRED
runAsMode CLIENT_IDENTITY
); end buy
); end controlDescriptors
(environmentProperties
(clusterProperties
; Cluster-specific environment properties
homeIsClusterable true
; homeLoadAlgorithm
; statelessBeanIsClusterable true
; statelessBeanMethodsAreIdempotent false
); end clusterProperties
; Application-specific environment properties
(StockPrices
; Stock prices is a nested hash table
WEBL 10.0
INTL 15.0
); end Stock Prices
tradeLimit 500
; end Application-specific environment properties
; homeClassName
; ejbObjectClassName
maxBeansInFreePool 100
maxBeansInCache 100
idleTimeoutSeconds 5
persistentDirectoryRoot c:\mystore
); end environmentProperties
); end SessionDescriptor
Index of deployment descriptor properties
V. Change history
- Release 4.0.3
-
We have added a new Deployment Descriptor environmental property called
"delayUpdatesUntilEndOfTx". This optional optimization affects when changes
to a bean's state are propogated to the persistent store. If the property
is set to "true" (the default), updates of the persistent store of
all beans in the transaction will be performed at the end of the
transaction. If this is set to "false", the update of a bean's persistent store will be
performed at the conclusion of each method invoke.
Previously, this optimization was enabled automatically which can
cause problems in applications that utilize integrity constraints
on the underlying database tables.
-
Fixed a problem with EJB Deployment Wizard passing the classpath to the EJB compiler.
-
Fixed a problem when the EJB Deployment Wizard opened a corrupted preferences file.
-
Fixed a problem with our extensions to the standard DeploymentDescriptors not implementing
equals() correctly.
-
Added a note to this document that if you use a
non-primitive data type in a finder descriptor,
you need to use a fully qualified name, such as
java.sql.Timestamp.
- Release 4.0
- Help is now available from within the deployment wizard
by selecting "Help ¬ Using the Deployment Wizard".
- The user interface has been simplified with new icons
and displays.
- A new option has been added under the "options" menu
allowing you to specify colors used for display of selected
information.
- Clustering features can be specified.
- New finder operators are documented.
- Release 3.1.1
- The behavior of the ejbc compiler has changed; if given a jar
file, it will now unpack the jar file automatically.
-
Added caching for opened wizards to improve initialization
performance on subsequent uses.
-
Added support for storing filenames of loaded deployment descriptors
and other GUI-related startup information in the .ini file.
-
Added support to write out PersistenceDescriptor info to ASCII
description file.
-
Set FieldTable to get reflection information about the bean's
dependent class from the deployment descriptor.
- Release 3.1
- Fixed problems related to ObjectStorage configuration.
- Fixed problems with loading and configuring .ser
files.
- Added support for reverting the deployment descriptor's
state when cancelled.
|