In the process of combining JettyWebAppContext and JettyWebAppJACCContext I've tried to make sense of the security automapping code. My conclusion is that it is currently a mass of half implemented features that don't work together.

Problems:

automapping is spread between deployment and runtime
Most automap features used at deployment time require gbean features only available at runtime
There are 3 places automap classes can come from, as far as I can tell:


login domain (only available at runtime)
security realm (currently only available at runtime, but can be made available at deployment time fairly easily)
plan security config (available at deployment time)


Of these, the security config classes are ignored completely, although they are named as if they should override the other two.
The classes from login domain are commented as defaults, but IIUC they will replace anything in the security realm at runtime.


I'd like to propose that we remove any automapping functionality from the realms and login modules until a complete implementation can be done. In this way we will have a simpler system that works at deployment time and we can try to implement a more sophisticated defaults scheme that works without assuming gbeans are started at deployment time.

Comments?

thanks
david jencks



Reply via email to