Stephen wrote:
> Daniel Frey wrote:
>
>> Stephen wrote:
>>
>>
>>> Daniel Frey wrote:
>>>
>>>
>>>> Stephen wrote:
>>>>
>>>>
>>>>> Daniel Frey wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Timothy,
>>>>>>
>>>>>> After a regexp search through my *.java files I find that I've got
>>>>>> exactly on component with two constructors. AnimationQueue has one
>>>>>> parameter-less and one parameter-ful constructor:
>>>>>>
>>>>>> public AnimationQueue()
>>>>>> public AnimationQueue(Image backgroundImage)
>>>>>>
>>>>>> However, this is not a compnent in Merlins sense as it is not
>>>>>> mentioned in any block.xml. It's just a class behind the scenes.
>>>>>> Can this be the cause?
>>>>>>
>>>>>> Or do you mean two constructors with the same signature?
>>>>>
>>>>> I need to goo look at the code in detail - but basically what the
>>>>> exception is saying is that there is a component (i.e. a class with
>>>>> an associated .xinfo) that has multiple public constructors. For a
>>>>> number of reasons this is considered to be ambigouse.
>>>>>
>>>>> Cheers, Stephen.
>>>>
>>>>
>>>> I've got three .xinfo files in my build tree:
>>>>
>>>> Application.xinfo -- no constructors
>>>>
>>>> HierarchialResourceManagerFacade.xinfo -- no constructors
>>>>
>>>> SimpleSplash.xinfo -- two constructors
>>>> public SimpleSplash(ImageIcon backgroundImage)
>>>> public SimpleSplash(ImageIcon backgroundImage,
>>>> Component component)
>>>
>>> I hope the reference to Component is not a framework reference!
>>
>>
>> It's a reference into a java.awt.Component.
>
> OK - so its either another case of constructing a context entry, or its a
> non-proxied dependency that should be supplied via the service manager.
I don't understand the full meaning of this yet. But I think as soon as I
get to the point I'll meet the problem and start to understand what you are
explaining.
>>
>>>> Bingo. I think that's the reason: No default constructor or
>>>> configuraiton to address one of the given constructors (if the second
>>>> solution is possible).
>>>>
>>>> I'm on the way to transform this class to a Merlin component.
>>>> However, it needs at least a ImageIcon for the background. How do I
>>>> handle this with Merlin? Do I need to have a default constructor and
>>>> an mutator for the backgroundImage property? Why not, seems kind of a
>>>> proper solution... Except that the Splash may be without background
>>>> image, which would be nice to be enforced by passing it in the
>>>> constructor.
>>>
>>> You can handle this my defining a custom context entry. Basically you
>>> component SimpleSplash declares under either the constructor or under
>>> a contextualization method that it needs an entry of the type
>>> ImageIcon.
>>>
>>> E.g.:
>>>
>>> /**
>>> * @avalon.entry key="splash" type="x.u.z.ImageIcon"
>>> */
>>> public SimpleSplash( Context context )
>>> {
>>> ImageIcon icon = (ImageIcon) context.get( "splash" );
>>> // whatever
>>> }
>>>
>>> Then in the block (or packaged profile for the component) you declare
>>> to merlin how to build your image icon. For details on constructed
>>> context entries - take a look at the following example:
>>>
>>>
>>> http://avalon.apache.org/merlin/starting/tutorial/context/entries.htm
>>> l
>>>
>>> Cheers, Stephen.
>>
>> I'll try that.
>
> Don't hesitate to post any problems or issues - the custom entries
> approach is probably one of the main mechanisms that will be used in the
> future for customization of the lifecycle management. There is a lot
> more we pack into this area to make this really powerful. What already
> exists is sufficient but I think we can do a lot more with integration of
> dynamic loading and repository based factory handling in context
> directives (or more simply stated - the ability to plugin complex dynamic
> context value creation mechanisms).
It works perfectly!
Ok, I went through the tutorial. Pretty simple and understandable. Some
points are not clear. I.e. has the entry-key attribute [<entry
key="cruncher">] given in the block.xml to be the same as in the javadoc tag
[EMAIL PROTECTED] key="cruncher" type="tutorial.NumberCruncher"]?
The component deployment descriptor has now its dependency to the
implementation used for the cuncher. Is there a way to override this context
like in the configuration tutorial by mean of a target in a config.xml?
Thanks,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
