EJB3 Alignment with JBoss Security

[anil.saldhana]

I am going to list all that I am doing with ejb3 codebase to align it with ejb2 security.
http://jira.jboss.com/jira/browse/JBAS-4423

I do not want to affect Bill Burke's embedded effort. So he can raise any issues here.

Some of the steps are:
a) Move the ejb3 security annotations to security.
b) Align ejb3 security context with the JBoss Securitycontext.

[wolfc]

Another important issue: how are we going to keep this backportable to AS 4.x?

I've committed ejb3/build-from-5.xml in Branch_4_2 just to try something out. It clearly shows the security portability problem.

Check the jboss.as.root variable in the first line. I need to pull this to a properties file.
cd ejb3; ./build.sh -f build-from-5.xml clean compile-classes

[bill.burke]

The code bases need to diverge. Its inevitable.

[wolfc]

I concur, but only partially.

If we create a EJB3 security spi which is provided by the EJB3 core and implemented by both EJB3 AS 4.2 security int and EJB3 AS 5.0 security int, then we don't have a lot of divergant code.
Configuration of the security int is then done in the EJB3 deployer meta data.

[anil.saldhana]

As part of JBoss Seam alignment with JBoss Security, I have been thinking of bringing the SPI into the 4.x world, such that integrators are shielded from the JBoss security internals.

So you program to the SPI and the JBoss Security implementation will take care of the internals.

[anil.saldhana]

"wolfc" wrote:
I concur, but only partially.

If we create a EJB3 security spi which is provided by the EJB3 core and implemented by both EJB3 AS 4.2 security int and EJB3 AS 5.0 security int, then we don't have a lot of divergant code.
Configuration of the security int is then done in the EJB3 deployer meta data.

Rather than every individual project define a security spi in the AS workspace, why shouldn't the security integration module in the AS workspace have a spi that both the 4 and 5 code base in the AS can leverage? This is the direction.

EJB3 will depend on the interfaces defined in the security module of the AS workspace. I brought this issue with Scott and he concurred.

[wolfc]

Ah yes even better. But this spi shouldn't be in AS workspace, but in AS projects because it must be equal both in AS 4.2 and AS 5.0.
Then it's easily mavenazible as well.

So effectively I remove security module as a dependency and add security-spi artifact. This should highlight all the functions I want as compiler errors. :-)