geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: We might need "aliased" modules/configurations/artifactIds
Date Fri, 15 Sep 2006 22:52:42 GMT
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 <david_jencks@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
>>>
>>>


Mime
View raw message