Deploying Session EJB From Jdev9i(Beta) - OC4J 9i

Hi All ,
I wanted from u , i have recently Upgraded to Oracle 9i 1.0.2.2.1 (OC4J) . Now i want a simple Step wise process as how can i deploy my Ejb (Session Bean ) into the OC4J container and Use its DataSource .
Is it possible to deploy using Jdev 9i (Beta) .
Can any one please help me out to point to a Documentaion , give me a breif process .
Regards
Asif

Asif -
Yes you can use Jdeveloper 9i beta to deploy your session ejb.
Step 1 should be setting up your Data Source. In the System
Navigator Panel expand the "Connections" listing. Right-click
on "Database" and select "New Connection..." - follow the
wizard's instructions to set up your data source. Step 2 should
be setting up a connection to the OC4J container - again on the
System Navigator Panel ->Connections->Application Servers -
follow the instructions there. I am assuming that you have
developed your session ejb using Jdeveloper, right click on
your .jpr entry (or wherever suits you) and choose "New..." then
Deployment Profiles. You need to package your session ejb into a
jar file and I would recommend packaging your jar file into an
ear file (it really helps for clean deployment). If you have a
web portion, package that and make it dependent on the jar file
just to keep it straight. Once you have these, you will be able
to right click on the jar or web file and deploy to an ear file,
or straight to the server. If this is what you are looking for,
you will then just select this and away you go.
Apparently there are some howtos here:
http://otn.oracle.com/docs/products/jdev/howto.html
although I don't know how good they are.
I wasn't quite sure what you were looking for so this post is
vague. If you have specific questions, let me know and I will
try and answer them!
Cheers
Ray

