[VOTE] Weakness in RoleManager

[Berin Loritsch <bl...@apache.org>]

I would like to make RoleManager have an additional method--unfortunately that is not
backwards compatible.  I highly doubt that it would affect any existing projects as
the DefaultRoleManager is sufficient for most people.

The method I want to add is "String[] getManagedRoleNames()" so that the ExcaliburComponentManager
does not load new Components during runtime--and they are all done at init time.

There are a couple of issues with this approach, however:

What if a Role is managed by a parent ComponentManager?  this is a simple check...
What if the role is never needed by a running system?  this is not easily determinable.

This brings up another question:

*Should* ExcaliburComponentManager implicitly build Components on demand if the
entries are in the RoleManager?  The tradeoff is that allowing Components to be
instantiated at runtime allows the configuration file size be minimized.  By
requiring all components to be explicitly declared, you will end up with a number
of configuration entries like this:

<parser/>

I find it to be a useful feature in order to reduce configuration file verbosity.


VOTE ON PLAN OF ATTACK

Add the non-backwards compatible method to RoleManager

interface RoleManager
{
     // ..... Skip already declared methods .....

     String[] getManagedRoleNames();
}

This allows the ExcaliburComponentManager to build all the necessary Components
at intialization time instead of during run time.  It also allows the Lookup
method to be simpler.

Alternatively, I can subinterface the RoleManager with the method I need, testing
for the specialization in ExcaliburComponentManger--but this will not allow the
lookup method to be cleaned up....

Last alternative is a cleanroom implementation of everything--not supporting the
deprecated Loggable interface....

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VOTE] Weakness in RoleManager

[Berin Loritsch <bl...@apache.org>]

Peter Donald wrote:

> On Thu, 13 Dec 2001 08:27, Berin Loritsch wrote:
> 
>>Last alternative is a cleanroom implementation of everything--not
>>supporting the deprecated Loggable interface....
>>
> 
> If you decide to go this path then give me some heads up. I have a few 
> different projects that are based on ideas in ECM but with slight variations. 
> One example is the Ant2 proposal that I just started working on again. The 
> variations I use (different handlers and no default classes) could be handled 
> by specifying different conventions. Some would be documentation (ie the hint 
> "default" could mean that getDefaultClassname goes away) while others would 
> be changes to code. 


It's something I have been thinking of for a while.  I want to separate out the
Container and referencing the elements of the Container so that the CM was purely
what it was intended to be, and the Container takes care of it's issues.

That is why I want the Circuit class.  I have to map the class name to the
configuration to the ComponentHolder.

 



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VOTE] Weakness in RoleManager

[Peter Donald <pe...@apache.org>]

On Thu, 13 Dec 2001 08:27, Berin Loritsch wrote:
> Last alternative is a cleanroom implementation of everything--not
> supporting the deprecated Loggable interface....

If you decide to go this path then give me some heads up. I have a few 
different projects that are based on ideas in ECM but with slight variations. 
One example is the Ant2 proposal that I just started working on again. The 
variations I use (different handlers and no default classes) could be handled 
by specifying different conventions. Some would be documentation (ie the hint 
"default" could mean that getDefaultClassname goes away) while others would 
be changes to code. 

-- 
Cheers,

Pete

---------------------------------------------------
Murphy's law - "Anything that can go wrong, will." 
(Actually, this is Finagle's law, which in itself 
shows that Finagle was right.)
---------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>