Hi!
>>>
>>>
>> Both will make it, but in this case I'd go the filter-config way. Then
>> we do not need any parameter name tangling.
>>
>
> Ok. So no ability to configure the object via dependency injection.
> That's a shame, but I agree that the extra complexity is probably not
> worth it.
>
Not necessarily. I currently experiment with the code a little bit and
that is what I have:
1) an AbstractFrameworkAdapter with the member "ConversationMessager
conversationMessager" and getter/setter for it.
2) the LocalFrameworkAdapter inheriting from AbstractFrameworkAdapter
so for Dan can use DI to create the LocalFrameworkAdapter again. There
is no default yet, one has to configure the messager always.
3) the AbstractFrameworkAdapter provides a createConversationMessager()
method which will be called if no one set one.
4) The BasicFrameworkAdapter implement this method like this:
protected ConversationMessager createConversationMessager()
{
if (conversationMessager == null)
{
return new JsfConversationMessager();
}
Object instance = getBean(conversationMessager);
if (instance instanceof ConversationMessager)
{
return (ConversationMessager) instance;
}
return (ConversationMessager)
ClassUtils.newInstance(conversationMessager);
}
conversationMessager is a string representing the filter configuration.
As you can see, I still lookup the bean first and only if this fails the
string is treated as a class name.
5) The JsfFrameworkAdapter inherits from BasicFrameworkAdapter which
makes the getBean call through the JSF variable resolver and effectively
Spring in our case.
I am going to commit this stuff in a couple of minutes so that you can
review it - we can rollback if you don't like it.
> Well, how about we just implement this in the LocalFrameworkAdapter for
> now? I cannot see how this can be used in any other case.
>
Well, I'd like to have a common ground for all Adapters.
> Are we still looking at returning the messager from the getBean method,
> or adding a method to the FrameworkAdapterInterface?
Not with my tests. I've added an additional method to the FAI - well it
is an abstract basis class yet.
> I still like the
> idea of using getBean as it provides a standard interface for
> framework-specific resource lookup no matter what resources we discover
> we need later.
We can make my methods protected and route them through the getBean
method if we don't want to expose them as interface.
Ciao,
Mario
