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 :-)
branches/configid/modules/service-builder/src/schema/geronimo-
config-1.1.xsd
thanks
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:
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
