Inital Context Bug in WebLogic5.1 ??


EJB programming & troubleshooting: Inital Context Bug in WebLogic5.1 ??

  1. Inital Context Bug in WebLogic5.1 ?? (5 messages)

    I have a SessionBean Method :

    public void contextTest() throws RemoteException {
    try {
      System.out.println("Principal 1: " + ctx.getCallerPrincipal());

      Properties h = new Properties();
      h.put(Context.PROVIDER_URL, "t3://localhost:7001");
      h.put(Context.SECURITY_PRINCIPAL, "toto");
      h.put(Context.SECURITY_CREDENTIALS, "test");
      Context new_ctx = new InitialContext(h);

      System.out.println("Principal 2: " + ctx.getCallerPrincipal());
      } catch (Exception e) {e.printStackTrace(); }

    When principal "titi" invokes this Method it produces the following output:

    Principal 1: titi
    Principal 2: toto

    As You can see the Method just replaced the Caller Context's principal stored in the ctx field without even touching it. Since my Servlets run on the same JVM and use PassByReference calling this Method twice results in :

    Principal 1: titi
    Principal 2: toto
    Principal 1: toto
    Principal 2: toto

    I think this is a Bug because it makes it quiet difficult to open two Context's at the same time.

    I would like to read some opinions.

    Threaded Messages (5)

  2. ejb security[ Go to top ]

    how and where to set the principal & roles for enterprise beans?

  3. ejb security[ Go to top ]

    This line sets the Security Principal.

    h.put(Context.SECURITY_PRINCIPAL, "toto");

    Roles can be mapped to certain principals or groups by using the deployment descriptor.
  4. This is correct behaviour - security info is associated with the current thread.
  5. I thought that the callers credentials override whatever you put into the Properties object passed tot he InitialContext. This is how you then define a page which can run as an unauthenticated user or as an authenticated user.

    Dave Wolf
    Internet Applications Division
  6. If I understand this right, the principal is associated with the calling thread: How does this interfere with the Idea of caching Home&Remoteinterfaces?! The Idea of caching a homeinterface is, that you can skip new IniitialContext&the Lookup for the Home - however, when you store the Home, the second call on <Home>.create(...) has lost the principal (if you do ctx.getCallerPrincipal().getName() you see "guest") - which is not the Principal from the InitialContext that was used to lookup the Home. Is this the intended behaviour?!