geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Proposed solution for the configId dilemma
Date Fri, 03 Feb 2006 02:42:11 GMT
After a long discussion on IRC we may have a proposal for the  
configId dilemma.

People: Dain and I will work to implement this
Timeframe: for the next week, then we will see where we are
svn tags: we'll make a branch off 1.0.  If we succeed, the merge of  
our work and 1.0 will become 1.1 and we will not release 1.0.1.  Then  
we'll merge into trunk.

Goal: make version Id optional almost everywhere: certainly in any  
normal user plan.

xml changes:
eliminate configId and parentId attributes: there is already the  
<import> element to replace parentId, and introduce a new configId  
element to replace the configid attribute.  This will have the same  
structure as dependencies, imports, etc.  For all these tags except  
configId version will be optional.

Introduce a new element <config-dependency> (name up for grabs :-)  
that creates a dependency on the named configuration but does not add  
it to the set of classloader parents.  This would have the dependency  
type with optional version.

eliminate direct specification of gbean names in gbeans and in gbean  
reference patterns.  Replace specification of e.g.


where any of these is optional.

There may be changes in the meaning of gbean name specifications, see  
the resolution process described later.

problems with this:
- configId can appear in module or application.  We think that the  
configId resolution process described later will be able to resolve  
the meaning
- there are a few gbeans that don't have as many object name keys,  
such as the jsr-77 beans for the server and jvm.  I don't know how to  
deal with these yet.

GBean name changes: Change the configuration gbean names to have  
separate groupId, artifactId, and version keys.  We might need to  
separate out a version in every gbean name but think this is unlikely.

File system changes: adopt a maven2 repository structure for the  
geronimo repo.

algorithm changes:
1. resolving parents (imports) and config-dependencies.  These both  
involve finding a configuration given only partial information.  The  
config-store is going to need to be queriable to some extent and we  
will need some kind of resolution strategy in case there is more than  
one match.

Starting from a plan, resolving the parents and config-dependencies  
recursively results (when combined) with a directed acyclic graph of  
configurations (configDAG).

2. resolving gbean references.  This part is still open to  
considerable modification, but some parts are clear.  We start with a  
partially specified object name: typically we will have a name key, a  
j2eeType key, and a partial specification of the configId.  We start  
by resolving the configId by a depth first search of the configDAG  
until we find a match.  Depending on whether the target configuration  
is for an ear or anything else, we can determine if the configId is  
the J2EEApplication or J2EEModule key for the name.  We can then look  
for names matching the rest of the specification.

Discussion of algorithm changes:  Currently there are 2 kinds of name  
resolution: "link" resolution that typically starts in the current  
module and then if not matched looks in any module with  
J2EEApplication="null", and exact specification where you specify  
several name components and the rest are the same as the gbean with  
the reference.  There is also specifying an entire name explicitly  
(possibly with wildcards).  We plan to eliminate the whole-name  
option.  We think that we can replace both the other resolution  
methods with the method just outlined, where the search path for  
resolution is not the whole server but the configDAG.  For me, this  
requires more study to be completely confident that it will work but  
I am very hopeful.

An unusual situation that requires a reference out of the configDAG:   
It is possible for a config A to have a gbean X and a config B to  
have a gbean Y where both X and Y reference the other gbean, so long  
as at least one of the references is multi-valued.  In order to allow  
for this, it has to be possible to specify a reference pattern in  
some way that is not resolved at deploy time.  This is an extremely  
unusual situation and complex xml should be acceptable here.

Console changes:  Several console portlets let you construct a plan.   
These need to be modified to allow you to specify groupid,  
artifactId, and version explicitly.  The version can default to a  
timestamp.  The groupId should default to something.  I would prefer  
there to be a server-wide explicit setting where you name your  
company :-) so all the groupIds default to that.  However if this is  
too hard we might end up with "unspecified" or something.

There may be a problem using the packaging plugin with plans that  
don't specify parent/import versions.  The packaging plugin runs  
against your local maven repo.  So if you have been building geronimo  
1.1 and 1.2 on your machine recently, both sets of cars will be in  
the maven repo, and building a plan will automatically resolve  
against the 1.2 cars.  This might or might not be what you want.  The  
moral of the story may be that we should specify versions in our  
plans and encourage people who use the packaging plugin to use  
versions also.  After all, they are using maven so they have a  
version handy already.  Once the import and config-dependencies are  
resolved (perhaps by explicit versions) the gbean references should  
not need the version to be resolved.

david jencks

View raw message