geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Proposed solution for the configId dilemma
Date Sat, 04 Feb 2006 10:03:53 GMT
I've added a very rough first draft of a new/modified schema  
following the design on the wiki.  Many of the element names are not  
very satisfactory and I would appreciate suggestions.  There are  
probably other errors as well :-)


david jencks

On Feb 3, 2006, at 5:38 PM, David Jencks wrote:

> I talked with Dain some more and we laid out some steps to follow,  
> I put them on the confluence wiki:
> configId
> If people would like me to summarize changes and progress on the  
> dev list as well I will attempt to do that.
> I hope to have a proposal for schema changes in the next day or  
> so.  Please get ready to review and criticize it :-)
> thanks
> david jencks
> On Feb 2, 2006, at 6:42 PM, David Jencks wrote:
>> 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.
>> <module>groupId/artifactId/version/car</module>
>>  with
>> <groupId>foo</groupId>
>> <artifactId>bar</artifactId>
>> <version>1.0</version>
>> 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.
>> Comments?
>> thanks
>> david jencks

View raw message