Replicated jndi tree

We are running multiple WL servers (vers. 2.5.1 non-clustered)
registered to
different ports and would like to have the component names of one server
known to the other. Is there a way of doing this w/o having to
hard-code
that component A lives on machineX : port 999 or buying the clustering
option?

Yes, you can use federation do achieve this but remember federation is
just putting a refence that points to the original JNDI provider and
doesn't really give you replication of the entire JNDI namespace.
Guillaume Bedard wrote:
Hi!
Can you elaborate as to what makes it impossible?
What if we "federate" the two clusters, which have their
own autonomous naming systems, by binding a reference to
these naming systems in another naming service?
Thanks,
Guillaume
"Raja Mukherjee" <[email protected]> wrote:
No
..raja
"Guillaume Bedard" <[email protected]> wrote in message
news:3cab4a00$[email protected]..
More specifically, I would like be able to join two clusters
(each having their own cluster-wide replicated naming tree)
by replicating their bindings into a global naming tree,
possibly hosted by a dedicated "jndi" server.
Guillaume
"Raja Mukherjee" <[email protected]> wrote:
My immediate response would be 'No', but I am confused as to what
are
you
trying to achieve?
..raja
"Guillaume Bedard" <[email protected]> wrote in message
news:3ca9cd9c$[email protected]..
Hi!
Is it possible to have a JNDI tree replicated to an external
global naming service? For instance, to merge two clusters
of WLS 5.1 servers from two different network zones?
Thanking you in advance,
Guillaume Bedard

