What is happening is the TomcatDeployer ends up in DelegatingPolicy.setInstance(), which caches the policy in the singleton.
A DelegatingPolicy instance is created for the JaccPolicyProvidet service via its constructor, a proxy to which is created by the JaccSecurityService as the arg for Policy.setPolicy(). This DelegatingPolicy instance is not set as the DelegatingPolicy singleton. The EJB 3 installation ends up in JaccPolicyProviderFactory. The Policy.getPolicyCall() returns the installed proxy to the DelegatingPolicy installed by the JaccPolicyProvider service. This has the wrong type and so we call DelegatingPolicy.getInstance() and get the one cached in DelegatingPolicy. One way to fix this would be to have an MBean wrapper for DelegatingPolicy that gets hold of the underlying DelegatingPolicy via DelegatingPolicy.getInstance(). > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Kabir Khan > Sent: 24 March 2006 18:31 > To: 'Scott M Stark'; 'Bill Burke' > Cc: 'QA'; jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] RE: JACC (ejb 3) - WAS RE: > jboss-4.0-testsuite Build Completed With Testsuite Errors > > Should ejb 3 be calling Policy.setPolicy()? The only place I > can find this being called is in > org,jboss.security.jacc.SecurityService.start() and stop(). > > I don't know if this is of any help, but what seems to happen > on startup is: > > 1) TomcatDeployer deploys the http invoker, and calls the > JBossPolicyConfigurationFactory. It's call to > Policy.getPolicy() returns a PolicyFile and so it calls > DelegatingPolicy.getInstance() which creates a new DelegatingPolicy. > > 2) The JaccPolicyProvider mbean starts up and creates another > DelegatingPolicy, which is set as the policy using > Policy.setPolicy() when the SecurityService starts. > > Later, when deploying the jacc test the Policy.getPolicy() > call returns a proxy for the policy created by the > JaccPolicyProvider in 2). Since the proxy is not an instance > of DelegatingPolicy, but wrapping the actual policy it calls > DelegatingPolicy.getInstance(), this call does not create a > new instance but returns the DelegatingPolicy set up by the > TomcatDeployer in 1) to which permissions are added. > > The JaccAuthorizationInterceptor calls Policy.getPolicy() and > uses the policy from 2) which has no permissions. > > > > > > > -----Original Message----- > > From: Scott M Stark [mailto:[EMAIL PROTECTED] > > Sent: 24 March 2006 17:57 > > To: Kabir Khan; Bill Burke > > Cc: QA; jboss-development@lists.sourceforge.net > > Subject: RE: JACC (ejb 3) - WAS RE: jboss-4.0-testsuite Build > > Completed With Testsuite Errors > > > > What I'm looking for is what code is actually doing the > > Policy.setPolicy for the ejb3 configuration. The JaccHelper > does not > > appear to be doing this. I can figure it out by working with the > > tests. > > > > > -----Original Message----- > > > From: Kabir Khan > > > Sent: Friday, March 24, 2006 8:29 AM > > > To: Scott M Stark; Bill Burke > > > Cc: QA; jboss-development@lists.sourceforge.net > > > Subject: RE: JACC (ejb 3) - WAS RE: jboss-4.0-testsuite Build > > > Completed With Testsuite Errors > > > > > > I didn't commit the Policy.setPolicy() stuff if that's what > > you mean. > > > Apart from that main work is being done in > > > org.jboss.ejb3.security.JaccHelper and > > > org.jboss.ejb3.security.JaccAuthorizationInterceptor(Factory) > > > > > > If you want to run the test (currently only deploys in > > Branch_4_0 due > > > to some problems with persistence.xml in my copy of head > at least): > > > $cd ejb3 > > > $build.sh -f build-test.xml > > > $build.sh -f build-test.xml jacc-test > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking > scripting language that extends applications into web and > mobile media. Attend the live webcast and join the prime > developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&; dat=121642 > _______________________________________________ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
