Ok, I will post a patch for cvs HEAD later this coming week. Btw, this stuff needs a little bit more from interceptor support then I originally thought. Specifically jaas interceptor must access BlockInfo somehow my guess through "Contextualizable" interface. It also needs to be Initializable/Startable. In other words, interceptors need lifecycle support as any other block (interceptor's lifecycle is couple with lifecycle of its block, so implementation might get tricky). Should I resubmit "interceptor patch" with this added functionality or should I wait for you to check interceptor support in and extend it after that?
Peter Donald wrote: > Hiya, > > On Sun, 1 Sep 2002 15:17, Igor Fedorenko wrote: > >>I am finishing implementation of a coarse-grain access control for >>phoenix blocks and wonder if you are interesting in it. >> >>What I am doing is pretty much driven by current ejb approach (if I got >>it right :-) but with some simplifications. Basically, application >>developer associates methods of service interface (sic) with logical >>role or roles allowed to call the method. You could specify "unchecked" >>as well as have settings for "all other methods" and, of course, there >>is xdoclet support for all this. Application assembler maps logical >>roles into physical roles of environment using simple xml file and >>configures security interceptors for blocks (I still hope to see >>interceptors committed into the cvs :-). I have JAAS interceptor but >>other could be written easily. I still have some issues to resolve, like >>how to assign security context with calls originated from phoenix >>blocks, but otherwise I am almost there. The code lives in application >>space but could be migrated into phoenix kernel if you would like to >>adopt it. So, what do you think? > > > I think it sounds fantastic. I am still working on integrating the interceptor > stuff in. However I don't want to change too much at a time because of the > upcoming release. Maybe it may be time to branch for release purposes and > then we could keep applying your stuff to main tree where it wont effect the > release. That may be the best idea .... -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
