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: module builders/deployers in plugins
Date Tue, 11 Mar 2008 20:03:47 GMT

On Mar 11, 2008, at 9:15 AM, Jarek Gawor wrote:

> Does anybody have any thoughts on this? Both are important to the
> concurrency work but 2) is a little more important as I can't
> integrate the concurrency code with Geronimo without disabling some
> other functionality.
>
> Thanks,
> Jarek
>
> On Wed, Feb 20, 2008 at 4:12 PM, Jarek Gawor <jgawor@gmail.com> wrote:
>> I have a couple of questions about module builders/deployers and
>>  plugin support in Geronimo:
>>
>>  1) I have a plugin that contains a NamingBuilder. Once I install  
>> this
>>  plugin, that NamingBuilder will not be called during module  
>> deployment
>>  until I 'register' it with the NamingBuilders gbean (e.g. in
>>  plugins/j2ee/j2ee-deployer/src/main/plan/plan.xml or config.xml).  
>> The
>>  questions is, can we make this more dynamic? It would be great  
>> just to
>>  install the plugin and have the NamingBuilder to be invoked
>>  automatically without any additional configuration steps.

Right now you have to add it to the list of accepted names.  I don't  
see an easy way around this at the moment.

>>
>>  2) The AdminObjectRefBuilder is always trying to process _all_
>>  resource-env-ref entries (AdminObjectRefBuilder is just an  
>> example in
>>  this case). However, as things evolve (Java EE 5 -> 6) and new
>>  resource env. types are added, it does not scale to keep updating  
>> the
>>  AdminObjectRefBuilder to handle these new types. So I think it would
>>  be nice to install a new builder that would handle these new types
>>  only. But that would require communicating with the
>>  AdminObjectRefBuilder and somehow telling it to ignore the new  
>> types.
>>  The question is, what would be the best way of doing it? Or maybe we
>>  need a different way of processing the DDs?

This is kind of a tricky problem and I don't know the best way to  
handle it.  I doubt you want to get into rewriting the entire way we  
resolve resource-env-refs at this point -- let me know if you do --  
so I would look into exactly what is keeping the current  
AdminObjectRefBuilder from handling your new kinds of refs and  
whether there is an easy way to exclude them.

Some possibilities....
- the AdminObjectRefBuilder.AdminObjectRefProcessor picks out the  
annotations we will look at.  If the new stuff can only be referred  
to as @Resource you can have the AdminObjectRefProcessor skip the new  
kinds.
- basically the AdminObjectRefBuilder works by finding a gbean that  
corresponds to the name information and type information supplied,  
around line 373.  We could expand the choices for how we look for  
target gbeans.
- we might be able to make the NamingBuilderCollection ordered and  
have the builders not try to deal with questionable items that have  
already been processed.

There are probably lots of other solutions I can't think of yet...

Hope this helps a bit
david jencks

>>
>>  Jarek
>>


Mime
View raw message