This sounds like a good idea.
Regards,
Alan
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
