Geoff Howard wrote:
> Berin Loritsch wrote:
>
>>> What this means is that the @x-avalon-info should be considered
>>> differently for service interfaces (element name) and for classes
>>> ("type" attribute).
>>
>>
>>
>> No, it means that your interpretation of the configuration to get
>> at the short name would be different.
>
>
>
> Is there an easy way to find out what real class a given shortcut/role
> is associated with (resolving to)? In
> digging into things in Cocoon now I and I'm sure others grep through the
> roles file and cocoon.xconf to find
> where to look for a given implementation. I'm thinking it would be good
> to provide some way to trace back
> from a hint name or service type back to the concrete class.
When Fortress starts up, it spits out all that info in the log file.
However look at this as a strength. Not too long ago I refactored some
libraries for my GUIApp application to put all the code in a different package.
With ECM, I would have to change the packages, change the roles file, and
hope that there were no conflicts between role files. If the class name
were listed in a configuration file, then I would have to change that as well.
With Fortress, I only had to use the IDE's move refactoring support and the
same configuration worked with the new code--no other edits necessary.
It truly does bring more benefits than liabilities.
> Also, the roles file defines default implementation which can be
> overridden in xconf. Is this the same in fortress? If I want to replace
> the default implementation of transient-store with my own souped up
> version (you'll need to
> momentarily suspend your disbelief that I'm capable of coming up with
> one ;) ) how do I do that?
> Geoff
Yes, the xconf does allow you to override things--but what real-world
requirements would require that to happen? I've been doing this for
years, and I can't really think of a reason.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
|