Similar Messages

  • Common JNDI Tree

    We want to run 2 instances of WLS on one machine and 2 on other machine.
    Is there any way to setup a common jndi tree. so components on all 4 instances can access the same jndi URL.
    any help will be greatly appreciated.
    Thanks

    Hi ,
    You would have to set them up on a cluster and the JNDI tree by default is replicable .
    But it seems like there is a bug in the JNDI Implementation and if any objects
    unbind or rebind , they dont get reflected on the replicated JNDI tree.
    Cheers,
    Naggi
    Baraut wrote:
    We want to run 2 instances of WLS on one machine and 2 on other machine.
    Is there any way to setup a common jndi tree. so components on all 4 instances can access the same jndi URL.
    any help will be greatly appreciated.
    Thanks

  • JNDI tree replicated to an external global naming service

    Hi!
    Is it possible to have a JNDI tree replicated to an external
    global naming service? For instance, to merge two clusters
    of WLS 5.1 servers from two different network zones?
    Thanking you in advance,
    Guillaume Bedard

    Yes, you can use federation do achieve this but remember federation is
    just putting a refence that points to the original JNDI provider and
    doesn't really give you replication of the entire JNDI namespace.
    Guillaume Bedard wrote:
    Hi!
    Can you elaborate as to what makes it impossible?
    What if we "federate" the two clusters, which have their
    own autonomous naming systems, by binding a reference to
    these naming systems in another naming service?
    Thanks,
    Guillaume
    "Raja Mukherjee" <[email protected]> wrote:
    No
    ..raja
    "Guillaume Bedard" <[email protected]> wrote in message
    news:3cab4a00$[email protected]..
    More specifically, I would like be able to join two clusters
    (each having their own cluster-wide replicated naming tree)
    by replicating their bindings into a global naming tree,
    possibly hosted by a dedicated "jndi" server.
    Guillaume
    "Raja Mukherjee" <[email protected]> wrote:
    My immediate response would be 'No', but I am confused as to what
    are
    you
    trying to achieve?
    ..raja
    "Guillaume Bedard" <[email protected]> wrote in message
    news:3ca9cd9c$[email protected]..
    Hi!
    Is it possible to have a JNDI tree replicated to an external
    global naming service? For instance, to merge two clusters
    of WLS 5.1 servers from two different network zones?
    Thanking you in advance,
    Guillaume Bedard

  • Jndi tree different in different servers in a cluster?

    I bind a Properties object in jndi tree and it comes up fine in one node
    i.e. I can see it in the jndi tree on one Server.
    But I cannot see it in another Server in the cluster. Any idea why this
    behaviour?
    the code looks like this:
    Hashtable h = new Hashtable();
    h.put(Context.INITIAL_CONTEXT_FACTORY, JNDITags.JNDI_FACTORY);
    h.put(WLContext.CREATE_INTERMEDIATE_CONTEXTS, new
    Boolean(true));
    if (user != null) {
    h.put(Context.SECURITY_PRINCIPAL, user);
    if (pwd == null)
    pwd = "";
    h.put(Context.SECURITY_CREDENTIALS, pwd);
    InitialContext ic = new InitialContext(h);
    Context ctx = ic.createSubcontext( "yy");
    ctx.bind( "lp", props );
    ctx.close();
    ic.close();
    Komal

    If you are trying to do the lookup "at startup time for server 2", the JNDI
    replication may not be complete yet. We had a similar problem trying to deploy
    MDBs against JMS destinations on remote servers...
    komal mangtani wrote:
    Can't a bind an object on 1 server and do a lookup on other server ?
    Like in my case, when 1st server starts, it binds the object to the jndi
    tree in its startup class.
    Then the second server comes up and does a lookup on the same object in its
    own startup class.
    Isn't the jndi tree, suppose to get replicated to another server?
    Komal.
    komal mangtani wrote:
    I bind a Properties object in jndi tree and it comes up fine in one node
    i.e. I can see it in the jndi tree on one Server.
    But I cannot see it in another Server in the cluster. Any idea why this
    behaviour?
    the code looks like this:
    Hashtable h = new Hashtable();
    h.put(Context.INITIAL_CONTEXT_FACTORY, JNDITags.JNDI_FACTORY);
    h.put(WLContext.CREATE_INTERMEDIATE_CONTEXTS, new
    Boolean(true));
    if (user != null) {
    h.put(Context.SECURITY_PRINCIPAL, user);
    if (pwd == null)
    pwd = "";
    h.put(Context.SECURITY_CREDENTIALS, pwd);
    InitialContext ic = new InitialContext(h);
    Context ctx = ic.createSubcontext( "yy");
    ctx.bind( "lp", props );
    ctx.close();
    ic.close();
    Komal

  • Loading the JNDI Tree in a Cluster

    Is there any special processing that occurs with a Startup class when it
              has been
              started via the cluster level properties file?
              We've got a class that loads the JNDI tree for various configuration for
              our application.
              It's written that so that it will rebind() entries in the tree, so two
              copies could work together
              in the cluster, but I'd like to prevent the double work. (One copy
              bind()s an element, then the other rebind()s the same value.
              Are Startups "cluster" aware, and is there any magic to simplify this
              for me (or do I do the
              work of creating a semaphore-like setup in my class to detect two copies
              running.)
              Thanks in Advance,
              Brian Homrich
              Chicago, Illinois
              

    In the startup class on Environment object if you don't set
              replicatebindings to false, in a cluster all locally bound objects will be
              replicated. The default it true. So, jndi will try replicate every
              bind/rebind etc.
              Rebind will remove old copy and bind the new copy. But I have to understand
              more what you are trying to do, before I can be of any help.
              - Prasad
              Brian Homrich wrote:
              > Is there any special processing that occurs with a Startup class when it
              > has been
              > started via the cluster level properties file?
              >
              > We've got a class that loads the JNDI tree for various configuration for
              > our application.
              > It's written that so that it will rebind() entries in the tree, so two
              > copies could work together
              > in the cluster, but I'd like to prevent the double work. (One copy
              > bind()s an element, then the other rebind()s the same value.
              >
              > Are Startups "cluster" aware, and is there any magic to simplify this
              > for me (or do I do the
              > work of creating a semaphore-like setup in my class to detect two copies
              > running.)
              >
              > Thanks in Advance,
              >
              > Brian Homrich
              > Chicago, Illinois
              

  • Distinction of EJBs in shared clusterwide JNDI-Tree

    Hi,
              for logging issues i want to browse the shared clusterwide JNDI-Tree. As far
              as i know, the clusterwide JNDI-Tree contains all services of any deployed
              EJB in the cluster.
              My problem is that i want do distinguish between the EJBs on the unique
              Application Servers in the cluster. I need to get information about the
              ApplicationServer/Thread the EJB is running in.
              -Is it possible to get this information out of the clusterwide JNDI-Tree of
              WLS6.0sp1?
              -Is there a way to work with the replica-aware stubs of clusterable EJBs to
              distinguish between "originals" and their replicas on other AppServers?
              -Which type of EJBs can be accessed? All types?
              -How can this task be achieved?
              Thanks in advance for your help
              René
              

    "René Eßer" wrote:
              > Hi,
              >
              > for logging issues i want to browse the shared clusterwide JNDI-Tree. As far
              > as i know, the clusterwide JNDI-Tree contains all services of any deployed
              > EJB in the cluster.
              Yes, the cluster wide JNDI tree contains everything that is deployed in the
              cluster.
              > My problem is that i want do distinguish between the EJBs on the unique
              > Application Servers in the cluster. I need to get information about the
              > ApplicationServer/Thread the EJB is running in.
              I don't understand what you mean here. "EJB's on the unique App Servers in the
              cluster". To find out which thread is running you can do a
              Thread.currentThread().getName()
              >
              > -Is it possible to get this information out of the clusterwide JNDI-Tree of
              > WLS6.0sp1?
              No not really.
              >
              > -Is there a way to work with the replica-aware stubs of clusterable EJBs to
              > distinguish between "originals" and their replicas on other AppServers?
              This is all hidden and transperent to the users.
              -- Prasad
              >
              > -Which type of EJBs can be accessed? All types?
              >
              > -How can this task be achieved?
              >
              > Thanks in advance for your help
              >
              > René
              

  • Adding entries to the JNDI tree

    Is it possible to add entries to the JNDI path of the OC4J server? I know you can add it via web.xml, but I´m looking into doing that manually through the admin console?
    Thanks,
    Mario

    True. At the end I configured the value as a "server property". The cool thing about configuring the jndi tree is that it is replicated in a cluster.
    Obviously the values that I inserted affected all the applications, like the url of our SOA server.

  • Binding huge object to the jndi tree.

    Hi we are loading all the master tables in to objects at the app server startup (SUN ONE 7) and then binding the whole object to the jndi tree. All the tables data in text files comes to about 5 MB and the serilized object with data to about 8 MB. But when the app server tries to bind the object the app server process consumes over 500MB of ram and gives OutOfmemoryError as the total ram is 512MB. why is it consuming so much memory. It does bind an object of about 5 MB but when trying to lookup subsequent to the first lookup it fails. Is this a bug or what??? the same thing works perfectly with Weblogic and Websphere and also Weblogic is very efficient in memory consumption and response time is amazing. For a 5 MB object the lookup takes about 5Secs in Weblogic and about 15Mins in Sun One. We might have to drop the Sun One App Srv and go for Weblogic though we dont want. This same thing is working with about 4MB object in Sun One but takes about 45 Mins to 1 Hour to finish the serialization etc for jndi .Kindly provide some guidance.Thanks in advance.

    True. At the end I configured the value as a "server property". The cool thing about configuring the jndi tree is that it is replicated in a cluster.
    Obviously the values that I inserted affected all the applications, like the url of our SOA server.

  • Some JMS objects do not show up in JNDI tree

    Hello friends. I have a situation where some of my JMS Queues do not show up in
    the JNDI tree. Other Queues / Topics show up fine. I cannot find any difference
    in the interface that tells me what my cause this to happen. Any insight would
    be appreciated.
    brian

    are you using a cluster? if so check the multicast to see if its working
    right.
    Where are you looking up the JNDI tree? in the console or are you checking
    the JNDI tree via weblogic.Admin LIST command? the LIST command may be a
    better way to see it for sure.
    sree
    "Brian" <[email protected]> wrote in message
    news:40b74519$1@mktnews1...
    >
    Hello friends. I have a situation where some of my JMS Queues do not showup in
    the JNDI tree. Other Queues / Topics show up fine. I cannot find anydifference
    in the interface that tells me what my cause this to happen. Any insightwould
    be appreciated.
    brian

  • How to delete conext entries in JNDI tree after undeployment?

    Hi,
    When I deploy an EAR or JAR file with EJBs, they bind in the JNDI server.
    When I undeploy the application the beans are no longer bound to the JNDI
    tree, but the contexts they created remain.
    For example, I deploy a bean that binds its home object to the following
    entry in the JNDI:
    myapp/mymodule/MyBean
    When I undeploy MyBean, the context myapp/mymodule remain.
    Is there an utility to remove these entries or do I have to develop my own
    utility? I did not find anything in the administration console to do this.
    This has been a source of some trouble, because sometimes I get error
    messages when I want to redeploy the beans.
    Thanks in advance,
    Vegeta

    Please don't cross post. see my reply in the ejb newsgroup.
    Thanks,
    Michael
    Vegeta wrote:
    Hi,
    When I deploy an EAR or JAR file with EJBs, they bind in the JNDI server.
    When I undeploy the application the beans are no longer bound to the JNDI
    tree, but the contexts they created remain.
    For example, I deploy a bean that binds its home object to the following
    entry in the JNDI:
    myapp/mymodule/MyBean
    When I undeploy MyBean, the context myapp/mymodule remain.
    Is there an utility to remove these entries or do I have to develop my own
    utility? I did not find anything in the administration console to do this.
    This has been a source of some trouble, because sometimes I get error
    messages when I want to redeploy the beans.
    Thanks in advance,
    Vegeta--
    Michael Young
    Developer Relations Engineer
    BEA Support

  • Could not lookup PortalManagerHome in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager

    Hi
    I am just a starter on WLPortal.
    I have created a barebone Application from scratch. I have synchronized it properly
    from EBCC to WLP. But When I am trying to access the home page of my application,
    I am getting from stack trace -
    <Nov 6, 2002 5:37:59 PM IST> <Error> <PortalAppflow> <Could not lookup PortalManagerHome
    in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager.
    javax.naming.NameNotFoundException: Unable to resolve comp/env/ejb/PortalManager
    Resolved: 'comp/env' Unresolved:'ejb' ; remaining name 'PortalManager'
    at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:802)
    at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:209)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:173)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:181)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:181)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:323)
    at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(ReadOnlyContextWrapper.java:36)
    at weblogic.jndi.internal.AbstractURLContext.lookup(AbstractURLContext.java:124)
    at javax.naming.InitialContext.lookup(InitialContext.java:350)
    at com.bea.p13n.util.JndiHelper.lookupNarrow(JndiHelper.java:96)
    at com.bea.portal.appflow.PortalAppflowHelper.<clinit>(PortalAppflowHelper.java:64)
    at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.init(PortalWebflowServlet.java:78)
    at javax.servlet.GenericServlet.init(GenericServlet.java:258)
    at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java:700)
    at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.java:643)
    at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:588)
    at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:368)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
    at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:215)
    at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
    at jsp_servlet.__index._jspService(__index.java:92)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:304)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2459)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    >
    <Nov 6, 2002 5:37:59 PM IST> <Error> <HTTP> <[WebAppServletContext(19695286,FirstWebApp,/FirstWebApp)]
    Servlet failed with Exception
    java.lang.NullPointerException:
    at com.bea.portal.appflow.PortalAppflowHelper.createPortalManager(PortalAppflowHelper.java:82)
    at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.setupPortalRequest(PortalWebflowServlet.java:187)
    at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.doGet(PortalWebflowServlet.java:99)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
    at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:215)
    at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
    at jsp_servlet.__index._jspService(__index.java:92)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:304)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2459)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    When I decompiled the class PortalAppflowHelper, I found a static block in it,
    which was as under-
    static
    debug = Debug.getInstance(com.bea.portal.appflow.PortalAppflowHelper.class);
    try
    if(debug.ON)
    debug.out("Looking up PortalManagerHome using EJB reference java:comp/env/ejb/PortalManager");
    portalManagerHome = (PortalManagerHome)JndiHelper.lookupNarrow("java:comp/env/ejb/PortalManager",
    com.bea.portal.manager.ejb.PortalManagerHome.class);
    if(debug.ON)
    debug.out("Successfully retrieved PortalManagerHome " + portalManagerHome);
    catch(Exception e)
    PortalAppflowLogger.errorFindingPortalManagerHome("java:comp/env/ejb/PortalManager",
    e);
    I have checked the PortalManager's JNDI name on WLConsole. Its ${APPNAME}.BEA_portal.PortalManager.
    Should I change it?
    When I tried to change it, I started getting other weird errors.
    Thanks
    Neeraj Hans

    Neeraj -
    The Portal framework code (including PortalAppflowHelper) uses ejb
    references to find the PortalManager (and other EJBs) from servlets and
    taglibs; that is what is signified by the java:comp/env/... name.
    Since you built your webapp from scratch (instead of using the portal
    wizard), you will need to make sure the you have the appropriate
    <ejb-ref> entries in your web.xml, and the corresponding
    <ejb-reference-description> entries in your weblogic.xml. By default,
    you will need at least mappings for:
    - ejb/PortalManager
    - ejb/UserManager
    - ejb/GroupManager
    - ejb/PipelineExecutor
    - ejb/EventService
    See either the resulting webapp from using the portal wizard or
    BEA_HOME/weblogic700/samples/portal/sampleportalDomain/beaApps/sampleportal/sampleportal/WEB-INF
    for example syntax.
    Greg
    Neeraj Hans wrote:
    Hi
    I am just a starter on WLPortal.
    I have created a barebone Application from scratch. I have
    synchronized it properly
    from EBCC to WLP. But When I am trying to access the home page of my
    application,
    I am getting from stack trace -
    <Nov 6, 2002 5:37:59 PM IST> <Error> <PortalAppflow> <Could not lookup
    PortalManagerHome
    in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager.
    javax.naming.NameNotFoundException: Unable to resolve
    comp/env/ejb/PortalManager
    Resolved: 'comp/env' Unresolved:'ejb' ; remaining name 'PortalManager'
    at <stack trace lines snipped>
    When I decompiled the class PortalAppflowHelper, I found a static
    block in it,
    which was as under-
    static
    debug =
    Debug.getInstance(com.bea.portal.appflow.PortalAppflowHelper.class);
    try
    if(debug.ON)
    debug.out("Looking up PortalManagerHome using EJB
    reference java:comp/env/ejb/PortalManager");
    portalManagerHome =
    (PortalManagerHome)JndiHelper.lookupNarrow("java:comp/env/ejb/PortalManager",
    com.bea.portal.manager.ejb.PortalManagerHome.class);
    if(debug.ON)
    debug.out("Successfully retrieved PortalManagerHome "
    + portalManagerHome);
    catch(Exception e)
    PortalAppflowLogger.errorFindingPortalManagerHome("java:comp/env/ejb/PortalManager",
    e);
    I have checked the PortalManager's JNDI name on WLConsole. Its
    ${APPNAME}.BEA_portal.PortalManager.
    Should I change it?
    When I tried to change it, I started getting other weird errors.
    Thanks
    Neeraj Hans

  • Unable to Find EJB in JNDI Tree

    Good Morning to All!
    I have been scratching my head all day yesterday trying to understand this error:
    [2005-06-15 09:44:38,203][Servlet.Engine.Transports : 1][FATAL][{ServiceLocator}{getHome}{CONFIG0001}{Failed to find EJB Reference from JNDI tree}{External Message:Name comp/env/ejb not found in context "java:".}]
    {ServiceLocator}{getHome}{CONFIG0001}{Failed to find EJB Reference from JNDI tree}{External Message:Name comp/env/ejb not found in context "java:".}
    What is going on is the user is logging into the web application. The process is the user comes in from the web container and enters the EJB container through the AdminEJB. The AdminEJB has a reference to a singleton POJO entitled ServiceLocator. This POJO follows the locator pattern. One of the things the Locator is attempting to accomplish is retrieving the CacheEJBLocalHome. This Cache ejb has a JNDI name of
    ejb/CacheEJBHome
    I have promoted the Cache ejb to the Local and the Remote interfaces using WSAD.
    I realize the lookup method can not find the EJB, but I do not know what is causing this behavior. I originally thought the AdminEJB needed a bean reference to the CacheEJB, but this did not work.
    Any insight or debugging techniques into this issue would be greatly appreciated.
    Thank you for reading my post.
    Russ

    Hi Ten,
    FYI, just by placing the ejb jar inside EAR project it will not be picked up for deployment. The EJB module has to be defined on EAR Module Assembly, and the steps are:
    > EAR Project | Properties, Deployment Assembly - Add EJB module
    NOTE: To verify the dependency you could try to export the EAR project to an .ear file. If the exported .ear file bundles ejb jar then deployment should work fine.
    As far as the deployment mode, OEPE supports WebLogic Split-source (default) and Exploded archive. In the default split-source mode, the .beabuild.txt contains the mapping to the actual files whereas in exploded archive the files are copied over to deployment staging location.
    Steps to modify deployment mode:
    > In the server view, right click on server configuration | Properties, select WebLogic | Publishing
    Please make sure the ejb module is defined appropriately and let me know if this resolves the issue.
    Thanks,
    Ram

  • Publish, deploy, jndi tree

    Hello,
    I work with Weblogic server 9.2 and Ganymede 3.4.
    Here are some beginner questions:
    Why do I, in Ganymede's server tab, publish on the server node instead of on the EAR node?
    When I publish my EAR I cannot see anything added in the jndi tree of the app-server (via admin console, view jndi tree). What do I miss?
    This my weblogic-ejb-jar:
    <?xml version="1.0" encoding="UTF-8"?>
    <weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
    <!-- server-version: 9.2 -->
    <weblogic-enterprise-bean>
    <ejb-name>HelloWorld</ejb-name>
    <stateless-session-descriptor>
    </stateless-session-descriptor>
    <jndi-name>ejb.EjbHelloWorldHome</jndi-name>
    </weblogic-enterprise-bean>
    </weblogic-ejb-jar>
    Is there a perspective that displays the weblogic generated stub/skeleton files?
    Is there a difference between publishing an EAR and deploying an EAR, except that deploying refers to a production environment instead of dev environment?
    Thanks for any ideas.

    If you are using OEPE - Oracle Enterprise Pack for Eclipse (or Workshop), then WebLogic EJB's are built (the stubs, etc) with a tool called EJBGen, this link is for 10.3, but I'm pretty sure it's the same for 9.2
    http://download.oracle.com/docs/cd/E12839_01/wls/docs103/ejb/EJBGen_reference.html
    I think that is implemented as a an Eclipse build task, so it's only run when exporting to an archive like an EAR or EJB jar OR when publishing to the server. In either case, those generated classes would not be shown in Eclipse.
    Check your deployments tab of your WLS console to see if you application is deployed an active. If it is, then I would expect to see entries from your application in the JNDI tree.
    The OEPE forum is a better place to ask Eclipse questions:
    Enterprise Pack for Eclipse

  • Error While Viewing JNDI Tree

              Hi
              I'm facing the following problem while viewing the JNDI tree. I had configured
              two servers ejbServer,ejbServer1 both clustered, i can able to start both the
              servers, but in the JNDI tree when i click ejbServer or Replication Manager
              i'm getting the following error please help me out.
              An unexpected error was encountered in processing your request.
              Exception
              javax.naming.NameNotFoundException: Unable to resolve weblogic.transaction.coordinators.ejbServer.
              Resolved: 'weblogic.transaction.coordinators' Unresolved:'ejbServer' ; remaining
              name ''
                   <>
              Current Date
              Mon Aug 27 09:15:19 GMT+08:00 2001
              Console Release Build
              6.0 Service Pack 2
              Console Build
              6.0 Service Pack 2 05/24/2001 11:55:28 #117037
              Server Release Build
              6.0 Service Pack 2
              Server Build
              6.0 Service Pack 2 05/24/2001 11:55:28 #117037
              All Server Product Versions
              WebLogic Server Build:     6.0 Service Pack 2 05/24/2001 11:55:28 #117037
              WebLogic XML Module:     6.0 Service Pack 2 05/24/2001 12:34:27 #117037
              Request Info
              Protocol: HTTP/1.1
              ServerName: 127.0.0.1
              ServerPort: 7001
              Secure: false
              ContextPath: /console
              ServletPath: /common/error.jsp
              QueryString: null
              PathInfo: null
              PathTranslated: null
              RequestURI: /console/common/error.jsp
              AuthType: Basic
              ContentType: null
              CharacterEncoding: null
              Locale: hi
              Method: GET
              Session: weblogic.servlet.internal.session.MemorySessionData@37b6ef
              RequestedSessionId: O4meRts3MSQ1pr2YCfOsUGA3MckiUv6wmiQVYrdcQBy3oYpYTz2Q/console
              RequestedSessionIdFromCookie: true
              RequestedSessionIdFromURL: false
              UserPrincipal: system
              RemoteUser: system
              RemoteAddr: 127.0.0.1
              RemoteHost: localhost
              Parameters
              binding = ejbServer
              context = weblogic.transaction.coordinators
              Attributes
              console.original./console/common/error.jsp.ContextPath = /console
              console.original./console/common/error.jsp.Method = GET
              console.original./console/common/error.jsp.RemoteUser = system
              console.original./console/common/error.jsp.RequestURI = /console/common/error.jsp
              console.original./console/common/error.jsp.ServletPath = /common/error.jsp
              console.original./console/panels/mbean/JNDIBinding.jsp.ContextPath = /console
              console.original./console/panels/mbean/JNDIBinding.jsp.Method = GET
              console.original./console/panels/mbean/JNDIBinding.jsp.QueryString = context=weblogic.transaction.coordinators&binding=ejbServer
              console.original./console/panels/mbean/JNDIBinding.jsp.RemoteUser = system
              console.original./console/panels/mbean/JNDIBinding.jsp.RequestURI = /console/panels/mbean/JNDIBinding.jsp
              console.original./console/panels/mbean/JNDIBinding.jsp.ServletPath = /panels/mbean/JNDIBinding.jsp
              console.preferences.ContextKey = /panels/mbean/JNDIBinding.jsp
              javax.servlet.include.context_path = /console
              javax.servlet.include.request_uri = /console/common/requestinfo.jsp
              javax.servlet.include.servlet_path = /common/requestinfo.jsp
              javax.servlet.jsp.jspException = javax.naming.NameNotFoundException:
              Unable to resolve weblogic.transaction.coordinators.ejbServer. Resolved: 'weblogic.transaction.coordinators'
              Unresolved:'ejbServer' ; remaining name ''
              weblogic.httpd.user = system
              weblogic.management.console.tags.ContentTag = java.lang.Object@397a54
              weblogic.management.console.tags.HeaderTag = java.lang.Object@e4a33
              Headers
              Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel,
              application/msword, application/vnd.ms-powerpoint, */*
              Accept-Encoding = gzip, deflate
              Accept-Language = hi
              Authorization = Basic c3lzdGVtOm1hbmFnZXIx
              Connection = Keep-Alive
              Cookie = JSESSIONID=O4meRts3MSQ1pr2YCfOsUGA3MckiUv6wmiQVYrdcQBy3oYpYTz2Q!2557472653882942880!-1062729946!7001!7002
              Host = 127.0.0.1:7001
              User-Agent = Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
              BrowserInfo
              User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
              IE: true
              Netscape: false
              Supported: true
              JavscriptHrefs: false
              TableCellClick: true
              DocumentReloadedOnResize: false
              DropdownStretchable: true
              CellSpacingBlank: false
              EmptyCellBlank: false
              ImgOnclickSupported: true
              TableBorderFancy: true
              PartialToWideTables: false
              Server System Properties
              awt.toolkit = sun.awt.windows.WToolkit
              bea.home = d:\Weblogic
              cloudscape.system.home = ./samples/eval/cloudscape/data
              file.encoding = Cp1252
              file.encoding.pkg = sun.io
              file.separator = \
              java.awt.fonts =
              java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment
              java.awt.printerjob = sun.awt.windows.WPrinterJob
              java.class.path = .;d:\Weblogic\jdk130\lib\tools.jar;d:\Weblogic\wlserver\lib\weblogic_sp.jar;d:\Weblogic\wlserver\lib\weblogic.jar;d:\Weblogic\wlserver\lib\xmlx.jar;d:\Weblogic\wlserver\lib\ejb20.jar;d:\Weblogic\wlserver\samples\eval\cloudscape\lib\cloudscape.jar;;;;d:\Weblogic;d:\Weblogic\wlserver\bin\oci816_8;d:\Oracle_Home\iSuites\jdbc\lib\classes12.zip;d:\Weblogic\wlserver\lib;d:\Oracle_Home\iSuites\lib\xmlparserv2.jar;d:\JDeveloper\lib\xsu12.jar;;
              java.class.version = 47.0
              java.ext.dirs = d:\Weblogic\jdk130\jre\lib\ext
              java.home = d:\Weblogic\jdk130\jre
              java.io.tmpdir = C:\TEMP\
              java.library.path = d:\Weblogic\jdk130\bin;.;C:\WINNT\System32;C:\WINNT;.\bin;D:\Oracle_Home\iSuites\BIN;D:\Oracle_Home\iSuites\Apache\Perl\5.00503\bin\mswin32-x86;C:\Program
              Files\Oracle\jre\1.1.7\bin;C:\WINNT\system32;C:\WINNT;C:\VisualCafeSE\Java2\Bin;C:\Program
              Files\Common Files\WebGain Shared;C:\VisualCafeSE\Bin;
              java.naming.factory.initial = weblogic.jndi.WLInitialContextFactory
              java.naming.factory.url.pkgs = weblogic.jndi.factories
              java.protocol.handler.pkgs = weblogic.utils|weblogic.utils|weblogic.net|weblogic.management|weblogic.net|weblogic.net|weblogic.utils
              java.runtime.name = Java(TM) 2 Runtime Environment, Standard
              Edition
              java.runtime.version = 1.3.0-C
              java.security.policy = =d:\Weblogic\wlserver/lib/weblogic.policy
              java.specification.name = Java Platform API Specification
              java.specification.vendor = Sun Microsystems Inc.
              java.specification.version = 1.3
              java.vendor = Sun Microsystems Inc.
              java.vendor.url = http://java.sun.com/
              java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
              java.version = 1.3.0
              java.vm.info = mixed mode
              java.vm.name = Java HotSpot(TM) Client VM
              java.vm.specification.name = Java Virtual Machine Specification
              java.vm.specification.vendor = Sun Microsystems Inc.
              java.vm.specification.version = 1.0
              java.vm.vendor = Sun Microsystems Inc.
              java.vm.version = 1.3.0-C
              javax.rmi.CORBA.PortableRemoteObjectClass = weblogic.iiop.PortableRemoteObjectDelegateImpl
              javax.rmi.CORBA.UtilClass = weblogic.iiop.UtilDelegateImpl
              javax.xml.parsers.DocumentBuilderFactory = weblogic.xml.jaxp.RegistryDocumentBuilderFactory
              javax.xml.parsers.SAXParserFactory = weblogic.xml.jaxp.RegistrySAXParserFactory
              jmx.implementation.name = JMX RI
              jmx.implementation.vendor = Sun Microsystems
              jmx.implementation.version = 1.0
              jmx.specification.name = Java Management Extensions
              jmx.specification.vendor = Sun Microsystems
              jmx.specification.version = 1.0 Final Release
              line.separator =
              os.arch = x86
              os.name = Windows NT
              os.version = 4.0
              path.separator = ;
              sun.boot.class.path = d:\Weblogic\jdk130\jre\lib\rt.jar;d:\Weblogic\jdk130\jre\lib\i18n.jar;d:\Weblogic\jdk130\jre\lib\sunrsasign.jar;d:\Weblogic\jdk130\jre\classes
              sun.boot.library.path = d:\Weblogic\jdk130\jre\bin
              sun.cpu.endian = little
              sun.cpu.isalist = pentium_pro+mmx pentium_pro pentium+mmx
              pentium i486 i386
              sun.io.unicode.encoding = UnicodeLittle
              user.dir = D:\Weblogic\wlserver
              user.home = C:\WINNT\Profiles\venkata
              user.language = en
              user.name = venkata
              user.region = US
              user.timezone = Asia/Singapore
              weblogic.Domain = DNSdomain
              weblogic.Name = DNSserver
              weblogic.management.discover = true
              weblogic.security.jaas.Configuration = weblogic.security.internal.ServerConfig
              weblogic.security.jaas.Policy = d:/Weblogic/wlserver/lib/Server.policy
              

    [att1.html]
              

  • Stack dump while trying to view the JNDI Tree on a managed server.

    Hi,
    We are running WLI 9.2.3.
    I have a problem when trying to view the managed servers JNDI Tree via the Admin console. The admin servers JNDI tree appears to be fine, but trying to view the 1st managed servers JNDI Tree via the admin console keeps producing a stack dump.
    Does anyone know why this would be? Is it a security issue, judging by the classes below:
    ####<Jul 14, 2010 1:31:29 PM BST> <Warning> <RMI> <sofatd2b> <tgri02_rsk_ms11> <[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel
    <> <> <1279110689890> <BEA-080004> <An error was thrown by rmi server: weblogic.jndi.internal.RootNamingNode.listBindings(Ljava.lang.String;Ljava.util.Hashtable;)java.lang.StackOverflowError.
    java.lang.StackOverflowError
    at $Proxy5.isAccessAllowed(Unknown Source)
    at com.bea.common.security.internal.service.AccessDecisionServiceImpl.isAccessAllowed(AccessDecisionServiceImpl.java:105)
    at sun.reflect.GeneratedMethodAccessor202.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at com.bea.common.security.internal.utils.Delegator$ProxyInvocationHandler.invoke(Delegator.java:61)
    at $Proxy11.isAccessAllowed(Unknown Source)
    at com.bea.common.security.internal.service.AuthorizationServiceImpl.isAccessAllowed(AuthorizationServiceImpl.java:81)
    at sun.reflect.GeneratedMethodAccessor201.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at com.bea.common.security.internal.utils.Delegator$ProxyInvocationHandler.invoke(Delegator.java:61)
    at $Proxy13.isAccessAllowed(Unknown Source)
    at weblogic.security.service.AuthorizationManager.isAccessAllowed(AuthorizationManager.java:461)
    at weblogic.security.service.AuthorizationManager.isAccessAllowed(AuthorizationManager.java:524)
    at weblogic.jndi.internal.ServerNamingNode.checkPermission(ServerNamingNode.java:414)
    at weblogic.jndi.internal.ServerNamingNode.checkLookup(ServerNamingNode.java:394)
    at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:169)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:206)
    at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:269)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at weblogic.deployment.jms.ForeignOpaqueReference.getReferent(ForeignOpaqueReference.java:196)
    at weblogic.jndi.internal.WLNamingManager.getObjectInstance(WLNamingManager.java:95)
    at weblogic.jndi.internal.ServerNamingNode.resolveObject(ServerNamingNode.java:348)
    at weblogic.jndi.internal.BasicNamingNode.resolveObject(BasicNamingNode.java:856)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:209)
    at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:269)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
    at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:269)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at weblogic.deployment.jms.ForeignOpaqueReference.getReferent(ForeignOpaqueReference.java:196)
    at weblogic.jndi.internal.WLNamingManager.getObjectInstance(WLNamingManager.java:95)
    at weblogic.jndi.internal.ServerNamingNode.resolveObject(ServerNamingNode.java:348)
    at weblogic.jndi.internal.BasicNamingNode.resolveObject(BasicNamingNode.java:856)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:209)
    at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:269)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at weblogic.deployment.jms.ForeignOpaqueReference.getReferent(ForeignOpaqueReference.java:196)
    at weblogic.jndi.internal.WLNamingManager.getObjectInstance(WLNamingManager.java:95)
    at weblogic.jndi.internal.ServerNamingNode.resolveObject(ServerNamingNode.java:348)
    at weblogic.jndi.internal.BasicNamingNode.resolveObject(BasicNamingNode.java:856)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:209)
    at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:269)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at weblogic.deployment.jms.ForeignOpaqueReference.getReferent(ForeignOpaqueReference.java:196)
    at weblogic.jndi.internal.WLNamingManager.getObjectInstance(WLNamingManager.java:95)
    at weblogic.jndi.internal.ServerNamingNode.resolveObject(ServerNamingNode.java:348)
    at weblogic.jndi.internal.BasicNamingNode.resolveObject(BasicNamingNode.java:856)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:209)
    at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:269)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at weblogic.deployment.jms.ForeignOpaqueReference.getReferent(ForeignOpaqueReference.java:196)
    at weblogic.jndi.internal.WLNamingManager.getObjectInstance(WLNamingManager.java:95)
    at weblogic.jndi.internal.ServerNamingNode.resolveObject(ServerNamingNode.java:348)
    at weblogic.jndi.internal.BasicNamingNode.resolveObject(BasicNamingNode.java:856)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:209)
    at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:269)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)

    Hi,
    if it works in Chrome then this Problem is related to IE.
    Maybe the URL is to long? IE can "only" handle 2048 Characters.
    Regards
    -Seb.

Maybe you are looking for