geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Proposed solution for the configId dilemma
Date Fri, 03 Feb 2006 03:26:25 GMT
This sounds like a good idea.


David Jencks wrote, On 2/2/2006 6:42 PM:
> 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