Jan, > -----Original Message----- > From: Jan Bartel [mailto:[EMAIL PROTECTED] > > What is the architecture of the security service? I'll look over on the > wiki for some info, but a bit of an overview would be extremely helpful > ...
You're right. I shall not continue w/ coding until I've written it down. > > It's my understanding that the DeploymentController gets a bunch of > > DeploymentGoals in the form of DeployURLs and starts "randomly" passing > them > > around various registered DeploymentPlanners. These DeploymentPlanners > > opportunistically eat the goals and spit out plans. If I add a > > SecurityDeploymentPlanner, there is no guarantee that there will be any > > DeployURLs left by the time the DeploymentController gets to it. Even > if > > there was a way to guarantee that the SecurityDeploymentPlanner, there > is no > > way to pass information on to the WEB/EJB deployers to ensure the proper > > start/stop dependency. > Do we really need to make the security service a deployment planner? I > thought a suitable level of granularity of a deployment planner was a > deployable unit (an ear, a war, an ejb jar, a service, rar etc). Each > deployer uses various services in order to perform its deployment, and I > envisaged a security service as being pretty fundamental to all of the > j2ee deployers. That is, I thought that all the j2ee-type deployers > would be explicitly looking to contact a security service that would do > whatever security setup was necessary. I was thinking that this contact > would be via calls on a security service mbean. What is the motivation > for making it a deployment planner? You're right; I may be over engineering this. Let me finish the wiki stuff and I'll revisit this. Thanks for your comments. Regards, Alan
