You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/02/03 03:42:11 UTC
Proposed solution for the configId dilemma
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
Re: Proposed solution for the configId dilemma
Posted by David Jencks <da...@yahoo.com>.
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
>>
>>
>
Re: Proposed solution for the configId dilemma
Posted by David Jencks <da...@yahoo.com>.
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
>
>
Re: Proposed solution for the configId dilemma
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
>