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
