EJB Container datasource problem

hi,
I'm working with websphere 5.
I create a EJB project with oracle 9i database, when i execute the
application and I want from my session bean to call a
findByPrimaryKey() method over my entity bean the WebSphere container load
the datasource (my database is configured as 'desa' ) and show me the
following error :
FreePool J2CA0046E: The method createManagedConnctionWithMCWrapper got a
excepci�n when create a ManagedConnection for resource jdbc/desa,
genering ResourceAllocationException.
Original excepci�n: com.ibm.ws.exception.WsException: DSRA8100E: Unable
to get a PooledConnection from the DataSource.
Nested exception is: javax.ejb.EJBException: nested exception is:
com.ibm.ws.ejbpersistence.utilpm.ResourceAdapterException: PMGR6020E:
Error when connect with
com.ibm.ws.rsadapter.cci.WSRdbConnectionFactoryImpl@1687178e adapterI defined my datasource on websphere with all required parameters. I don't
know what's can be happening.
sombody can help me ?
thanks

You can get further clue by seeing the original wrapped exception.
One reason you get this exception can be : your userid/password is not set correctly to logon to the database. Check the J2C authentification data you defined for this datasource. Also make sure the alias is indicated in the datasource's Container-managed Authentication Alias(EJB CMP's container authorization type == contaier) or Component-managed Authentication Alias (EJB CMP's container authorization type == per_connection_factory)

Similar Messages

  • Yet Another EJB/JBoss/Datasource problem

    This is my first try at creating an ejb. I got that working, and now i'm trying to hook the ejb to a database via a datasource. I know I'm just doing something stupid and missing a tag or an xml file of a java: or whatever. If you can find this probem, I'll be completely in your debt forever.
    I've googled and searched this form to death.
    Here're the relevant parts:
    META-INF\ejb-ref.xml
          <session>
             <description><![CDATA[Stuff]]></description>
             <display-name>Stuff</display-name>
             <ejb-name>NrcrCore</ejb-name>
             <home>my.ejb.NrcrCoreHome</home>
             <remote>my.ejb.NrcrCore</remote>
             <ejb-class>my.ejb.NrcrCoreBean</ejb-class>
             <session-type>Stateless</session-type>
             <transaction-type>Container</transaction-type>
         <resource-ref>
              <res-ref-name>nrcrds</res-ref-name>
              <res-type>javax.sql.Datasource</res-type>
              <res-auth>Container</res-auth>
         </resource-ref>
          </session>META-INF\jboss.xml
    <jboss>
      <enterprise-beans>
        <session>
          <ejb-name>NrcrCore</ejb-name>
          <jndi-name>nrcr/NrcrCore</jndi-name>
           <resource-ref>
              <res-ref-name>nrcrds</res-ref-name>
              <jndi-name>java:nrcrds</jndi-name>
         </resource-ref>
        </session>
      </enterprise-beans>
    </jboss>deploy\nrcr-ds.xml
    <datasources>
      <local-tx-datasource>
        <jndi-name>nrcrds</jndi-name>
        <connection-url>jdbc:jtds:sqlserver://myserver/nrcr;domain=isledev</connection-url>
        <driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>
        <user-name>nrcr</user-name>
        <password>mypass</password>
      </local-tx-datasource>
    </datasources>And the code to connect:
                try{
                     ctx = new InitialContext();
                     if(ctx == null )
                          throw new Exception("No Context Found");
                     ds = (DataSource)ctx.lookup("java:nrcrds");
                catch(Exception e) {
                     System.out.println(e);
                }If you can make this work, I'll be your best friend.

    I think it would be better if u develop ejb by using
    weblogic Server and X-Doclet tags. Then u don't need
    to think about the xml files and their hectic tags.You don't need weblogic server to use x-doclet. It can be done even on jboss. The xml files can be automatically generated with some tool/plugin available with popular IDEs.

  • Integration with Websphere 5.0 (EJB 2.0) problems

    Hello all,
    Although a bit new to JDO, I have been trying to integrate Kodo 2.4 with
    Websphere 5.0 (using EJB 2.0).
    I have been basically binding a PersistenceManagerFactory into JNDI via
    start-up servlet, however got the exception bellow when I tried to create
    PersistenceManagerFactory (in setSessionContext of the EJB).
    <i>JDOFatalInternalException: Could not perform automatic lookup of EJB
    container's javax.transaction.TransactionManager implementation. Please ensure
    that you are running the application from within an <b>EJB 1.1</b> compliant
    EJB container, and then set the
    com.solarmetric.kodo.ee.ManagedRuntimeProperties property to the appropriate
    value to obtain the TransactionManager.</i>
    The reference to EJB 1.1 actually scared me a bit. Does this imply that
    Kodo (2.4) does not support J2EE 1.3?
    Would you know how to set the
    com.solarmetric.kodo.ee.ManagedRuntimeProperties to make it work with WSAD
    5.0?
    Thank you,
    Petr

    Petr-
    Is the integration with Websphere 5.0 application server officially
    supported? Has anobody (that you know of) done it successfully yet?Yes, we do have reports of people using Kodo successfully from within
    Websphere. However, it should be noted that it is not as rigorously
    tested internally at SolarMetric as some other application servers (E.g.,
    JBoss and WebLogic). In short, integration is known to work, but it
    might be a little more rough around the edges than for other application
    servers (as shown in our misspelling of Websphere's TransactionManager
    implementation name).
    How do I tell Kodo to use existing Datasource managed by app server?You can have Kodo use a named DataSource by specifying the
    javax.jdo.option.ConnectionFactoryName property (see
    http://www.solarmetric.com/docs/2.4.0/docs/manual.html#javax.jdo.option.ConnectionFactoryName).
    This is often more appropriate for applications server usage, since it
    allows you to configure pooling and other information from within the
    application server's centralized configuration.
    javax.jdo.option.ConnectionDriverName=COM.ibm.db2.jdbc.app.DB2Driver
    javax.jdo.option.ConnectionURL=jdbc:db2:snetWhat kind of driver is COM.ibm.db2.jdbc.app.DB2Driver? The DB2
    configuration we use for testing with IBM's drivers is:
    javax.jdo.option.ConnectionDriverName=COM.ibm.db2.jdbc.net.DB2Driver
    javax.jdo.option.ConnectionURL=jdbc:db2://SERVER_NAME/DATABASE_NAME
    They shouldn't behave differently (I am guessing that the app driver is
    a type 2 driver or something), but it might be worth a shot to try using
    the net driver. If this fixes the problem, please let us know, because
    it will indicate that Kodo has a deficiency with one of IBM's drivers
    that we should look into resolving.
    Since I have been trying to integrate with App server, this is the
    initialization code that I use to bind PersistenceManagerFactory to JNDI.
    You may find some funny stuff there.The binding code looks fine, and you are obviously able to retrive the
    PM and start persistence operations. Note that you should also be able
    to deploy Kodo as a Resource Adapter (which allows Kodo configuration
    through the centralized Websphere configuration interface). However, I
    doubt this is part of the issue.
    So, in short, I recommend trying the following things:
    1. Using the ConnectionFactoryName to use the DataSource defined for the
    appserver, on the off chance this will fix it.
    2. Using the net driver instead of the app driver.
    3. Seeing if it will work with javax.jdo.option.Optimistic set to false
    If none of these work, please let us know, and we will continue to
    investigate other possible solutions.
    In article <[email protected]>, Petr Bulanek wrote:
    Hello Marc,
    Very good guess. Pretty much the same code worked well without App server.
    In that case, there obviously was no magic related to
    TransactionManagerFactory initialization (see bellow).
    Is the integration with Websphere 5.0 application server officially
    supported? Has anobody (that you know of) done it successfully yet?
    How do I tell Kodo to use existing Datasource managed by app server?
    Here is the basic configuration (URL, class, etc):
    javax.jdo.PersistenceManagerFactoryClass=com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory
    javax.jdo.option.ConnectionDriverName=COM.ibm.db2.jdbc.app.DB2Driver
    javax.jdo.option.ConnectionURL=jdbc:db2:snet
    javax.jdo.option.Optimistic=true
    javax.jdo.option.RetainValues=true
    javax.jdo.option.NontransactionalRead=true
    We use DB2 Version 7.2/Version 7.1 FixPak 3 for Windows, in case it helps.
    Since I have been trying to integrate with App server, this is the
    initialization code that I use to bind PersistenceManagerFactory to JNDI.
    You may find some funny stuff there.
    The new EESimpleConfiguration(true) construct seems to (by default) read
    the kodo.properties file that is part of the project.
    EEConfiguration conf = new EESimpleConfiguration(true);
    conf.setManagedRuntimeProperties(\"TransactionManagerMethod=com.ibm.ejs.jts.jta.TransactionManagerFactory.getTransactionManager\");
    conf.setManagedRuntimeClass(\"com.solarmetric.kodo.ee.InvocationManagedRuntime\");
    EEPersistenceManagerFactory pmf =
                        new EEPersistenceManagerFactory(conf);
    InitialContext ic = new InitialContext();
    ic.rebind(\"KodoPMF\", pmf);
    Thank you,
    Petr
    Marc Prud\'hommeaux wrote:
    Petr-
    It looks like DB2 doesn\'t like our attempt to close the connection
    without a rollback or commit. This is odd, since we have never
    seen this happen in our stand-alone DB2 tests. Can you let us know
    the connection details (driver, connectionURL, etc)?
    In the meantime, one possible workaround may be to turn off
    optimistic transactions (since this will cause the PM to
    only use a single Connection); can you try to specify:
    javax.jdo.option.Optimistic=false
    Also, have you tried to run this code in a non-managed environment
    (e.g., outside the application server)? I would be interested
    to know if it is related to running within an appserver.
    In article <[email protected]>, Petr Bulanek wrote:
    Hi Abe,
    Thank you for a speedo reply. You guys really are on the ball!!!
    As you suggested, the
    \\\'com.ibm.ejs.jts.jta.TransactionManagerFactory.getTransactionManager\\\'
    did the job (for others, please note that the proper package name should
    contain \\\'jts.jta\\\', not \\\'jts.jts\\\').
    Unfortunately, I got another problem. When running a method containing
    query (code bellow),
    I get SQLException complaining about \\\'Invalid transaction state\\\'.
    The method that executes the query is a stateless transactional Session
    bean.
    Thank you for your help,
    Petr
    --------------------------- DB2 - transaction state description
    CLI0116E Invalid transaction state.
    Explanation: There was a transaction in progress when SQLDisconnect was
    called.
    User Response: Call SQLTransact before calling SQLDisconnect.
    --------------------------- Exception ------------------------------------
    [2/01/03 16:34:19:050 EST] 563ddb8a SQL I
    com.solarmetric.kodo.impl.jdbc.SQL [ C:336042896; T:1446894474;
    D:118283149 ] preparing statement <369367952>: SELECT DISTINCT
    PARENTX.JDOCLASSX FROM PARENTX
    [2/01/03 16:34:19:050 EST] 563ddb8a SQL I
    com.solarmetric.kodo.impl.jdbc.SQL [ C:336042896; T:1446894474;
    D:118283149 ] executing statement <369367952>: [reused=1;params={}]
    [2/01/03 16:34:19:061 EST] 563ddb8a JDBC I
    com.solarmetric.kodo.impl.jdbc.JDBC [ C:336042896; T:1446894474;
    D:118283149 ] close:
    com.solarmetric.datasource.PoolConnection@14079b90[[requests=6;size=6;max=70;hits=0;created=6;redundant=0;overflow=0;new=6;leaked=0;unavailable=0]]
    [2/01/03 16:34:19:061 EST] 563ddb8a JDBC I
    com.solarmetric.kodo.impl.jdbc.JDBC [ C:336042896; T:1446894474;
    D:118283149 ] close connection
    [2/01/03 16:34:19:061 EST] 563ddb8a JDBC W
    com.solarmetric.kodo.impl.jdbc.JDBC [ C:null; T:1446894474; D:118283149 ]
    exception when closing connection
    [2/01/03 16:34:19:541 EST] 563ddb8a JDBC W
    com.solarmetric.kodo.impl.jdbc.JDBC TRAS0014I: The following exception
    was logged COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0116E
    Invalid transaction state. SQLSTATE=25000
    atcom.solarmetric.datasource.ConnectionWrapper.close(ConnectionWrapper.java:243)
    atcom.solarmetric.datasource.DataSourceImpl$AbstractPool.close(DataSourceImpl.java:690)
    atcom.solarmetric.datasource.DataSourceImpl.close(DataSourceImpl.java:373)
    atcom.solarmetric.datasource.DataSourceImpl.close(DataSourceImpl.java:347)
    at com.solarmetric.datasource.PoolConnection.close(PoolConnection.java:70)
    atcom.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.close(SQLExecutionManagerImpl.java:885)
    atcom.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.release(JDBCStoreManager.java:654)
    atcom.solarmetric.kodo.impl.jdbc.ormapping.SubclassProviderImpl.getSubclasses(SubclassProviderImpl.java:274)
    atcom.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.addSubclassConditions(ClassMapping.java:1239)
    atcom.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.selectPrimaryMappings(ClassMapping.java:1218)
    atcom.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.executeQuery(JDBCStoreManager.java:717)
    atcom.solarmetric.kodo.impl.jdbc.runtime.JDBCQuery.executeQuery(JDBCQuery.java:92)
    at com.solarmetric.kodo.query.QueryImpl.executeWithMap(QueryImpl.java:792)
    atcom.solarmetric.kodo.query.QueryImpl.executeWithArray(QueryImpl.java:668)
    at com.solarmetric.kodo.query.QueryImpl.execute(QueryImpl.java:609)
    at com.testkodo.ejb.ControllerBean.observeHumans(ControllerBean.java:66)
    --------------------------- Failing code sample
    try {
                   PersistenceManager pm = factory.getPersistenceManager();
                   Extent ex = pm.getExtent(Parent.class, false);
                   Query q = pm.newQuery(ex, \\\"name==parName\\\");
                   q.declareParameters(\\\"String parName\\\");
                   Collection col = (Collection) q.execute(\\\"James\\\");
                   Iterator iter = col.iterator();
                   Parent pp;
                   Collection ch;
                   while (iter.hasNext()) {
                        pp = (Parent) iter.next();
                        System.out.println(pp);
                        ch = pp.getChildren();
                        Iterator it= ch.iterator();
                        while (it.hasNext()) {
                             System.out.println(it.next());
                   q.closeAll();
                   pm.close();
              } catch (Exception e) {
                   System.out.println(e);
                   throw new EJBException(e);
    Abe White wrote:
    The reference to EJB 1.1 actually scared me a bit. Does this imply that
    Kodo (2.4) does not support J2EE 1.3?
    EJB 2.0 is also supported. Sorry for the confusing error message.
    Would you know how to set the
    com.solarmetric.kodo.ee.ManagedRuntimeProperties to make it work with
    WSAD
    5.0?
    Try these settings:
    com.solarmetric.kodo.ee.ManagedRuntimeClass=\\\\
         com.solarmetric.kodo.ee.InvocationManagedRuntime
    com.solarmetric.kodo.ee.ManagedRuntimeProperties=\\\\
         TransactionManagerMethod=\\\\
         com.ibm.ejs.jts.jts.TransactionManagerFactory.getTransactionManager
    Marc Prud\'hommeaux [email protected]
    SolarMetric Inc. http://www.solarmetric.com

  • Error at SJSAS-8_1(XP Pro SP2) startup:Can't create EJB Container

    Hi Guys,
    I installed Sun Java System App Server v.8 update 1 on my XP Pro(SP2) machine.
    Here are the particulars:
    Install Dir : C:\Sun\AppServer
    Java Version : 1.4.2_04
    J2EE_HOME: Set to Install Dir
    JAVA_HOME:C:\j2sdk1.4.2_04
    PATH : Includes [Install Dir] \ bin
    Here is the problem(On the very first run,I verified):
    -----------------------------------------------SNIP--------------------------------------------------------------------------------
    [#|2004-11-15T03:26:52.812+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|CORE5100:Loading system apps|#]
    [#|2004-11-15T03:26:53.343+0530|SEVERE|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.ejb|_ThreadID=10;|EJB5090: Exception in creating EJB container [java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.enterprise.management.agent._MEJB_Stub]|#]
    [#|2004-11-15T03:26:53.359+0530|SEVERE|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.ejb|_ThreadID=10;|appId=MEjbApp moduleName=mejb_jar ejbName=MEJBBean|#]
    [#|2004-11-15T03:26:53.359+0530|SEVERE|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.classloading|_ThreadID=10;|LDR5004: UnExpected error occured while creating ejb container
    java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.enterprise.management.agent._MEJB_Stub
         at com.sun.enterprise.iiop.POARemoteReferenceFactory.<init>(POARemoteReferenceFactory.java:150)
         at com.sun.enterprise.iiop.POAProtocolMgr.getRemoteReferenceFactory(POAProtocolMgr.java:117)
         at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:290)
         at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:135)
         at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:191)
         at com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:477)
         at com.sun.enterprise.server.ApplicationLoader.load(ApplicationLoader.java:125)
         at com.sun.enterprise.server.TomcatApplicationLoader.load(TomcatApplicationLoader.java:96)
         at com.sun.enterprise.server.AbstractManager.loadSystem(AbstractManager.java:265)
         at com.sun.enterprise.server.SystemAppLifecycle.loadSystemApps(SystemAppLifecycle.java:133)
         at com.sun.enterprise.server.SystemAppLifecycle.onStartup(SystemAppLifecycle.java:74)
         at com.sun.enterprise.server.ApplicationServer.onStartup(ApplicationServer.java:295)
         at com.sun.enterprise.server.PEMain.run(PEMain.java:220)
         at com.sun.enterprise.server.PEMain.main(PEMain.java:172)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at org.apache.commons.launcher.ChildMain.run(ChildMain.java:269)
    Caused by: java.lang.ClassNotFoundException: com.sun.enterprise.management.agent._MEJB_Stub
         at com.sun.enterprise.loader.EJBClassLoader.findClass(EJBClassLoader.java:505)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
         at com.sun.enterprise.iiop.POARemoteReferenceFactory.<init>(POARemoteReferenceFactory.java:132)
         ... 18 more
    |#]
    [#|2004-11-15T03:26:53.359+0530|WARNING|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|CORE5021: Application NOT loaded: [MEjbApp]|#]
    ------------------------------------------------------SNIP--------------------------------------------------------------------
    The server starts up properly otherwise , i.e. , I came to see the problem only with
    a "--verbose" flag to "asadmin".There is no problem with the server startup, and I even
    tested the "Hello" app in quickstart folder successfully.I have not yet deployed any ejb sample.
    I have tried all that I could think of(ENV_VARIABLES,PATH,CLASSPATH etc.)
    I would appreciate it if someone can help me out on this.

    I tried uninstalling the app server and J2SE-1.4.2,and reinstalled the server with 1.4.2_04,again.
    Strangely enough it worked!
    Here is the log:
    ---------------------------------------server.log----------------------------------------------------------
    Starting Sun Java System Application Server Platform Edition 8.0.0_01 (build b08-fcs) ...
    [#|2004-11-16T13:42:54.703+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|CORE5076: Using [Java HotSpot(TM) Client VM, Version 1.4.2_04] from [Sun Microsystems Inc.]|#]
    [#|2004-11-16T13:42:56.437+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|ADM0020:Following is the information about the JMX MBeanServer used:|#]
    [#|2004-11-16T13:42:56.812+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|ADM0001:MBeanServer initialized successfully|#]
    [#|2004-11-16T13:42:59.687+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|Creating virtual server server|#]
    [#|2004-11-16T13:42:59.703+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|S1AS AVK Instrumentation disabled|#]
    [#|2004-11-16T13:42:59.734+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.security|_ThreadID=10;|SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.|#]
    [#|2004-11-16T13:43:06.468+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.transaction|_ThreadID=10;|JTS5014: Recoverable JTS instance, serverId = [100]|#]
    [#|2004-11-16T13:43:08.609+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|Satisfying Optional Packages dependencies...|#]
    [#|2004-11-16T13:43:09.031+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.resource.resourceadapter|_ThreadID=10;|RAR7008 : Initialized monitoring registry and listeners|#]
    [#|2004-11-16T13:43:10.203+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|CORE5100:Loading system apps|#]
    [#|2004-11-16T13:43:10.265+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|Selecting file [C:\Sun\AppServer\lib\install\applications\MEjbApp.ear] for autodeployment|#]
    [#|2004-11-16T13:43:10.265+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|Selecting file [C:\Sun\AppServer\lib\install\applications\__ejb_container_timer_app.ear] for autodeployment|#]
    [#|2004-11-16T13:43:10.265+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|[AutoDeploy] Selecting file [ C:\Sun\AppServer\lib\install\applications\MEjbApp.ear ] for autodeployment.|#]
    [#|2004-11-16T13:43:12.078+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|DPL5109: EJBC - START of EJBC for [MEjbApp]|#]
    [#|2004-11-16T13:43:12.093+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|Processing beans ...|#]
    [#|2004-11-16T13:43:12.125+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|Compiling RMI-IIOP code ...|#]
    [#|2004-11-16T13:43:23.093+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|DPL5110: EJBC - END of EJBC for [MEjbApp]|#]
    [#|2004-11-16T13:43:23.125+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.stream.out|_ThreadID=10;| role is admin-role class class java.lang.String|#]
    [#|2004-11-16T13:43:23.250+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.stream.out|_ThreadID=10;|
    role is admin-role class class java.lang.String|#]
    [#|2004-11-16T13:43:23.593+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|Total Deployment Time: 12859 msec, Total EJB Compiler Module Time: 11015 msec, Portion spent EJB Compiling: 85%
    Breakdown of EJBC Module Time: Total Time for EJBC: 11015 msec, CMP Generation: 0 msec (0%), Java Compilation: 0 msec (0%), RMI Compilation: 10968 msec (99%), JAX-RPC Generation: 16 msec (0%),
    |#]
    [#|2004-11-16T13:43:23.625+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|deployed with moduleid = MEjbApp|#]
    [#|2004-11-16T13:43:23.734+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|ADM1041:Sent the event to instance:[ApplicationDeployEvent -- deploy MEjbApp]|#]
    [#|2004-11-16T13:43:24.750+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.classloading|_ThreadID=10;|LDR5010: All ejb(s) of [MEjbApp] loaded successfully!|#]
    [#|2004-11-16T13:43:24.765+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|ADM1042:Status of dynamic reconfiguration event processing:[success]|#]
    [#|2004-11-16T13:43:24.781+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|[AutoDeploy] Successfully autodeployed : C:\Sun\AppServer\lib\install\applications\MEjbApp.ear.|#]
    [#|2004-11-16T13:43:24.781+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|[AutoDeploy] Selecting file [ C:\Sun\AppServer\lib\install\applications\__ejb_container_timer_app.ear ] for autodeployment.|#]
    [#|2004-11-16T13:43:25.484+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|DPL5109: EJBC - START of EJBC for [__ejb_container_timer_app]|#]
    [#|2004-11-16T13:43:30.281+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|Processing beans ...|#]
    [#|2004-11-16T13:43:30.281+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|DPL5110: EJBC - END of EJBC for [__ejb_container_timer_app]|#]
    [#|2004-11-16T13:43:30.453+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|Total Deployment Time: 5594 msec, Total EJB Compiler Module Time: 4797 msec, Portion spent EJB Compiling: 85%
    Breakdown of EJBC Module Time: Total Time for EJBC: 4797 msec, CMP Generation: 1563 msec (32%), Java Compilation: 3125 msec (65%), RMI Compilation: 0 msec (0%), JAX-RPC Generation: 0 msec (0%),
    |#]
    [#|2004-11-16T13:43:30.453+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.deployment|_ThreadID=10;|deployed with moduleid = __ejb_container_timer_app|#]
    [#|2004-11-16T13:43:30.515+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|ADM1041:Sent the event to instance:[ApplicationDeployEvent -- deploy __ejb_container_timer_app]|#]
    [#|2004-11-16T13:43:31.203+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.ejb|_ThreadID=10;|EJB5109:EJB Timer Service started successfully for datasource [jdbc/__TimerPool]|#]
    [#|2004-11-16T13:43:31.203+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.classloading|_ThreadID=10;|LDR5010: All ejb(s) of [__ejb_container_timer_app] loaded successfully!|#]
    [#|2004-11-16T13:43:31.203+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|ADM1042:Status of dynamic reconfiguration event processing:[success]|#]
    [#|2004-11-16T13:43:31.218+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|[AutoDeploy] Successfully autodeployed : C:\Sun\AppServer\lib\install\applications\__ejb_container_timer_app.ear.|#]
    [#|2004-11-16T13:43:31.234+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0302: Starting Tomcat.|#]
    [#|2004-11-16T13:43:31.515+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0100: Loading web module [adminapp] in virtual server [server] at [web1]|#]
    [#|2004-11-16T13:43:31.781+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0100: Loading web module [admingui] in virtual server [server] at [asadmin]|#]
    [#|2004-11-16T13:43:31.781+0530|WARNING|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0500: default-locale attribute of locale-charset-info element has been deprecated and is being ignored. Use default-charset attribute of parameter-encoding element instead|#]
    [#|2004-11-16T13:43:31.812+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0100: Loading web module [com_sun_web_ui] in virtual server [server] at [com_sun_web_ui]|#]
    [#|2004-11-16T13:43:31.843+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.catalina.startup.Embedded|_ThreadID=10;|Starting tomcat server|#]
    [#|2004-11-16T13:43:31.843+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.catalina.startup.Embedded|_ThreadID=10;|Catalina naming disabled|#]
    [#|2004-11-16T13:43:32.000+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.catalina.core.StandardEngine|_ThreadID=10;|Starting Servlet Engine: Sun-Java-System/Application-Server-PE-8.0|#]
    [#|2004-11-16T13:43:37.796+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.catalina.startup.ContextConfig|_ThreadID=10;|Missing application web.xml, using defaults only StandardEngine[server].StandardHost[server].StandardContext[]|#]
    [#|2004-11-16T13:43:40.828+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Initializing Coyote HTTP/1.1 on port 8080|#]
    [#|2004-11-16T13:43:40.890+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Starting Coyote HTTP/1.1 on port 8080|#]
    [#|2004-11-16T13:43:41.140+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Initializing Coyote HTTP/1.1 on port 1043|#]
    [#|2004-11-16T13:43:41.156+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Starting Coyote HTTP/1.1 on port 1043|#]
    [#|2004-11-16T13:43:41.234+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Initializing Coyote HTTP/1.1 on port 4848|#]
    [#|2004-11-16T13:43:41.250+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Starting Coyote HTTP/1.1 on port 4848|#]
    [#|2004-11-16T13:43:41.562+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.resource.jms|_ThreadID=10;|JMS5023: JMS service successfully started. Instance Name = imqbroker, Home = [C:\Sun\AppServer\imq\bin].|#]
    [#|2004-11-16T13:43:41.578+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|[AutoDeploy] Enabling AutoDeployment service at :1100592821578|#]
    [#|2004-11-16T13:43:41.578+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|CORE5053: Application onReady complete.|#]
    [#|2004-11-16T13:43:41.578+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|Application server startup complete.|#]
    [#|2004-11-16T13:47:06.859+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|sending notification to server...server|#]
    [#|2004-11-16T13:47:06.921+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=11;|WEB0303: Stopping Tomcat.|#]
    [#|2004-11-16T13:47:06.921+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=11;|Stoping http11 protocol on 8080 server:type=ThreadPool,name=http8080|#]
    [#|2004-11-16T13:47:06.984+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=11;|Stoping http11 protocol on 1043 server:type=ThreadPool,name=http1043|#]
    [#|2004-11-16T13:47:07.015+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=11;|Stoping http11 protocol on 4848 server:type=ThreadPool,name=http4848|#]
    [#|2004-11-16T13:47:07.203+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=11;|CORE5051: Shutting down all J2EE applications ...|#]
    [#|2004-11-16T13:47:07.234+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.ejb|_ThreadID=11;|EJB5122:EJB Timer Service shutdown at [2004/11/16 13:47:07]|#]
    [#|2004-11-16T13:47:07.234+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=11;|CORE5052: Application shutdown complete.|#]
    [#|2004-11-16T13:47:07.250+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=11;|[AutoDeploy] Disabling AutoDeployment service.|#]
    [#|2004-11-16T13:47:07.250+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.resource.jms|_ThreadID=11;|JMS5025: JMS service shutting down.|#]
    [#|2004-11-16T13:47:07.656+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.resource.jms|_ThreadID=11;|JMS5026: JMS service shutdown complete.|#]
    [#|2004-11-16T13:47:08.328+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|Server shutdown complete.|#]
    [#|2004-11-16T13:53:39.500+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|CORE5076: Using [Java HotSpot(TM) Client VM, Version 1.4.2_04] from [Sun Microsystems Inc.]|#]
    [#|2004-11-16T13:53:41.984+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|ADM0020:Following is the information about the JMX MBeanServer used:|#]
    [#|2004-11-16T13:53:42.359+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|ADM0001:MBeanServer initialized successfully|#]
    [#|2004-11-16T13:53:48.312+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|Creating virtual server server|#]
    [#|2004-11-16T13:53:48.328+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|S1AS AVK Instrumentation disabled|#]
    [#|2004-11-16T13:53:48.453+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.security|_ThreadID=10;|SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.|#]
    [#|2004-11-16T13:53:54.203+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.transaction|_ThreadID=10;|JTS5014: Recoverable JTS instance, serverId = [100]|#]
    [#|2004-11-16T13:53:56.968+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|Satisfying Optional Packages dependencies...|#]
    [#|2004-11-16T13:53:57.406+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.resource.resourceadapter|_ThreadID=10;|RAR7008 : Initialized monitoring registry and listeners|#]
    [#|2004-11-16T13:53:59.000+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|CORE5100:Loading system apps|#]
    [#|2004-11-16T13:54:00.734+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.classloading|_ThreadID=10;|LDR5010: All ejb(s) of [MEjbApp] loaded successfully!|#]
    [#|2004-11-16T13:54:02.031+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.ejb|_ThreadID=10;|EJB5109:EJB Timer Service started successfully for datasource [jdbc/__TimerPool]|#]
    [#|2004-11-16T13:54:02.031+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core.classloading|_ThreadID=10;|LDR5010: All ejb(s) of [__ejb_container_timer_app] loaded successfully!|#]
    [#|2004-11-16T13:54:02.265+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0302: Starting Tomcat.|#]
    [#|2004-11-16T13:54:02.718+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0100: Loading web module [adminapp] in virtual server [server] at [web1]|#]
    [#|2004-11-16T13:54:03.015+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0100: Loading web module [admingui] in virtual server [server] at [asadmin]|#]
    [#|2004-11-16T13:54:03.031+0530|WARNING|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0500: default-locale attribute of locale-charset-info element has been deprecated and is being ignored. Use default-charset attribute of parameter-encoding element instead|#]
    [#|2004-11-16T13:54:03.031+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=10;|WEB0100: Loading web module [com_sun_web_ui] in virtual server [server] at [com_sun_web_ui]|#]
    [#|2004-11-16T13:54:03.046+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.catalina.startup.Embedded|_ThreadID=10;|Starting tomcat server|#]
    [#|2004-11-16T13:54:03.062+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.catalina.startup.Embedded|_ThreadID=10;|Catalina naming disabled|#]
    [#|2004-11-16T13:54:03.250+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.catalina.core.StandardEngine|_ThreadID=10;|Starting Servlet Engine: Sun-Java-System/Application-Server-PE-8.0|#]
    [#|2004-11-16T13:54:09.234+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.catalina.startup.ContextConfig|_ThreadID=10;|Missing application web.xml, using defaults only StandardEngine[server].StandardHost[server].StandardContext[]|#]
    [#|2004-11-16T13:54:12.140+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Initializing Coyote HTTP/1.1 on port 8080|#]
    [#|2004-11-16T13:54:12.203+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Starting Coyote HTTP/1.1 on port 8080|#]
    [#|2004-11-16T13:54:12.375+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Initializing Coyote HTTP/1.1 on port 1043|#]
    [#|2004-11-16T13:54:12.390+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Starting Coyote HTTP/1.1 on port 1043|#]
    [#|2004-11-16T13:54:12.453+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Initializing Coyote HTTP/1.1 on port 4848|#]
    [#|2004-11-16T13:54:12.468+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=10;|Starting Coyote HTTP/1.1 on port 4848|#]
    [#|2004-11-16T13:54:13.265+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.resource.jms|_ThreadID=10;|JMS5023: JMS service successfully started. Instance Name = imqbroker, Home = [C:\Sun\AppServer\imq\bin].|#]
    [#|2004-11-16T13:54:13.281+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=10;|[AutoDeploy] Enabling AutoDeployment service at :1100593453281|#]
    [#|2004-11-16T13:54:13.281+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|CORE5053: Application onReady complete.|#]
    [#|2004-11-16T13:54:13.281+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|Application server startup complete.|#]
    [#|2004-11-16T13:54:44.234+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|sending notification to server...server|#]
    [#|2004-11-16T13:54:44.296+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.web|_ThreadID=11;|WEB0303: Stopping Tomcat.|#]
    [#|2004-11-16T13:54:44.296+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=11;|Stoping http11 protocol on 8080 server:type=ThreadPool,name=http8080|#]
    [#|2004-11-16T13:54:44.328+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=11;|Stoping http11 protocol on 1043 server:type=ThreadPool,name=http1043|#]
    [#|2004-11-16T13:54:44.359+0530|INFO|sun-appserver-pe8.0.0_01|org.apache.coyote.http11.Http11Protocol|_ThreadID=11;|Stoping http11 protocol on 4848 server:type=ThreadPool,name=http4848|#]
    [#|2004-11-16T13:54:44.546+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=11;|CORE5051: Shutting down all J2EE applications ...|#]
    [#|2004-11-16T13:54:44.546+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.container.ejb|_ThreadID=11;|EJB5122:EJB Timer Service shutdown at [2004/11/16 13:54:44]|#]
    [#|2004-11-16T13:54:44.546+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=11;|CORE5052: Application shutdown complete.|#]
    [#|2004-11-16T13:54:44.562+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.tools.admin|_ThreadID=11;|[AutoDeploy] Disabling AutoDeployment service.|#]
    [#|2004-11-16T13:54:44.562+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.resource.jms|_ThreadID=11;|JMS5025: JMS service shutting down.|#]
    [#|2004-11-16T13:54:45.812+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.resource.jms|_ThreadID=11;|JMS5026: JMS service shutdown complete.|#]
    [#|2004-11-16T13:54:46.453+0530|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.core|_ThreadID=10;|Server shutdown complete.|#]
    ---------------------------------------------server.log------------------------------------------------------------------
    Interesting thing is,when I had tried reinstalling it with 1.4.2_04 earlier,the log was not clean.
    The problem is still not clear.Anyway , it is working fine for now.
    Thanks.

  • How to use embeddable EJB container (Java EE 6 / EJB 3.1) on Mac OS?

    To my understanding, the intent of the embeddable EJB 3.1 container is - among others - to support out-of-container testing. I've created a JUnit test case that uses glassfish embeddable for integration testing of ejb 3.1 Light ejbs. I run the tests using Maven.
    I have one general problem and one problem specific to Mac OS (I'm not able to use the embeddable container at all on Mac OS).
    1. First the general problem: the ejb container does not inject or publish classes that are on the test class-path only:
    src>main>java>MyEjb.class
    src>test>java>MyTestEjb.class
    The test case looks like this:
    public class TestCase1b {
         static EJBContainer container;
         @BeforeClass
         public static void initEjbContainer() {
              container = EJBContainer.createEJBContainer();
              for ( Object property : System.getProperties().keySet() ) {
              System.out.print(property + " : ");
              System.out.println(System.getProperty((String)property));
         @Test
         public void canTestWithTransaction() throws NamingException, NotSupportedException, SystemException {
              Context ctx = container.getContext();
              OrderServiceTesterEjb orderServiceTester = (OrderServiceTesterEjb) ctx
                        .lookup("java:global/classes/OrderServiceTesterEjb");
              Assert.assertNotNull(orderServiceTester.testCreateOrderWithTransaction());
         @AfterClass
         public static void closeEjbContainer() {
              container.close();
    The idea with a test-ejb is to mimic the way I typically perform junit integration testing with Spring: the test database i preloaded with test data. Each test-method of the junit test case starts a transaction, invokes the service, evaluates the state of the database and finally performs a rollback. My idea was to mimic that by creating a test ejb (Stateless, REQUIRES_NEW), that injects the EJB to test, calls the method to test, evaluates the result or db state and finally sets rollbackonly before returning. The problem is that the test case can lookup ejbs in src/main/java, but not the "test" ejbs in src/test/java. My workaround is to include the test-EJBs in src/main/java which I think is not acceptable.
    2. Next the Mac-problem:
    The Mac OS JDK 1.6 contains version 1.0 of javax.annotation (jsr 250). EJBs developed with Java EE 6 depends on version 1.1 of javax.annotation. Specifically, one typically need @Resource(lookup=... and @DataSourceDefinition of javax.annotation.sql which are both missing in the JDK. I can compile my EJBs by adding the javaee-api-6.0.jar library to my classpath. But when running unit tests with maven (as described above), a runtime error is reported, stating that the lookup-property of the @Resource annotation is undefined. This is logical, since the boot classpath should have precedence. So I added javaee-api-6.0.jar to the lib/endorsed directory of the jre. Unfortunetely, this triggers a segmentation fault of the Mac OS JVM when running the test. I have no other workaround than switching to windows. Any help / hints are much appreciated.
    /Johan

    Just as an update, we're soon to release the WLS 11g R1 PS2 update, which will contain WLS 10.3.3 just to confuse things.
    As part of that, we're distributing for the first time, an additional .zip version of WLS to make it easier for developers.
    The zip file distribution has no GUI installer -- it's a simple case of unzip, run a script it provides, then start the server.
    The zip file distribution has been specifically tested on Mac OS X and the WLS config/domain scripts automatically adjust as necessary for the Mac OS X java environment.
    Once the zip file distribution is available, we hope that developing against WLS on Mac OS X (and Windows/Linux) will be an easier task.
    -steve-

  • Dynamic Class Loading in an EJB Container

    Hello,
    We have a need to load classes from a nonstandard place with in an ejb container, ie a database or secure store. In order to do so we have created a custom class loader. Two issues have come up we have not been able to solve, and perhaps some one knows the answer to.
    Issue 1.
    Given the following code:
    public static void main(String args[])
    MyClassLoader loader = new MyClassLoader("lic.dat");
    System.out.println("Loading class ..." + "TestObject");
    Object o = Class.forName("TestObject",true,loader).newInstance();
    System.out.println("Object:" + o.toString());
    TestObject tstObj = (TestObject) o;
    tstObj.doIt();
    What happens when executed is as follows. Class.forName calls our loader and does load the class as we hoped, it returns it as well, and the o.toString() properly executes just fine. The cast of the object to the actual TestObject fails with a class not found exception. We know why this happens but don't know what to do about it. It happens because the class that contains main was loaded by the system class loader (the primordial class loader as its sometimes called), That class loader does not know about TestObject, so when we cast even though the class is "loaded" in memory the class we are in has no knowledge of it, and uses its class loader to attempt to find it, which fails.
    > So the question is how do you let the main class know to use our class loader instead of
    the system class loader dispite the fact is was loaded by the system class loader.
    Issue 2:
    To make matters worse we want to do this with in an EJB container. So it now begs the question how do you inform an EJB container to use a specific class loader for some classes?
    Mike...

    Holy crap! We are in a similar situation. In creating a plugin engine that dynamically loads classes we use a new class loader for each plugin. The purpose is so that we can easily unload and/or reload a class at runtime. This is a feature supposedly done by J2EE app servers for hot-deploy.
    So our plugins are packaged as JAR files. If you put any class in the CLASSPATH, the JVM class loader (or the class loader of the class that is loading the plugin(s)), will load the class. The JavaDoc API states that the parent classloader is first used to see if it can find the class. Even if you create a new URLClassLoader with NULL for parent, it will always use the JVM class loader as its parent. So, ideally, in our couse, plugins will be at web sites, network drives, or outside of the classpath of the application and JVM.
    This feature has two benefits. First, at runtime, new updates of plugins can be loaded without having to restart the app. We are even handling versions and dependencies. Second, during development, especially of large apps that have a long startup time, being able to reload only one plugin as opposed to the annoying startup time of Java apps is great! Speeds up development greatly.
    So, our problem sounds just like yours. Apparently, the Client, which creates an instance of the plugin engine, tries to access a plugin (after the engine loades it via a new classloader instance for each plugin). Apparently, it says NoDefClassFound, because as you say, the client classloader has no idea about the plugin class loaded by another classloader.
    My co-developer came up with one solution, which I really dont like, but seems to be the only way. The client MUST have the class (java .class file) in its classpath in order to work with the class loaded by another class loader. Much like how in an EJB container, the web server calling to EJB MUST contain the Home and Remote interface .class files in its classpath, the same thing needs to be done here. For us, this means if a plugin depends on 5 others, it must contain ALL of the .class files of those plugins it depends on, so that the classloader instance that loads the plugin, can also see those classes and work with them.
    Have you got any other ideas? I really dislike that this has to be done in this manner. It seems to me that the JVM should be able to allow various class loaders to work with one another in such a way that if a client loaded by one classloader has an import statement in it to use a class, the JVM should be able to fetch the .class out of the other classloader and share it, or something!
    This seems to me that there really is no way to actually properly unload and then reload a class so that the JVM will discard and free up the previous class completely, while using the new class.
    I would be interested in discussing this topic further. Maybe some others will join in and help out on this topic. I am surprised there isn't a top-level forum topic about things like class loaders, JVM, etc. I wish there was a way to add one!

  • CDI not working in Weblogic 12c Embedded EJB Container?

    Hi,
    we are trying to use embedded ejb container from weblogic 12c (12.1.2.0) for our junit tests.
    As our application is running in weblogic 12c, we would like to run our tests  in same environment.
    But we encountered two problems, which brings me to the conclusion that CDI is not working correctly in embedded ejb container.
    1. CDI Interceptor are not working
    2. CDI Objects (@Inject) are null
    I can provide an error message, which I think is thrown, when container tries to access the interceptor, because if I delete the interceptors the error message gets no longer thrown:
    Caused by: java.lang.UnsupportedOperationException: authenticatedLookup is unavailable for BasicNamingNode types
          at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:234)
          at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:463)
          at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:274)
          at weblogic.jndi.internal.ServerNamingNode_12120_WLStub.authenticatedLookup(UnknownSource)
          at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:483)
    We just want to know, if CDI is not working in embedded ejb container, so we can go ahead and look for another solution for our junit tests.
    Stefan

    Hi There,
    If you have access to Oracle Support Portal, please go through below Knowledge Articles which can provide more information on your requirement:
    Sample Application Using Timer API (CommonJ) to configure Timer Based tasks in Oracle WebLogic Cluster 10.3.X Cluster (Doc ID 1614886.1)
    Clustered EJB Timer - The minimum time for recurring execution of a timer (Doc ID 1931091.1)
    Let us know if it helps.
    Cheers,
    Naveen

  • Calling a Java aplication from EJB container

    We have a standalone Java application which is thread safe, and works well when called from web container. Now we are planning to call this app from EJB container (We are using OC4J) i.e our client apps which call this Java app will be written as EJBs. Our concern is to make sure that our application's thread mechanism does not conflict with EJB Container's thread mechanism. Any thoughts on this will be appreciated. Thanks. (Mubashar Tariq)

    Thread management isn't really a problem as long as you keep a couple of things in mind:
    1. You(r EJB) can only act on incoming calls (or messages) or so to say
    2. You're not allowed to spawn threads when acting on an incoming call
    3. Calls via RMI may timeout (check the default SocketFactory for the timeout, I think it's about 3 mins)
    Calling an outside application isn't really a problem as well I think. As long as you remember the two rules above and the following: an EJB cannot have two 'clients'. So if your application gets called and you're somehow able to reach (within your standalone application) the EJB, you're not allowed to call it (because it's already called by somebody else, on which the EJB acts).
    Also you should check if OC4J (I don't really know) offers the possibility of having resourcemanagers for RMI. Just opening an RMI connection might not be possible from an EJB. HTTP however is (but then you would have to open an HTTP server at the client, the rules above would not apply then however).
    The solution I see:
    either bind a Object in the RMI Registry you create at the client or open a ServerSocket. Somehow the EJB making the client application gets called (via the Web part???), it contacts the client application via the ServerSocket or the RemoteObject and does it work. Then the business method ends and the thread the EJB is working on dies...
    alef

  • Using J2EE EJB Container and Oracle 8.1.7

    I am trying to setup the J2EE EJB container to use and Oracle 8.1.7 database instead of Cloudscape. So far I have done the following
    0. Created the table for the Savings Account tutorial in the Oracle Database.
    1. Added the Classes12.jar (Oracle's latest JDBC thin drivers) to my CLASSPATH
    2. Under "Server Configuration" I added the standard/jdbc drivers value: "oracle.jdbc.driver.OracleDriver".
    3. Under "Server Configuration" I added the standard/datasource value: JNDI name "jdbc/Oracle" and JDBC URL "jdbc:oracle:thin:@10.1.1.254:1521:DEV".
    4. For the savings account tutorial, when deploying I specified "jdbc/Oracle" for the reference "jdbc/SavingsAccountDB".
    I have gotten this tutorial to work using the Cloudscape database. After I did the previous steps and tried to run the client, I get no valid driver available, unable to connect to Oracle.
    What else to I need to do?
    My setup is:
    Windows 2000 Professional
    J2EE (JDK 1.3.1)
    Oracle 8.1.7
    Thank you in advance.

    Exactly which classpath did you add the Oracle JDBC library jar to ?
    The thing that works for me is to have the following line in the file %J2EE_HOME%\bin\userconfig.bat
    set J2EE_CLASSPATH=D:\DownLoad\Oracle\classes12_01.zip;

  • Singletons in EJB Container

    I'm working with an existing application that uses "traditional" Singletons in the EJB continer (static instance variable to contain the state and guarded access to the state). These singletons are running in the EJB container and I need to get rid of them and replace them with something that will work in a clustered environment.
    Basically, there are single instances of resources that are being shared across multiple EJB components. These resources are not serializable. Short of a complete re-write of the entire application (which, BTW, is not feasible), how can these resources be shared in the EJB Container.
    I've tried adding them to the naming context, but that's not working because they are not serializable. Is there any place I can park these resources so that all my EJBs have access?
    I have a feeling there is no simple solution to this problem.
    TG

    Well, you might have already thought of this, but the traditional way would be to store the resource in a database ?

  • Webserver/jsp engine call into weblogic ejb container

    Which one of these architectures would give the best performance.
              First architecture:
              3 boxes -
              1st box - webserver(IIS or IPlaner) with a JSP engine. (The JSP's
              produce dynamic content.)
              2nd box - weblogic 5.1 hosting EJB's
              3rd box - Oracle or DB2
              The 1st box is used to server up dynamic contect. The JSP's make dynamic
              contect from calls into the EJB container in the 2nd box. The EJB's then
              calls the DB in the 3rd box.
              2nd architecture:
              3 boxes-
              1st box - webserver with weblogic plug-ins for IIS or IPlanet
              2nd box - weblogic 5.1 - hosting JSP pages and EJBs
              3rd box - Oracle or DB2
              The 1st box's webserver just receives the request to JSPs and lets the
              plug-in find the appropriate weblogic instance. The JSPs that are processed
              on the 2nd box make calls into the EJB container on the 2nd box. The EJBs
              then make calls to the DB on the 3rd box.
              thanks
              -cb
              

    thanks you both for you input
              "Cameron Purdy" <[email protected]> wrote in message
              news:[email protected]...
              > It is certainly more efficient in terms of JSP/Servlet to EJB invocations
              if
              > you use WebLogic to do all three (JSP/Servlet/EJB) due to the
              well-designed
              > client stubs for EJBs that do pass-by-reference. If you have lots of
              small
              > invocations to EJBs, that is a good reason to consider WL for all three
              > (JSP/Servlet/EJB).
              >
              > OTOH there are a good number of developers that I have spoken with that
              > prefer other Servlet engines. These developers have had excellent
              > experiences with WL EJB handling, but some issues with JSP/Servlets, or
              > simply needed features offered by other servers. A few may have decided
              on
              > a price basis. Some of the technical issues were related to WL class
              > loading issues that are scheduled to be completely improved in the fall WL
              > release.
              >
              > All of that said, I personally would probably stick with WL to do all
              three
              > (JSP/Servlet/EJB). I believe that I have found most of the problems that
              WL
              > has ;-) and I have come through the other side still really liking the
              > product -- so even it's worst points (like the linkage error that had me
              > pulling out my hair and even searching through the Sun JVM sources ;-)
              > aren't that bad because it is a strong enough product that there are
              always
              > ways to work through or around just about anything. If I had to look at a
              > different JSP/Servlet engine, I would start with Caucho Resin, simply
              > because I like their approach and I know it works well with WL.
              >
              > Lastly remember that in the J2EE world, "no one ever got fired for buying
              > BEA WebLogic!"
              >
              > --
              >
              > Cameron Purdy
              > http://www.tangosol.com
              >
              >
              > "Chris Bick" <[email protected]> wrote in message
              > news:[email protected]...
              > > So you would not support/advise an architecture that has the JSP/Servlet
              > > engine on a different box then weblogic? If this is the case, could you
              > > give some reasons why?
              > >
              > > thanks,
              > > -cb
              > > "Cameron Purdy" <[email protected]> wrote in message
              > > news:[email protected]...
              > > > 1. Your bottleneck will probably be the third box (database server)
              in
              > > > either scenario. That's probably your biggest up-front cost -- making
              > > sure
              > > > the db server is up to the task.
              > > > 2. The second architecture is suggested by WL. The reason is that if
              > box
              > > > #2 (WL) is a cluster, you can theoretically add more boxes easily to
              get
              > > > pseudo-linear scaling for JSP and EJB processing. Of course, that
              only
              > > > helps if your database is not a bottleneck ;-) WL cluster is $17k per
              > > CPU.
              > > > 3. The real answer is that it depends on your application and the
              > number
              > > of
              > > > users that you are expecting. You want to make sure that when your
              site
              > > is
              > > > loaded that there is no significant queueing of requests on the WL
              side.
              > > I
              > > > believe you can see that information in the WL monitor.
              > > >
              > > > --
              > > >
              > > > Cameron Purdy
              > > > http://www.tangosol.com
              > > >
              > > >
              > > > "Chris Bick" <[email protected]> wrote in message
              > > > news:[email protected]...
              > > > > Which one of these architectures would give the best performance.
              > > > >
              > > > > First architecture:
              > > > >
              > > > > 3 boxes -
              > > > >
              > > > > 1st box - webserver(IIS or IPlaner) with a JSP engine. (The
              > > JSP's
              > > > > produce dynamic content.)
              > > > > 2nd box - weblogic 5.1 hosting EJB's
              > > > > 3rd box - Oracle or DB2
              > > > >
              > > > > The 1st box is used to server up dynamic contect. The JSP's make
              > > dynamic
              > > > > contect from calls into the EJB container in the 2nd box. The
              EJB's
              > > then
              > > > > calls the DB in the 3rd box.
              > > > >
              > > > > 2nd architecture:
              > > > >
              > > > > 3 boxes-
              > > > >
              > > > > 1st box - webserver with weblogic plug-ins for IIS or IPlanet
              > > > > 2nd box - weblogic 5.1 - hosting JSP pages and EJBs
              > > > > 3rd box - Oracle or DB2
              > > > >
              > > > > The 1st box's webserver just receives the request to JSPs and lets
              the
              > > > > plug-in find the appropriate weblogic instance. The JSPs that are
              > > > processed
              > > > > on the 2nd box make calls into the EJB container on the 2nd box.
              The
              > > EJBs
              > > > > then make calls to the DB on the 3rd box.
              > > > >
              > > > > thanks
              > > > > -cb
              >
              >
              >
              

  • UnExpected error occured while creating ejb container

    Hey, I am trying to deploy a new bean that I just wrote with a bean that has already been written. My bean is the News bean, the existing bean is the PPSO bean.
    when I deploy, I get the following exception:
    [26/Feb/2004:11:22:42] SEVERE ( 2104): LDR5004: UnExpected error occured while creating ejb container
    java.lang.ClassNotFoundException: com.pragmatics.ppcig.model.ejb.NewsBean_LocalHomeImpl
         at com.iplanet.ias.loader.EJBClassLoader.findClass(EJBClassLoader.java:457)
         at com.iplanet.ias.loader.EJBClassLoader.loadClass(EJBClassLoader.java:585)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
         at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:426)
         at com.sun.ejb.containers.EntityContainer.initializeHome(EntityContainer.java:355)
         at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:230)
         at com.iplanet.ias.server.AbstractLoader.loadEjbs(AbstractLoader.java:345)
         at com.iplanet.ias.server.ApplicationLoader.load(ApplicationLoader.java:81)
         at com.iplanet.ias.server.ApplicationManager.applicationDeployed(ApplicationManager.java:134)
         at com.iplanet.ias.server.ApplicationManager.applicationDeployed(ApplicationManager.java:110)
         at com.iplanet.ias.server.ApplicationManager.applicationDeployed(ApplicationManager.java:294)
         at com.iplanet.ias.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:424)
         at com.iplanet.ias.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:408)
         at com.iplanet.ias.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:291)
         at com.iplanet.ias.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:99)
         at com.iplanet.ias.admin.server.core.channel.AdminChannelServer.sendNotification(AdminChannelServer.java:84)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
         at sun.rmi.transport.Transport$1.run(Transport.java:148)
         at java.security.AccessController.doPrivileged(Native Method)
         at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
         at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
         at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
         at java.lang.Thread.run(Thread.java:534)
    here are pieces of my deployment descriptor:
    <entity>
              <description>PPSO EJB</description>
              <display-name>PPSO EJB</display-name>
              <ejb-name>PPSO</ejb-name>
              <local-home>com.pragmatics.ppcig.model.ejb.PPSOLocalHome</local-home>
              <local>com.pragmatics.ppcig.model.ejb.PPSOLocal</local>
              <ejb-class>com.pragmatics.ppcig.model.ejb.PPSOBean</ejb-class>
              <persistence-type>Bean</persistence-type>
              <prim-key-class>java.lang.String</prim-key-class>
              <reentrant>False</reentrant>
              <env-entry>
    // - select statements here that don't apply - //
    </entity>
         <entity>
              <description>News EJB</description>
              <display-name>News EJB</display-name>
              <ejb-name>News</ejb-name>
              <local-home>com.pragmatics.ppcig.model.ejb.NewsLocalHome</local-home>
              <local>com.pragmatics.ppcig.model.ejb.NewsLocal</local>
              <ejb-class>com.pragmatics.ppcig.model.ejb.NewsBean</ejb-class>
              <persistence-type>Bean</persistence-type>
              <prim-key-class>java.lang.String</prim-key-class>
              <reentrant>False</reentrant>
              <resource-ref>
                   <res-ref-name>jdbc/ppcigDS</res-ref-name>
                   <res-type>javax.sql.DataSource</res-type>
                   <res-auth>Container</res-auth>
                   <res-sharing-scope>Shareable</res-sharing-scope>
              </resource-ref>
         </entity>
    Any ideas what is causing this error?
    Thanks!

    Hi shanu, thanks for your reply,
    Yes I configured the JMS Objects in my AS before deploying the MDB.
    I set
    - a Queue: RFIDLocatorQueue
    - a connection Factory: RFIDLocatorConnectionFactory
    - and a Physical destination for my logical queue called: RFIDLocatorPhysicalQueue
    The latter was linked to the RFIDLocatorQueue by putting RFIDLocatorPhysicalQueue in the name parameter of the RFIDLocatorQueue.
    Is there maybe something else I forgot to configure ?
    thanks a lot

  • Logging ejb container operations

    Hello guys,
    I'm new to WebLogic, so excuse me for such, probably, a faq-question.
    Is there a way to enable logging of EJB container operations? I.e. to make the
    container to log what beans, what cmp and cmr fields it loads.
    TIA,
    alex

    "alex" <[email protected]> wrote
    I'm new to WebLogic, so excuse me for such, probably, a faq-question.No problem...
    Is there a way to enable logging of EJB container operations? I.e. to make the
    container to log what beans, what cmp and cmr fields it loads.Well, first start here:
    http://edocs.bea.com/wls/docs70/logging/
    NOTE: This documentation applies to version 7.0 of WebLogic Server.
    Next, I'd make sure my WebLogic Server was sending (to STDOUT)
    low-level DEBUG messages -- that appears to be the sort of information
    you are looking to obtain from your EJB operations. One of the things
    I did on a project a while back was create an object that contained a
    boolean value (within my app.). Then, to enable/disable this
    debugging, we'd appropriately toggle this value. Do you understand
    what I mean?
    Hope this helps...
    Brian J. Mitchell
    BEA Systems Administrator
    TRX
    Atlanta, GA
    email: [email protected]
    office: 404-327-7238
    mobile: 678-283-6530

  • Classes, Stateful EJBs and EJB Container

    Hi,
    We have several doubts about classes, servlets, and EJBs.
    We have been told that the instance of non-static classes from JSPs or servlets
    can be a problem if we have a big number of clients connecting to weblogic (or
    any other app server). Would it be a problem? Is it a better practice to instantiate
    those classes from EJBs?
    We have been told that EJBs are managed by the EJB container, and it uses a pool
    for serving them to clients, passivating and activating them. This would include
    the classes instantiated inside them. Is it true?
    If all our guesses are true, the better way to implement a search with pagination
    would be a stateful EJB, using handlers to save it in the client's session. But
    we've heard that stateful EJBs are really bad for server's perfomance. Is it true?
    We are using Weblogic 7.0. If so, what are they useful for???
    If they can be a problem, how to build that searching using stateless EJBs?
    Best regards,
    Ignacio Sanchez

    You're right, the concrete tag to use seems to be:
    <replication-type>InMemory</replication-type>
    Anyway, do you have any further explanation on Stateful's behaviour with many
    clients and pagination implementation?
    "Stanley Beamish" <[email protected]> wrote:
    >
    "Ignacio Sanchez" <[email protected]> wrote in message
    news:[email protected]...
    Thanks for your replies.
    Anyway, I still have some questions about stateful EJBs. In a clusteredenvironment,
    we've been told that stateful EJBs are only balanced before create()method. So,
    if we have already "created" the Remote interface, we're using it,and the
    server
    fails and must be balanced to another instance, what will happen? Willwe
    lost
    that Remote interface and data included in it?
    Not necessarily, you can enable replication, which means that your stateful
    EJB's state (values of i-vars) can be replicated across nodes in a cluster.
    Search through the WLS cluster documentation for details.
    SB
    And about your suggestion on pagination using stateless. Could youplease
    explain
    it in more detail? I haven't understood it well.
    Thank you very much for your attention.
    "Sri" <[email protected]> wrote:
    Hi,
    Look below for my coments.
    S
    "Ignacio Sanchez" <[email protected]> wrote:
    Hi,
    We have several doubts about classes, servlets, and EJBs.
    We have been told that the instance of non-static classes from JSPsor
    servlets
    can be a problem if we have a big number of clients connecting to
    weblogic
    (or
    any other app server). Would it be a problem? Is it a better practice
    to instantiate
    those classes from EJBs?It all boils down to your architecture. If you have a lot of clients
    connecting
    to web container then and if each client needs objects stored in session
    then
    you have to refactor your object distribution. But this could be avoided
    by separating
    static content from dynamic content (using proxies, load balancersetc),
    having
    more web containers etc. It's not necessary to instantiate these classes
    in EJBs
    always (then you are increasing your memory footprint). The generalguidelne
    is
    to do more heavy duty work as you go deeper into tiers hopefully handling
    less
    connections etc.
    We have been told that EJBs are managed by the EJB container, and
    it
    uses a pool
    for serving them to clients, passivating and activating them. Thiswould
    include
    the classes instantiated inside them. Is it true?
    True.
    If all our guesses are true, the better way to implement a search
    with
    pagination
    would be a stateful EJB, using handlers to save it in the client'ssession.
    But
    we've heard that stateful EJBs are really bad for server's perfomance.
    Is it true?
    We are using Weblogic 7.0. If so, what are they useful for???
    True if misused as stateful EJBs, just like HTTP sessions could bereplicated
    and could be activated/passivated.
    If they can be a problem, how to build that searching using stateless
    EJBs?
    You could cache searchs and pass identity and page numbers to theSLSB.
    Best regards,
    Ignacio Sanchez

  • Error while setting up existing code--WSAD+EJB container caught java.lang.

    [5/8/08 9:12:31:741 IST] 3bb9beb5 BeanMetaData E CNTR0035E: EJB container caught java.lang.NoClassDefFoundError: com/scb/scp/util/exceptions/SCPException
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:1753)
    at java.lang.Class.privateGetPublicMethods(Class.java:1781)
    at java.lang.Class.getMethods(Class.java:896)
    at com.ibm.ejs.container.util.DeploymentUtil.getMethods(DeploymentUtil.java:124)
    at com.ibm.ejs.container.BeanMetaData.initializeBeanMethods(BeanMetaData.java:1522)
    at com.ibm.ejs.container.BeanMetaData.completeInitialization(BeanMetaData.java:1359)
    at com.ibm.ws.runtime.component.EJBContainerImpl.createBeanMetaData(EJBContainerImpl.java:981)
    at com.ibm.ws.runtime.component.EJBContainerImpl.createModuleMetaData(EJBContainerImpl.java:796)
    at com.ibm.ws.runtime.component.EJBContainerImpl.createMetaData(EJBContainerImpl.java:1517)
    at com.ibm.ws.runtime.component.MetaDataMgrImpl.createFactoryMetaData(MetaDataMgrImpl.java:115)
    at com.ibm.ws.runtime.component.MetaDataMgrImpl.createMetaData(MetaDataMgrImpl.java:159)
    at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:350)
    at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:575)
    at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:271)
    at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:249)
    at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:536)
    at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:413)
    at com.ibm.ws.runtime.component.ApplicationServerImpl.start(ApplicationServerImpl.java:125)
    at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:536)
    at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:413)
    at com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:183)
    at com.ibm.ws.runtime.WsServer.start(WsServer.java:128)
    at com.ibm.ws.runtime.WsServer.main(WsServer.java:225)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41)
    at java.lang.reflect.Method.invoke(Method.java:386)
    at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)
    at com.ibm.etools.websphere.tools.runner.api.ServerRunnerV5$1.run(ServerRunnerV5.java:97)
    and is throwing com.ibm.ejs.container.ContainerException: Failed to initialize BeanMetaData instance - caught Throwable; nested exception is:
    java.lang.NoClassDefFoundError: com/scb/scp/util/exceptions/SCPException
    at com.ibm.ejs.container.BeanMetaData.completeInitialization(BeanMetaData.java:1456)
    at com.ibm.ws.runtime.component.EJBContainerImpl.createBeanMetaData(EJBContainerImpl.java:981)
    at com.ibm.ws.runtime.component.EJBContainerImpl.createModuleMetaData(EJBContainerImpl.java:796)
    at com.ibm.ws.runtime.component.EJBContainerImpl.createMetaData(EJBContainerImpl.java:1517)
    at com.ibm.ws.runtime.component.MetaDataMgrImpl.createFactoryMetaData(MetaDataMgrImpl.java:115)
    at com.ibm.ws.runtime.component.MetaDataMgrImpl.createMetaData(MetaDataMgrImpl.java:159)
    at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:350)
    at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:575)
    at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:271)
    at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:249)
    at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:536)
    at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:413)
    at com.ibm.ws.runtime.component.ApplicationServerImpl.start(ApplicationServerImpl.java:125)
    at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:536)
    at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:413)
    at com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:183)
    at com.ibm.ws.runtime.WsServer.start(WsServer.java:128)
    at com.ibm.ws.runtime.WsServer.main(WsServer.java:225)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41)
    at java.lang.reflect.Method.invoke(Method.java:386)
    at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)
    at com.ibm.etools.websphere.tools.runner.api.ServerRunnerV5$1.run(ServerRunnerV5.java:97)
    Caused by: java.lang.NoClassDefFoundError: com/scb/scp/util/exceptions/SCPException

    Hello again,
    What do you exactly mean by saying:
    Did you create the deployment code?
    I deployed the EJB on the Application Server is there anything else i have to do?
    -regards
    Fabian

Maybe you are looking for