Help-Problem in calling JMS  inside an EJB having  transaction attribute Required New

          Hi,
          Version wl 5.1 service pack 8
          OS - unix
          I am using a Container managed bean say Bean1(transaction attribute Required)
          which in one of its method is trying to call another EJB say Bean2 which has the
          transaction attribute set to "RequiredNew".Inside the method in Bean2 i have my
          JMS funtions coded to persist to database.JMS uses Queue connection factory and
          is an non transaction JMS session.The JMS server is running in a separate weblogic
          server and not in the server where EJB is deployed.I use the url of the JMS server
          and get the context of that server and connect my JMS.
          The problem that i am facing is
          I do the transaction in bean1 and the i make the call to bean2 to do the JMS work
          and i can see the JMS doing the insert in the table and everthing works fine.But
          after few seconds i can see the exception/message seen on the console of the weblogic
          server where my JMS server is running as below
          Tue Sep 04 15:57:09 CDT 2001:<I> <TX> Transaction (TxC (30486015, xid = 99963563
          2756_5, timeout = 30, txState = Marked Rollback, root = 829817264280676325S10.51
          .110.237:[7001,7001,7002,7002,7001,-1]/326) rolled back after 30 sec.
          After this happen i dont see any roll back in either bean1 or bean2 or the JMS
          insert is rolled back.
          I don't know why this exception is thrown and no effects on the rollback and it
          works the way i wanted.But the only thing that keeps bothering me is the rollback
          and why does this happen.
          Thanks
          Krish.
          

The exception your seeing is troubling - if the tran is rolled
          back than whatever work is associated should also roll back. I suggest
          instrumenting your code to see if the tran rolling back is the same tran
          that is being used for the transactional application work that appears to succeed.
          Also, try forcing a rollback, you may see that the EJB work truly rolls back
          while the JMS work does not.
          I'm not really familiar with 5.1, but I know there is a fundamental limitation to one
          phase commits, this means that the JDBC connection pool used by JMS as well
          as that used by the EJB must be one and the same - I'm not exactly sure how
          it works, but I'm pretty sure multiple servers can share the same connection pool.
          This post seems unrelated to clustering, if you need further help, I
          suggest posting in the ejb or transaction newsgroups.
          Krish wrote:
          > Hi,
          >
          > Version wl 5.1 service pack 8
          > OS - unix
          >
          > I am using a Container managed bean say Bean1(transaction attribute Required)
          > which in one of its method is trying to call another EJB say Bean2 which has the
          > transaction attribute set to "RequiredNew".Inside the method in Bean2 i have my
          > JMS funtions coded to persist to database.JMS uses Queue connection factory and
          > is an non transaction JMS session.The JMS server is running in a separate weblogic
          > server and not in the server where EJB is deployed.I use the url of the JMS server
          > and get the context of that server and connect my JMS.
          >
          > The problem that i am facing is
          >
          > I do the transaction in bean1 and the i make the call to bean2 to do the JMS work
          > and i can see the JMS doing the insert in the table and everthing works fine.But
          > after few seconds i can see the exception/message seen on the console of the weblogic
          > server where my JMS server is running as below
          >
          > Tue Sep 04 15:57:09 CDT 2001:<I> <TX> Transaction (TxC (30486015, xid = 99963563
          > 2756_5, timeout = 30, txState = Marked Rollback, root = 829817264280676325S10.51
          > 110.237:[7001,7001,7002,7002,7001,-1]/326) rolled back after 30 sec.
          >
          >
          > After this happen i dont see any roll back in either bean1 or bean2 or the JMS
          > insert is rolled back.
          >
          > I don't know why this exception is thrown and no effects on the rollback and it
          > works the way i wanted.But the only thing that keeps bothering me is the rollback
          > and why does this happen.
          >
          > Thanks
          >
          > Krish.
          

Similar Messages

  • Can i call Bean managed EJB with transaction attribute Required New

              I am calling a BeanManaged EJB which has a transaction attribute
              set to Required New from a container managed bean. Does it create a new transaction
              other than the Bean managed transaction. Do i really need a required new field
              transaction attribute.All i need is user controlled transaction.Do i need to set
              the transaction aatibute.
              Thanks
              Krish.
              

    Hi Krish,
              The question does not make much sense.
              I would suggest that you set all your tx settings to "Required" unless you
              have a specific reason to do otherwise, and in those few instances that you
              have a specific reason to do otherwise, then change it in just those places.
              Peace,
              Cameron Purdy
              Tangosol Inc.
              << Tangosol Server: How Weblogic applications are customized >>
              << Download now from http://www.tangosol.com/download.jsp >>
              "KRISH" <[email protected]> wrote in message
              news:[email protected]..
              >
              > I am calling a BeanManaged EJB which has a transaction attribute
              > set to Required New from a container managed bean. Does it create a new
              transaction
              > other than the Bean managed transaction. Do i really need a required new
              field
              > transaction attribute.All i need is user controlled transaction.Do i need
              to set
              > the transaction aatibute.
              >
              > Thanks
              >
              > Krish.
              >
              

  • JMS publisher inheriting EJB container transaction

              I have trawled through the archives but just need to clarify :-
              How can I have an Session EJB which send messages to a JMS Queue inherit the EJB
              container managed transaction from the session bean, such that if the EJB rollsback
              the message will as well ?
              1) Firstly is this possible with container managed transactions ?
              2) Should I use a transacted (true) or non-transacted (false)
              Session ?
              queueConnection.createQueueSession(true,0); or
              queueConnection.createQueueSession(false,0); or
              3) Unless I call queueSession.commit() the message never seems to get there, but
              if I call commit() it seems to arrive at the MessageDriven bean IMMEDIATELY, i.e
              before the Session bean's transaction has committed. Do I need to commit() ?
              Any help would be appreciated.
              I have tried
              

              Pete wrote:
              > I have trawled through the archives but just need to clarify :-
              >
              > How can I have an Session EJB which send messages to a JMS Queue inherit the EJB
              > container managed transaction from the session bean, such that if the EJB rollsback
              > the message will as well ?
              >
              > 1) Firstly is this possible with container managed transactions ?
              Yes.
              > 2) Should I use a transacted (true) or non-transacted (false)
              > Session ?
              >
              > queueConnection.createQueueSession(true,0); or
              > queueConnection.createQueueSession(false,0); or
              >
              non-transacted, otherwise you will get the behavior in (3)
              ensure that the connection factory used has the
              "UserTransactionsEnabled" flag configured to true
              > 3) Unless I call queueSession.commit() the message never seems to get there, but
              > if I call commit() it seems to arrive at the MessageDriven bean IMMEDIATELY, i.e
              > before the Session bean's transaction has committed. Do I need to commit() ?
              >
              > Any help would be appreciated.
              > I have tried
              This is a frequently-asked question. See the JMS FAQ for details, also
              check out the tranaction chapter of the JMS programmer's guide, and, if
              your interested in performance considerations, check out the WebLogic
              JMS Performance Guide white-paper available on dev2dev.bea.com.
              

  • Regarding EJB transaction attributes

    Hi,
    I am having a method in a stateless session bean. This bean's transaction
    attribute is "Required'. This method in turn is calling a create method using another entity bean whose transaction attribute is "Required".
    After calling the create method we are using another stateless session bean
    having transaction attribute "NotSupported" to retrieve the previously created record(We have our own business requirement, that's the reason we are using here another session bean to retrieve immediatly the created record, instead of using the same entity bean). All the above transactions are done in the same method.
    while calling the retrive method to retrieve the immediatly created record, we are getting an exception saying the below.
    SQL0911N The current transaction has been rolled back because of
    a deadlock or timeout. Reason code "68".
    What could be the problem? Can anyone help me out?
    Note : if we use a different method for the retrieval alone then it's working fine.
    Thanks.

    The container might have suspended the current transaction, and called the retrieve method whose tx attribute is NotSupported. The duration of this invocation may have exceeded the transaction timeout limit. After the transaction has been left idle for such a long period, it times out.

  • EJB + "transaction attributes" + "best practice"

    hi
    For EJBs, when you specify multiple transaction attributes for a single
    method, is the latest attribute taken or the first?
    for e.g. In Jbuilder8 in the container transaction section for an EJB,
    if i were to put
    Method Transaction attribute
    * Required
    getSomeThing() Supported
    As you can see all the methods were initially given the required attribute,
    and then the method getSomeThing() was given Supported. will the
    getSomething() method use Required or else Supported. Secondly, will this
    cause an extra overload (Transaction attributes are set and the again
    reset), is it a recommended best practice?
    suren

    getSomeThing() Supported
    As you can see all the methods were initially given
    the required attribute,
    and then the method getSomeThing() was given
    Supported. will the
    getSomething() method use Required or else Supported.It will use supported.
    Secondly, will this
    cause an extra overload (Transaction attributes are
    set and the againIt won't cause extra overload.
    reset), is it a recommended best practice?It really depends on your needs - what you're trying to achieve. There is no best practice for that it depends on the application you're building.
    Regards,
    Dimitar

  • Problem calling a session bean (EJB 3.0)

    Hello,
    I'm new to netbeans and J2EE. I'm using NetBeans 5.5 Beta 2 and sun application server 9 pe.
    I created a new enterprise application and i'm trying to access a Session Bean (Remote and Stateless)
    from the app-client (outside the main class).
    This is the loockup method that was generated by the IDE (Enterprise Resources > Call enterprise bean):
    private ejb.SessionBeanDoenteRemote lookupSessionBeanDoenteBean() {
    try {
    javax.naming.Context c = new javax.naming.InitialContext();
    return (ejb.SessionBeanDoenteRemote) c.lookup("java:comp/env/ejb/SessionBeanDoenteBean");
    catch(javax.naming.NamingException ne) {
    java.util.logging.Logger.getLogger(getClass().getName()).log(java.util.logging.Level.SEVERE,"exception caught" ,ne);
    throw new RuntimeException(ne);
    When I run the application and try to invoke the lookup method my application gets the following exception:
    SEVERE: exception caught
    javax.naming.NameNotFoundException: No object bound to name java:comp/env/ejb/Se
    ssionBeanDoenteBean
    at com.sun.enterprise.naming.NamingManagerImpl.lookup(NamingManagerImpl.
    java:751)
    at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.j
    ava:156)
    at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:307
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at intensivecare.entrada.JDialogEntrada.lookupSessionBeanDoenteBean(JDia
    logEntrada.java:219)
    at intensivecare.entrada.JDialogEntrada.buttonMenuGravarActionPerformed(
    JDialogEntrada.java:79)
    at intensivecare.JDialogWizzard$2.jButtonGravarActionPerformed(JDialogWi
    zzard.java:178)
    at componentes.JTaskPanelMenu$3.actionPerformed(JTaskPanelMenu.java:54)
    at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:18
    49)
    at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.jav
    a:2169)
    Please... can someone help me?

    The portable way to acquire the dependency is through java:comp/env or @EJB. Accessing the
    global namespace directly is not recommended. If you use an ejb-ref, you need to define it
    in the component environment within which you'll be looking up the dependency. So if you're
    looking it up from an Application Client, you'll need to define the ejb-ref in application-client.xml.
    Also, the ejb-ref-name is the portion of the string after java:comp/env. There is no automatic
    "ejb" appended to it. If you do ic.lookup("java:comp/env/foo"), your ejb-ref-name would be "foo".
    You can use @EJB but it can only be defined in certain managed classes such as the
    Application Client main class.
    You can find additional info in our EJB FAQ :
    https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • After updating my iPhone 5 to ios 6.1 I'm getting a hissing sound during calls. Any one else having this problem? Need help

    After updating my iPhone 5 to ios 6.1 I'm getting a hissing sound during calls. Any one else having this problem? Need help

    I am having the same issue. I am updating to 6.1.3 to see if that helps. It is really annoying. It seems to vibrate as well as hiss on my ear piece speaker while on a call. I keep looking at the phone thinking maybe another call is coming in.

  • Problem with call of function F4UT_RESULTS_MAP in search help exit

    Hi everybody,
    i have a problem concerning call of function F4UT_RESULTS_MAP.
    I call this function in this way:
    CALL FUNCTION 'F4UT_RESULTS_MAP'
           TABLES
                shlp_tab          = p_shlp_tab
                record_tab        = p_record_tab
                source_tab        = lt_zv055[]
           CHANGING
                shlp              = p_shlp
                callcontrol       = p_callcontrol
           EXCEPTIONS
                illegal_structure = 1
                OTHERS            = 2.
    in lt_zv055[] there are results from previous select, but i want to select only values,
    that match select options that are specified in p_shlp.
    But it always shows all the values that are in lt_zv055.
    What am i doing wrong?
    Thanks in advance.

    Read the "Notes" part in FM documentation and you will find the reason .

  • Transaction with third party JMS providers and ejb

              I am using a container managed stateless session bean to send messages to an ibm
              mqseries running on the same computer. The EJB is deployed on weblogic 7.0. It
              seems that sending JMS messages do not participate in the transaction and that
              I have to call queueSession.commit() explicity every time. However, receiving
              messages via Message Driven Beans in a transaction is not a problem. Any clue
              how to resolve this or what is happening?
              

    To do this today, you'd have to get the "XAResource" object from your JMS
              provider's XASession object, and register it with JTA. I know this has come
              up before, and you should be able to find more about this on the newsgroup.
              Basically, every time you send a message, you need to do something like
              this:
              import javax.jms.*;
              import javax.transaction.*;
              XASession xaSession; // This is your vendor's XASession object
              XAResource xaResource = xaSession.getXAResource();
              Transaction tran = weblogic.transaction.TxHelper.getTransaction();
              tran.enlistResource(xaResource);
              // Now send your message!
              You need to call "enlistResource" every time you send a message, or it won't
              work.
              WebLogic Server 8.1 will be able to do this automatically as long as you're
              inside an EJB or a servlet.
              greg
              "raj" <[email protected]> wrote in message
              news:[email protected]..
              >
              > I am using a container managed stateless session bean to send messages to
              an ibm
              > mqseries running on the same computer. The EJB is deployed on weblogic
              7.0. It
              > seems that sending JMS messages do not participate in the transaction and
              that
              > I have to call queueSession.commit() explicity every time. However,
              receiving
              > messages via Message Driven Beans in a transaction is not a problem. Any
              clue
              > how to resolve this or what is happening?
              

  • How do I reference an EJB inside anothe EJB ,both are on different hosts

    Hi,
    I want to reference an EJB on one host inside another EJB in another
    host. Even if i hardcode the url of the host on which the EJB is
    deployed , it gives me the error regarding the no such ejb found.
    I would appreciate your help.
    Thanks

    Robert,
    We've been trying to implement this type of multi-server setup for some
    time now. Our application consists of 260+ EJBs with a large team of
    developers actively working against it. The business logic in our
    application puts the EJBS in a highly interrelated situation. This
    degree of interrelation makes it necessary for each developer to deploy
    the entire application before any work can get done.
    Starting a weblogic server, on a Windows Workstation, with 260+ beans is
    very time consuming. But to get around this development bottle neck, we
    are attempting the same scenario described in this thread. We have
    recently upgraded from WL4.5.x to WL5.1 SP8. With WL5.1, we get the
    CommunicationException seen previously in this thread. But the Error
    message in WL5.1 is less descriptive. The 5.1 error message is missing:
    WL6.0 Error Text: "This error could indicate that a component was
    deployed on a cluster member but not other members of that cluster. Make
    sure that any component deployed on a server that is part of a cluster
    is also deployed on all other members"
    It is obvious that weblogic's clustering depends on classes being
    available to each server in the cluster, including the ejbc generated
    _WLStub classes.  To me, it seems wrong that a weblogic server can only
    use standard JNDI to lookup HomeInterfaces on other weblogic servers if
    the hidden _WLStub classes are available to both servers.  I say this
    because non-weblogic clients have JNDI lookup abilities without these
    requirements. This whole experience was frustrating because all along
    I knew that the solution was simply to take the hacker route and put the
    classes in the the client classpath. I guess I just want to know if
    this is bug? If not, I think it should be.
    Thanks for listening
    Steve Dodge
    Steve Dodge
    Realeum Inc.
    Robert Patrick wrote:
    Here is an example:
    On server1, I have a Bean called TellerBean that calls the AccountBean
    that lives on server2. To make this work, I need to deploy the
    TellerBean.jar file AND any/all AccountBean Stub classes (any file in the
    deployed version of the AccountBean.jar file matching the pattern
    AccountBean*Stub.class) on server1. Server2 only needs to deploy the
    AccountBean.jar file
    Hope this helps,
    Robert
    kamps wrote:
    Thanks.
    I did include the files using import and they are alsso packaged
    into the jar file .
    I have done this , TradeCheck is the ejb i am trying to reference
    in Trader EJB.
    I package them into the jar file as follows:-
    @REM Compile EJB classes into the build directory (jar preparation)
    javac -d build TradeCheck.java TradeCheckHome.java Trader.java
    TraderHome.java TraderBean.java TradeResult.java
    @REM Make a EJB jar file, including XML deployment descriptors
    cd build
    jar cv0f std_ejb20_basic_statelessSession2.jar META-INF examples
    images
    cd ..
    @REM Run EJBC on jar file
    java -classpath
    %WL_HOME%/lib/weblogic_sp.jar;%WL_HOME%/lib/weblogic.jar weblogic.ejbc
    -compiler javac build\std_ejb20_basic_statelessSession2.jar
    %APPLICATIONS%\ejb20_basic_statelessSession2.jar
    It still gives the same error not finding the stub class.... Could
    you kindly elaborate on what needs to be done.
    I would appreciate your help.
    Thanks,
    Sunitha
    Robert Patrick <[email protected]> wrote:
    The problem is that the client that downloads the stubs
    at runtime cannot
    be another WebLogic Server. We do not support downloading
    classes into a
    running server so you will need to make sure that the
    stubs are
    "available" to the server that is acting as a client (e.g.,
    packaged in
    the EAR file) on the server acting as a client.
    kamps wrote:
    Thanks Mahendra. I am using WebLogic 6.0. Should I importthe package
    in the first ejb which references the 2nd ejb or evenin the client
    which references the first ejb.
    Thanks again,
    Sunitha
    "Mahendra Dhamdhere" <[email protected]> wrote:
    You are not getting the reference of stub.
    try this. In your client program, import the package
    in
    which ejb classes
    are present. As client downloads the stub from weblogic,
    you have to import
    the package where your stubs are present.
    which version of weblogic are you using?
    Mahendra
    kamps <[email protected]> wrote in message
    news:[email protected]...
    Thanks,
    I have 2 ejbs: one is TraderBean and a client RefClient.
    TraderBean in turn calls a method of another bean
    TradeCheckBean.
    I tried making the changes as suggested but I amgetting
    the following
    error on the client side.
    java examples.ejb20.basic.tatelessSession.RefClient"t3://localhost:7001"
    javax.naming.CommunicationException. Root exceptionis
    java.rmi.UnmarshalException:
    failed to unmarshal class java.lang.Object; nested
    exception
    is:
    java.lang.ClassNotFoundException:examples.ejb20.basic.statelessSession.Trade
    CheckBeanHomeImpl_WLStub: This error could indicatethat a component
    was deployed on
    a cluster member but not other members of that
    cluster.
    Make
    sure that any componen
    t deployed on a server that is part of a cluster
    is
    also deployed
    on all other member
    s of that cluster
    java.lang.ClassNotFoundException:examples.ejb20.basic.statelessSession.TradeCheckBea
    nHomeImpl_WLStub: This error could indicate that
    a
    component was
    deployed on a clus
    ter member but not other members of that cluster.
    Make
    sure that
    any component deploy
    ed on a server that is part of a cluster is also
    deployed
    on all
    other members of tha
    t cluster
    <<no stack trace available>>
    I would appreciate any help.
    Thanks,
    kamps
    "Mahendra Dhamdhere" <[email protected]> wrote:
    you need to get initialcontext of that server.
    Context ctx = null;
    Hashtable ht = new Hashtable();
    ht.put(Context.INITIAL_CONTEXT_FACTORY,
    "weblogic.jndi.WLInitialContextFactory");
    ht.put(Context.PROVIDER_URL, "t3://localhost:7001");
    try
    ctx = new InitialContext(ht); // Use
    the
    context
    in your program
    } catch (NamingException e)
    {    // a failure occurred  }
    finally {    try {ctx.close();}
    catch (Exception e)
    {      // a failure occurred    } }
    use url of that other server. After getting initialcontext,
    lookup for your
    ejb.
    Mahendra
    kampu S <[email protected]> wrote in message
    news:[email protected]...
    Hi,
    I want to reference an EJB on one host inside
    another
    EJB in another
    host. Even if i hardcode the url of the host on
    which
    the EJB is
    deployed , it gives me the error regarding the
    no
    such
    ejb found.
    I would appreciate your help.
    Thanks

  • Problem While calling a session bean (J2EE)

    Hi!!
    Please see my client-side code..where I am calling a session bean (J2EE Server)
    It's correct or not?????
    InitialContext ctx = new InitialContext();
    Object objref = ctx.lookup("SecDbSecRoleJndi");
    SecBusSecRoleHome home =(SecBusSecRoleHome)PortableRemoteObject.narrow(objref,SecBusSecRoleHome.class);
    SecBusSecRoleRemote remote =(SecBusSecRoleRemote)PortableRemoteObject.narrow(home.create(),SecBusSecRoleRemote.class);
    Here I am getting the error at 3rd line
    java.lang.ClassCastException
    at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:296)
    at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
    at TestServlet.init(TestServlet.java:22)
    Please do the favor to me..reply me back.
    Bhumika

    Hello,
    Hope you are bale to sole the problem by this time. Iam using the follwing code and its working fine for me. i'm using the weblogic application server.
    <%@ page import="javax.naming.*, java.rmi.*, javax.ejb.*, java.util.*,java.rmi.server.*,java.net.*,javax.rmi.PortableRemoteObject,com.hmp.webcasting.services.ejb.*"%>
    <%
    try{             
    Properties prop = new Properties();
    prop.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
              System.out.println("Hello......3333333333Test");
              prop.put(Context.PROVIDER_URL, "t3://pani:7001");
              InitialContext ctx = new InitialContext(prop);
    Object home = ctx.lookup("personMgr");
              KeywordsMgrHome roleHome = (KeywordsMgrHome) javax.rmi.PortableRemoteObject.narrow(home, KeywordsMgrHome.class);
              KeywordsMgr kmgr=roleHome.create();
              //KeywordsMgrHome roleHome = (KeywordsMgrHome) ctx.lookup("personMgr");;
              System.out.println(roleHome);
              System.out.println(kmgr);
              }catch(Exception e){
              e.printStackTrace();
              %>
    Try using this.
    Genrally calss cast exception occurs if you are using classes out of a shared library directory instead of within the webapp, or if you are somehow maintaining references to object instances created with the old class and trying to use them after the reload. So try to delete the old file files and deploy the bean once again . Hope this may help you. Anyway if you can give the full code i will check by deploying it.([email protected])

  • Problem with Call Transaction opt-RACOMMIT = 'X'.

    Hello Experts
    I am having a problem with call transction. I am calling a Z transaction in function module. Within the Z transaction I am furhter calling some function modules and doing commit work and then some more processing  after the comit work inside  So to make sure the code after comit work is fired I am using opt-RACOMMIT = 'X' in call transaction. Whenever I set this parameter opt-RACOMMIT = 'X' call transaction fails and gives error saying No batch Input data for screen XXXX. However the Z tcode processed succesfully.
    By changing the Mode to E i found that it remians at the last screen of call transction after executing the Z transaction and never comes back 
    But if I donot use RACOMMIT = 'X'  everything is fine. Please let me know if anyone came across such problem. Any help will be apreciated.
    Thanks,
    kamal

    Hello,
    as you said, if there is more than commit statement in your ztransaction, then you should put RACOMMIT to 'X'.
    I think the problem is in your bdcdata: change it to be sure to get back to the 1st screen of your ztransaction. Then, at this point (1st screen) hit "back" button.
    Cordialement,
    Chaouki

  • Problem with calling onApplicationStart() method

    Hi all,
         I have a problem with calling application.cfc's methods from coldfusion template. The problem is like when i am calling "onapplicationstart" method inside a cfml template i getting the error shown below
    The onApplicationStart method was not found.
    Either there are no methods with the specified method name and argument types or the onApplicationStart method is overloaded with argument types that ColdFusion cannot decipher reliably. ColdFusion found 0 methods that match the provided arguments. If this is a Java object and you verified that the method exists, use the javacast function to reduce ambiguity.
    My code is like below.
    Application.cfc
    <cfcomponent hint="control application" output="false">
    <cfscript>
    this.name="startest";
    this.applicationtimeout = createtimespan(0,2,0,0);
    this.sessionmanagement = True;
    this.sessionTimeout = createtimespan(0,0,5,0);
    </cfscript>
    <cffunction name="onApplicationStart" returnType="boolean">
        <cfset application.myvar = "saurav">
    <cfset application.newvar ="saurav2">
        <cfreturn true>
    </cffunction>
    </cfcomponent>
    testpage.cfm
    <cfset variables.onApplicationStart()>
    I have tried to call the above method in different way also like
    1--- <cfset onApplicationStart()>
    i got error like this
    Variable ONAPPLICATIONSTART is undefined.
    2---<cfset Application.onApplicationStart()>
    The onApplicationStart method was not found.
    Either there are no methods with the specified method name and argument types or the onApplicationStart method is overloaded with argument types that ColdFusion cannot decipher reliably. ColdFusion found 0 methods that match the provided arguments. If this is a Java object and you verified that the method exists, use the javacast function to reduce ambiguity
    Please help me out.
    Thanks
    Saurav

    You can't just call methods in a CFC without a reference to that CFC. This includes methods in Application.cfc.
    What are you trying to do, exactly, anyway? You'd probably be better served by placing a call to onApplicationStart within onRequestStart in Application.cfc, if your goal is to refresh the application based on some condition:
    <cffunction name="onRequestStart">
         <cfif someCondition>
              <cfset onApplicationStart()>
         </cfif>
    </cffunction>
    Dave Watts, CTO, Fig Leaf Software
    http://www.figleaf.com/
    http://training.figleaf.com/

  • Call another WebLogic's EJBs from resource adapter?

              Is it possible to call another WebLogic's EJBs from a resource adapter?
              A call to the javax.naming.InitialContext(Hashtable environment) results in a
              VersioningError:
              weblogic.common.internal.VersioningError: Incompatible service packs in CLASSPATH:
              (BEA Systems, WebLogic Server 6.1 SP4 11/08/2002 21:50:43 #221641 , 6.1.4.0)
              not compatible with
              (BEA Systems, WebLogic Server 6.1 SP3 06/19/2002 22:25:39 #190835 , 6.1.3.0)
              at weblogic.common.internal.VersionInfo.verifyPackages(VersionInfo.java:128)
              at weblogic.common.internal.VersionInfo.<init>(VersionInfo.java:60)
              at weblogic.common.internal.VersionInfo.initialize(VersionInfo.java:79)
              at weblogic.kernel.Kernel.initialize(Kernel.java:122)
              at weblogic.kernel.Kernel.ensureInitialized(Kernel.java:101)
              at weblogic.jndi.WLInitialContextFactoryDelegate.<init>(WLInitialContextFactoryDelegate.java:166)
              at java.lang.Class.newInstance0(Native Method)
              at java.lang.Class.newInstance(Class.java:232)
              at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:147)
              at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:241)
              at javax.naming.InitialContext.init(InitialContext.java:217)
              at javax.naming.InitialContext.<init>(InitialContext.java:193)
              at java.lang.reflect.Constructor.newInstance(Native Method)
              I'm not sure it will always be possible to match the version, although here upgrading
              the SP3 to SP4 will probably be done soon.
              Does anyone have experience with this?
              Or better: is there any documentation on this issue?
              

              Hi Hans,
              Here is the link for Weblogic SP3 / SP4 vulnerability and comparison for
              http://216.239.53.104/search?q=cache:RqqaQ3HZdwoJ:www.nipc.gov/cybernotes/2003/cyberissue2003-06.pdf+Versioning+Error+in+BEA+weblogic+6.1+SP3+and+SP4&hl=en&ie=UTF-8
              Hope this will help you.
              Let me know if u have any further problems.
              rgds
              KSK
              "Hans Bausewein" <[email protected]> wrote:
              >
              >
              >Is it possible to call another WebLogic's EJBs from a resource adapter?
              >
              >A call to the javax.naming.InitialContext(Hashtable environment) results
              >in a
              >VersioningError:
              >
              >weblogic.common.internal.VersioningError: Incompatible service packs
              >in CLASSPATH:
              >(BEA Systems, WebLogic Server 6.1 SP4 11/08/2002 21:50:43 #221641 ,
              >6.1.4.0)
              >not compatible with
              >(BEA Systems, WebLogic Server 6.1 SP3 06/19/2002 22:25:39 #190835 , 6.1.3.0)
              > at weblogic.common.internal.VersionInfo.verifyPackages(VersionInfo.java:128)
              > at weblogic.common.internal.VersionInfo.<init>(VersionInfo.java:60)
              > at weblogic.common.internal.VersionInfo.initialize(VersionInfo.java:79)
              > at weblogic.kernel.Kernel.initialize(Kernel.java:122)
              > at weblogic.kernel.Kernel.ensureInitialized(Kernel.java:101)
              > at weblogic.jndi.WLInitialContextFactoryDelegate.<init>(WLInitialContextFactoryDelegate.java:166)
              > at java.lang.Class.newInstance0(Native Method)
              > at java.lang.Class.newInstance(Class.java:232)
              > at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:147)
              > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:241)
              > at javax.naming.InitialContext.init(InitialContext.java:217)
              > at javax.naming.InitialContext.<init>(InitialContext.java:193)
              > at java.lang.reflect.Constructor.newInstance(Native Method)
              >
              >
              >
              >I'm not sure it will always be possible to match the version, although
              >here upgrading
              >the SP3 to SP4 will probably be done soon.
              >
              >Does anyone have experience with this?
              >
              >Or better: is there any documentation on this issue?
              >
              

  • How do I run a JCA adapter when I am calling it from an EJB?

    How do I run a JCA adapter when I am calling it from an EJB? Do I need to create an EJB client and place it in a Client container? If my EJB and JCA adapter are deployed is there a way to call my EJB from the command line?
    Mike

    Hi. When you look at the code I provided for you in other thread you will see that connecting to adapter is done through JNDI lookup. The creation of the adapter is done in your J2EE server. Here is some code for you where you can find mapping from code to ejb-jar and orion-ejb-jar.
    ejb-jar.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"
    version="2.1">
    <!--
    This file declares the interface (needs/promises) of the message-driven bean.
    The MDB requires:
    - a JMS queue (to receive messages from the client),
    - a JMS exception queue (to send undeliverable messages back to the source), and
    - a connection factory (to communicate with a JMS resource provider).
    Note that communication with the resource provider may be (and for this
    application is) via a JMS Connector rather than direct.
    -->
    <display-name>JMS Consume MDB - opp-ifs</display-name>
    <enterprise-beans>
    <entity>
    <description>Entity Bean ( BMP )</description>
    <display-name>EBEjbMecomsIFS</display-name>
    <ejb-name>EBEjbMecomsIFS</ejb-name>
    <local-home>EBEjbMecomsIFSLocalHome</local-home>
    <local>EBEjbMecomsIFSLocal</local>
    <ejb-class>EBEjbMecomsIFSBean</ejb-class>
    <persistence-type>Bean</persistence-type>
    <prim-key-class>java.lang.Long</prim-key-class>
    <reentrant>false</reentrant>
    <service-ref>
    <service-ref-name>service/interceptor</service-ref-name>
    <service-interface>javax.xml.rpc.Service</service-interface>
    <wsdl-file>META-INF/wsdl/MHS5_Jms_In_RS.wsdl</wsdl-file>
    <service-qname xmlns:ns="http://oracle.com/esb/namespaces/PilotOWSM_MustHavesScenario5">ns:ESB_MHS5_Jms_In_RS_Service</service-qname>
    </service-ref>
    </entity>
    <message-driven>
    <display-name>JMS Consume MDB - MDB</display-name>
    <ejb-name>MDBEjbMecomsIFS</ejb-name>
    <!-- name of bean in deployment descriptor (including orion-ejb-jar.xml file) -->
    <ejb-class>MDBEjbMecomsIFSBean</ejb-class>
    <!-- bean's fully qualified Java class name -->
    <messaging-type>javax.jms.MessageListener</messaging-type>
    <transaction-type>Container</transaction-type>
    <!-- allow incoming messages to be included in transactions -->
    <!-- The ejb requires a connection factory to access an external resource (JMS). -->
    <ejb-local-ref>
    <ejb-ref-name>ejb/local/EBEjbopp_ifs</ejb-ref-name>
    <ejb-ref-type>Entity</ejb-ref-type>
    <local-home>EBEjbMecomsIFSLocalHome</local-home>
    <local>EBEjbMecomsIFSLocal</local>
    <ejb-link>EBEjbMecomsIFS</ejb-link>
    </ejb-local-ref>
    <resource-ref>
    <!-- The resource's connection factory must be accessible at jndi location "java:comp/env/jms/QueueConnectionFactory". -->
    <res-ref-name>jms/QueueConnectionFactory</res-ref-name>
    <!-- The resource's connection factory must implement the "javax.jms.ConnectionFactory" interface. -->
    <res-type>javax.jms.ConnectionFactory</res-type>
    <!-- container managed authorization -->
    <res-auth>Container</res-auth>
    </resource-ref>
    </message-driven>
    </enterprise-beans>
    <assembly-descriptor>
    <!--
    Declare that a global transaction is required when the onMessage method of the ejb named
    "MDBEjbName" is called. This will cause the app server to automatically initiate a
    global (XA) transaction before calling onMessage (actually, before even receiving the JMS
    message that triggers onMessage) and end the transaction after onMessage returns. The
    JMS Connector will automatically rollback the transaction if onMessage throws an
    exception. onMessage may also set the transaction to be "rollback only".
    Participating in global transactions requires that the connection factory provided in the
    activation spec (see the ConnectionFactoryJndiName property earlier in this file) must be
    XA-capable (it must implement the javax.jms.XAConnectionFactory interface).
    If this declaration is ommitted, then onMethod will not be part of any global
    transaction. In that case the connection factory provided in the activation spec must
    implement the javax.jms.ConnectionFactory interface.
    -->
    <container-transaction>
    <method>
    <ejb-name>MDBEjbMecomsIFS</ejb-name>
    <method-name>onMessage</method-name>
    </method>
    <trans-attribute>Required</trans-attribute>
    </container-transaction>
    <container-transaction>
    <method>
    <ejb-name>EBEjbMecomsIFS</ejb-name>
    <method-name>*</method-name>
    </method>
    <trans-attribute>Supports</trans-attribute>
    </container-transaction>
    </assembly-descriptor>
    </ejb-jar>
    orion-ejb-jar.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <orion-ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNameSpaceSchemaLocation="http://www.oracle.com/technology/oracleas/schema/orion-ejb-jar-10_0.xsd">
    <enterprise-beans>
    <entity-deployment name="EBEjbMecomsIFS">
    <service-ref-mapping name="service/interceptor">
    <wsdl-location>http://on-poc62.ontw.alfa.local:7777/event/PilotOWSM/MustHavesScenario5/MHS5_Jms_In_RS?wsdl</wsdl-location>
    <service-qname localpart="ESB_MHS5_Jms_In_RS_Service" namespaceURI="http://oracle.com/esb/namespaces/PilotOWSM_MustHavesScenario5"/>
    <port-info>
    <wsdl-port namespaceURI="http://oracle.com/esb/namespaces/PilotOWSM_MustHavesScenario5"
    localpart="__soap_MHS5_Jms_In_RS_execute_ppt"/>
    <service-endpoint-interface>javax.xml.rpc.Service</service-endpoint-interface>
    <call-property>
    <name>javax.xml.rpc.service.endpoint.address</name>
    <value>http://on-poc62.ontw.alfa.local:7777/event/PilotOWSM/MustHavesScenario5/MHS5_Jms_In_RS</value>
    </call-property>
    <call-property>
    <name>javax.xml.rpc.soap.http.soapaction.uri</name>
    <value>execute</value>
    </call-property>
    <call-property>
    <name>javax.xml.rpc.soap.http.soapaction.use</name>
    <value>true</value>
    </call-property>
    <call-property>
    <name>javax.xml.rpc.soap.operation.style</name>
    <value>document</value>
    </call-property>
    <runtime enabled="owsm">
    <owsm init-home="/oracle/product/SoaAs/10.1.3/owsm/config/interceptors/C0003002"
    init-file="confluent.properties"/>
    </runtime>
    </port-info>
    </service-ref-mapping>
    </entity-deployment>
    <message-driven-deployment name="MDBEjbMecomsIFS"
    resource-adapter="OEMSJMSDRAopp-ifs"
    enabled="true" max-instances="10">
    <!--
    The ejb requires a connection factory implementing the "javax.jms.XAConnectionFactory"
    interface to be accessible at jndi location "java:comp/env/jms/QueueConnectionFactory". (see ejb-jar.xml and ....)
    A suitable connection factory is already accessible at jndi location "OEMSJMSDRASubcontext/MyXACF" (see oc4j-ra.xml)
    -->
    <resource-ref-mapping location="OEMSJMSDRASubopp-ifs/MyXACF"
    name="jms/QueueConnectionFactory"/>
    <!-- don't misspell this or you'll get an RP CF which doesn't work -->
    <!-- Required activation-spec properties. -->
    <!--
    ConnectionFactoryJndiName (string, no default)
    This should be the JNDI location of an RA connection factory.
    The JMS Connector will use this connection factory to create the JMS
    connection it uses to receive messages for this MDB's onMessage. If the
    exception queue is enabled (see UseExceptionQueue), the JMS Connector will
    also use a connection created from this connection factory for the production
    of messages to the exception queue.
    This connection factory must be compatible with the message domain(s). (For
    example, if the MDB is receiving messages from a queue, the connection
    factory should implement javax.jms.[XA]QueueConnectionFactory or
    javx.jms.[XA]ConnectionFactory.)
    For XA/non-XA considerations, see the <container-transaction> comments later
    in this file.
    -->
    <config-property>
    <config-property-name>ConnectionFactoryJndiName</config-property-name>
    <config-property-value>OEMSJMSDRASubopp-ifs/MyXAQCF</config-property-value>
    </config-property>
    <!--
    DestinationName (string, no default)
    This is JNDI location of the queue or topic from which messages to be
    delivered to the MDB's onMessage method should be received.
    The JNDI locations for RA destinations are defined in the
    oc4j-connectors.xml file.
    -->
    <config-property>
    <config-property-name>DestinationName</config-property-name>
    <config-property-value>OEMSJMSDRASubopp-ifs/MyQ</config-property-value>
    </config-property>
    <!--
    DestinationType (string, no default)
    This must be set to the type of the destination named by the above
    "DestinationName" property.
    The EJB 2.1 spec states that this must be set to either javax.jms.Queue or
    javax.jms.Topic. OracleGJRA also allows it to be set to
    javax.jms.Destination (which works for both queues and topics).
    -->
    <config-property>
    <config-property-name>DestinationType</config-property-name>
    <config-property-value>javax.jms.Queue</config-property-value>
    </config-property>
    <!--
    Other activation-spec properties.
    The following activation-spec properties supported by OracleGJRA are optional
    except where otherwise noted:
    -->
    <!--
    ListenerThreadMaxPollInterval (milliseconds, 5000)
    Listener threads "poll" to see if there is a message waiting to be processed.
    The more frequently this polling is performed, the faster (on average) a given
    listener thread can respond to a new message. The price for frequent polling is
    overhead - the resource provider must process a receive request each time it is
    polled.
    Oracle's JMS Connector implementation applies an adaptive algorithm which
    uses shorter polling intervals (high polling rates) during periods of activity
    (once activity is noticed) and longer polling intervals (lower polling rates)
    during periods of inactivity. The ListenerThreadMaxPollInterval property places
    an upper limit on the polling interval used by this adaptive algorithm.
    -->
    <config-property>
    <config-property-name>ListenerThreadMaxPollInterval</config-property-name>
    <config-property-value>5000</config-property-value>
    </config-property>
    <!--
    AcknowledgeMode (string, default = Auto-acknowledge)
    This should be set to Auto-acknowledge or Dups-ok-acknowledge. This
    controls the quality-of-service provided by listener threads which
    consume messages and call the MDB's onMessage method.
    MessageSelector (string, default = no message filtering)
    This is the selector expression used to filter messages sent to the
    MDB's onMessage method. (I.e., this is used as the messageSelector for
    the JMS sessions created for the listener threads.)
    SubscriptionDurability (string, default = NonDurable)
    For topics this should be set to Durable or NonDurable. (This should
    not be set for queues.) This controls the durability of the topic
    consumer used by the listener thread. When SubscriptionDurability is
    set to Durable (and DestinationType is javax.jms.Topic or
    javax.jms.Destination), the SubscriptionName property is required.
    SubscriptionName (string, no default)
    This property is required when SubscriptionDurability is Durable (and
    DestinationType is javax.jms.Topic or javax.jms.Destination). (In all
    other cases it is ignored.) This is the name used when creating the
    durable subscriber used by the listener thread. For a given JMS server,
    a given subscription name should be assigned to at most one MDB (which
    must have most one listener thread).
    ClientId (string, no default)
    If set, connection(s) used by the listener threads will be set to use
    this client ID.
    TransactionTimeout (milliseconds, default = 300,000)
    This limits the amount of time that the JMS Connector will wait for a
    message to arrive before exiting the current transaction. The
    transaction manager limits the amount of time a transaction can last
    (see transaction-timeout in transaction-manager.xml).
    TransactionTimeout should be set such that the transaction manager will
    not timeout the transaction during the onMessage routine unless
    something is wrong. For example, If the transaction mananager timeout
    is set to 30 seconds, and the onMessage routine will never take more
    than 10 seconds unless something is wrong, then this property could be
    set to 20 seconds (20000 milliseconds).
    EndpointFailureRetryInterval (milliseconds, default = 60,000)
    If an endpoint can not be processed (due to the app server WorkManager
    not accepting new work), it will be scheduled to be retried this many
    milliseconds later.
    ReceiverThreads (integer, default = 1)
    This sets the maximum number of listener threads to create for this
    endpoint. For queues, using more than one thread may be useful in
    increasing the rate at which messages can be consumed. For topics this
    value should always be 1. (Each listener thread gets its own session
    and TopicSubscriber. For durable subscribers it would be an error to
    have more than one subscriber with the same subscription name. For
    nondurable subscribers having more than one thread will not help because
    more threads translates into more subscribers which translates into more
    copies of each message.) See also: ListenerThreadMinBusyDuration
    UseExceptionQueue (boolean, default = false)
    When "UseExceptionQueue" is true:
    - Messages that would otherwise be discarded are sent to the
    exception queue. (Currently the only case where this happens is
    when the max delivery count is exceeded. See MaxDeliveryCnt
    property.) Rather than sending the original message directly to
    the exception queue, the following procedure is used:
    o Create a new message of the same type.
    o Copy the properties and body from the original message to the
    new message.
    o If the headers were copied, sending the message to the
    exception queue would cause most of them to be lost
    (over-written by the resource-provider). So instead,
    translate headers in the original to properties in the copy,
    assigning each header obtained via "getJMS{Header}" to
    property "GJRA_CopyOfJMS{Header}". Since
    javax.jms.Destination is not a valid property type, translate
    destination headers into descriptive messages.
    (Currently this same service is not provided for JMSX*
    properties, most notably the JMSXDeliveryCount property.)
    o If some part of the copy process (above) or augmentation
    process (below) fails, do not abort. Attempt to complete the
    rest of the procedure. (For Bytes/Map/Stream message types,
    this can mean that part of the body is copied and the rest is
    not.)
    o If the copy process is 100% successful, add a boolean property
    called "GJRA_CopySuccessful" with the value "true".
    o Add a string property called "GJRA_DeliveryFailureReason" which
    indicates why the message was not delivered.
    o If the MDB onMessage method generated an exception immediately
    prior to the delivery failure, add a string property called
    "GJRA_onMessageExceptions" which contains exception information.
    o Send the resulting message to the exception queue.
    Note that only one attempt is made to send the message to the
    exception queue. Should this attempt fail, the message will
    be discarded without being placed in the exception queue.
    See IncludeBodiesInExceptionQueue property for potential variations
    of the above procedure.
    - The ExceptionQueueName property is required.
    - In addition to being used for the primary destination, the
    connection factory specified by the ConnectionFactoryJndiName
    property will also be used for the exception queue. If the primary
    destination (specified by the DestinationName property) is a topic,
    then the connection factory must support both queues and topics.
    (I.e., the <connectionfactory-interface> [see oc4j-ra.xml] for the
    given connection factory must be either javax.jms.ConnectionFactory
    or javax.jms.XAConnectionFactory.)
    ExceptionQueueName (string, no default)
    This is the JNDI location of the javax.jms.Queue object to use as the
    exception queue. (See UseExceptionQueue property for information about
    the use of the exception queue.) This property is required when
    UseExceptionQueue is true, and ignored when UseExceptionQueue is false.
    IncludeBodiesInExceptionQueue (boolean, default = true)
    This controls whether or not messages sent to the exception queue will
    include a message body. (See UseExceptionQueue property for information
    about the use of the exception queue.) If many messages are sent to the
    exception queue during normal operation and the message body is of no
    use in the exception queue, then this property may be set false to
    improve performance. This property is ignored when UseExceptionQueue is
    false. There are two cases where this property does not apply:
    - If the original message did not have a message body, then the
    message sent to the exception queue will not have one either.
    - If a copy of the original message can not be created for any
    reason, then the original may be sent to the exception queue
    instead. This may result in a message body being sent to the
    exception queue.
    MaxDeliveryCnt (integer, default = 5)
    If a message has the "JMSXDeliveryCount" property and the value of that
    property is greater than MaxDeliveryCnt, then the message will be
    discarded (and not sent to onMessage). If the exception queue is
    enabled (see UseExceptionQueue), a copy of the message will be sent to
    the exception queue. If MaxDeliveryCnt is set to 0, no messages will be
    discarded. (Note that when an MDB responds to a message by throwing an
    exception, the message is not considered delivered and it may be
    redelivered. If the MDB might always respond to a given message by
    throwing an exception, and MaxDeliveryCnt is set to 0 to prevent the
    message from ever being discarded, the result may be an MDB stuck in an
    "infinite loop" - failing to process the same message over and over
    again.)
    -->
    <config-property>
    <config-property-name>MaxDeliveryCnt</config-property-name>
    <config-property-value>0</config-property-value>
    </config-property>
    <!--
    LogLevel (string, no default)
    This controls the level of detail of messages logged by the JMS
    Connector. These messages are primarily intended for debugging the
    JMS Connector itself, but may also be useful when debugging issues
    related to the use of the JMS Connector. This property should not be
    set in production code. (It should only be set temporarily for
    debugging purposes - specific log messages and log levels may be and
    will be added/removed/modified in future versions of the JMS
    Connector.) Currently the allowed values are:
    ConnectionPool
    ConnectionOps
    TransactionalOps
    ListenerThreads
    INFO
    CONFIG
    FINE
    FINER
    FINEST
    SEVERE
    WARNING
    OFF
    ListenerThreadMaxIdleDuration (milliseconds, default = 300,000)
    This is how long a listener thread which is not receiving any messages
    will be kept around. (At least one listener thread will remain as long
    as the endpoint is active.)
    ListenerThreadMinBusyDuration (milliseconds, default = 10,000)
    If a listener thread has just received a message, has not been idle (had to
    wait for a new message to arrive) at any point during the past
    ListenerThreadMinBusyDuration milliseconds, and the current number of
    listener threads for this endpoint is less than ReceiverThreads, then
    (application server willing) an additional listener thread will be created.
    ResUser (string, default = null)
    ResPassword (string, default = null)
    These properties allow a user/password to be passed to the resource
    provider. When neither of these properties are set, connections used for
    this MDB's inbound message handling (as well as for exception queue
    handling, if enabled) are created using the no-argument version of the
    create*Connection method. When one or both of these properties are set,
    they are passed to the create*Connection method as the user/password
    arguments. (If only one property is not set, then 'null' is used for that
    particular create*Connection argument.) The ResPassword property supports
    the standard password indirection options (e.g., using "->joeuser" to
    represent the password of "joeuser").
    Note that the commas used in many of the above default values and examples are
    included here for readability but can not be used in the actual activation spec.
    (I.e., integer/milliseconds values in the activation spec must not include
    embedded commas.)
    -->
    </message-driven-deployment>
    </enterprise-beans>
    <assembly-descriptor>
    <default-method-access>
    <security-role-mapping name="&lt;default-ejb-caller-role>"
    impliesAll="true"/>
    </default-method-access>
    </assembly-descriptor>
    </orion-ejb-jar>

Maybe you are looking for