Doing a jndi lookup() for an EJB deployed on Glassfish v3

Hello.
I have deployed a Stateful Sesion EJB on a Glassfish v3 AppServer.
It is running under 'localhost' on my laptop pc.
I am also running a stand-alone java application on the same pc... it attempts to get a remote connection from the client-app to the Glassfish Server and then do a jndi lookup() to get a reference to my EJB.
here is the client source code:
public class LookupTest {
static Properties props = null;
public static void main(String[] args) {
try {
props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");
     props.put(Context.PROVIDER_URL, "iiop://localhost:3700");
     Context ctx = new InitialContext(props);
     System.out.println( "the context is: " + ctx);
     System.out.println( "the environment contains: " + ctx.getEnvironment() );
     System.out.println( " ");
     // do a lookup.
     Object elementObj = ctx.lookup("SerialContextProvider");
     System.out.println(elementObj);
} catch (NamingException e) {
e.printStackTrace();
When I run this app, there are no Errors or Exceptions. It appears that the connection succeeds. But there are no EJB references in the context that is created. The only item that seems to be present in the context is an item named "SerialContextProvider", as noted in the return value from a list("") method invocation. Why can i not see the EJB within the context? Is my code wrong ??
Thanks,
Andy Jerpe
Edited by: user1169567 on Nov 28, 2010 12:12 PM

Ok, but the communication seems to be OK over the wire because if I use netstat -a I can see the ESTABLISHED connection with the server in the right RMI port.
TCP PORTAL35:1581 caapiranga:12405 ESTABLISHED
and then when I stop the instance in the OAS, the client shows an exception telling that the connection was lost.
An curious thing is that the ons.log doesn't log this connection ;/

Similar Messages

  • Issues in looking up a ejb deployed on glassfish from tomcat.

    Hi all,
    I have followed the steps mentioned in the EJB FAQ in the glassfish site and was able to lookup a remote ejb deployed in glassfish from a standalone client.
    In case of standalone client, i set the appropriate jndi properties in the initial context as mentioned in the FAQ and added the 4 jars specified to the classpath of the application.
    It all worked perfectly well.
    But I attempted to do the same from a servlet running under tomcat.
    I set the appropriate jndi properties in the intial context and added 4 jars specified in the lib directory of the war file.
    But this did not turn out well and tomcat complained me with some servlet init errors.
    Then i searched through the web and found this posting from you:
    http://www.archivesat.com/GlassFish_Enterprise_JavaBeans_Developers/thread1399339.htm
    Then i created a folder called "shared/lib" under TOMCAT_HOME directory in my machine and ran the same example. Wow.....miraculously the application ran well.
    But i found that the "index.jsp" which i configured in the welcome file list does not appear now. But i was able to access the servlet without any problem. And the servlet was able to successfully lookup the ejb deployed in glassfish.
    Then i thought, let me try to access the ejb from a jsf application.
    Then i created a jsf application in netbeans 5.5.1 and tried to access the bean deployed in glassfish.
    (Note: the jsf application runs in tomcat 5.5.17 which is bundled with netbeans)
    OOPSS....
    Tomcat now complains me that it cannot compile the jsp page..
    This is the error i got...
    org.apache.jasper.JasperException: Unable to compile class for JSP
    Generated servlet error:
    C:\Documents and Settings\james\.netbeans\5.5.1\apache-tomcat-5.5.17_base\work\Catalina\localhost\CityExplorer-WebClient1\org\apache\jsp\index_jsp.java:7: org.apache.jsp.index_jsp is not abstract and does not override abstract method getDependants() in org.apache.jasper.runtime.JspSourceDependent
    public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase
    ^
    Generated servlet error:
    C:\Documents and Settings\james\.netbeans\5.5.1\apache-tomcat-5.5.17_base\work\Catalina\localhost\CityExplorer-WebClient1\org\apache\jsp\index_jsp.java:12: getDependants() in org.apache.jsp.index_jsp cannot implement getDependants() in org.apache.jasper.runtime.JspSourceDependent; attempting to use incompatible return type
    found : java.lang.Object
    required: java.util.List
    public Object getDependants() {
    ^
    2 errors
    org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510)
    org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
    org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
    org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
    org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:368)
    Any ideas...
    Can you please help me.
    I've noticed that you were eagerly answering questions related to ejb lookup in many places.
    I feel there is some potential compatability issue between tomcat and glassfish...
    I request you to investigate on this and clarify the community with your response.
    Thanks in advance,
    James Selvakumar

    Thank you guys!
    I've found the answer myself.

  • JNDI lookup for UserTransaction

              Hi all,
              in Weblogic, in a typical scenario, do a client provide exactly
              one JNDI lookup for the UserTransaction object (interface) or do
              the client have to provide a JNDI lookup for each transaction?
              In some EJB implementations, a JNDI lookup for UserTransaction
              returns always the same reference. For example, in JOnAS, you can
              have one static reference which is set when the client starts.
              Then, more threads can simultaneously use the same static
              UserTransaction reference without any conflict, since the
              implementation of UserTransaction recognizes, which thread invoked
              a particular method.
              In other words, can I make an assumption that two different JNDI
              lookups for UserTransaction returns different references or not?
              Thanks a lot,
              Marek Prochazka
              Distributed Systems Research Group
              Department of Software Engineering
              Charles University, Faculty of Mathematics and Physics
              Malostranske namesti 25, 118 00 Prague 1, Czech Republic
              phone: +420-2-2191 4236
              http://nenya.ms.mff.cuni.cz/thegroup/
              

    Actually, UserTransaction is a singleton and it's not a transaction. It's just
              very mis-named.
              It should be called UserTransactionManager or UserInterfaceToJTA.
              The actual transaction is javax.transaction.Transaction.
              -- Rob
              Cameron Purdy wrote:
              > Within a transaction, it is different instances? For example, if you call
              > it two times one right after another?
              >
              > A transaction is a unit of work. I understand why the transaction object
              > changes from transaction to transaction, since a single transaction object
              > (UserTransaction) represents exactly one transaction. Why would it be a
              > singleton? It is not a transaction manager.
              >
              > Peace,
              >
              > --
              > Cameron Purdy
              > Tangosol, Inc.
              > http://www.tangosol.com
              > +1.617.623.5782
              > WebLogic Consulting Available
              >
              > "Sarita" <[email protected]> wrote in message
              > news:[email protected]...
              > >
              > > Hi Priscilla--
              > >
              > > This is not the behavior that I'm seeing, and I'm perplexed.
              > > Every time I request a UserTransaction from JNDI, I receive a
              > > a different instance. Should the value immediately returned by JNDI be
              > the singleton
              > > instance? If not, then how do I retrieve the singleton instance?
              > >
              > > I would like a session bean to start a transaction, and then call a method
              > on another
              > > session bean (which should operate under the same transaction). How does
              > the second
              > > session bean grab the correct transaction object? Is that possible?
              > >
              > > Thanks In Advance,
              > > Sarita
              > >
              > > "Priscilla Fung" <[email protected]> wrote:
              > > >
              > > >Hi Marek,
              > > >
              > > >In Weblogic 6.0, JNDI lookup of UserTransaction returns a reference to
              > the
              > > >singleton
              > > >Transaction Manager instance, which is thread-safe and can be used from
              > > >multiple
              > > >threads for transaction demarcations etc.
              > > >
              > > >-- Priscilla Fung, BEA Systems, Inc.
              > > >
              > > >"Marek Prochazka" <[email protected]> wrote:
              > > >>
              > > >>Hi all,
              > > >>
              > > >>in Weblogic, in a typical scenario, do a client provide exactly
              > > >>one JNDI lookup for the UserTransaction object (interface) or do
              > > >>the client have to provide a JNDI lookup for each transaction?
              > > >>
              > > >>In some EJB implementations, a JNDI lookup for UserTransaction
              > > >>returns always the same reference. For example, in JOnAS, you can
              > > >>have one static reference which is set when the client starts.
              > > >>Then, more threads can simultaneously use the same static
              > > >>UserTransaction reference without any conflict, since the
              > > >>implementation of UserTransaction recognizes, which thread invoked
              > > >>a particular method.
              > > >>
              > > >>In other words, can I make an assumption that two different JNDI
              > > >>lookups for UserTransaction returns different references or not?
              > > >>
              > > >>Thanks a lot,
              > > >>Marek Prochazka
              > > >>--------------------------------------------------------------
              > > >> Distributed Systems Research Group
              > > >> Department of Software Engineering
              > > >> Charles University, Faculty of Mathematics and Physics
              > > >> Malostranske namesti 25, 118 00 Prague 1, Czech Republic
              > > >> phone: +420-2-2191 4236
              > > >> http://nenya.ms.mff.cuni.cz/thegroup/
              > > >>--------------------------------------------------------------
              > > >>
              > > >
              > >
              

  • Problem in Jndi lookup for  ITaskService

    HI,
    I am trying to initiate oracle bpm Human task programatically by using Java remotely.
    for this I am using following JNDI lookup for ITaskService.
    Hashtable ht = new
                  Hashtable<IWorkflowServiceClientConstants.CONNECTION_PROPERTY,java.lang.String>();
              ht.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_INITIAL_CONTEXT_FACTORY, 
                     "weblogic.jndi.WLInitialContextFactory");
              ht.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_PROVIDER_URL, "t3://localhost:7001");
              ht.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_SECURITY_PRINCIPAL, "username"); 
              ht.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_SECURITY_CREDENTIALS, "password");
              Context ctx  = new InitialContext(ht);
    ITaskService taskService = (ITaskQueryService)ctx.lookup("ejb/bpel/services/workflow/TaskServiceBean");
    taskService.initiateTask(task);
    It the right approach or not.
    Please help.

    To access human workflow api remotely try using the following code :
    Map properties = new HashMap();
      properties.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_PROVIDER_URL, "t3://localhost:8001");
      properties.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_SECURITY_CREDENTIALS, "welcome1");
      properties.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_SECURITY_PRINCIPAL, "weblogic");
    IWorkflowServiceClient wfSvcClient =
      WorkflowServiceClientFactory.getWorkflowServiceClient(WorkflowServiceClientFactory.REMOTE_CLIENT, properties, null);
      //Get the task query service
      ITaskQueryService querySvc = wfSvcClient.getTaskQueryService();
      //Login as weblogic
      IWorkflowContext ctx = querySvc.authenticate("weblogic","welcome1".toCharArray(),null);
    after getting the workflow context, you can call any method like query task list. perform actions etc. just see the api doc.
    Regards,
    Anshul

  • JNDI lookup for weblogic.management.MBeanHome

    Tried to do JNDI lookup for MBeanHome. It could resolve
    weblogic.management, but not MBeanHome.
    Any idea? Thank you
    T. Pei
    PS
    The statement and the error message:
    MBeanHome mBeanHome = (MBeanHome) initialContext.lookup
    ("weblogic.management.MBeanHome.JNDI_NAME.MyServer");
    javax.naming.NameNotFoundException:
    Unable to resolve weblogic.management.MBeanHome.JNDI_NAME.MyServer
    Resolved: 'weblogic.management'
    Unresolved:'MBeanHome' ; remaining name 'JNDI_NAME.MyServer'

    I answered this in my last post, but to clarify your attempt below.
    you can access MBeanHome through JNDI in any of three ways that I
    currently know...
    MBeanHome mBeanHome =
    (MBeanHome)ctx.lookup("weblogic.management.adminhome");
    MBeanHome mBeanHome =
    (MBeanHome)ctx.lookup(MBeanHome.ADMIN_JNDI_NAME);
    MBeanHome mBeanHome =
    (MBeanHome)ctx.lookup(MBeanHome.JNDI_NAME+"."+yourservername);
    typically yourservername = "myserver"
    when I print MBeanHome.ADMIN_JNDI_NAME I get
    "weblogic.management.adminhome"
    when I print MBeanHome.JNDI_NAME I get
    "weblogic.management.home"
    so using MBeanHome.JNDI_NAME+"."+yourservername is the same as
    "weblogic.management.home.myserver", if the server you are trying to access
    is called myserver.
    may be more information than you want.
    "T. Pei" <[email protected]> wrote in message
    news:3a7a1562$[email protected]..
    >
    Tried to do JNDI lookup for MBeanHome. It could resolve
    weblogic.management, but not MBeanHome.
    Any idea? Thank you
    T. Pei
    PS
    The statement and the error message:
    MBeanHome mBeanHome = (MBeanHome) initialContext.lookup
    ("weblogic.management.MBeanHome.JNDI_NAME.MyServer");
    javax.naming.NameNotFoundException:
    Unable to resolve weblogic.management.MBeanHome.JNDI_NAME.MyServer
    Resolved: 'weblogic.management'
    Unresolved:'MBeanHome' ; remaining name 'JNDI_NAME.MyServer'

  • Problems with JNDI lookup for java:comp/env/ejb

    Hi all,
    I'm using OC4J 9.0.3 and I have problems when looking up for the local
    EJB context.
    I have a SLSB which refers to another SLSB via a JNDI mapping like
    shown below. Both services are deployed within one EAR file.
    (snippets of ejb-jar.xml and orion-ejb-jar.xml)
    <ejb-jar>
    <enterprise-beans>
    <session>
    <ejb-name>ServiceABean</ejb-name>
    <home>com.coi.ServiceAHome</home>
    <remote>com.coi.ServiceA</remote>
    <ejb-class>com.coi.ServiceABean</ejb-class>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>
    <ejb-ref>
    <ejb-ref-name>ejb/some/sub/packages/ServiceB</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <home>com.coi.ServiceBHome</home>
    <remote>com.coi.ServiceB</remote>
    </ejb-ref>
    </session>
    </enterprise-beans>
    </ejb-jar>
    <orion-ejb-jar>
    <enterprise-beans>
    <session-deployment location="global/some/sub/packages/ServiceA" name="ServiceABean">
    <ejb-ref-mapping name="ejb/some/sub/packages/ServiceB" location="global/some/sub/packages/ServiceB" />
    </session-deployment>
    </enterprise-beans>
    </orion-ejb-jar>
    The ApplicationInitialContextFactory will be used (prepared by the container),
    so the lookup for ServiceB within a method of ServiceA should work as follows:
    public class ServiceABean implements SessionBean
    public void someMethod()
    InitialContext con = new InitialContext(); // will be of class ApplicationContext
    Context localEjbContext = (Context)con.lookup( "java:comp/env/ejb" );
    ServiceBHome serviceBHome = (ServiceBHome) PortableRemoteObject.narrow(
    localEjbContext.lookup( "some/sub/packages/ServiceB" ),
    ServiceBHome.class );
    The problem is now, that the lookup for "java:comp/env/ejb" doesn't work
    and throws a NameNotFoundException.
    To figure out what's actually happening during lookup I debugged a little bit and
    tried a few things:
    1. A lookup for "java:comp" works fine. It returns an instance of class FlatMapContext
    which consists of a hash map which itself contains an entry for "env".
    2. So a lookup for "env" on that FlatMapContext also works and returns an instance of SubContext.
    3. A lookup for "ejb" using this SubContext causes a NameNotFoundException
    with message "java:comp/env/ejb not found".
    4. A lookup like con.lookup( "java:comp/env" ) throws also a NameNotFoundException
    with message "java:comp/env not found (not inside a J2EE module, for instance a Web-App,
    EJB, or Application-Client)".
    Does anyone know something about this?
    Regards
    --thomas

    Hi Debu,
    Great! 9.0.4 will be released in june/july this year, right? Sorry for my ironical reaction, but does that mean, that I don't have any chance to get my whole stuff running in 9.0.3? I cannot believe that. Isn't there a wordaround I could apply? A setting or whatever to substitute the daft FlatCtx by something else that is implemented according to the spec?
    Regards
    --thomas

  • JAVA client JNDI lookup for EJB session in cluster in WLS 5.1

    The documentation says :
              to obtain a Context for JNDI lookup do the following :
              Hashtable ht = new Hashtable();
              ht.put(Context.INITIAL_CONTEXT_FACTORY,
              "weblogic.jndi.WLInitialContextFactory");
              ht.put(Context.PROVIDER_URL, "t3://mycluster:7001");
              try {
              Context ctx = new InitialContext(ht);
              // Do the client's work
              catch (NamingException ne) {
              // A failure occurred
              finally {
              try {ctx.close();}
              catch (Exception e) {
              // a failure occurred
              where "mycluster" is the DNS name of my cluster. My DNS server (Windows 200
              DNS server) use round robin
              to call alernatively all the wls server node in "mycluster" and it's OK. The
              two servers of my cluster
              are called alternatively for my EJB session stateless.
              Now I unplug one of the two nodes of my cluster and the remaining server is
              called only 2 times
              and not after.
              Questions :
              -is the load balancing between the nodes of mycluster only rely on DNS or
              is there an internal
              mecanism in EJB sub to try one server then an other ?
              - do I need to obtain a new reference on JNDI Context for each call ?
              Thank's a lot.
              Farid Bellameche.
              

              I too have the same problem. My scenario is :
              I have the web tier architecture away from cluster. All ejbs are in cluster
              running in two seperate machines. We have a factory class running in
              webtier(we use servlet in this tier) which obtains home interface only once
              and stores it for future reference. When ever we need the remoteobject stub,
              we ask the factory class and which in turn uses the stored home interface to
              get the same.
              In the webtier, I list all the servers in the cluster as a part of url as
              mentioned by you.
              I started the web tier as well as Object tier cluster. I could see the
              request coming in both the machines in the cluster for the ejb. But When I
              bring one the server in the cluster,
              1. Web tier throws an exception saying that it could not connect
              to server using t3.
              2. The other machine which is running the server, also says
              'failed to create socket to : -32323234324 sever name
              using protocol t3.
              It looks like I am able to get load balance. But I am not able to get the
              fail over to be working.
              In the weblogic-ejb-jar.xml, I added the following.
              <clustering-descriptor>
              <home-is-clusterable>true</home-is-clusterable>
              <home-load-algorithm>round-robin</home-load-algorithm>
              </clustering-descriptor>
              I compiled and added the .jar file. So the jar file now has replica aware
              stubs.
              Could any one of you help me for why the fail over is not working?
              Suersh
              "Giri Alwar" <[email protected]> wrote in message
              news:[email protected]...
              > Farid,
              > (1) Yes, the stub has the logic to perform load-balancing and
              fail-over.
              > (2) In almost all cases, no. You can get the context once, store it
              and
              > use it thereafter. Please refer to
              > http://www.weblogic.com/docs51/cluster/concepts.html#1025061 for more
              info.
              >
              > A couple of notes on your situation. From what you are describing, your
              > Windows DNS server is setup to serve only one IP from the cluster (using
              > round-robin) as opposed to a list of all IP's in the cluster. Hence, the
              > initial context you obtain is tied to a single server in the cluster (the
              > one returned by the DNS). The weblogic implementation on the client side
              has
              > no idea of the existence of the other servers in the cluster. This is not
              a
              > cluster aware context. To obtain a cluster aware context, either list all
              > the IP's in the URL like t3://server1,server2,server3:7001 or have
              > "mycluster" return a list of all servers in the cluster.
              >
              > Giri
              >
              >
              > "Farid Bellameche" <[email protected]> wrote in message
              > news:[email protected]...
              > > The documentation says :
              > >
              > > to obtain a Context for JNDI lookup do the following :
              > > Hashtable ht = new Hashtable();
              > > ht.put(Context.INITIAL_CONTEXT_FACTORY,
              > > "weblogic.jndi.WLInitialContextFactory");
              > > ht.put(Context.PROVIDER_URL, "t3://mycluster:7001");
              > > try {
              > > Context ctx = new InitialContext(ht);
              > > // Do the client's work
              > > }
              > > catch (NamingException ne) {
              > > // A failure occurred
              > > }
              > > finally {
              > > try {ctx.close();}
              > > catch (Exception e) {
              > > // a failure occurred
              > > }
              > > }
              > >
              > > where "mycluster" is the DNS name of my cluster. My DNS server (Windows
              > 200
              > > DNS server) use round robin
              > > to call alernatively all the wls server node in "mycluster" and it's OK.
              > The
              > > two servers of my cluster
              > > are called alternatively for my EJB session stateless.
              > > Now I unplug one of the two nodes of my cluster and the remaining server
              > is
              > > called only 2 times
              > > and not after.
              > >
              > > Questions :
              > > -is the load balancing between the nodes of mycluster only rely on DNS
              > or
              > > is there an internal
              > > mecanism in EJB sub to try one server then an other ?
              > >
              > > - do I need to obtain a new reference on JNDI Context for each call ?
              > >
              > >
              > > Thank's a lot.
              > >
              > > Farid Bellameche.
              > >
              > >
              > >
              > >
              >
              >
              

  • How to write the jndi lookup for ejb using oc4j server in jdeveloper

    Hi All,
    i am new to the JDeveloper. i want to develop the session bean in JDeveloper using the OC4J server. how to write the jndi lookup in cllient. what are the xml files need to deploy the application. where can i mention the JNDI name in xml file. so please provide the information as soon as possible.
    regards
    ram

    There is quite in-depth information in the Enterprise JavaBeans Developer's Guide.
    Section 2 (Understanding EJB Application Development) explains the xml files needed and Section 29 (Accessing an EJB from a Client) explains how to do a JNDI lookup.
    Hope this helps.

  • Manual JNDI lookup for EJB3 between different Application Server Instances

    Hi all,
    i have spent quite some time looking into this problem and searching the net but i just can't figure out for the life of me what i am doing wrong so i hope someone here can give me a clue or a good resource where i can look it up myself.
    I am currently doing some interoperability tests concerning EJB calls between Glassfish and Weblogic 10. In my test setup i have an EJB deployed in a jar file on one server and a servlet in a war file deployed on the other. The objective is to try to look up and call the EJB from the servlet. As there seem to be some issues with injection in Weblogic 10 i set that one aside for now (i have opened a case at BEA support for this) but i would like to do a plain old JNDI lookup to obtain the EJB.
    The online tutorials and FAQs i have read so far all state that this can be done the same way as it works for EJB2.x, at least if i understood them correctly. The interessting thing is, when i deploy an EJB2.x bean i can look it up without problems, but when i try to do the same with the EJB3 bean the name cannot be found. On the other hand when listing all contents of the JNDI tree in Glassfish from a stand alone application i can see entries for both EJBs of the type java.naming.Reference (in Weblogic i can also see entries for both, but the ones for EJB3 are of some weird internal weblogic types, which i put down as a weblogic problem for now).
    The lookup code for the servlet running in weblogic looks like this:
    Properties env = new Properties();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.PROVIDER_URL, "corbaname:iiop:1.2@localhost:3700");
    Object myEjb = new InitialContext(env).lookup("JNDINameDisplayedByContextListing");
    I know that the preferred way would be to have the corbaname put into weblogic.xml/sun-web.xml and just use an InitialContext without an environment to perform the lookup but i wanted to get rid of any additional indirections to pinpoint the source my problem and it should work this way, too. As i said, it works when i target an EJB2.x bean but not with the EJB3 one, so i guess i am doing something wrong there. The jar file contains the interface of the bean annotated with @Remote and the implementation of the interface annotated with @Stateless, i also tried setting the mappedName attribute for the bean and use that name as JNDI name, but that also fails. In addition i added an ejb-jar.xml to the jars META-INF containing the following:
    <?xml version="1.0" encoding="UTF-8"?>
    <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
         version="3.0">
         <enterprise-beans>
              <session>
                   <ejb-name>SecurityTest3EJB</ejb-name>
                   <ejb-class>
                        testcase.ejb.SecurityTestBean
                   </ejb-class>
                   <session-type>Stateless</session-type>
                   <transaction-type>Container</transaction-type>
    </session>
    </enterprise-beans>
    But the ejb-name specified there does not show up in a context listing, so i would guess that means the file is ignored or only accessible from within the same application server (note, there is no indication of any problems in the Glassfish log when deploying the jar file).
    This might be just a stupid mistake by me, but i just can't figure it out at the moment, so any advice will be greatly appriciated.
    Thanks, Chris

    I think i stumbled across something now. From some posts it seems to me that the EJB3 spec does not require EJBs to be accessible from a remote location, since this can be achieved by using the @RemoteHome annotation and performing a EJB2.x compliant look up. Is that correct?

  • Stand-alone JNDI lookup of an EJB in an Enterprise Application (EAR) build

    Hi All,
    I am having some difficulty doing JNDI look up an EJB 3.0 Bean that is part of an Enterprise Application (EAR) build. Below are all the related codes:
    package ejb;
    import javax.ejb.Local;
    @Local
    public interface Hello1Local {
        public String getHello1();
    package ejb;
    import javax.ejb.Stateless;
    @Stateless
    public class Hello1Bean implements Hello1Local {
        public String getHello1() {
            return "I am Hello1 Bean!";
    package ejb;
    import javax.ejb.Remote;
    @Remote
    public interface Hello2Remote {
        public String getHello2();
    package ejb;
    import javax.ejb.Stateless;
    import javax.ejb.EJB;
    @Stateless
    @EJB(name="ejb/Hello1",
         beanInterface=Hello1Local.class,
         beanName="Hello1Bean")
    public class Hello2Bean implements Hello2Remote {
        @EJB private Hello1Local hello1bean;
        public String getHello2() {
            return hello1bean.getHello1();
    There is no problem looking up Hello2 Bean using an Application Client such as the following:
    public class LocalHelloApplicationClient {
        @EJB(name="Hello2")
        private static Hello2Remote hello2Bean;
        public static void main(String[] args) {
            System.out.println("hello2Bean.getHello2(): " + hello2Bean.getHello2());
    }There is also no problem doing JNDI lookup (from a Stand-Alone Client the same bean if both Hello1 and Hello2 were created by themselves. ie not part of an Enterprise Application (EAR) build. However, I am wondering whether it is possible to do JNDI lookup of the same bean (Hello2) that is part of an Enterprise Application (EAR) built. Below are the type of JNDI lookup entries that I have tried without success:
    public class StandalonePojoCallHelloWorld {
        public static void main(String [] args)
            try
                InitialContext jndiContext = new InitialContext();
                Hello2Remote hello2Bean =  (Hello2Remote) jndiContext.lookup("ejb.Hello2Remote");
                                                                     or
                Hello2Remote hello2Bean =  (Hello2Remote) jndiContext.lookup("LocalHelloEnterpriseApplication.Hello2.remote");
                                                                     or
                Hello2Remote hello2Bean =  (Hello2Remote) jndiContext.lookup("LocalHelloEnterpriseApplication.ejb.Hello2Remote");
                                                                     or
                Hello2Remote hello2Bean =  (Hello2Remote) jndiContext.lookup("LocalHelloEnterpriseApplication.Hello2Remote");
                                                                     or
                Hello2Remote hello2Bean =  (Hello2Remote) jndiContext.lookup("LocalHelloEnterpriseApplication.LocalHelloEnterpriseApplication-ejb.Hello2Remote");
                System.out.println("hello2Bean.getHello2(): " + hello2Bean.getHello2());
            catch (javax.naming.NamingException ne)
             ne.printStackTrace();
    They all came up with the same error message:
    javax.naming.NameNotFoundException: LocalHelloEnterpriseApplication.LocalHelloEnterpriseApplication-ejb.Hello2Remote not found
            at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)
            at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:188)
            at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:74)
            at com.sun.enterprise.naming.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:129)
            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:597)Any suggestion would be appreciated.
    Thanks,
    Jack

    Hello
    I've somme problems to get access to ejb interface from remote stand-alone client.
    Here is my EJB code :
    package stateless;
    import javax.ejb.Stateless;
    @Stateless(name = "TestSB", mappedName = "ejb/stateless/TestSB")
    public class TestEJBBean implements TestEJBRemote {
        public String getMessage() {
           return "Hello EJB World";
    }And the remote interface :
    package stateless;
    import javax.ejb.Remote;
    @Remote
    public interface TestEJBRemote {
        String getMessage();
    } In client side, i just edit main.java like this :
    package testclient;
    import java.io.FileInputStream;
    import java.util.Properties;
    import javax.naming.InitialContext;
    import stateless.TestEJBRemote;
    public class Main {
        public static void main(String[] args) throws Exception {
            Properties props = new Properties();
            props.load(new FileInputStream("jndi.properties"));
            InitialContext ctx = new InitialContext(props);
            TestEJBRemote testEJB = (TestEJBRemote) ctx.lookup("ejb/stateless/TestSB");
            System.out.println(testEJB.getMessage());
    }here is my jndi.properties file (my glassfish server IP is 192.168.0.10) :
    java.naming.factory.initial = com.sun.enterprise.naming.SerialInitContextFactory
    java.naming.factory.url.pkgs = com.sun.enterprise.naming
    java.naming.factory.state = com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
    org.omg.CORBA.ORBInitialHost = 192.168.0.10
    org.omg.CORBA.ORBInitialPort = 3918when i run client on the same machine than the glassfish app server, it works fine.
    But i run it on the different machine than the glassfish app server (on the same LAN without firewall), it fails with this error message :
    eclan@eclan-laptop:~/NetBeansProjects/TestClient$ java -jar dist/TestClient.jar
    24 ao&ucirc;t 2008 09:53:05 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
    ATTENTION: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: 127.0.1.1; port: 3918"
    org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2690)
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2711)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:261)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
         at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:130)
         at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:192)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:181)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:325)
         at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
         at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
         at com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:131)
         at com.sun.enterprise.naming.SerialContext.getRemoteProvider(SerialContext.java:220)
         at com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:160)
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
         at javax.naming.InitialContext.lookup(InitialContext.java:392)
         at testclient.Main.main(Main.java:14)
    Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:347)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:244)
         ... 13 more
    Caused by: java.net.ConnectException: Connection refused
         at sun.nio.ch.Net.connect(Native Method)
         at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
         at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)
         ... 14 more
    24 ao&ucirc;t 2008 09:53:05 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
    ATTENTION: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: 127.0.1.1; port: 4038"
    org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2690)
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2711)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:261)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
         at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:130)
         at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:192)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:181)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:325)
         at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
         at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
         at com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:131)
         at com.sun.enterprise.naming.SerialContext.getRemoteProvider(SerialContext.java:220)
         at com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:160)
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
         at javax.naming.InitialContext.lookup(InitialContext.java:392)
         at testclient.Main.main(Main.java:14)
    Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:347)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:244)
         ... 13 more
    Caused by: java.net.ConnectException: Connection refused
         at sun.nio.ch.Net.connect(Native Method)
         at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
         at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)
         ... 14 more
    24 ao&ucirc;t 2008 09:53:05 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
    ATTENTION: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: 127.0.1.1; port: 4138"
    org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2690)
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2711)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:261)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
         at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:130)
         at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:192)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:181)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:325)
         at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
         at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
         at com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:131)
         at com.sun.enterprise.naming.SerialContext.getRemoteProvider(SerialContext.java:220)
         at com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:160)
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
         at javax.naming.InitialContext.lookup(InitialContext.java:392)
         at testclient.Main.main(Main.java:14)
    Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:347)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:244)
         ... 13 more
    Caused by: java.net.ConnectException: Connection refused
         at sun.nio.ch.Net.connect(Native Method)
         at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
         at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)
         ... 14 more
    24 ao&ucirc;t 2008 09:53:05 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
    ATTENTION: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: 127.0.1.1; port: 3918"
    org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2690)
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2711)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:261)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
         at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:130)
         at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:192)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:181)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:325)
         at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
         at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
         at com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:131)
         at com.sun.enterprise.naming.SerialContext.getRemoteProvider(SerialContext.java:220)
         at com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:160)
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
         at javax.naming.InitialContext.lookup(InitialContext.java:392)
         at testclient.Main.main(Main.java:14)
    Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:347)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:244)
         ... 13 more
    Caused by: java.net.ConnectException: Connection refused
         at sun.nio.ch.Net.connect(Native Method)
         at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
         at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)
         ... 14 more
    24 ao&ucirc;t 2008 09:53:05 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
    ATTENTION: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: 127.0.1.1; port: 4038"
    org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2690)
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2711)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:261)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
         at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:130)
         at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:192)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:181)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:325)
         at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
         at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
         at com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:131)
         at com.sun.enterprise.naming.SerialContext.getRemoteProvider(SerialContext.java:220)
         at com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:160)
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
         at javax.naming.InitialContext.lookup(InitialContext.java:392)
         at testclient.Main.main(Main.java:14)
    Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:347)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:244)
         ... 13 more
    Caused by: java.net.ConnectException: Connection refused
         at sun.nio.ch.Net.connect(Native Method)
         at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
         at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)
         ... 14 more
    24 ao&ucirc;t 2008 09:53:05 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
    ATTENTION: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: 127.0.1.1; port: 4138"
    org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2690)
         at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2711)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:261)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
         at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:130)
         at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:192)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:181)
         at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:325)
         at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
         at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
         at com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:131)
         at com.sun.enterprise.naming.SerialContext.getRemoteProvider(SerialContext.java:220)
         at com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:160)
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
         at javax.naming.InitialContext.lookup(InitialContext.java:392)
         at testclient.Main.main(Main.java:14)
    Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:347)
         at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:244)
         ... 13 more
    Caused by: java.net.ConnectException: Connection refused
         at sun.nio.ch.Net.connect(Native Method)
         at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
         at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
         at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)
         ... 14 more
    eclan@eclan-laptop:~/NetBeansProjects/TestClient$ THANKS YOU FOR YOUR HELP
    Justin

  • Specifying JNDI Details for Controls (EJB/JMS) in Workshop

    Hello,
    I was running into some basic issues in using workshop for building applications. Any help is appreciated !
    How do I point Controls (EJB/JMS) to JNDI where the Objects have been bound
    In J2EE I will do this :
    Context ctx = new InitialContext(ht); // ht has Provider URL etc.
    Specifically in Design view of Workshop for (WLI) JMS Control how do you define PROVIDER_URL, SECURITY_PRINCIPAL, etc. My JMS Server is targeted to separate Managed Server that where Workshop Applications are deployed and I do not want to create Foriegn Destinations etc. on Managed Server where Applications get deployed.
    For EJB Controls: How do you lookup remote EJBs that get deployed as a part of (EARs) on managed server (different from where Workshop Application and EJB Controls reside)
    Basic Question: How do we distribute this "EJB Control" JAR to clients to call these EJBs using controls and specify the JNDI Environment for the control that surfaces the EJB resource deployed remotely?
    I cannot import these as modules in an Workshop Application (=> EAR) and generate controls from these as they will get "deployed" in that application and we want only one deployment.
    Thanks
    Harish

    Hi there,
    In your GUI client you should consdier building a model that represents the data that you want the GUI to display. This model would contain the references to the EJB's that you need to use. If you want to avoid using some kid of model then it really depends on the complexity of your GUI. If your GUI consists of one JFrame then everything can be done inside the main class for the GUI. If you have lots of sub windows then you need to consider where the references will be used. If theyare used in more than one window then you could end up with lots of complex cross references which is why the model would be better in this situation.
    JNDI lookups can be expensive and this depends on several factors particularly network latency, if your client is self contained then once you have a reference to a home interface then you may as well keep and use it for any future calls. The key to this is keeping references to home interfaces as instance variables rather than scoping them locally.
    There should really be no bottleneck caused by using as single session bean as a Facade to your EJB tier. The Session Facade is a very common pattern and the one that is most espoused by the various authors writing EJB tech books. As far as coupling is concerned this is an ideal situation as your client can then make coarse grained calls to the single facade session bean instead of making lots of smaller fine-grained calls to several session beans. I'd say that this is a good general design.
    Hope this helps
    Amanda
    Developer Technical Support
    Sun Microsystems
    http://www.sun.com/developers

  • Error during JNDI lookup Accessing Remote EJB (access to web service restricted using declarative security model)

    Hello everyone,
    I developed a Web Service prototype accessing remote EJB using the EJB
    control with special syntax in the jndi-name attribute: @jws:ejb
    home-jndi-name="t3://10.10.245.70:7131/AccountDelegatorEJB"
    Everything works fine, but I get an error when I restrict access to my web
    service with a declarative security model by implementing steps provided in
    help doc:
    - Define the web resource you wish to protect
    - Define which security role is required to access the web resource
    - Define which users are granted the required security role
    - Configure WebLogic Server security for my web service(Compatibility
    Security/Users)
    I launch the service by entering the address in a web browser. When prompted
    to accept the digital certificate, click Yes, when prompted for network
    authentication information, enter username and password, navigate to the
    Test Form tab of Test View, invoke the method by clicking the button and I
    get the following exception:
    <error>
    <faultcode>JWSError</faultcode>
    <faultstring>Error during JNDI lookup from
    jndi:t3://10.10.245.70:7131/AccountDelegatorEJB[Lookup failed for
    name:t3://10.10.245.70:7131/AccountDelegatorEJB]</faultstring>
    <detail>
    <jwErrorDetail> weblogic.jws.control.ControlException: Error during JNDI
    lookup from jndi:t3://10.10.245.70:7131/AccountDelegatorEJB[Lookup failed
    for name:t3://10.10.245.70:7131/AccountDelegatorEJB] at
    weblogic.knex.control.EJBControlImpl.acquireResources(EJBControlImpl.java:27
    8) at
    weblogic.knex.context.JwsInternalContext.acquireResources(JwsInternalContext
    .java:220) at
    weblogic.knex.control.ControlHandler.invoke(ControlHandler.java:260) at
    ibas.AccountControl.getTransactionHistory(AccountControl.ctrl) at
    ibas.GetSecure.retrieveVisaHistoryTxn(GetSecure.jws:64) </jwErrorDetail>
    </detail>
    </error>
    I have a simple Hello method as well in my WebService (which is also
    restricted) and it works fine, but remote EJB access doesn't. I tested my
    prototype on Weblogic 7.2 and 8.1 platforms - same result.
    Is that a bug or I am missing some additional configuration in order to get
    that working. Has anyone seen similar behavior? Is there a known resolution?
    Or a suggested way to work around the problem?
    Thank you.
    Andre

    Andre,
    It would be best if this issue is handled as an Eval Support case. Please
    BEA Customer Support at http://support.beasys.com along with the required
    files, and request that an Eval support case be created for this issue.
    Thanks
    Raj Alagumalai
    WebLogic Workshop Support
    "Andre Shergin" <[email protected]> wrote in message
    news:[email protected]...
    Anurag,
    I removed "t3", still get an error but a different one (Unable to create
    InitialContext:null):
    <error>
    <faultcode>JWSError</faultcode>
    <faultstring>Error during JNDI lookup from
    jndi://secuser1:[email protected]:7131/AccountDelegatorEJB[Unable to
    create InitialContext:null]</faultstring>
    <detail>
    <jwErrorDetail> weblogic.jws.control.ControlException: Error during JNDI
    lookup from
    jndi://secuser1:[email protected]:7131/AccountDelegatorEJB[Unable to
    create InitialContext:null] at
    weblogic.knex.control.EJBControlImpl.acquireResources(EJBControlImpl.java:27
    8) at
    weblogic.knex.context.JwsInternalContext.acquireResources(JwsInternalContext
    .java:220) at
    weblogic.knex.control.ControlHandler.invoke(ControlHandler.java:260) at
    ibas.AccountControl.getTransactionHistory(AccountControl.ctrl) at
    ibas.GetVisaHistoryTransactions.getVisaHistoryTxn(GetVisaHistoryTransactions
    .jws:67) </jwErrorDetail>
    </detail>
    </error>
    Note: inter-domain communication is configured properly. The Web Service to
    remote EJB works fine without a declarative security.
    Any other ideas?
    Thank you for your help.
    Andre
    "Anurag" <[email protected]> wrote in message
    news:[email protected]...
    Andre,
    It seems you are using the URL
    jndi:t3://secuser1:[email protected]:7131/AccountDelegatorEJB
    whereas you should not be specifying the "t3:" protocol.
    The URL should be like
    jndi://secuser1:[email protected]:7131/AccountDelegatorEJB
    Please do let me know if you see any issues with this.
    Note that this will only allow you to access remote EJBs in the same WLS
    domain. For accessing EJBs on another domain, you need to configure
    inter-domain communication by
    following a few simple steps as mentioned at
    http://e-docs.bea.com/wls/docs81/ConsoleHelp/jta.html#1106135. This link has
    been provided in the EJB Control Workshop documentation.
    Regards,
    Anurag
    "Andre Shergin" <[email protected]> wrote in message
    news:[email protected]...
    Raj,
    I tried that before, it didn't help. I got similar error message:
    <error>
    <faultcode>JWSError</faultcode>
    <faultstring>Error during JNDI lookup from
    jndi:t3://secuser1:[email protected]:7131/AccountDelegatorEJB[Lookup
    failed for
    name:t3://secuser1:[email protected]:7131/AccountDelegatorEJB]</faultstr
    ing>
    <detail>
    <jwErrorDetail> weblogic.jws.control.ControlException: Error during JNDI
    lookup from
    jndi:t3://secuser1:[email protected]:7131/AccountDelegatorEJB[Lookup
    failed for
    name:t3://secuser1:[email protected]:7131/AccountDelegatorEJB] at
    weblogic.knex.control.EJBControlImpl.acquireResources(EJBControlImpl.java:27
    8) at
    weblogic.knex.context.JwsInternalContext.acquireResources(JwsInternalContext
    .java:220) at
    weblogic.knex.control.ControlHandler.invoke(ControlHandler.java:260) at
    ibas.AccountControl.getTransactionHistory(AccountControl.ctrl) at
    ibas.GetSecure.retrieveVisaHistoryTxn(GetSecure.jws:64) </jwErrorDetail>
    </detail>
    </error>
    Anything else should I try?
    P.S. AccountDelegatorEJB, the remote EJB my Web Service calls is NOTaccess
    restricted.
    I hope there is a solution.
    Thanks,
    Andre
    "Raj Alagumalai" <[email protected]> wrote in message
    news:[email protected]...
    Andre,
    Can you try using the following url with username and password
    jndi://username:password@host:7001/my.resource.jndi.object ?
    once you add webapp level security, the authenticated is the user who
    invokes the EJB.
    http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/controls/ejb/con
    CreatingANewEJBControl.html?skipReload=true
    has more info on using remote EJB's.
    Hope this helps.
    Thanks
    Raj Alagumalai
    WebLogic Workshop Support
    "Alla Resnik" <[email protected]> wrote in message
    news:[email protected]...
    Hello everyone,
    I developed a Web Service prototype accessing remote EJB using the EJB
    control with special syntax in the jndi-name attribute: @jws:ejb
    home-jndi-name="t3://10.10.245.70:7131/AccountDelegatorEJB"
    Everything works fine, but I get an error when I restrict access to my
    web
    service with a declarative security model by implementing steps
    provided
    in
    help doc:
    - Define the web resource you wish to protect
    - Define which security role is required to access the web resource
    - Define which users are granted the required security role
    - Configure WebLogic Server security for my web service(Compatibility
    Security/Users)
    I launch the service by entering the address in a web browser. Whenprompted
    to accept the digital certificate, click Yes, when prompted for
    network
    authentication information, enter username and password, navigate tothe
    Test Form tab of Test View, invoke the method by clicking the buttonand
    I
    get the following exception:
    <error>
    <faultcode>JWSError</faultcode>
    <faultstring>Error during JNDI lookup from
    jndi:t3://10.10.245.70:7131/AccountDelegatorEJB[Lookup failed for
    name:t3://10.10.245.70:7131/AccountDelegatorEJB]</faultstring>
    <detail>
    <jwErrorDetail> weblogic.jws.control.ControlException: Error during
    JNDI
    lookup from jndi:t3://10.10.245.70:7131/AccountDelegatorEJB[Lookupfailed
    for name:t3://10.10.245.70:7131/AccountDelegatorEJB] at
    weblogic.knex.control.EJBControlImpl.acquireResources(EJBControlImpl.java:27
    8) at
    weblogic.knex.context.JwsInternalContext.acquireResources(JwsInternalContext
    .java:220) at
    weblogic.knex.control.ControlHandler.invoke(ControlHandler.java:260)at
    ibas.AccountControl.getTransactionHistory(AccountControl.ctrl) at
    ibas.GetSecure.retrieveVisaHistoryTxn(GetSecure.jws:64)</jwErrorDetail>
    </detail>
    </error>
    I have a simple Hello method as well in my WebService (which is also
    restricted) and it works fine, but remote EJB access doesn't. I testedmy
    prototype on Weblogic 7.2 and 8.1 platforms - same result.
    Is that a bug or I am missing some additional configuration in order
    to
    get
    that working. Has anyone seen similar behavior? Is there a knownresolution?
    Or a suggested way to work around the problem?
    Thank you.
    Andre

  • Servlet jndi lookup to remote EJB, servlet and EJB not in the same application

    Hi,
    I think that the subject explain my problem.
    I have Oracle IAS9i 9.0.2.0.0, and JDeveloper 9.0.2.829
    I have deployed and EJB in IAS9i and i want to use from the developer machines, which have JDeveloper.
    how can i to do remote calls from JDeveloper?.
    I have modifed the orion-application.xml, and added remote=true.
    I have modifed the rmi.xml and added the hosts where the Jdeveloper placed.
    Any ideas?
    Thanks and cheers
    P.D The app server and jdeveloper are in the same net.
    if it is posible replys me to [email protected] too.

    Steps to access a remote EJB from within OC4J
    ++++++++++++++++++++++++++++++++++++++++++++++
    1) Deploy EJB application (ApplicationRemote) to remote container (REMOTE)
    "java -jar admin.jar -deploy ormi://REMOTE.hostname:REMOTE.port REMOTE.username REMOTE.password -deploy -file ApplicationRemote.ear
    -deploymentName ApplicationRemote"
    2) Ensure that local application (ApplicationLocal) has ejb-ref tags for remote EJBs accessed (in web.xml or ejb-jar.xml)
    3) Deploy to local container (LOCAL) an empty application (ApplicationEmpty) with the same name as the remote application (ApplicationRemote)
    "java -jar admin.jar -deploy ormi://LOCAL.hostname:LOCAL.port LOCAL.username LOCAL.password -deploy -file ApplicationEmpty.ear -deploymentName
    ApplicationRemote"
    5) Deploy local application (ApplicationLocal) to local container (LOCAL)
    "java -jar admin.jar -deploy ormi://LOCAL.hostname:LOCAL.port LOCAL.username LOCAL.password -deploy -file ApplicationLocal.ear -deploymentName
    ApplicationLocal"
    4)Restart local container
    ApplicationEmpty should consist of just an application.xml file - no modules. The same file can be deployed with different application names for all the remote
    applications that must be accessed.
    ApplicationLocal should access the remote EJB by using the following JNDI properties
    java.naming.factory.initial = "com.evermind.server.rmi.RMIInitialContextFactory"
    java.naming.provider.url = "ormi://REMOTE.hostname:REMOTE.port/ApplicationRemote"
    java.naming.security.principal = "REMOTE.username"
    java.naming.security.credentials = "REMOTE.password"
    regards
    Debu Panda

  • Problems while performing lookup for Local EJBs

    Can anybody tell me how can i perform local ejb lookup in Sun app Server 8.0/8.1 ?
    I have following entries in ejb-jar.xml.
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
    <ejb-jar >
    <enterprise-beans>
    <session >
    <ejb-name>TeamLeaderBean</ejb-name>
    <local-home>spring.ejb.example.TeamLeaderLocalHome
    </local- home>
    <local>spring.ejb.example.TeamLeaderLocal</local>
    <ejb-class>spring.ejb.example.TeamLeaderBean</ejb-class>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>
    </session>
    </enterprise-beans>
    <assembly-descriptor></assembly-descriptor>
    </ejb-jar>
    In sun-ejb-jar.xml I have
    <sun-ejb-jar>
    <enterprise-beans>
    <ejb>
    <ejb-name>TeamLeaderBean</ejb-name>
    <jndi-name>TeamLeaderBeanLocal</jndi-name>
    </ejb>
    </enterprise-beans>
    </sun-ejb-jar>
    In the client EJBs code I have used following ways of performing lookup...
    ctx.lookup("java:comp/env//TeamLeaderBeanLocal");
    ctx.lookup("java:comp/env/ejb/local/TeamLeaderBeanLocal");
    ctx.lookup("ejb/TeamLeaderBeanLocal");
    Unfortunately none of these performs a successful lookup...???
    Can anybody solve my problem?

    In order to look up a local EJB from an EJB client you have to add an <ejb-local-ref> element for client EJB. So:
    <session>
    <ejb-name>MyClientEJB</ejb-name>
    <ejb-local-ref>
    <ejb-ref-name>ejb/TeamLeaderBeanLocal</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <ejb-link>TeamLeaderBeanLocal</ejb-link>
    </ejb-local-ref>
    </session>
    fil
    Can anybody tell me how can i perform local ejb
    lookup in Sun app Server 8.0/8.1 ?
    I have following entries in ejb-jar.xml.
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems,
    Inc.//DTD Enterprise JavaBeans 2.0//EN"
    "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
    <ejb-jar >
    <enterprise-beans>
    <session >
    <ejb-name>TeamLeaderBean</ejb-name>
    <local-home>spring.ejb.example.TeamLeaderLocalHome
    </local- home>
    <local>spring.ejb.example.TeamLeaderLocal</local>
    <ejb-class>spring.ejb.example.TeamLeaderBean</ejb-clas
    s>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>
    </session>
    </enterprise-beans>
    <assembly-descriptor></assembly-descriptor>
    </ejb-jar>
    In sun-ejb-jar.xml I have
    <sun-ejb-jar>
    <enterprise-beans>
    <ejb>
    <ejb-name>TeamLeaderBean</ejb-name>
    <jndi-name>TeamLeaderBeanLocal</jndi-name>
    </ejb>
    </enterprise-beans>
    </sun-ejb-jar>
    In the client EJBs code I have used following ways of
    performing lookup...
    ctx.lookup("java:comp/env//TeamLeaderBeanLocal");
    ctx.lookup("java:comp/env/ejb/local/TeamLeaderBeanLoca
    l");
    ctx.lookup("ejb/TeamLeaderBeanLocal");
    Unfortunately none of these performs a successful
    lookup...???
    Can anybody solve my problem?

  • JNDI Lookup for EJB3 (Bean to Bean)

    Hi Forum,
    i've search the whole internet and two books but I could not find an answer that pleased me.
    I want to get a reference to an EJB3 by JNDI Lookup. With container managed dependency injection everything works fine but I have to do a little more generic way, thats why I want to work with JNDI Lookup.
    I have the following situation:
    At first I have a stateless bean
    @Local
    public interface Job {
         * run the job
         * @return true if the job executed without errors
        public boolean run(SchedulerConfig schedulerConfig ,JobContext context);
    @Local
    public interface AConcreteJobLocal extends Job {   
    //no more declarations
    @Stateless
    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    public class AConcreteJobBean implements AConcreteJobLocal {
    //implemented methods goes here | removed for better overview in the post
    } This is a typical declaration for a bunch of jobs I have. Every concrete job has it's own bean if it necessary in some way for you to know.
    So now I wanted to write a bean which returns me an bean instance via a JNDI lookup
    @Stateless
    public class JobJNDILookupBean implements JobJNDILookupLocal {
        Logger logger = Logger.getLogger(JobJNDILookupBean.class.getName());
        public Job getJobBeanFromJNDIName(String jndiName) {
            Job job = null;
            try {
                Context c = new InitialContext();
                job = (Job) c.lookup("jndiName");
            } catch (NamingException ex) {
                Logger.getLogger(JobJNDILookupBean.class.getName()).log(Level.SEVERE, null, ex);
            } catch (IllegalArgumentException ex) {
                logger.log(Level.SEVERE, "Bean not found", ex);
            return job;
    }When I call this method I always get a NameNotFoundException
    javax.naming.NameNotFoundException: JNDI_NAME_GOES_HERE not found
            at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)
            at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:188)
            at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:74)
            at com.sun.enterprise.naming.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:111)
            at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
            at javax.naming.InitialContext.lookup(InitialContext.java:351)
            at com.vw.ais.dcl.timer.engine.JobJNDILookup.getJobBeanFromJNDIName(JobJNDILookup.java:46)
            at com.vw.ais.dcl.timer.engine.EngineBean.init(EngineBean.java:221)
            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.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
            at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
            at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
            at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
            at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:197)
            at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:83)
            at $Proxy713.init(Unknown Source)
            at com.vw.ais.dcl.timer.SchedulerBean.runEngine(SchedulerBean.java:192)
            at com.vw.ais.dcl.timer.SchedulerBean.handleIncomingByTimer(SchedulerBean.java:171)
            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.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
            at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
            at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
            at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:2824)
            at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1401)
            at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:99)
            at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1952)
            at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.service(EJBTimerService.java:1948)
            at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75)
            at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)I've tried I guess all combinations for the JNDI_NAME
    java:/comp/env/ejb/AConcreteJob
    java:/comp/env/ejb/AConcreteJobLocal
    java:/comp/env/ejb/AConcreteJobBean
    java:/comp/env/AConcreteJob
    java:/comp/env/full.package.and.Class.name
    this all without java:/comp/env
    etc.
    The only way it worked was when I added a annotation to the JobJNDILookupBean in this way
    @Stateless
    *@EJB(name="ejb/AConcreteJob",beanInterface=A.Interface.location)*
    public class JobJNDILookupBean implements JobJNDILookupLocal {
    }But this is not what I want to do. Thats why my question. How can I lookup a bean without annotate it in the bean which want to look it up???
    In other words whats wrong here
    @Stateless
    public class JobJNDILookupBean implements JobJNDILookupLocal {
        Logger logger = Logger.getLogger(JobJNDILookupBean.class.getName());
        public Job getJobBeanFromJNDIName(String someJndiName) {
            Job job = null;
            try {
                Context c = new InitialContext();
                job = (Job) c.lookup("someJndiName");
            } catch (NamingException ex) {
                Logger.getLogger(JobJNDILookupBean.class.getName()).log(Level.SEVERE, null, ex);
            } catch (IllegalArgumentException ex) {
                logger.log(Level.SEVERE, "Bean not found", ex);
            return job;
    }I hope you understand my question and more than this I hope some has the answer.

    Hi Zsom,
    Zsom wrote:
    One thing you need to keep in mind is that beans aren't instantiated every time you make a call to your EJB. You're right! But because the fact the beans are all stateless it doesn't matter. I don't want to get a new EJB at a lookup. If I get a reference to a bean which was used a million times before it is absolutely ok
    Zsom wrote:
    You might be gaining some time because the container can create new beans more quickly, but you are also looking up the beans before each call, which in the long run will be even more expensive.Mhm, I don't know if I understand you. Maybe I explain my process a little bit. I have a lot of different jobs in my application (JobDoThis, JobDoThat, JobFoo, JobBar). Every job has a own bean which keeps the business logic. Furthermore I have an job engine which is able to execute jobs which are configured to run and this engine can solve some dependencies (If JobFoo fails don't execute JobBar , and so on). When I build my engine I want to get a reference to a jobBean by jndi lookup which keeps the business logic and then call some method on it. This means that the lookup will only be called when I build a new engine. And because this doesn't happen so often performance is not so important. Furthermore if all jobs all configured to run the application needs sometimes more than 12 hours (depended from the amount of data) for one run (Start to End -> the application has a little script character), that's why performance as I said already is not so important.
    Zsom wrote:
    But it would be worth making some test, because to me it seems a bit like bad design.Yes it could be, but this was my first thought to instantiate a bean (or get a reference to an existing one) dynamically. I don't like this hard coded dependency injection. I mean it's great If you know at compiletime which beans you need. But because we don't know which beans we need it's a big overhead to inject them all by container and then use only 40 percent of the injected bean because for example only 40 of 100 jobs shall run.
    If there is another approach to get a reference dynamically which is better than this then I will try, no problem, but unfortunally I don't see another.

Maybe you are looking for

  • Bridge think photoshop is busy with a task  -  CS6/Window 7

    Bridge keeps telling me that photoshop is busy with a task and asks if a wish to queue the request. Photoshop is not busy. I can go to photoshop and open and close items, run batch process, ect. I even tried closing and opening Photoshop. Bridge stil

  • Hi guys urgent

    Hi, I am using SO_NEW_DOCUMENT_SEND_API1 for sending mail notifications    l_wa_recieve-receiver = '[email protected]'.    l_wa_recieve-rec_type = 'U'.    l_wa_recieve-com_type  = 'SOTR'.    APPEND l_wa_recieve TO l_it_recieve.    clear l_wa_recieve.

  • IPhone 5 iMessage not syncing to iPad

    I just got the iPhone 5 and can't get my incoming iMessages to sync to my iPad. When I send an iMessage, I see it on both devices, however, I only recieve iMessages on the device I sent the message from. I used to have an iPhone 4 and there was no is

  • Resizing on html page

    I have created an animation with a stage size of 1000px wide by 321px high. When I insert it into Dreamweaver using the Insert > Media > Edge Animate Composition, it resizes to 1020 by 341, then when I play it online on Safari, it looks OK, but on Fi

  • Cannot install InDesign once removed from computer

    Hi Indesign users, Here are some tech details: 1. MacMini 3.1, 6Gb RAM, OS X 10.9 2. Adobe CC - InDesign, Photoshop, Illustrator 3. InDesign worked without errors until this morning. 4. No updates from yesterday (Saturday, Novermber 30) and today (De