Clarification for client JNDI lookups needed

Hello,
While analyzing j2eeguide directory samples under iAS 6.0 SP3 I could see that this code is used on the client side for JNDI lookups (from warehouse example):
Properties env = new Properties();
env.put("java.naming.factory.initial",
"com.sun.jndi.cosnaming.CNCtxFactory");
env.put("java.naming.provider.url", "iiop://" + host + ":"+port);
Context initial = new InitialContext(env);
Object objref = initial.lookup("ejb/MyWarehouse");
In runtime deployment descriptor for this sample we have these lines:
<ias-ejb-jar>
<enterprise-beans>
<session>
<ejb-name>MyWarehouse</ejb-name>
<guid>{a430b5c0-673f-11d4-a025-0010a4e78552}</guid>
Does it mean that iAS automatically places beans under java:comp/env/ejb directory? This is recommended (but not required) place by J2EE 1.3 spec. For other AppServers I need explicitly specify through <jndi-name> clause (in form <jndi-name>ejb/MyWarehouse</jndi-name>) in which place my bean should be placed and thus could put them under for example java:comp/env/testejb/MyWarehouse. Any comments on this?
Thank you,
Andrejus

I'm using a Singleton class to cache HomeInterfaces. The first time a
HomeInterface is requested, the JNDI lookup is done, after that, all
requests to that HomeInterface are handled by the cache. Works great, no
problems. AFAIK there are no problems with storing the HomeInterface
reference and reusing it.
Hope that helps,
Nils
Tiffany wrote:
>
JNDI lookups are expensive timewise. Our question is ... would it be
pratical to lookup all our EJB Home interfaces once at startup and store
these references in a global class accessible to all clients? These home
interfaces then become readily available factories for acquiring instances
of remote interfaces. Is there anything wrong with this picture? Is this a
problem because these home stubs are not reentrant and may be accessed
concurrently by more than one client? Is there a problem with have one home
reference create multiple remote references of an ejb?
Any light that can be shed on this question wouls be appreciated.
Thanks.
tiffany
San Diego--
============================
[email protected]

