Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <1879412994.1123109555473.JavaMail.jira@ajax.apache.org>
Date: Thu, 4 Aug 2005 00:52:35 +0200 (CEST)
From: "Aaron Mulder (JIRA)" <dev@geronimo.apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Closed: (GERONIMO-850) Be able to add configuration
 dependencies
In-Reply-To: <299780752.1123108894950.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/GERONIMO-850?page=all ]
     
Aaron Mulder closed GERONIMO-850:
---------------------------------

    Fix Version:     (was: 1.0)
     Resolution: Duplicate

Didn't really need to be submitted twice

> Be able to add configuration dependencies
> -----------------------------------------
>
>          Key: GERONIMO-850
>          URL: http://issues.apache.org/jira/browse/GERONIMO-850
>      Project: Geronimo
>         Type: Improvement
>   Components: kernel
>     Versions: 1.0-M4
>     Reporter: Aaron Mulder

>
> It would be nice if the code of a GBean could register new dependencies for iteself.  This could be used for:
>  - Tomcat, so you could give it a list of valves and it could make itself depend on them
>  - A security realm, so you could give it a list of login modules and it could make itself depend on them
>  - J2EE modules, so when you declare a resource-ref or EJB-ref to a resource/EJB in a separate app or module then it could make itself depend on that app or module
> Note all of these are cases where the current GBean knows precisely which target GBeans it depends upon -- this does not deal with queries for which an unknown number of GBeans might match.
> The first two cases are currently handled by a, erm, unfortunate workaround whereby the first GBean depends on the second that depends on a third so each "target" GBean needs a "next" reference that it doesn't actually need but arranges the dependencies.  It would be nice to not have to do that.
> The third case can't be done right now AFAIK.
> I'm imagining some kind of kernel call like addDependency(me, thingIDependUpon) -- where the method won't return until a dependency has been registered for "my configuration" on "my target's configuration" and that configuration has been loaded and the target GBean has been loaded.  The main problem seems to be figuring out what configuration the target GBean is in.  Seems like this could be determined by parsing the ObjectName of the target.
> Perhaps instead of working like standard dependencies, this could be arranged to work via a helper class where the master GBean just says "helper.load(new String[]{a,b,c})" when the master is loaded, and "helper.start(new String[]{a,b,c})" when the master is started.

-- 
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