On Jun 18, 2008, at 4:31 AM, Stig Even Larsen wrote:
<snip>
Hi again,

I think I've found an related error.
I use javaBeans for wrapping Session EJB via jndi (one-to-one, method to method) to avoid to much java code in jsps.

request.isUserInRole() always return false no mather how many times it is called. Is seems like the jndi lookup prevents the isUserinRole to work normally.

Should I file a new bug-report or is this the same problem describe with EJB injection?

An example.

I have an stateless session bean (EJB):
@Stateless
public class TimeUtilsBean implements TimeUtilsLocal {

   public String getString() {
       return "Hello from Stateless EJB!";
   }
}

A javaBean EJB wrapper:
public class EJBWrapper {

   private TimeUtilsLocal lookupTimeUtilsBean() {
       try {
           Context c = new InitialContext();
return (TimeUtilsLocal) c.lookup("java:comp/env/ TimeUtilsBean");
       } catch (NamingException ne) {
        System.out.println("NameingException: "+ne.getMessage());
       }
   }


   public String getDate(){
       return(this.lookupTimeUtilsBean().getString());
   }
}


A form protected (j_security_check) jsp

<[EMAIL PROTECTED] contentType="text/html" pageEncoding="UTF-8" import="no.nimra.ejb.wrapper.EJBWrapper "%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd";>
<jsp:useBean id="nisAdmin" class="no.nimra.ejb.wrapper.EJBWrapper" scope="session" />

<html>
   <head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
       <title>JSP Test</title>
   </head>
   <body>

       <h2>Role test</h2>

       Time: <%= nisAdmin.getDate() %>

       <%if(request.isUserInRole("partners")){%>
           user is partner :)
       <%}else{%>
           user is NOT partner :(
       <%}%>
   </body>
</html>



My jsp deciphering skills are not the best but it looks to me as if the role check is done after the ejb lookup. This is the subject to the same problem as in GERONIMO-4119 and ought to work properly in the latest code in svn (in all branches): there's a test case in trunk checking that this scenario works. Which code are you seeing the problem with?

thanks
david jencks

Reply via email to