Using WebLogic Enterprise JavaBeans
The icons link to the glossary entry for the word preceding the icon.
I. IntroductionOverview of WebLogic Enterprise JavaBeansWebLogic Enterprise JavaBeans (EJB) is one of the services that operate within WebLogic. As a service, it has access to all of the WebLogic facilities (like logging, instrumentation, and Workspaces), and like other WebLogic component-based services, it is an integrated part of WebLogic. The APIs for all of the WebLogic services and facilities share many common aspects that make building a complex networked application easier; your application may use several services, all of which can share access to objects and client resources. EJB offers another design choice -- along with JavaServer Pages (JSP), Java Message Service (JMS), Remote Method Invocation (RMI), Java Naming and Directory Interface (JNDI), WebLogic Events and WebLogic Beans -- for building distributed applications in WebLogic. This document covers aspects specific to writing applications with the EJB API. You should also read and be familiar with:
WebLogic Enterprise JavaBeans (EJB) is an implementation of the Enterprise JavaBeans specification (version 1.0) from JavaSoft and supports these EJB features:
Introduction to EJBWhat are Enterprise JavaBeans?The JavaSoft Enterprise JavaBeans (EJB) specification defines a component architecture for building distributed, object-oriented business applications in Java. The EJB architecture addresses the development, deployment, and runtime aspects of an enterprise application's lifecycle. An Enterprise JavaBean (EJBean) encapsulates business logic inside a component framework that manages the details of security, transaction, and state management. Low-level details such as multithreading, resource pooling, clustering, distributed naming, automatic persistence, remote invocation, transaction boundary management, and distributed transaction management are handled by the EJB "container." This built-in low-level support allows the EJB developer to focus on the business problem to be solved. An Enterprise JavaBean is, in essence, a transactional and secure RMI (or CORBA) object, some of whose runtime properties are specified at deployment time using special classes called "deployment descriptors." With the EJB model, you can write or buy business components (such as invoices, bank accounts and shipping routes) and, during deployment into a certain project, specify how the component should be used -- which users have access to which methods, whether the framework should automatically start a transaction or whether it should inherit the caller's transaction, and so on. In this scenario, an EJBean contains the business logic (methods) and the customization needed for a particular application (deployment descriptor), and the EJBean will run within any standard implementation of the EJB framework. The spirit of "write once, run anywhere" carries through into EJB: any vendor's EJB framework can run any third-party EJBeans to create an application. Nuances of the security mechanisms and specific distributed transaction monitors are entirely abstracted out of the application code (unless the bean author chooses to make such calls explicitly).
II. The WebLogic EJB APIWebLogic EJB API ReferenceThe EJB API reference is available via ftp from JavaSoft in the Enterprise JavaBeans specification (version 1.0).There are three packages shipped as part of WebLogic EJB:
WebLogic's implementation includes these utilities:
III. Implementing with WebLogic EJBBefore starting to write your own Enterprise JavaBeans, we highly recommend that you go through all of the example EJBeans included in the WebLogic distribution, compiling, installing and running them.There are three parts to using WebLogic EJB:
In this section, we'll cover the basics of developing, deploying and accessing EJBeans, along these topics:
Developing an Enterprise JavaBeanHere are the steps to developing an EJBean:
Step 1. Write or obtain an EJBeanThe EJB specification outlines the different responsibilities of the EJBean writer and EJB framework, and WebLogic EJB expects EJBeans to conform to those responsibilities. In writing your own EJBeans, pay careful attention to these responsibilities. Example EJBeans are included in the WebLogic distribution to demonstrate these relationships.A utility called ComplianceChecker is provided with WebLogic EJB to examine packaged EJBeans and determine if they follow specified relationships. Step 2. Create a serialized Deployment DescriptorThe Deployment Descriptor ties together the different classes and interfaces, and is used to build the code-generated class files. It also allows you to specify some aspects of the EJBean's deployment at runtime.The Deployment Descriptor is an instance of either a session descriptor or an entity descriptor, serialized and stored in a file. To facilitate the preparation of this file, WebLogic EJB includes a utility application DDCreator that takes a text file specification and creates the appropriate serialized deployment descriptor. Step 3. Package the EJBean components into a .jar file (optional)This is optional because if you are going to immediately deploy the EJBean, you can skip this step because you will need to do it again at the end of the deployment process.However, if you are going to send the EJBean to someone else for deployment, you can package the output of the previous steps into a .jar file and send it to them for deployment. Deploying Enterprise JavaBeans in WebLogicHere are the steps to deploying an EJBean, assuming you have completed the steps of the previous section:
Step 1. Set your CLASSPATH for your developmentWe cover this in our TechStart Guide Setting your development environment.Step 2. Adjust the serialized Deployment Descriptor (optional)Check the deployment descriptor and modify any of its properties for your particular deployment (if required). To do so, you can either use the WebLogic EJB Deployment Wizard or look at the text file that was used to generate the deployment descriptor.If you change any of the properties, you will need to create a new serialized deployment descriptor to replace the existing one packaged with the bean. Step 3. Generate the EJB container classes using ejbcGenerate the wrapper classes using the WebLogic EJB compiler (ejbc) with this command (typed on one line), referencing the serialized deployment descriptor:$ java weblogic.ejbc -d /weblogic/myserver/temp AccountBeanDD.ser or, if using a .jar file (type this command on one line): $ java weblogic.ejbc -d /weblogic/myserver/temp AccountBean.jarThis will create the appropriate files for the bean, and place them in a temporary directory, in this case /weblogic/myserver/temp. (The classes will have been passed through the RMI compiler automatically.) Step 4. Package the EJB components into a .jar file.Package the outputs of the previous steps -- the serialized Deployment Descriptor, the compiled files for the EJBean classes, all generated classes, and any additional required classes -- into a .jar file, using the Jar tool included in your Java JDK.The Enterprise JavaBeans specification (version 1.0) from JavaSoft describes in section 15.3: ejb-jar Manifest (page 116) how to construct the manifest file to be included in the .jar file. Sample manifests are included with each of the example EJBeans. A manifest file points to the serialized deployment descriptors that describes the EJBeans in the .jar file. Multiple beans may be packaged together, provided that there is a deployment descriptor for each one. It's a good idea to ship the text file used to create the deployment descriptor, in the event that at deployment, properties in the deployment descriptor need alteration. If there are multiple beans packaged together, there is a single manifest file that lists all the serialized deployment descriptors that are found in the .jar file. Note: If you are upgrading from an earlier version of WebLogic, you will need to re-run ejbc on any existing EJBeans to regenerate the wrapper classes so that they're compatible with the WebLogic Server version. The .jar file should be placed in a directory that's not on the CLASSPATH of your WebLogic Server. (Our examples use the /myserver directory for placing EJBeans.) Step 5. Deploy the EJBean in a WebLogic ServerDeploy the EJBean either by:
Note: Beginning with version 4.5.1, deploying an EJB using the .ser file in the weblogic.ejb.deploy property has been deprecated. Use .jars instead, even when using the Microsoft JDK for Java. If you are using EJBeans and the Microsoft SDK for Java, you will need to:
EJB and persistenceAn entity EJBean can save its state in any transactional or non-transactional persistent storage, or it can ask the framework to save its non-transient instance variables automatically. WebLogic EJB allows both choices -- even a mixture of the two. You can either manually control persistence, or use the automatic persistence available for entity beans. Persistence is controlled by specifying one or more environment properties in the deployment descriptor:
This fragment from a deployment descriptor specifies automatic saving using file persistence of an EJBean to a file in a directory "c:\myobjects": (environmentProperties (persistentStoreProperties persistentStoreType file persistentDirectoryRoot c:\myobjects ); end persistentStoreProperties ); end environmentProperties This fragment from a deployment descriptor specifies automatic saving using jdbc persistence of two attributes of an EJBean ("accountId", "balance") to a database table ("ejbAccounts") using a connection pool ("ejbPool"): (environmentProperties (persistentStoreProperties persistentStoreType jdbc (jdbc tableName ejbAccounts ; Ensure that table "ejbAccounts" is ; already created in the database using ; an appropriate SQL statement such as: ; "create table ejbAccounts (id varchar(15), bal float, type varchar(15))" ; Otherwise, a run-time exception will be thrown. dbIsShared false ; Either "true" or "false". ; If this is true, caching is turned off, because ; WebLogic knows it doesn't "own" the table. poolName ejbPool (attributeMap ; Maps the EJBean fields to database column names ; EJBean fields Database column name ; ----------------------------------------- accountId id balance bal ); end attributeMap ); end jdbc ); end persistentStoreProperties ); end environmentPropertiesNote that the connection pool must be established in the weblogic.properties file, and that the table and columns must already exist in the database before the EJBean is called. EJB and findersIf you are using container-managed JDBC persistence, you can specify finder methods of the form findMethod() to find either an individual or collection of EJBeans.If you need to do complicated SQL lookups -- such a dynamically set 'where' clause -- you will not be able to do that with the current syntax provided for container-managed persistence. Instead, you will need to use bean-managed persistence, which allows you to write custom finders. You specify a method signature in the EJBHome interface for the EJBean and specify the method's expressions in the deployment descriptor using a custom syntax. You use method parameters and EJBean attributes in the expressions; the EJB container will automatically map the attributes to the appropriate columns in the persistent store. The EJBean compiler follows the syntax to generate code that automatically does the lookup in the JDBC persistent store. Here is an interface for the findAccount method from the container-managed JDBC persistence example: public interface AccountHome extends EJBHome { // ... public Account findAccount(double balanceEqual) throws FinderException, RemoteException; // ... } Here is an interface for the findBigAccounts method from the container-managed JDBC persistence example: public interface AccountHome extends EJBHome { // ... public Enumeration findBigAccounts(double balanceGreaterThan) throws FinderException, RemoteException; // ... }The expression defined in the deployment descriptor for this finder could be: (> balance $balanceGreaterThan)where balance is an attribute (field) of the EJBean and $balanceGreaterThan is the symbol for the method parameter balanceGreaterThan. A call in the client such as myEJBean.findBigAccounts(amount) will return an list of all EJBeans whose balance attribute is greater than the value of amount. Details of using finders are described in Using the WebLogic EJB Deployment Wizard: JDBC Finders (finderDescriptors). An example using a finder is the containerManaged example. EJB and transactionsNote that in all cases, transactions must be restricted to a single persistent store. You can't, for instance, mix JDBC persistence from two different sources in the same transaction, because JDBC 1.2 does not support the 2-phase commit protocol. A future version of JDBC may support this.Transaction isolation levelThe isolation level for transactions set in the control descriptor property of the Deployment Descriptor is passed to the underlying database. The behavior of an EJBean depends on the isolation level passed and the concurrency control of the underlying persistent store.If you would like the behavior of previous versions of WebLogic EJB, you should use an isolation level consistent with the default isolation level for your installation. You should consult with your DBMS administrator for details. You should write your client following standard design principles for client-server systems, avoiding long updates and locking rows indefinitely. Special note for Oracle databases In particular, you should be aware that Oracle uses optimistic concurrency. As a consequence, even with a setting of TRANSACTION_SERIALIZABLE, it does not detect serialization problems until commit time. The message returned is: java.sql.SQLException: ORA-08177: can't serialize access for this transactionEven if you use TRANSACTION_SERIALIZABLE, you will get exceptions and rollbacks in the client if contention occurs between clients for the same rows. You will need to write your client to catch any SQL exceptions that occur, examine them and take appropriate action, such as attempting the transaction again. Multiple EJBeans in a single manual transactionIn this first code fragment, a client calls two different beans, and shows what is required to begin and commit a transaction. The transactionAttribute property in the bean's deployment descriptor has been set to TX_REQUIRED:import javax.ejb.*; import javax.naming.*; import javax.jts.*; // To begin a transaction, // get a UserTransaction object from JNDI UserTransaction u = null; // First, get initial jndi context jndiContext = .... ; // Then, get a reference to a UserTransaction object u = (UserTransaction) jndiContext.lookup("javax.jts.UserTransaction"); u.begin(); // make EJB calls account1.withdraw(100); account2.deposit(100); u.commit(); // or u.rollback. To the client, the transaction is bracketed across two separate calls to two different EJ beans. Multiple EJBeans in automatic transactionsIn this second code fragment, we'll let WebLogic EJB generate transactions. The transactionAttribute property in the bean's deployment descriptor can be set to either TX_REQUIRED or TX_REQUIRES_NEW:// make EJB calls account1.withdraw(100); account2.deposit(100);In this case, each method call is automatically in its own transaction. Encapsulating a multi-operation transactionA third possibility is to use a "wrapper" EJBean that encapsulates a transaction. The client would call the wrapper EJBean to perform an action such as a bank transfer. The wrapper EJBean would respond by starting a new transaction that depended on the successful completion of both an increment of one account and the decrement of another before committing.To the client, this would appear as a single operation, conducted as a single transaction; to the wrapper EJBean, it would appear as two separate operations that are bracketed by a transaction. This would be a matter of taking the first case above and turning it into a session EJBean. Further information on transactions can be found in the packages javax.jts and javax.ejb.deployment. Pooling and instantiating EJBeans on the serverWebLogic EJB uses both a free pool and a cache of bean instances to improve performance and throughput.Free poolThe free pool contains instantiated (but uninitialized or referenced) instances of a bean class. Having beans in the free pool allows the Server to quickly allocate a bean with values when required instead of having to both create the object and set its attributes.The pool size starts at zero and grows as needed up to the maximum size specified in the deployment descriptor by the maxBeansInFreePool property. EJBean cacheReferenced EJBeans are stored in a cache.The size of the cache is set by the maxBeansInCache property which is the maximum number of objects (active plus inactive) of this class that are allowed in memory. Active objects are beans that are in use by a client in a transaction; inactive objects are beans that are either not in a transaction nor currently engaged in a method call, but have not yet timed out. Once a bean has timed out, it may be passivated. The timeout is based on the idleTimeoutSeconds setting in the deployment descriptor. If the maxBeansInCache limit is reached, and all beans are active, the next call for a new bean will get a CacheFullException. If some beans are inactive, they may be passivated before the idle time out is reached in order to fulfill the request for a new bean. For stateful session beans and entity EJBeansWhen the server starts, the pool is empty. When clients lookup and obtain a reference to an EJBean, new instances are created, but with only one instance per primary key. (Stateful session beans have an implicit primary key.) This means:
For stateless session beansFor stateless session beans there are, of course, no primary keys. The EJBean is returned to the pool as soon as the invocation is complete -- not when the references are freed. Hence each client accesses its own instance of the EJBean and the instance may be different from invocation to invocation.EJB and JDBCSetting up a server-side connection pool for EJBWhen writing EJBeans that use bean-managed persistence and JDBC, you will need to be familiar with WebLogic JDBC server-side connection pools. WebLogic's JDBC pool drivers give server-side Java programs, including EJBeans, access to connection pools on the WebLogic Server.Using a connection pool means that databases can be changed by editing entries in the WebLogic properties file and that you do not need to know in advance which database your EJB will use. The driver only works with server-side Java classes running on the same WebLogic Server with which the connection pool was registered. A WebLogic JDBC connection pool provides a pool of JDBC connections that are created when the WebLogic Server is started up. Then, when an authorized user needs a connection to a database, the user requests and uses an already existing connection from the pool, rather than creating a direct, specific connection to the database. You can configure a pool to set:
When a user calls close() on a pool connection, it is merely returned to the pool. Connection pools, because they're efficient and configurable, provide performance benefits, and they also allow you to manage database connections within your application. For more information on connection pools, read Using connection pools in the WebLogic JDBC Developers Guide. WebLogic has special server-side pool drivers that allow you to set up connection pools for objects that operate within WebLogic, rather than within a WebLogic client. One of the server-side pool drivers is a JTS-based driver that understands how to handle EJB-related requests. Because EJBeans are essentially contained within the WebLogic Server's VM, you do not need a multitier connection. There are several pieces of information that you will use, either in your source code or in the deployment descriptor, and in the weblogic.properties file. You will need to know:
Configuring the pool in the weblogic.properties fileHere is an example of a registration that sets up a connection pool named "ejbPool" for a Cloudscape database. (This pool registration is shipped commented out in the properties file packaged with the distribution.) To use this pool, just change the database- and user-specific information to match your environment. weblogic.jdbc.connectionPool.ejbPool=\ url=jdbc:cloudscape:ejbdemo,\ driver=COM.cloudscape.core.JDBCDriver,\ loginDelaySecs=1,\ initialCapacity=2,\ maxCapacity=2,\ capacityIncrement=1,\ props=user=none;password=none;server=none weblogic.allow.reserve.weblogic.jdbc.connectionPool.ejbPool=\ guest,joe,jill The "weblogic.allow" entry is the access control list for the "ejbPool" connection pool. It lists those T3Users that are allowed access to the connections in the pool. Each user in the list should be registered with a password in the properties file. Read more about setting up usernames, passwords, and access control lists in the WebLogic Administrator Guide document, Setting WebLogic properties. Using the pool in your EJBeanIn your EJBean's source code, or optionally in the deployment descriptor where you can use a named environment property to retrieve the information, you will set up the JTS-pool-related information, the name of the table for EJB data, and optionally other database-related information. Here is an example of how you might use a connection pool in your EJBean. Here we have hard-coded the driver URL ("jdbc:weblogic:jts") and package name ("weblogic.jdbc.jts.Driver") as well as the table name ("tradingorders"), directly into the source code. We have set up environment properties in the deployment descriptor for the "jdbc" properties, which includes a sub-property "poolName" set as "ejbPool", the name of a connection pool we have set up in the weblogic.properties file. We pass the pool name as part of the driver URL ("jdbc:weblogic:jts:poolName"). You can place all such information directly in the source, or make it all environment variables, depending on your application. Class.forName("weblogic.jdbc.jts.Driver").newInstance(); Connection con = DriverManager.getConnection("jdbc:weblogic:jts:ejbPool"); Statement stmt = con.createStatement(); str = "insert into tradingorders " + "(traderName, account, stockSymbol, shares, price)" + " VALUES (" + "'" + traderName + "'" + "," + "'" + customerName + "'" + "," + "'" + stockSymbol + "'" + "," + shares + "," + price + ")"; stmt.executeUpdate(str); For more on using server-side connection pools, read the Developers Guide Using WebLogic HTTP Servlets: Using connection pools with server-side Java. Using EJB with the JDBC-ODBC bridgeUsing the JDBC-ODBC bridge -- for example, to access a Microsoft Access database with Enterprise JavaBeans -- is not supported.Because the JDBC-ODBC bridge is not thread-safe, it can interfere with the operation of the Server. EJB and securityThis is a summary on implementing security with WebLogic EJBeans. For more information on security, read the Developers Guide Using WebLogic ACLs (Access Control Lists).WebLogic security has the notion of "groups" which can contain "users" or other groups. Users can belong to multiple groups. Users have a name and a credential (a certificate or a password). WebLogic works with different security domains (also called "realms"). Examples are NT realm, NIS realm, UNIX realm. Each of these realms can validate a given username/credential combination. WebLogic allows custom realms to be plugged in, and defaults to the "weblogic realm", which uses user names and passwords defined in the weblogic.properties file. For information on custom realms, see Using WebLogic ACLs: Customizing the WebLogic realm with user-defined ACLs. For information on setting up users and groups, see Using WebLogic ACLs: Setting up ACLs in the WebLogic realm. As per the JavaSoft EJB specification, in EJB you should not define a single user for access control; instead, you should use a role. Roles map directly to groups. You can then change the users in the ACL (by changing the membership of the group) without having to recompile your EJBean. In the deployment descriptor, in the access control properties, you can configure access control, in this case using groups "administrator" and "managers": (accessControlEntries DEFAULT [administrator managers] ; applies to the entire bean unless overridden ; by a method-specific access control entry buy [managers] ; override for method buy "sell(int)" [managers] "sell(int, double)" [managers] ; To distinguish between two methods with the same name ; and differing signatures, specify the signature )On the client side, you specify the user and credentials (in this case, the password) while logging into JNDI. Your permissions would be determined by the group that you belong to. static public Context getInitialContext() throws Exception { Properties p = new Properties(); p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.T3InitialContextFactory"); p.put(Context.PROVIDER_URL, url); if (user != null) { System.out.println ("user: " + user); p.put(Context.SECURITY_PRINCIPAL, user); } if (password != null) { p.put(Context.SECURITY_CREDENTIALS, password); } return new InitialContext(p); } In summary:
Retrieving EJBean properties at runtimeAt runtime, you can retrieve values from the deployment descriptor of an EJBean. This is very useful for initializing values. Here is a fragment of environment properties from a deployment descriptor:(environmentProperties (StockPrices ;StockPrices is a nested hash table WEBL 100.0 INTL 150.0 ); end StockPrices ); end environmentPropertiesYou can retrieve the value of the stock prices at runtime by using: Properties props = context.getEnvironment(); stockPrices = (Hashtable) props.get("StockPrices");You can retrieve all the properties (environment and otherwise) using an Enumeration: public void propertyTest() { Properties props = context.getEnvironment(); Enumeration enum = props.elements(); while (enum.hasMoreElements()) { System.out.println("Property: " + enum.nextElement()); } }The output would look like this: Property: {findBigAccounts(double amount)=(> balance $amount)} Property: isModified Property: {jdbc={tableName=ejbAccounts, attributeMap={testInteger=testint, balance=bal, accountId=id}, dbIsShared=false, poolName=ejbPool}, persistentStoreType=jdbc}Additional information on environment properties, WebLogic-specific properties and their use can be found in Using the WebLogic EJB Deployment Wizard: Environment (environmentProperties). This section covers the utilities supplied with WebLogic EJB to help you in development and deployment:
ejbc: the EJB compilerFor each deployment descriptor either specified in the command line or present in a .jar file, weblogic.ejbc creates wrapper classes for the corresponding EJBean class. It then runs these through the RMI compiler, which generates a client-side stub and a server-side skeleton. These files are not inserted back into the .jar file. They are left under the directory specified by the -d option. By default, ejbc uses javac as a compiler. For faster performance, specify a different compiler (such as Symantec's sj) using the -compiler flag. Running WebLogic under Microsoft SDK for JavaIf you are going to run WebLogic under Microsoft SDK for Java and use EJBeans, you need to be aware that Microsoft SDK for Java serializes objects in a manner that is different from what other JVMs expect, and which causes serialization problems when using EJBeans. It means that you must use JView instead of Java when running any EJB utilities such as DDCreator or the EJB compiler (ejbc) if you intend to run WebLogic under Microsoft SDK for Java and use EJBeans. See the example EJBeans build script (using the -ms option) that demonstrates this. Syntax$ java weblogic.ejbc options .jar or .ser Arguments
Additional options are available; use the -help option for a list. Examples(To be entered each on a single line)
$ java weblogic.ejbc AccountBeanDD.ser $ java weblogic.ejbc -classpath %CLASSPATH% -compiler c:\VisualCafedbDE\Bin\sj.exe -d c:\weblogic\classes Account.jar DDCreator: Deployment descriptor generatorGiven a text description of the deployment descriptor, DDCreator generates a serialized EntityDescriptor or SessionDescriptor. The example EJB deployment descriptor template created by the -example flag contains extensive comments describing the different options for setting up a deployment descriptor. Also, each deployment descriptor included with the example EJBeans included in the WebLogic distribution contains comments explaining the different parts of a deployment descriptor. See these examples and their deployment descriptors for additional information. Running WebLogic under Microsoft SDK for JavaIf you are going to run WebLogic under Microsoft SDK for Java and use EJBeans, you need to be aware that Microsoft SDK for Java serializes objects in a manner that is different from what other JVMs expect, and which causes serialization problems when using EJBeans. It means that you must use JView instead of Java when running any EJB utilities such as DDCreator or the EJB compiler (ejbc) if you intend to run WebLogic under Microsoft SDK for Java and use EJBeans. See the example EJBeans build script (using the -ms option) that demonstrates this. Syntax$ java weblogic.ejb.utils.DDCreator options textfile Arguments
Example
$ java weblogic.ejb.utils.DDCreator -example > myBeanDD.txt
(For an example, see the file DeploymentDescriptor.txt in examples/ejb/beanManaged/deployment)
$ java weblogic.ejb.utils.DDCreator myBeanDD.txt If your deployment descriptor describes an EJBean myBean, DDCreator will create the serialized deployment descriptor in a file myBeanDD.ser. ComplianceChecker: EJBean package checkerThe utility program weblogic.ejb.utils.ComplianceChecker inspects a packaged EJBean and determines if it follows specified relationships. The utility outputs to stdout. Syntax$ java weblogic.ejb.utils.ComplianceChecker .jar or .ser Arguments
Example
$ java weblogic.ejb.utils.ComplianceChecker beanManaged.jarIf the EJBean is correctly constructed, you will see a message such as: File is compliant with EJB 1.0If there is an error, you will see a message such as: File: statefulSession.jar ========================================================== Bean class: examples.ejb.statefulSession.server.TraderBean ---------------------------------------------------------- Session bean must have at least one valid create() method EJB Deployment WizardAn additional document describes the EJB Deployment Wizard for configuring and deploying EJBeans.
weblogic.jdbc.connectionPool.ejbPool=\ url=jdbc:weblogic:oracle,\ driver=weblogic.jdbc.oci.Driver,\ loginDelaySecs=1,\ initialCapacity=1,\ maxCapacity=10,\ capacityIncrement=2,\ props=user=SCOTT;password=tiger;server=demo weblogic.allow.reserve.weblogic.jdbc.connectionPool.ejbPool=\ guest
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|