Similar Messages

  • 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.
              > >
              > >
              > >
              > >
              >
              >
              

  • Using external LDAP server for  WL JNDI lookups

    I'm trying to find out if it is possible to re-direct JNDI calls to the WL
    server to an external LDAP server. I know you can install an external LDAP
    server for security purposes, but I would like to use an external LDAP
    server to handle all JNDI lookups (like for JNDI EJB name location, etc.).
    Is this possible?

    You typically need to use our JNDI store. We strongly recommend this for
    performance reasons..
    You can use the JNDI To LDAP bridge which is available from the sun web
    site.
    Michael Girdley
    BEA Systems Inc
    "Jack Archer" <[email protected]> wrote in message
    news:[email protected]..
    I'm trying to find out if it is possible to re-direct JNDI calls to the WL
    server to an external LDAP server. I know you can install an external LDAP
    server for security purposes, but I would like to use an external LDAP
    server to handle all JNDI lookups (like for JNDI EJB name location, etc.).
    Is this possible?

  • JNDI lookup fails for client applications

    I am currently porting our j2ee application to weblogic 7.0. The application already
    runs successfully on Orion and Jboss. I have got everything working now except
    for our client applications, which all fail with a JNDI lookup error. The exception
    is:
    javax.naming.NameNotFoundException: Unable to resolve 'java:comp.env/ejb/QualiferInstance'
    Resolved: '' Unresolved:'java:comp' ; remaining name 'java:comp.env
    /ejb/QualifierInstance'
    at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutbound
    equest.java:109)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
    ef.java:262)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
    ef.java:229)
    at weblogic.jndi.internal.ServerNamingNode_WLStub.lookup(Unknown Source
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:338)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:333)
    at javax.naming.InitialContext.lookup(InitialContext.java:347)
    at BatchIndexer.main(BatchIndexer.java:89)
    I have looked up numerous postings on various mailing lists describing similar
    problems, but none of them give an explanation which helps me.
    I am convinced that I have the ejb deployment descriptors correct because all
    our JSPs, servlets and session beans successfully lookup and use the EJBs.
    I am also convinced that I have the correct code for the JNDI lookup in our client
    applications, because they work perfectly well on Orion and Jboss and use syntax
    which is described as correct in the jsee specification, i.e. "java:comp/env/..."
    Here is the descriptor from weblogic-ejb-jar.xml for the EJB mentioned in the
    example exception above:
    <weblogic-enterprise-bean>
    <ejb-name>QualifierInstance</ejb-name>
    <jndi-name>comp/env/ejb/QualifierInstance</jndi-name>
    </weblogic-enterprise-bean>
    And here is the descriptor in the application-client.xml file:
         <ejb-ref>
              <ejb-ref-name>ejb/QualifierInstance</ejb-ref-name>
              <ejb-ref-type>Entity</ejb-ref-type>           <home>com.espritsoutron.xengine.ejb.metamodel.QualifierInstanceHome</home>
              <remote>com.espritsoutron.xengine.ejb.metamodel.QualifierInstance</remote>
              <ejb-link>QualifierInstance</ejb-link>
         </ejb-ref>
    And here is the code in the client application that attempts to perform the lookup:
    qiHome = (QualifierInstanceHome)PortableRemoteObject.narrow(context.lookup("java:comp/env/ejb/QualifierInstance"),
    QualifierInstanceHome.class);
    The annoying thing is that I know I can make this work if I change the code to
    omit the "java:" prefix, but I don't want to do this because then it would no
    longer work on either Orion and Jboss.
    P.S. I have also tried changing the jndi-name in the weblogic-ejb-jar descriptor
    to "ejb/QualifierInstance" and just "QualifierInstance", but neither of these
    make any difference. I even tried chaning it to "java:comp/env/ejb/QualifierInstance"
    but that totally breaks the server.
    Can anyone can please help with this?

    you can find the JNDI name in the JNDI tree from the admin console
    right click on your server and choose "view jndi tree".
    if you bind your ejb to ejb/QualifierInstance
    you look it up with that exact same name ejb/QualifierInstance
    Julian Fawcett wrote:
    I am currently porting our j2ee application to weblogic 7.0. The application already
    runs successfully on Orion and Jboss. I have got everything working now except
    for our client applications, which all fail with a JNDI lookup error. The exception
    is:
    javax.naming.NameNotFoundException: Unable to resolve 'java:comp.env/ejb/QualiferInstance'
    Resolved: '' Unresolved:'java:comp' ; remaining name 'java:comp.env
    /ejb/QualifierInstance'
    at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutbound
    equest.java:109)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
    ef.java:262)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
    ef.java:229)
    at weblogic.jndi.internal.ServerNamingNode_WLStub.lookup(Unknown Source
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:338)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:333)
    at javax.naming.InitialContext.lookup(InitialContext.java:347)
    at BatchIndexer.main(BatchIndexer.java:89)
    I have looked up numerous postings on various mailing lists describing similar
    problems, but none of them give an explanation which helps me.
    I am convinced that I have the ejb deployment descriptors correct because all
    our JSPs, servlets and session beans successfully lookup and use the EJBs.
    I am also convinced that I have the correct code for the JNDI lookup in our client
    applications, because they work perfectly well on Orion and Jboss and use syntax
    which is described as correct in the jsee specification, i.e. "java:comp/env/..."
    Here is the descriptor from weblogic-ejb-jar.xml for the EJB mentioned in the
    example exception above:
    <weblogic-enterprise-bean>
    <ejb-name>QualifierInstance</ejb-name>
    <jndi-name>comp/env/ejb/QualifierInstance</jndi-name>
    </weblogic-enterprise-bean>
    And here is the descriptor in the application-client.xml file:
         <ejb-ref>
              <ejb-ref-name>ejb/QualifierInstance</ejb-ref-name>
              <ejb-ref-type>Entity</ejb-ref-type>           <home>com.espritsoutron.xengine.ejb.metamodel.QualifierInstanceHome</home>
              <remote>com.espritsoutron.xengine.ejb.metamodel.QualifierInstance</remote>
              <ejb-link>QualifierInstance</ejb-link>
         </ejb-ref>
    And here is the code in the client application that attempts to perform the lookup:
    qiHome = (QualifierInstanceHome)PortableRemoteObject.narrow(context.lookup("java:comp/env/ejb/QualifierInstance"),
    QualifierInstanceHome.class);
    The annoying thing is that I know I can make this work if I change the code to
    omit the "java:" prefix, but I don't want to do this because then it would no
    longer work on either Orion and Jboss.
    P.S. I have also tried changing the jndi-name in the weblogic-ejb-jar descriptor
    to "ejb/QualifierInstance" and just "QualifierInstance", but neither of these
    make any difference. I even tried chaning it to "java:comp/env/ejb/QualifierInstance"
    but that totally breaks the server.
    Can anyone can please help with this?

  • JNDI Lookup code for EntityMananger  inside SessionBean

    Hi ,
    I am using JNDI look up inside my stateless session Bean for Thread Safety issues .
    That is
    @PersistenceContext(Unitname="someunit" name= "somename")
    Context ctx = new InitialContext();
    EntityManager em = (EntityManager)ctx.lookup("somename")Now i am having 4 methods for (CRUD) inside my sessionBean
    Do i need to use this lookup code inside my every method that is in all my 4 methods
    Please tell me this if i am having four methods inside my Session Bean do i need to do lookup inside each of my method.

    Thread safety issues? So you are saying that you actually had them, or you are assuming they will happen?
    Because I have written multiple applications that simply inject an instance of the entity manager into the EJB and I have never had any problems. The whole idea of dependency injection is to minimize the need for manual JNDI lookups; why are you trying to swim against the current?

  • Cost of a local JNDI lookup

    5.1sp8
    I always thought that cost of a local JNDI lookup is pretty
    small, but just found that it is not:
    application JSP's extend common superclass which does(did!) JNDI
    lookup based on the URI and sets a threadlocal variable before
    invoking jspservice() method.
    During performance testing replacing JNDI with a static hashtable
    improved thoughput by ~25-30% (pages themselves are very fast -
    mostly jsp cache tags hits).
    Weird.
    Dimitri

    First of all I am not caching the Initial Context. I am caching the results
    of the initial context lookup into a hashmap (I have changed this from
    hashtable, which I proposed originally in my posting - see my latest post).
    Second, if you have client running in seperate JVM, can not lookup the
    hashmap created by the server.
    Third, on the server side, you cannot get a reference of a startup class.
    The server simply instantiates the class and invoke startup() method (from
    T3StartupDef interface) and it does not keep reference after startup()
    method returns. But you could use another class that you want to get an
    instance of by creating it within the startup class and provide a static
    method to create/return that instance. I guess the proper way of saying it
    would be create the hashmap as a class variable in a singleton class
    (hopefully you get the idea)...
    .raja
    -----Original Message-----
    From: Mittal, Raj [mailto:[email protected]]
    Sent: Wednesday, June 20, 2001 1:16 PM
    To: '[email protected]'
    Subject: Re: cost of a local JNDI lookup
    Raja,
    We are also wrapping all the JNDI requirements in a startup class and WL
    loads it automatically. Now my problem is how to access the InitalContext
    (initialized by startup class) by a client and also on the server side. If
    you have any code that explains that, please pass it along.
    Thanks
    Raj Mittal
    Front Office Group
    NEUBERGER BERMAN
    *(646) 497-4224
    "Raja Mukherjee" <[email protected]> wrote in message
    news:[email protected]...
    Mike,
    Thanks for the reply to the previous message. For the particularbenchmark,
    I knew all the JNDI lookup requirements at the design time (I think that
    would be the case in most applications), so I wrapped them into a startup
    class.
    .raja
    "mike " <[email protected]> wrote in message
    news:[email protected]...
    In the code where you need the context ...
    static Hashtable h=new Hashtable();
    ctx=h.get(ctx_name);
    if(ctx == null){
    ctx=new InitialContext(... args ...);
    h.put(ctx_name, ctx);
    mike
    Kirk Everett <[email protected]> wrote:
    Can you explan what you mean by "use a static hash table"? We did some
    load
    testing on 6.0 SP 1 and saw that
    creating an local initial context is fairly costly and I would like to
    understand your solution. Thanks.
    Kirk
    Raja Mukherjee wrote:
    Dimitri,
    I was surprised to see that in WLS 5.1. I have seen this on 6.0 and
    understood that JNDI lookups need to be sereilized because of the newclass
    loader. In the recent benchmark, for 6.0 we found that the about
    15-20%
    of
    the (client's) application CPU time was spent on JNDI lookup
    (serealization). We changed it to a static hash table.
    Unfortunately, I am only seeing marginal gain in 5.1sp8.
    For all 6.0 applications we are going to use static hashtable. Mightas well
    do it now for 5.1 so that your migration to 6.0 will be easier :).
    .raja
    "Daniel Hoppe" <[email protected]> wrote in message
    news:[email protected]...
    This is irritating. If I remember correctly, until now the official
    statement was that it's not even worth caching an InitialContext ifit's
    a local one. Guess I'll have to review my application for this as
    well.
    >>>>
    Daniel
    -----Ursprüngliche Nachricht-----
    Von: Dimitri Rakitine [mailto:[email protected]]
    Bereitgestellt: Freitag, 15. Juni 2001 05:17
    Bereitgestellt in: performance
    Unterhaltung: cost of a local JNDI lookup
    Betreff: cost of a local JNDI lookup
    5.1sp8
    I always thought that cost of a local JNDI lookup is pretty
    small, but just found that it is not:
    application JSP's extend common superclass which does(did!) JNDI
    lookup based on the URI and sets a threadlocal variable before
    invoking jspservice() method.
    During performance testing replacing JNDI with a static hashtable
    improved thoughput by ~25-30% (pages themselves are very fast -
    mostly jsp cache tags hits).
    Weird.
    Dimitri

  • JNDI lookup with DNS

    Hi all,
    we are using 2 weblogic 5.1 servers (not clustered) for
    our load balancing solution. In our client applications,
    we use a hostname against a DNS for the JNDI lookups for our
    RMI objects deployed on the 2 weblogic servers.
    Ideally, a round-robin load balancing is expected.
    But in reality, all the lookups are sticking to one of our
    servers until we restart our client applications. The
    lookups may switch to another. In our applications,
    we are making many subsequent RMI lookup using JNDI.
    We would like to spread the remote method invocation
    between our 2 servers. How can we integrate with the
    DNS? We have proved that the DNS will return the
    IP addresses of the 2 weblogic in round-robin manner.
    thanks!
    cheers,
    Kenneth
    [email protected]

    Ken,
    What client are you using? We had the same problem when we switched from
    Windows NT to Windows 2000 clients. Round-robin worked fine in NT and by
    default got "stuck" when we tried it from Win 2000 client. There is a
    setting in the network properties on Win 2000 to "unstick" that will fix the
    problem, if this is the setup you have?
    Bart Jenkins, Globeflow SA
    [email protected]
    "Kenneth Yue" <[email protected]> wrote in message
    news:3bb09863$[email protected]..
    >
    >
    Hi all,
    we are using 2 weblogic 5.1 servers (not clustered) for
    our load balancing solution. In our client applications,
    we use a hostname against a DNS for the JNDI lookups for our
    RMI objects deployed on the 2 weblogic servers.
    Ideally, a round-robin load balancing is expected.
    But in reality, all the lookups are sticking to one of our
    servers until we restart our client applications. The
    lookups may switch to another. In our applications,
    we are making many subsequent RMI lookup using JNDI.
    We would like to spread the remote method invocation
    between our 2 servers. How can we integrate with the
    DNS? We have proved that the DNS will return the
    IP addresses of the 2 weblogic in round-robin manner.
    thanks!
    cheers,
    Kenneth
    [email protected]

  • Taking a long time to do JNDI lookup

    Hi,
    I have something like this for my JNDI lookup:
    myEJBHome home = (myEJBHome) PortableRemoteObject.narrow(context.lookup("mybean")          ,myEJBHome.class);
    and
    myEJB session = (myEJB)home.create();
    Recently it's taking an EXTREMELY long time to do these 2 operations (before it took milliseconds, now it's like 10 minutes...but I haven't changed anything at all).
    Any idea why?
    Thanks

    If the bean is in another machine more than likely the connection or firewall issue?
    PC

  • How to create InitialContext for JNDI lookup in a cluster?

              I am new to clusters in WL7 and I wanted to know how a client would create an InitialContext
              object to perform a JNDI lookup for a remote object deployed across serveral servers
              in the cluster. Is the following correct?
              Physcial Servers in the cluster
              machine1:9001
              machine2:9001
              machine3:9001
              Code for creating InitialContext
              Properties p = new Properties();
              p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
              p.put(Context.PROVIDER_URL, "machine1:9001,machine2:9001,machine3:9001");
              Context c = new InitialContext( p);
              Thanks,
              Raffi
              

    Hi Ivaylo,
    There's another alternative solution to your problem. You can have the screen 120 as a user-defined selection screen. i.e., instead of creating this screen through the screen painter, you can create it from within your ABAP Program. This way, you can directly use the SELECT-OPTIONS statement within your screen. You then will no longer have to bother about how to handle the data for the field.
    Especially in the case where your screen 120 has few elements, this approach, in my opinion, will be the best.
    Please let me know if you need any further clarifications on how to go about it if you choose to follow this approach.
    Regards,
    Anand Mandalika.

  • Why only j2sdkee1.3 support JNDI lookup "java:comp/env" from remote client?

    Hi:
    I have been puzzled by this function of j2sdkee1.3.1 support JNDI lookup "java:comp/env" from client. I always think that "java:comp/env" namespace can only be access by the application server self for it is a private namespace. The weblogic and websphere doest support this.
    Why?
    Regards!
    John Lee

    Hi:I'm unable to get JNDI reference object from remote application client with "java:comp/env/ejb/<lookupName>".
    The exception says:
    Application threw an exception:javax.naming.CommunicationException: Cannot connect to ORB [Root exception is org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201 completed: No]
    The J2EE server and client are run on different machines, and needs to be like this. There isn't any problem with JSP/Servlet (cause they run/execute on the server itself). How will the client find out the JNDI refernce my mere specification of "java:comp/env/..."?
    Am I making a mistake anywhere?
    BEA Weblogic & IBM Websphere allows explicitly specifying the server name, while doing JNDI lookup. Is there anything similary for J2EE?
    I couldn't find reference for this anywhere in the J2EE tutorial or EJB books.
    - Devashish

  • Why j2sdkee1.3.1 support JNDI lookup "java:comp/env" from  remote client?

    Hi:
    I have been puzzled by this function of j2sdkee1.3.1 support JNDI lookup "java:comp/env"
    from client. I always think that "java:comp/env" namespace can only be access
    by the application server self for it is a private namespace. The weblogic and
    websphere doest support this.
    Why?
    Regards!
    John

    Hi:I'm unable to get JNDI reference object from remote application client with "java:comp/env/ejb/<lookupName>".
    The exception says:
    Application threw an exception:javax.naming.CommunicationException: Cannot connect to ORB [Root exception is org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201 completed: No]
    The J2EE server and client are run on different machines, and needs to be like this. There isn't any problem with JSP/Servlet (cause they run/execute on the server itself). How will the client find out the JNDI refernce my mere specification of "java:comp/env/..."?
    Am I making a mistake anywhere?
    BEA Weblogic & IBM Websphere allows explicitly specifying the server name, while doing JNDI lookup. Is there anything similary for J2EE?
    I couldn't find reference for this anywhere in the J2EE tutorial or EJB books.
    - Devashish

  • Do I need VXML Port Licenses for CVP Database Lookup.

    Hi,
    Please let me know that whether VXML Port Licenses are required for CVP Database Lookup.
    I am using CVP just for prompt playing in my scenario,
    Appreciate your response.
    Thanks,
    Manish

    [email protected],To make database integration with your IVR, you have different alternatives :1- Use the 'DB Lookup' node ICM scripting node for simple SELECT transactions on SQL Server databases2- Use an 'Application Gateway' component with ICM scripting for more complex database operations on different type of databases. Application Gateway is a software component developed by Cisco partners to make ICM scripts interact with different databases.3- Use VXML scripts. VXML scripts can connect and interact with any kind of databse using the JNDI protocol. You will need a VXML Studio license (to develop the VXML applications) and a CVP Server for VXML Servers (you need to deploy VXML servers on which you will deploy your VXML applications)Hope this will help.
    Good summary. If I can comment ....
    1. DBLookup is so restrictive it is not typically useful for looking up ANIs in a customer DB. It is useful for other things to do with routing - say a DNIS lookup to control some aspect of routing. Look up the restrictions on DBLookup if you don't believe me.
    2. This may be an expensive proposition. Unless you have in-house experience with something like a CTI all events bridge and the ability to code to the required heartbeat interface, you will find building an app gateway tricky. You also need to be in the Cisco Developer's Program ($25k). I have colleagues write app gateways in C++ and VB.NET, so it's possible - just not trvial. For a huge load, this may be the only suitable method, however.
    3. This is the way to go. JNDI is NOT a protocol - it is a naming standard. The protocol that the client (your application running under Tomcat) uses to talk to the server (the database out there) is defined by the library - the JAR file - you hook into it in VXMLServer\lib\endorsed. Through the JNDI specification in Tomcat\conf\server.xml you indicate the host, user name, password and client library that the system needs. Tomcat uses connection pooling to manipulate a pool of connections (threads) giving a more efficient database query system.
    You can then add an additional sepcification through context.xml that allows you to use the JNDI spec in your VXML Database Element.
    If you like coding in Java, you can write a Custom Action Element to use the JNDI (and therefore connection pooling), making your query and manipulating the result. This is the way I do it because I'm a competent programmer. Most will use the Database Element.
    Finally, you could write a Java Custom Action Element that does not use the JNDI at all, but given the server, user, password and database through the settings, opens a connection, runs the query, and closes the connection.
    Regards,
    Geoff

  • 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.

  • 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/
              > > >>--------------------------------------------------------------
              > > >>
              > > >
              > >
              

  • Need clarification for these names, R/3, WAS, NetWeaver

    Hi All
    I posted the question on WAS preview installation, then I realized I should have put it here. Here is the link to that post:
    Need clarification for these names, R/3, WAS, NetWeaver
    Thanks again for any input
    Xueqing
    Added the link to the first post
    Message was edited by: xueqing Han

    Hi Xueqing,
    First of all, sorry for any confusion that we have caused you. I hope I can give you an answer that will clear up the confusion. Sorry, but it is a long explanation of the development of two application solution but history tends to be very long winded!
    It is <b>not</b> true SAP R/3 Enterprise equals SAP Web AS, and I'll hopefully explain why:
    In the beginning (at least in the client server world) SAP only ship SAP R/3. The technology layer under SAP R/3 was called SAP Basis. There was only SAP Basis under SAP R/3.
    SAP then started to deliver other software solutions that were not included in or built on the SAP R/3 software. These included SAP Business Information Warehouse, SAP APO, SAP SEM, SAP CRM, and the list goes on.
    These solutions needed to run on technology layer (like SAP R/3 did). SAP Basis was the obvious choice for this because of the common technology layer providing DB/OS abstraction and a coding environment.
    <b>~2001:</b>
    Later there came the need to have SAP Basis support the web and its web standards and other programming languages. This radically changed what SAP Basis was and we decided to rename the new technology layer to SAP Web Application Server (SAP Web AS). So the SAP Basis name was retired and SAP Basis 4.6D was the last release called SAP Basis.
    The new release and the "technology change" means that all the applications mentioned above now ran on SAP Web AS. The first release of SAP Web AS was 6.10.
    <b>~2002:</b>
    SAP Web AS was first used in SAP R/3 Enterprise release .
    The important fact is that SAP R/3 Enterprise runs on SAP Web AS. SAP R/3 Enterprise = SAP R/3 business applications + new business functions + SAP Web AS.
    <b>~2003:</b>
    I hope the above explanation is clear, because technology takes another major change. It was realized that SAP now had a collection of business solutions/applications (SAP R/3, mySAP CRM, mySAP SCM, etc) and a collection of technology solutions (SAP Web AS, SAP BW, SAP EP, etc). The technology requirements for the business solutions did not end at SAP Web AS, they needed portal, data warehouse, knowledge management capabilities, etc to develop business solutions on.
    To address this SAP made the decision to combine all the technology solutions and tools into one single platform. This made complete sense for developers (SAP, Partners and customers). This single platform is called SAP NetWeaver. It includes all the old individual components of SAP Web AS, SAP BW, SAP KM, SAP EP, etc).
    <b>~2004:</b>
    I think you can guess what the next step is. Yes, the new release of SAP R/3. Since the release of SAP R/3 Enterprise and the release of SAP NetWeaver, SAP R/3's name changes. It is now called mySAP ERP as it includes a lot of applications that were previously sold separately (like SAP SEM, MSS, ESS, etc).
    So now mySAP ERP runs on SAP NetWeaver (yes everything that was in SAP Basis and then in SAP Web AS is still there but SAP NetWeaver has so much more now).
    Also with the release of SAP NetWeaver, SAP starts to stop using the old technology component names - you will not hear us talk about SAP Web AS, SAP BW, etc anymore, just SAP NetWeaver releases.
    In addition all the other SAP business applications also run on SAP NetWeaver, so the latest version of mySAP CRM, mySAP SRM, and mySAP SCM all run on SAP NetWeaver.
    So to simplify the explanation, it would be :
    <b>Evolution of SAP R/3:</b>
    SAP R/3 (up to release 4.6c) -> SAP R/3 Enterprise (releases 1.00 through 2.00 -> mySAP ERP (2004 onward)
    <b>Evolution of Basis:</b>
    SAP Basis (up to release 4.6d) -> SAP Web AS (up to release 6.40 which was included in SAP NetWeaver '04) -> SAP NetWeaver (2004 onward)
    SAP NetWeaver and mySAP ERP have <u>their own release cycles</u>. mySAP ERP always has an underlying technology release that it is built on (this is a SAP NetWeaver release)
    I hope this helps,
    Mike.
    <b></b>

Maybe you are looking for

  • Satellite L455 problems/hope you can help!

    First off, I have searched the forums extensively before posting, and have tried a lot of the previous recommendations.  I appreciated that folks here are so supportive and responsive to issues.  That said, I'm not all that tech savvy, so please bear

  • Error while loading data into PSA from data source

    Hi Experts , I am loading purchase order history data from standerd datasource 0SRM_TD_CF into PSA using infopackage.However,whenevr I run infopackage,the call monitor shows the status as yellow.I monitored the process for half an hour but it never e

  • JDeveloper 11g Tutorial, let's start ADF!

    Hi folks, http://docs.oracle.com/cd/E18941_01/tutorials/toc.htm Cheers, Patrick Chan

  • ARCck 2.6.16 2 request

    Hii, Can someone please upload here or something the PKGBUILD and install of this new PATCH for kernel 2.6.16? I know how to do it myself, but it seem I get some problems in a while, and I will like to see a good example of a build one so I can use i

  • Anyconnect using IKEV2 allowing access to Vendor

    Hi Everyone, We have configured Anyconnect using IKEv2 for our internal users and it is working fine. Recently i got  Request from our management to allow our  vendor to access our network but they dont need full access to our internal network. This