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/09/14 21:22:35 UTC
We might need "aliased" modules/configurations/artifactIds
I started working on a version of geronimo that uses the jta11
transaction manager in the sandbox. So, I wrote a new transaction
configuration using the new gbean and started trying to assemble a
server. My new config has gbeans with exactly the same names (except
for artifactId) as the old jta 1.0.1B configuration (present in
GERONIMO-2398, please vote). Now it turns out that in order to swap
these configs I am going to need to change almost all the other
configs so they depend on my new one instead of the old one.
This highlights a need for more functional-based dependencies.
Conceptually we kind of want to say, "this module depends on a module
supplying services A, B, C"
One idea I had that might be pretty easy to implement would be to
expand the explicit-versions resolving code a bit so that you can
supply a properties file that says "replace requests for artifactId X
with artifactId Y" and plug it in the the artifact resolver,
configuration, and kernel so that when you ask for a gbean with
artifactId X you get one with the same name map and interfaces but
with artifactId Y. I think of this as aliasing X as Y (or maybe its
vice-versa).
I'm starting to try to implement this since I'm kind of blocked
without something like this... but this might not be the best
possible solution or even the easiest. Anyone want to comment or
suggest better ideas?
thanks
david jencks
Re: We might need "aliased" modules/configurations/artifactIds
Posted by Bill Dudney <bd...@apache.org>.
This sounds a lot like OSGi.
Felix might be a bit young but it seems like a big part of this
functionality is covered there.
Thoughts?
-bd-
On Sep 14, 2006, at 1:32 PM, Aaron Mulder wrote:
> I sure wouldn't mind if a module could say "I provide javax.foo.Bar"
> and a separate module could say "I require a parent that provides
> javax.foo.Bar"... As in, interface dependencies instead of name-based
> dependencies.
>
> Thanks,
> Aaron
>
> On 9/14/06, David Jencks <da...@yahoo.com> wrote:
>> I started working on a version of geronimo that uses the jta11
>> transaction manager in the sandbox. So, I wrote a new transaction
>> configuration using the new gbean and started trying to assemble a
>> server. My new config has gbeans with exactly the same names (except
>> for artifactId) as the old jta 1.0.1B configuration (present in
>> GERONIMO-2398, please vote). Now it turns out that in order to swap
>> these configs I am going to need to change almost all the other
>> configs so they depend on my new one instead of the old one.
>>
>>
>> This highlights a need for more functional-based dependencies.
>> Conceptually we kind of want to say, "this module depends on a module
>> supplying services A, B, C"
>>
>> One idea I had that might be pretty easy to implement would be to
>> expand the explicit-versions resolving code a bit so that you can
>> supply a properties file that says "replace requests for artifactId X
>> with artifactId Y" and plug it in the the artifact resolver,
>> configuration, and kernel so that when you ask for a gbean with
>> artifactId X you get one with the same name map and interfaces but
>> with artifactId Y. I think of this as aliasing X as Y (or maybe its
>> vice-versa).
>>
>> I'm starting to try to implement this since I'm kind of blocked
>> without something like this... but this might not be the best
>> possible solution or even the easiest. Anyone want to comment or
>> suggest better ideas?
>>
>> thanks
>> david jencks
>>
>>
Re: We might need "aliased" modules/configurations/artifactIds
Posted by David Jencks <da...@yahoo.com>.
Well, something big and general and osgi-like might be great but I
don't know how to build it today and it certainly would require some
major debate on how it ought to work.
Meanwhile I modified the explicit_versions handling and it seems to
let me boot up a geronimo-jetty-jee5 server with only the tm module
replaced.
I suspect more changes will be needed to the Configuration and
BasicKernel gbean lookups, but I haven't run into these problems
yet. I'd like to commit the code I have so far.
http://issues.apache.org/jira/browse/GERONIMO-2409
Please take a look and vote.
thanks
david jencks
On Sep 14, 2006, at 4:18 PM, Joe Bohn wrote:
> We definitely need some form of type/function/interface/whatever
> based dependencies.
>
> I'm working on a new core framework assembly (little-G without the
> containers ... micro-G? ) that we could use as a base for user
> created assemblies via plugins. This is really the same item that
> I think could solve the assembly proliferation issue (per the
> recent jetty 5 vs. jetty 6 discussion).
>
> One of the things that would be helpful for this "micro-G" is type
> based dependencies as mentioned here. We could then create plugins
> that had a requirement on a servlet container without the need to
> create two or more plugins for the various container we support).
> We could also define plugins that had cardinality rules associated
> with them (only install if no other plugin of similar type is
> installed) so that we won't end up with 2 web container vying for
> the same ports, etc...
>
> How we go about doing this is something that I haven't dug into yet
> but I think it would require some fundamental changes to the gBean
> infrastructure.
>
> Sorry to get so long winded. I hope this is still relevant to the
> thread you intended to start David. :-)
>
> Joe
>
> Aaron Mulder wrote:
>> I sure wouldn't mind if a module could say "I provide javax.foo.Bar"
>> and a separate module could say "I require a parent that provides
>> javax.foo.Bar"... As in, interface dependencies instead of name-
>> based
>> dependencies.
>> Thanks,
>> Aaron
>> On 9/14/06, David Jencks <da...@yahoo.com> wrote:
>>> I started working on a version of geronimo that uses the jta11
>>> transaction manager in the sandbox. So, I wrote a new transaction
>>> configuration using the new gbean and started trying to assemble a
>>> server. My new config has gbeans with exactly the same names
>>> (except
>>> for artifactId) as the old jta 1.0.1B configuration (present in
>>> GERONIMO-2398, please vote). Now it turns out that in order to swap
>>> these configs I am going to need to change almost all the other
>>> configs so they depend on my new one instead of the old one.
>>>
>>>
>>> This highlights a need for more functional-based dependencies.
>>> Conceptually we kind of want to say, "this module depends on a
>>> module
>>> supplying services A, B, C"
>>>
>>> One idea I had that might be pretty easy to implement would be to
>>> expand the explicit-versions resolving code a bit so that you can
>>> supply a properties file that says "replace requests for
>>> artifactId X
>>> with artifactId Y" and plug it in the the artifact resolver,
>>> configuration, and kernel so that when you ask for a gbean with
>>> artifactId X you get one with the same name map and interfaces but
>>> with artifactId Y. I think of this as aliasing X as Y (or maybe its
>>> vice-versa).
>>>
>>> I'm starting to try to implement this since I'm kind of blocked
>>> without something like this... but this might not be the best
>>> possible solution or even the easiest. Anyone want to comment or
>>> suggest better ideas?
>>>
>>> thanks
>>> david jencks
>>>
>>>
Re: We might need "aliased" modules/configurations/artifactIds
Posted by Joe Bohn <jo...@earthlink.net>.
We definitely need some form of type/function/interface/whatever based
dependencies.
I'm working on a new core framework assembly (little-G without the
containers ... micro-G? ) that we could use as a base for user created
assemblies via plugins. This is really the same item that I think could
solve the assembly proliferation issue (per the recent jetty 5 vs. jetty
6 discussion).
One of the things that would be helpful for this "micro-G" is type based
dependencies as mentioned here. We could then create plugins that had a
requirement on a servlet container without the need to create two or
more plugins for the various container we support). We could also
define plugins that had cardinality rules associated with them (only
install if no other plugin of similar type is installed) so that we
won't end up with 2 web container vying for the same ports, etc...
How we go about doing this is something that I haven't dug into yet but
I think it would require some fundamental changes to the gBean
infrastructure.
Sorry to get so long winded. I hope this is still relevant to the
thread you intended to start David. :-)
Joe
Aaron Mulder wrote:
> I sure wouldn't mind if a module could say "I provide javax.foo.Bar"
> and a separate module could say "I require a parent that provides
> javax.foo.Bar"... As in, interface dependencies instead of name-based
> dependencies.
>
> Thanks,
> Aaron
>
> On 9/14/06, David Jencks <da...@yahoo.com> wrote:
>
>> I started working on a version of geronimo that uses the jta11
>> transaction manager in the sandbox. So, I wrote a new transaction
>> configuration using the new gbean and started trying to assemble a
>> server. My new config has gbeans with exactly the same names (except
>> for artifactId) as the old jta 1.0.1B configuration (present in
>> GERONIMO-2398, please vote). Now it turns out that in order to swap
>> these configs I am going to need to change almost all the other
>> configs so they depend on my new one instead of the old one.
>>
>>
>> This highlights a need for more functional-based dependencies.
>> Conceptually we kind of want to say, "this module depends on a module
>> supplying services A, B, C"
>>
>> One idea I had that might be pretty easy to implement would be to
>> expand the explicit-versions resolving code a bit so that you can
>> supply a properties file that says "replace requests for artifactId X
>> with artifactId Y" and plug it in the the artifact resolver,
>> configuration, and kernel so that when you ask for a gbean with
>> artifactId X you get one with the same name map and interfaces but
>> with artifactId Y. I think of this as aliasing X as Y (or maybe its
>> vice-versa).
>>
>> I'm starting to try to implement this since I'm kind of blocked
>> without something like this... but this might not be the best
>> possible solution or even the easiest. Anyone want to comment or
>> suggest better ideas?
>>
>> thanks
>> david jencks
>>
>>
>
Re: We might need "aliased" modules/configurations/artifactIds
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I sure wouldn't mind if a module could say "I provide javax.foo.Bar"
and a separate module could say "I require a parent that provides
javax.foo.Bar"... As in, interface dependencies instead of name-based
dependencies.
Thanks,
Aaron
On 9/14/06, David Jencks <da...@yahoo.com> wrote:
> I started working on a version of geronimo that uses the jta11
> transaction manager in the sandbox. So, I wrote a new transaction
> configuration using the new gbean and started trying to assemble a
> server. My new config has gbeans with exactly the same names (except
> for artifactId) as the old jta 1.0.1B configuration (present in
> GERONIMO-2398, please vote). Now it turns out that in order to swap
> these configs I am going to need to change almost all the other
> configs so they depend on my new one instead of the old one.
>
>
> This highlights a need for more functional-based dependencies.
> Conceptually we kind of want to say, "this module depends on a module
> supplying services A, B, C"
>
> One idea I had that might be pretty easy to implement would be to
> expand the explicit-versions resolving code a bit so that you can
> supply a properties file that says "replace requests for artifactId X
> with artifactId Y" and plug it in the the artifact resolver,
> configuration, and kernel so that when you ask for a gbean with
> artifactId X you get one with the same name map and interfaces but
> with artifactId Y. I think of this as aliasing X as Y (or maybe its
> vice-versa).
>
> I'm starting to try to implement this since I'm kind of blocked
> without something like this... but this might not be the best
> possible solution or even the easiest. Anyone want to comment or
> suggest better ideas?
>
> thanks
> david jencks
>
>