Similar Messages

  • Urgent!!!!How to deploy only an EJB from Weblogic to oc4j.

    Hi
    How can i deploy only EJB from Weblogic into oc4j without any web application or client coming into pitcture as my client access bean remotely....
    regards,
    Sapthapathi

    If you are migrating from ejb1.1->ejb1.1 you shouldn't have many changes - your ejb-jar.xml file should be the same (I assume you are still talking about ejbs). Once you pull over the base ejb - then if you want to, mess around with the automatically generated orion-ejb-jar.xml file. Obviously - those are all app server specific. I go back and forth between wls6.1 and oc4j all the time. When going from wls5.1 to oc4j - what particular issues do you run into. What do you mean, in particular, by configuration changes?
    Curious -
    Ray
    hi,
    EJBs and other applications can be migrated from weblogic to oc4j but many changes are required.These changes are mainly configuration changes rather than code changes.Infact there are many problems in effect while migrating and delloyment.Hope oracle is a bit more attentive to this issue.
    regards,
    chennai

  • How to call session EJB from EP service in EP 7.0?

    Hi,
    I am trying to invoke stateless session EJB from my portal service. Both the service and EJB are deployed on the same server which is EP 7.0.
    I found [this|http://help.sap.com/saphelp_nw70/helpdata/EN/42/9ddcc9bb211d72e10000000a1553f6/frameset.htm] in SAP help and tried to implement it (added PrivateSharingReference to portalapp.xml and implemented the code), but everytime I try to lookup the session bean and cast it using P4ObjectBroker.narrow() method, I get java.lang.ClassCastException. The object found in JNDI and my portal service have different classloaders, so I suppose this is the problem, but I don't know how to handle it...
    Can anyone please help me?
    Regards,
    Tomas

    Hi Satya ,
              please go though following blog for used DC concept.
    Componentization of Webdynpro Application in CE7.1
    In netweaver 7.1 interface controler is abstract and component controller is implementing interface controller so the context data and methods have to be implemented by component controller

  • IIOP Connection Hangs: Deploying Hotel EJB from Technet

    Hi,
    I was trying to deploy the EJB from the sample hotel application
    available at TECHNET. The System is using the standard ORacle 8i
    port for ORB.
    Please help identify the connection failure for IIOP connection.
    REgards
    Arvinder
    null

    Can you connect via the session shell to the orb namespace (with
    the same service URL you are trying to deploy to) from the same
    machine? This will validate the IIOP communiactions is working.
    If the connection isn't working it may take quite some time to
    actually error out.
    null

  • WL8.1 crashed during deployment of EJB from ear file

    Hello,
    WL8.1 crashed during deployment of EJB from ear file on SunOs 5.8:
    error: Invalid class file format in /export/home/bea/j2sdk1.4.1_03/jre/lib/rt.jar(java/lang/AssertionError.class).
    The major.minor version '48.0' is too recent for this tool to understand.
    /export/home/mydomain/./ep1/.wlnotdelete/EJBCompilerCache/1xd25ws3hwp86/mydomain/facade/payroll/PayrollFL_vww01c_HomeImpl.java:83:
    Class java.lang.AssertionError not found.
    throw new AssertionError("Unable to find expected "+
    Thanks,
    Oleg.

    Thank you Mark,
    It works now.
    Oleg.
    "Mark Griffith" <[email protected]> wrote:
    I don't think though that _03 is the problem, you should have compatability
    between minor versions of a VM release. How did you deploy the ear?
    Did
    you copy over from a 7.0 domain? It looks like the EJB was built on
    a
    previous version of WLS, or has not had "ejbc" run on it prior to
    deployment. Try running weblogic.appc foo.ear or fooExplodedEar. And
    then
    try redeploying. To be sure everything is clean rm -rf .wldonotdelete
    after
    you shut the server down.
    cheers
    mbg
    "Oleg" <[email protected]> wrote in message
    news:3ef54653$[email protected]..
    Hello,
    WL8.1 crashed during deployment of EJB from ear file on SunOs 5.8:
    error: Invalid class file format in/export/home/bea/j2sdk1.4.1_03/jre/lib/rt.jar(java/lang/AssertionError.class
    The major.minor version '48.0' is too recent for this tool to understand.
    /export/home/mydomain/./ep1/.wlnotdelete/EJBCompilerCache/1xd25ws3hwp86/mydo
    main/facade/payroll/PayrollFL_vww01c_HomeImpl.java:83:
    Class java.lang.AssertionError not found.
    throw new AssertionError("Unable to find expected "+
    Thanks,
    Oleg.

  • Using Session EJB from MDB in Weblogic 11G

    I am having trouble with what should be a very simple operation. I have created an MDB and deployed it successfully on the Weblogic managed server. Then in a separate application, I created a Stateless session bean that I would also like to call from the MDB. My SSB deploys and works fine. I added an @EJB annotation to the MDB so I could instantiate and access the SSB from the MDB. In order to resolve the interface class in jDeveloper, I went to my MDB project properties under libraries and classpath and added the jar file for my ejb.
    When I try to redeploy the MDB, I get a java.lang.ClassNotFoundException on the SSB interface class.
    Is there an example somewhere of how to properly create and configure all of the deployment packages and refereneces I need on the weblogic server? The SSB is a common service that going to be called by a lot of other MDBs in my system. Optimally, what I would like to do is to deploy the ejb-client.jar as a shared library so all of my MDBs can use it.
    Thanks for any pointers!

    I am using jDeveloper 11g, so both my MDB and SLSB were built and deployed using the wizzards in the IDE.
    The MDB is inside of an ejb-jar and deployed to a managed server. I am doing my development on a box that is resource challenged so I setup my WLS on a different box. There is an admin server (AdminServer) and a separate soa server (soa_server1) on which I have installed all of the SOA Suite packages.
    The SLSB represents a primary service for the system I am building. Service1SessionBean is deployed targeted to soa_server1. The MDB is also deployed to soa_server1. At least it was until I tried to add the EJB reference. Now it won't deploy at all.
    I would like to avoid packaging the Service1SessionBean client jar in with the MDB because there are several other EJBs that will also need to call the service. I would like to deploy the client jar as a shared library on soa_server1 so that any EJB artifacts that need to call it may do so, I have tried to deploy the client jar as a shared library using jDeveloper but when it deploys, it seems to be under the name "j2ee-app" rather than Service1SessionBean.

  • Deploying session Ejbs 1.1 in Weblogic 6

    I am deploying a session EJB 1.1 in Weblogic 6.0, this ejb contains a class that it connects to a JMS queue, this works perfectly in weblogic 5.1 but when I try to deploying in weblogic 6.1 the exception weblogic.rmi.extensions.UnknownHostIDException arises. I'd checked the weblogic.jar file, in fact this file do not contain that class, why should I do to deploy my EJB in weblogic 6.1?

    Alex,
    Are you experiencing the problem on 6.1 or 6.0? Your posting is confusing regarding which version of the server you are trying to deploy the bean on. Have you rebuilt the ejb, or are you trying to deploy the bean directly without rebuilding it from 5.1?
    Glenn Dougherty
    Developer Relations Engineer
    BEA Support
    Alex wrote:
    I am deploying a session EJB 1.1 in Weblogic 6.0, this ejb contains a class that it connects to a JMS queue, this works perfectly in weblogic 5.1 but when I try to deploying in weblogic 6.1 the exception weblogic.rmi.extensions.UnknownHostIDException arises. I'd checked the weblogic.jar file, in fact this file do not contain that class, why should I do to deploy my EJB in weblogic 6.1?

  • Invalid username/password connecting to deployed session EJB (to OAS)

    Hello,
    OAS version : 9.0.4.0.0
    JDeveloper version : 10.1.2.0.0 (Build 1811)
    I have generated a very simple session EJB with the EJB
    Diagram : business logic is only a method returning a
    "hello world" String (no DB connection).
    Next i have generated a "New Sample Java Client" to test
    that, first connecting to the Embedded OC4J and it worked
    very well.
    Then i wanted to deploy this small example to my OAS
    server, so i created a new session EJB deployment profile.
    Deployment worked very well too.
    To test this, i generated another "New Sample Java
    Client", but that time i choosed "Connect to Remote App
    Server", with adequate J2EE application and App Server
    Connection names.
    I took note of the new context lines. Login/password
    strings were automatically filled with the ones i use to
    connect to OEM Website (lets say the_login/the_password).
    But unfortunately, when i launch the client, it doesn't
    work. Here is the error stack :
    C:\jdev1012\jdk\bin\javaw.exe -ojvm -classpath C:\dev\jdev\mywork\DarkWork\DarkProject\classes;C:\jdev1012\jdev\lib\jdev-rt.jar;C:\jdev1012\j2ee\home\lib\activation.jar;C:\jdev1012\j2ee\home\lib\ejb.jar;C:\jdev1012\j2ee\home\lib\jaas.jar;C:\jdev1012\j2ee\home\lib\jaxp.jar;C:\jdev1012\j2ee\home\lib\jcert.jar;C:\jdev1012\j2ee\home\lib\jdbc.jar;C:\jdev1012\j2ee\home\lib\jms.jar;C:\jdev1012\j2ee\home\lib\jndi.jar;C:\jdev1012\j2ee\home\lib\jnet.jar;C:\jdev1012\j2ee\home\lib\jsse.jar;C:\jdev1012\j2ee\home\lib\jta.jar;C:\jdev1012\j2ee\home\lib\mail.jar;C:\jdev1012\j2ee\home\lib\servlet.jar;C:\jdev1012\j2ee\home\oc4j.jar;C:\jdev1012\opmn\lib\optic.jar;C:\jdev1012\lib\xmlparserv2.jar;C:\jdev1012\lib\xmlcomp.jar mypackage1.SessionEJBClient
    javax.naming.NamingException: Lookup error: javax.naming.AuthenticationException: Invalid username/password for DarkEJB (the_login); nested exception is:
         javax.naming.AuthenticationException: Invalid username/password for DarkEJB (the_login) [Root exception is javax.naming.AuthenticationException: Invalid username/password for DarkEJB (the_login)]
         at com.evermind.server.rmi.RMIContext.lookup(RMIContext.java:168)
         at javax.naming.InitialContext.lookup(InitialContext.java:347)
         at mypackage1.SessionEJBClient.main(SessionEJBClient.java:18)
    Caused by: javax.naming.AuthenticationException: Invalid username/password for DarkEJB (the_login)
         at com.evermind.server.rmi.RMIConnection.connect(RMIConnection.java:2523)
         at com.evermind.server.rmi.RMIConnection.connect(RMIConnection.java:2339)
         at com.evermind.server.rmi.RMIConnection.lookup(RMIConnection.java:1781)
         at com.evermind.server.rmi.RMIServer.lookup(RMIServer.java:663)
         at com.evermind.server.rmi.RMIContext.lookup(RMIContext.java:149)
         ... 2 more
    Process exited with exit code 0.
    Do you know what i can do to solve this problem ?
    I saw several posts on this forum about that problem,
    mostly in 2003, so perhaps it has been solved now.
    I tried the solutions and workarounds mentioned in those
    post, but the error is still there...
    Thank you for your help ! :-)

    When you are connecting through a hotels WiFi like this they may occasionally require you to login via a home web page, this is quite normal. In many cases the password for this will be provided at checkin and with this being the case it would be worth speaking with the front desk to see if they can assist you with this.
    What are your thoughts about this forum? Let us know by doing this short survey.
     - Official Sony Xperia Support Staff
    If you're new to our forums make sure that you have read our Discussion guidelines.
    If you want to get in touch with the local support team for your country please visit our contact page.

  • Migrate the EJBs from JVM to OC4J...?

    We are plan to migrate the EJBs modules from Oracle8i JServer to OC4J.
    From now we have developed the EJBs by using JDeveloper as the following
    conditions;
    - JVM: Oracle8i JServer (8.1.6.3.0)
    - EJBs: Session Beans only
    - IDE tool: JDeveloper 3.2
    And now we wanna migrate or re-deploy to the OC4J. Is there any good
    suggestions or idea to do it? Also I wanna know sth to considerate...
    Thanks in advance for any advice
    Phyllis
    null

    It would be good for you to migrate to OC4J as performance in OC4J is a lot better. Here is a little migration writeup I had done sometime back. It is work in progress. Hope this helps.
    Migrating EJB components from Database EJB container to OC4J
    Author: Ashok Banerjee [[email protected]]
    Oracle recommends the new J2EE containers in Oracle9iAS (OC4J) for deploying J2EE components. The goal of this paper is to recommend ways to migrate existing EJB applications, from database EJB container, to OC4J.
    The database EJB container runs on the aurora session based Java Virtual Machine, whereas the new container runs on standard JDK (version 1.2.2 onward) .
    The database EJB container runs in a database session. The database is itself the middle tier, in such a configuration. Users therefore have a logically three tiered architecture, that runs physically on two tiers. The database serves as both the middle tier and the backend. In such situations users would use the "kprb" driver (used for requests made from within the database). No further authentication is needed if the backend database is the same as the middle tier. Users can also use one database as the middle tier and another database as the backend.
    In OC4J the middle tier does not require a database installation on the middle tier. This helps make the middle tier lightweight. OC4J is also seen to significantly faster than the EJB container inside the database. Since OC4J runs on regular JDK the user can run OC4J on the Java Virtual Machine which is best for his/her specific needs. OC4J however has a limitation in that does not support pure CORBA clients. Currently OC4J does not support RMI over IIOP either.
    To migrate existing EJB applications from inside the database to OC4J the set of changes is minimal.
    Code changes
    1. Change all references in the code and any configuration files using JDBC URLs from kprb driver to either thin or oci. "kprb" driver is only for applications running inside the database. The new OC4J runs outside the database and therefore it must use thin or oci driver.
    2. The database EJB container clientside JNDI lookups were like:
    env.put (Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
    env.put (Context.SECURITY_PRINCIPAL, user);
    env.put (Context.SECURITY_CREDENTIALS, password);
    env.put (Context.SECURITY_AUTHENTICATION, ServiceCtx.NON_SSL_LOGIN);
    Context ic = new InitialContext (env);
    while in OC4J container the lookup code should read:
    env.setProperty("java.naming.factory.initial","com.evermind.server.ApplicationClientInitialContextFactory");
    env.setProperty("java.naming.provider.url","ormi://localhost");
    env.setProperty("java.naming.security.principal","username");
    env.setProperty("java.naming.security.credentials","password");
    Context ic = new InitialContext (env);
    3) Remove all references to oracle.aurora.* classes - they will not work with OC4J. These classes are specific to the container in the database.
    4) Check for client demarcation of Bean Managed Transactions and remember that transaction in OC4J cannot be propagated across tiers. In other words client demarcated transaction will work provided the client is another EJB or a servlet in the same OC4J instance. This is also listed in the "Current Limitations" section.
    Build changes
    1. For EJB in the database we use loadjava to load classes into the database - this step is not necessary any longer for middle tier EJBs. The user merely needs to ensure that the classes are in the classpath.
    2. Similarly the concept of resolver specification in the database EJB container ceases to be useful in OC4J. To make classes "findable" the user sets the classpath. In OC4J any jars in the $OC4J_HOME/lib directory are on the server side classpath of the application classloader. The user can also include classes in their own ear files before they deploy the ear. [If you do not know about the resolver specification, then you have not used it and do not need to know about it].
    3. The database J2EE container did not have support for .ear files. The OC4J container supports J2EE standard .ear files. Both makefiles and ANT files are available in the code samples on OTN which show how to build ear files and also provides samples for the structure of the EAR files.
    EAR File contains META-INF/application.xml
    META-INF/orion-application.xml [optional]
    applicationEjb.jar
    applicationweb.war
    applicationEjb.jar contains
    META-INF/ejb-jar.xml
    META-INF/orion-ejb-jar.xml
    EJB classes
    applicationWeb.war contains
    WEB-INF/web.xml
    WEB-INF/orion-web.xml
    WEB-INF/lib/jar files needed
    WEB-INF/classes class files needed for JSP servlets
    For further information on how to write the xml files etc. please refer to their respective DTDs.
    Both web.xml and ejb-jar.xml should be unaffected by the migration.
    4. The deployejb tool used to deploy EJB to the database has been deprecated. In OC4J EJBs are deployed as shown below:
    % java -jar admin.jar ormi://localhost:<rmi-port> userName password -deploy -file ejbdemo.ear -deploymentName jndiName
    5. The ApplicationClientContainer does not need aurora_client.jar in the classpath instead it needs oc4j.jar in the classpath.
    Configuration Changes:
    1. In the database EJB container the configurations exist in database tables but in OC4J the configuration exists in industry standard XML files. By default these files are located at $OC4J_HOME/config directory. Users can start their OC4J instance with a different configuration using the -config switch to specify a different server.xml file.
    %java -jar oc4j.jar -config config1/server1.xml
    2. In the database EJB container scalability was achieved using the MTS architecture and session based Java Virtual Machine. In OC4J scalability is achieved by clustering and using the loadbalancer. For more details on loadbalancer please read <link to loadbalancer.doc>
    3. The bindds tool used to bind data-sources to the JNDI namespace of the database EJB container is deprecated. In OC4J datasources are bound to the the namespace using the data-sources.xml in $OC4J_HOME/config. Non oracle data-sources can also be bound to the namespace. A typical entry in data-sources.xml could look like:
    <data-source
    class="com.evermind.sql.DriverManagerDataSource"
    name="OracleDS"
    location="jdbc/OracleCoreDS"
    xa-location="jdbc/xa/OracleXADS"
    ejb-location="jdbc/OracleDS"
    connection-driver="oracle.jdbc.driver.OracleDriver"
    username="scott"
    password="tiger"
    url="jdbc:oracle:thin:@dlsun1688:5521:jis2"
    inactivity-timeout="30"
    />
    4. Database EJB container used database authentication (database roles and database users) to authenticate users to the middle tier. OC4J uses principals.xml file to list groups and users and perform authentication. One can also implement UserManagers for OC4J to perform more complex authentication.
    5. The ports used by OC4J for RMI, JMS and HTTP are all specified in rmi.xml, jms.xml, web-site.xml.
    6. Both OC4J and the database container SSL (client authentication as well as server authentication).
    7. The database EJB container could only be remotely debugged using a jdb like interface by starting a debugagent on the server, and a debugproxy on the client. OC4J containers on the other hand run on JDK and can be debugged with any debugger. This is very useful for debugging EJB/Servlet application running in the server.
    8. The database EJB container comes with a database and hence has AQ (Advanced Queue) available for JMS. With OC4J there is a default in memory JMS implementation. OC4J server program can also connect to other JMS implementations(including AQ) using jms.xml. However a JNDI context may need to be implemented for AQ.
    Current Limitations
    1. The OC4J container at present does not support 2 phase commit.
    2. The OC4J container at present does not support transaction context propagation across tiers. Hence client demarcated transactions are not supported in OC4J except where the client demarcating the transaction is in the same container, for example an EJB having its transaction demarcated by another EJB or servlet, in the same container.
    3. In the classic container Oracle did not support RMI-IIOP tunneling through HTTP however in OC4J RMI over HTTP is supported.
    null

  • Changing the EJB connection not under OC4J

    Dear all,
    I am facing a problem that after I deploy an ejb from Jdev and using teh connection from the Jdev. It is working fine, however I found that the EJB is totally depends on the connection which I have setup from Jdev but not from the OC4J connection pool, because when I try to change the connection setting from oc4j, it doesn't make any change.
    Any one help!!!!

    repost

  • Calling OC4J deployed EJB from Oracle 8.1.7 DB

    Hi
    I have deployed a Stateless Session Bean to OC4J (9.0.2). The client works fine. The Servlet and JSP works fine.
    What I need to do now is call this EJB from PL/SQL , ie call from Database PL/SQL package to wrapper to OC4j EJB.
    Trying to get this loaded into Oracle DB we get a class compilation error with the
    com.evermind....rmi... class. I do believe this is the OC4J implementation of RMI lookup. Is there a comparable class to load in the DB?
    Any ideas how to ??
    Tks
    Andre
    Here is a client sample of calls to the EJB
    package SampleWizUpdates;
    import java.util.Hashtable;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    import WizUpdates.WizAllocTotals;
    import WizUpdates.WizAllocTotalsHome;
    import resTotals;
    import resSuccess;
    import javax.rmi.*;
    public class WizAllocTotalsClient2
    public static void main(String [] args)
    WizAllocTotalsClient2 wizAllocTotalsClient2 = new WizAllocTotalsClient2();
    try
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
    env.put(Context.SECURITY_PRINCIPAL, "admin");
    env.put(Context.SECURITY_CREDENTIALS, "manager");
    env.put(Context.PROVIDER_URL, "ormi://sdt10645:23791/WizAllocTotals");
    Context ctx = new InitialContext(env);
    WizAllocTotals totalsBean;
    Object homeObject = ctx.lookup("WizAllocTotals");
    WizAllocTotalsHome home =
    (WizAllocTotalsHome)PortableRemoteObject.narrow(homeObject,
    WizAllocTotalsHome.class);
    totalsBean = (WizAllocTotals)PortableRemoteObject.narrow(home.create(),
    WizAllocTotals.class);
    // create new EJB instance
    totalsBean = home.create( );
    // Call any of the Remote methods below to access the EJB
    int operatorId = 1238;
    resTotals newRes = new resTotals();
    resSuccess newResSucc = new resSuccess();
    String newDataBase = "dwz3";
    int eventRefNo = 17445291;
    int actionNumber = 3;
    int allocValue = 125;
    totalsBean.setDataBase( newDataBase );
    newRes = totalsBean.getOperatorTotals( operatorId, eventRefNo );
    System.out.println("Result total 1 is "+newRes.totTransactLimitValue);
    System.out.println("Result total 2 is "+newRes.totDailyLimitValue);
    System.out.println("Result total 3 is "+newRes.totWeeklyLimitValue);
    System.out.println("Result total 4 is "+newRes.totMonthlyLimitValue);
    System.out.println("Result total 5 is "+newRes.remDailyLimitValue);
    System.out.println("Result total 6 is "+newRes.remWeeklyLimitValue);
    System.out.println("Result total 7 is "+newRes.remMonthlyLimitValue);
    System.out.println("Result success code is "+newRes.resCode);
    System.out.println("Result success message is "+newRes.resMessage);
    newRes = totalsBean.setOperatorTotals(operatorId,
    eventRefNo,
    actionNumber,
    allocValue,
    "C",
    "Testing Reason");
    System.out.println("Insert result success code is "+newRes.resCode);
    System.out.println("Insert result success message is "+newRes.resMessage);
    catch(Throwable ex)
    ex.printStackTrace();
    }

    Hi Andre,
    I am using stand-alone OC4J version 9.0.2.0.0 under (SUN) Solaris 7
    with JDK 1.3.1 and Oracle DBMS version 8.1.7.4.
    I have not yet been able to create a java stored procedure in the
    database that directly looks up an EJB deployed to OC4J.
    The only two ways I have found to "talk to" an EJB from a java stored
    procedure is
    1) go through a servlet
    2) go through a "remote" object (using RMI)
    For the first option, deploy an application to OC4J that contains
    your EJBs and a servlet (which acts as the client for the EJBs).
    Then, from your java stored procedure, contact the servlet using
    the classes in the "java.net" package -- including "URL" and "URLConnection".
    For the second option, use the "rmiregistry" to register a remote
    object. This remote object acts as the EJB client. The remote object
    does not need to be part of an application deployed to OC4J. Then
    contact the remote object from your java stored procedure.
    Hope this helps.
    Good Luck,
    Avi.

  • How to deploy BC4J application as session EJB  to OC4J manually?

    We have created a BC4J application with JClient as a client server interface. BC4J is to be deloyed as Session EJB to OC4j.
    I need to know how to deploy the BC4J application as session EJB to OC4J manually (at the customer's site without the JDeveloper).
    Thanks.

    If you just have OC4J.
    java -jar admin.jar .....
    You can look at the commandlines when you use JDeveloper to deploy to a standalong OC4J and just use them pretty much.
    Or if they have IAS, use the Enterprise Manager web console to deploy your EAR files.
    Rob

  • Invoke a WebLogic EJB from a BPEL hosted on OC4J

    We are trying to invoke a simple Session EJB running on Weblogic 8.1.6 from a BPEL running on OC4J (10.1.3.4).
    but we constantly get NullPointerException :-(
    Could you please advise us (or point to a document) how to implement the invocation?
    (we are following the instructions in
    http://www.oracle.com/technology/pub/articles/bpel_cookbook/juric.html )
    (the invokation succeeds from a simple standalone client, meaning that the jndi names, credentials etc. are correct)
    thanx in advance
    ydes

    maybe if I post the exception someone could help
    <2009-04-10 01:04:43,203> <DEBUG> <default.collaxa.cube.ws> <WSInvocationManager::invoke> def is file:/C:/projects/Cosmoline/technical/CosmoteApp/CosmoteEJBSample/src/TestSessionBeanService.wsdl
    <2009-04-10 01:04:43,203> <DEBUG> <default.collaxa.cube.ws> <WSIFInvocationHandler::invoke> opName=sayHello, parnterLink=<partnerLink name="TestSessionBean" partnerLinkType="{urn:TestSessionBeanService}TestSessionBeanLT">
    <myRole name="TestSessionBeanService">
    <ServiceName>{urn:TestSessionBeanService}TestSessionBeanPT</ServiceName>
    <PortType>{urn:TestSessionBeanService}TestSessionBeanPT</PortType>
    <Address>http://myserver:7777/orabpel/default/MyEJBSample/1.0/TestSessionBean/TestSessionBeanService</Address>
    </myRole>
    <partnerRole name="TestSessionBeanService">
    <ServiceName>{urn:TestSessionBeanService}TestSessionBeanPT</ServiceName>
    <PortType>{urn:TestSessionBeanService}TestSessionBeanPT</PortType>
    <Address>null</Address>
    </partnerRole>
    <conversationId>bpel://localhost/default/CosmoteEJBSample~1.0/140001-BpInv0-BpSeq0.3-3</conversationId>
    <properties>{}</properties>
    </partnerLink>
    <2009-04-10 01:04:43,203> <DEBUG> <default.collaxa.cube.ws> <WSIFInvocationHandler::doShortCut> Parner Property optShortCut
    <2009-04-10 01:04:43,218> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::acquire> Acquired read lock for CosmoteEJBSample-1.0
    <2009-04-10 01:04:43,218> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::release> Released lock for CosmoteEJBSample-1.0
    <2009-04-10 01:04:48,046> <DEBUG> <default.collaxa.cube.ws> <WSIFInvocationHandler::createOperation> Failed to createOperation for op sayHello
    org.collaxa.thirdparty.apache.wsif.WSIFException: Failed to lookup EJB home using JNDI name 'ejb.TestSessionBeanRemoteHome'; nested exception is:
         java.lang.NullPointerException
         at com.collaxa.cube.ws.wsif.providers.ejb.WSIFPort_EJB.getEjbHome(WSIFPort_EJB.java:285)
         at com.collaxa.cube.ws.wsif.providers.ejb.WSIFPort_EJB.getEjbObject(WSIFPort_EJB.java:298)
         at com.collaxa.cube.ws.wsif.providers.ejb.WSIFOperation_EJB.<init>(WSIFOperation_EJB.java:191)
         at com.collaxa.cube.ws.wsif.providers.ejb.WSIFPort_EJB.getDynamicWSIFOperation(WSIFPort_EJB.java:150)
         at com.collaxa.cube.ws.wsif.providers.ejb.WSIFPort_EJB.createOperation(WSIFPort_EJB.java:376)
         at com.collaxa.cube.ws.wsif.providers.ejb.WSIFPort_EJB.createOperation(WSIFPort_EJB.java:365)
         at com.collaxa.cube.ws.WSIFInvocationHandler.createOperation(WSIFInvocationHandler.java:881)
         at com.collaxa.cube.ws.WSIFInvocationHandler.invoke(WSIFInvocationHandler.java:297)
         at com.collaxa.cube.ws.WSInvocationManager.invoke2(WSInvocationManager.java:511)
         at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:268)
         at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__invoke(BPELInvokeWMP.java:835)
         at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__executeStatements(BPELInvokeWMP.java:402)
         at com.collaxa.cube.engine.ext.wmp.BPELActivityWMP.perform(BPELActivityWMP.java:199)
         at com.collaxa.cube.engine.CubeEngine.performActivity(CubeEngine.java:3704)
         at com.collaxa.cube.engine.CubeEngine.handleWorkItem(CubeEngine.java:1656)
         at com.collaxa.cube.engine.dispatch.message.instance.PerformMessageHandler.handleLocal(PerformMessageHandler.java:75)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.handleLocalMessage(DispatchHelper.java:220)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.sendMemory(DispatchHelper.java:317)
         at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:5777)
         at com.collaxa.cube.engine.CubeEngine.createAndInvoke(CubeEngine.java:1088)
         at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.__createAndInvoke(CubeEngineBean.java:125)
         at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.createAndInvoke(CubeEngineBean.java:168)
         at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.syncCreateAndInvoke(CubeEngineBean.java:188)
         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:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor$1.run(JAASInterceptor.java:31)
         at com.evermind.server.ThreadState.runAs(ThreadState.java:693)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor.invoke(JAASInterceptor.java:34)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.TxRequiresNewInterceptor.invoke(TxRequiresNewInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at CubeEngineBean_LocalProxy_4bin6i8.syncCreateAndInvoke(Unknown Source)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequestAnyType(DeliveryHandler.java:549)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequest(DeliveryHandler.java:465)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.request(DeliveryHandler.java:134)
         at com.collaxa.cube.ejb.impl.DeliveryBean.request(DeliveryBean.java:95)
         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:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor$1.run(JAASInterceptor.java:31)
         at com.evermind.server.ThreadState.runAs(ThreadState.java:693)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor.invoke(JAASInterceptor.java:34)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:50)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at DeliveryBean_RemoteProxy_4bin6i8.request(Unknown Source)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processNormalOperation(SOAPRequestProvider.java:451)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processBPELMessage(SOAPRequestProvider.java:274)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processMessage(SOAPRequestProvider.java:120)
         at oracle.j2ee.ws.server.provider.ProviderProcessor.doEndpointProcessing(ProviderProcessor.java:956)
         at oracle.j2ee.ws.server.WebServiceProcessor.invokeEndpointImplementation(WebServiceProcessor.java:349)
         at oracle.j2ee.ws.server.provider.ProviderProcessor.doRequestProcessing(ProviderProcessor.java:466)
         at oracle.j2ee.ws.server.WebServiceProcessor.processRequest(WebServiceProcessor.java:114)
         at oracle.j2ee.ws.server.WebServiceProcessor.doService(WebServiceProcessor.java:96)
         at oracle.j2ee.ws.server.WebServiceServlet.doPost(WebServiceServlet.java:194)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
         at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64)
         at oracle.security.jazn.oc4j.JAZNFilter$1.run(JAZNFilter.java:400)
         at java.security.AccessController.doPrivileged(Native Method)
         at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
         at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:414)
         at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:623)
         at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370)
         at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:871)
         at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:453)
         at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:313)
         at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:199)
         at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    Caused by: java.lang.NullPointerException
         at java.lang.Class.isAssignableFrom(Native Method)
         at com.collaxa.cube.ws.wsif.providers.ejb.WSIFPort_EJB.getEjbHome(WSIFPort_EJB.java:267)
         ... 89 more
    <2009-04-10 01:04:48,046> <DEBUG> <default.collaxa.cube.ws> <WSIFInvocationHandler::invoke> invoke failed
    org.collaxa.thirdparty.apache.wsif.WSIFException: Failed to lookup EJB home using JNDI name 'ejb.TestSessionBeanRemoteHome'; nested exception is:
         java.lang.NullPointerException
         at com.collaxa.cube.ws.WSIFInvocationHandler.createOperation(WSIFInvocationHandler.java:906)
         at com.collaxa.cube.ws.WSIFInvocationHandler.invoke(WSIFInvocationHandler.java:297)
         at com.collaxa.cube.ws.WSInvocationManager.invoke2(WSInvocationManager.java:511)
         at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:268)
         at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__invoke(BPELInvokeWMP.java:835)
         at com.coll

  • How to access an EJB from a web application deployed in the same server

    Hey All,
    I deployed an EJB named EventServerBean to Sun Application Server 9.0, and put the client side jar file (named eventserver.jar which is generated by Sun Application Server) to C:\Sun\AppServer\lib. Now, I have a web application which is a simple jave file -- lookup EventServer EJB and invoke a remote method in this EJB. However, the web application always throws an exception "java.lang.NoClassDefFoundError: eventserver/EventServerRemoteHome"
    Here is my java class that access the ejb:
    public class Post_Event {
        public HashMap<String, String> getEventInfo(String event_name, String site) {
            System.out.println("Post_Event, the class path: " + System.getProperty("java.class.path"));       
            System.out.println("Post_Event, user.dir: " + System.getProperty("user.dir"));
            System.out.println("Post_Event, java.library.path: " + System.getProperty("java.library.path"));
            HashMap<String, String> result = null;
            EventServerRemote remote = null;
            StringTokenizer st, st2;
            // here get the event information from host
            try {
                String lookupStr = "corbaname:iiop:" + site + ":3700#ejb/EventServerBean";
                InitialContext initialContext = new InitialContext();
                EventServerRemoteHome remoteHome = (EventServerRemoteHome) javax.rmi.PortableRemoteObject.narrow(initialContext.lookup(lookupStr), EventServerRemoteHome.class);
                if (remoteHome != null) {
                    remote = remoteHome.create();
            } catch (javax.naming.NamingException ne) {
                ne.printStackTrace();
                return null;
            } catch (javax.ejb.CreateException ce) {
                ce.printStackTrace();
                return null;
            } catch (java.rmi.RemoteException re) {
                re.printStackTrace();
                return null;
            } catch (java.io.IOException ioe) {
                ioe.printStackTrace();
                return null;
            System.out.println("look up remote event server successfully.");
         result = remote.getEvent(event_name);
            return result;
        } I output the class path in this java file, and the class path DOES include the path C:\Sun\AppServer\lib where eventserver\EventServerRemoteHome.class is.
    Does anyone know why it happens? Why a java class can't find a class that is in its class path?
    appreciate any help!

    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Wael Abbas ([email protected]):
    Thank you for your great topic.
    I think you need to copy the snippet code and past it to every application, applet, servlet or JSP every time you need to use your EJB.
    Its better to include this snippet code in a simple JavaBean and use this bean as a bridge to your EJB, you may include a connect method in your JavaBean or but the connection code in the constructor and include a setters, getters and other methods to encapsulate your EJB methods.
    You can use your JavaBean in any application, applet, servlet or JSP just create an object form it and call its methods.
    Its just an idea
    I hope it will be useful.
    <HR></BLOCKQUOTE>
    null

  • Deploy multiple instances of the same stateless session EJB

    I have a stateless session bean.
    The methods on the bean operate against DB tables.
    Q: Can I deploy multiple instances of the same stateless session bean, but specify a different JNDI/datasource name in the deployment descriptor?
    The method calls are all enclosed within a single invocation, just that I need to hit different databases (all with the same schema), and Id like to be able to lookup the EJB via a different JNDI name, and have the exact same functionality, just against different deployed datasources.
    Does the spec allow/support this?
    If not, any suggestions as to how to achieve this sort of functionality?
    Im using JBoss 3.2.1 on Solaris, so Im not sure whether or not this is a JBoss "issue" or a limitation of the EJB Spec (or me being just plain wrong and trying to do something the "wrong way")
    Nick

    I have a stateless session bean.
    The methods on the bean operate against DB tables.
    Q: Can I deploy multiple instances of the same
    stateless session bean, but specify a different
    JNDI/datasource name in the deployment descriptor?
    The method calls are all enclosed within a single
    invocation, just that I need to hit different
    databases (all with the same schema), and Id like to
    be able to lookup the EJB via a different JNDI name,
    and have the exact same functionality, just against
    different deployed datasources.
    Does the spec allow/support this?
    If not, any suggestions as to how to achieve this sort
    of functionality?
    Im using JBoss 3.2.1 on Solaris, so Im not sure
    whether or not this is a JBoss "issue" or a limitation
    of the EJB Spec (or me being just plain wrong and
    trying to do something the "wrong way")
    NickI haven't done it but judging from the deployment descriptors yes.
    For example if I have two bounded datasources java:/Database1 and java:/Database2
    Lets say I have a session bean called MySession, then in your ejb-jar.xml you would have (notice that the desc, display, and ejb-name are the only differences)
    <session>
    <description>MySessionAlpha</description>
    <display-name>MySessionAlpha</display-name>
    <ejb-name>MySessionAlpha</ejb-name>
    <home>com.mycorp.MySessionRemoteHome</home>
    <remote>com.mycorp.MySessionRemote</remote>
    <local-home>com.mycorp.MySessionLocalHome</local-home>
    <local>com.mycorp.MySessionLocal</local>
    <ejb-class>com.mycorp.MySessionFacadeBean</ejb-class>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>
    <resource-ref>
    <res-ref-name>jdbc/DataSource</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
    </resource-ref>
    </session>
    <session>
    <description>MySessionBeta</description>
    <display-name>MySessionBeta</display-name>
    <ejb-name>MySessionBeta</ejb-name>
    <home>com.mycorp.MySessionRemoteHome</home>
    <remote>com.mycorp.MySessionRemote</remote>
    <local-home>com.mycorp.MySessionLocalHome</local-home>
    <local>com.mycorp.MySessionLocal</local>
    <ejb-class>com.mycorp.MySessionFacadeBean</ejb-class>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>
    <resource-ref>
    <res-ref-name>jdbc/DataSource</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
    </resource-ref>
    </session>
    But now in the jboss.xml, we will have the following elements. What you may notice is that are bound to different remote and local jndi names. But the resource bindings are very different. The res-ref-name stays the same, but the jndi-name are different. I think this will work for you.
    <session>
    <ejb-name>MySessionAlpha</ejb-name> <jndi-name>ejb/com/mycorp/MySessionAlphaRemoteHome</jndi-name> <local-jndi-name>ejb/com/mycorp/MySessionAlphaLocalHome</local-jndi-name>
    <resource-ref>
    <res-ref-name>jdbc/datasource</res-ref-name>
    <jndi-name>java:/Database1</jndi-name>
    </resource-ref>
    </session>
    <session>
    <ejb-name>MySessionBeta</ejb-name> <jndi-name>ejb/com/mycorp/MySessionBetaRemoteHome</jndi-name> <local-jndi-name>ejb/com/mycorp/MySessionBetaLocalHome</local-jndi-name>
    <resource-ref>
    <res-ref-name>jdbc/datasource</res-ref-name>
    <jndi-name>java:/Database2</jndi-name>
    </resource-ref>
    </session>

Maybe you are looking for