geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Proposed solution for the configId dilemma
Date Sat, 04 Feb 2006 01:38:21 GMT
I talked with Dain some more and we laid out some steps to follow, I  
put them on the confluence wiki:

http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/ 
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
>
>


Mime
View raw message