Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <1963566423.1139089383461.JavaMail.jira@ajax.apache.org>
Date: Sat, 4 Feb 2006 22:43:03 +0100 (CET)
From: "Daniel Fagerstrom (JIRA)" <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-1769) Role Handling
In-Reply-To: <157553995.1139000886449.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/COCOON-1769?page=comments#action_12365186 ] 

Daniel Fagerstrom commented on COCOON-1769:
-------------------------------------------

ATM role handling works for core components as I explicitly include resource://org/apache/cocoon/cocoon.roles in ECMBlockServiceManager,
so that all blocks get the cocoon.roles in their local role manager. That is obviously a hack that not generalize to the situation where other blocks declare roles.

The role handling do basically two different things, it provide shorthands (like the file key above) and it provide default implementations for roles.

For the default implementations this could possibly be solved with letting the service manager register the role together with the service manager that contains the role manager with the default in it, in the ServiceManagerRegistry. If the role manager register default values before the actual component registrations, an explicit declaration of a role would overwrite the default implementation (I know, it is hacky and fragile scheme).

For the shorthands the situation is more complicated, I don't think that they just can be saved in a global registry with a association to a certain block container, as one role shorthand can be connected several selector keys that can be connected to components in several blocks.

One way is to require that each used role file is included in the component configuration that uses it.

Another is to consider the shorthand as a component that contain the full role name and let the ECMBlockServiceManager do a two step lookup when it gets a "shorthand component".

> Role Handling
> -------------
>
>          Key: COCOON-1769
>          URL: http://issues.apache.org/jira/browse/COCOON-1769
>      Project: Cocoon
>         Type: Sub-task
>   Components: - Blocks Framework
>     Reporter: Daniel Fagerstrom

>
> The concept of role handling is Avalon specific, so it doesn't work that well if we want to register e.g. our sitemap components as OSGi services or Spring components. Maybe we could just put the role info in the container as well so that we don't need to maintain a parallel  set of rolemanagers for the blocks. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira