Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <D1D2AB7C-52CC-11D9-8437-000D93361CAA@gluecode.com>
References: <D1D2AB7C-52CC-11D9-8437-000D93361CAA@gluecode.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3CE820AF-52D3-11D9-8437-000D93361CAA@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Aplogies for "Severe problems with automapping" with rephrasing
Date: Mon, 20 Dec 2004 14:05:19 -0800
To: dev@geronimo.apache.org

I apologize for the rather abrasive tone of my previous email and try 
to rephrase my questions.

I've been looking at the automap code recently and think it may suffer 
from a couple problems.  I wonder if I've understood what is going on 
correctly and what the best way to proceed is.

The problems I see are:

automapping is spread between deployment and runtime.  I think it would 
be better to put all the functionality in one phase.  After talking 
with Alan, I think deployment time would be better, if we can figure 
out how to do it.

However... many automap features, including those currently  used at 
deploy time, use gbean operations that are only available if the gbeans 
are started.  This can only be guaranteed at runtime.

Now, there seem to be 3 places automap classes can be described, as far 
as I can tell:

1. login modules or other objects implementing DeploymentSupport.  The 
way this is currently implemented it will only be available at runtime. 
  A big redesign would be needed to make it available at deploy time.
2. GenericSecurityRealm/AutomapAssistant.  Currently this info is only 
available at runtime, but it is fairly easy to make it available as 
persistent gbean attributes  available at deploy time from a loaded but 
not started gbean.
3. the security config from a deployment plan.  This is definitely 
available at deployment time and would require some work to make 
available at runtime :-)

Along with the multiple sources, there seems to be some confusion about 
priority.
--the login modules/DeploymentSupport seems to indicate in comments 
that it is the default of last resort, yet it appears to me to replace 
settings from the GenericSecurityRealm at runtime.
--the security config stuff seems to indicate that it should override 
everything else, but it is completely ignored AFAICT.

I don't claim to completely understand this, but 3 levels of 
configuration for automapping seems to me like it might be too 
complicated for anyone to be able to predict the results.

It would be quite simple to write a deploy-time only automap system 
that only used info from the security descriptor.  This would eliminate 
a lot of complexity and the problems with getting info out of 
non-started gbeans.  I propose that we try this out and see how 
inconvenient it is in practice.

Comments?

thanks
david jencks