Nicola Ken Barozzi wrote:
>From: "Stephen McConnell" <[EMAIL PROTECTED]>
>
>
>
>
>>Peter Royal wrote:
>>
>>
>>
>>>On Thursday 06 June 2002 10:58 am, [EMAIL PROTECTED] wrote:
>>>
>>>
>>>
>>>> Modified:
>>>>containerkit/src/java/org/apache/excalibur/containerkit/lifecycle
>>>>LifecycleHelper.java
>>>> Log:
>>>> corrected to handle if( Configurable ) else if( Parameterizable )
>>>>
>>>>
>>>>
>>>Is this correct, are Configurable and Parameterizable mutally exclusive?
>>>
>>>
>>>
>>Yes.
>>See the Configurable description on
>>http://jakarta.apache.org/avalon/api/index.html and the Parameterizable
>>description on http://jakarta.apache.org/avalon/api/index.html.
>>
>>
>
>Oh. Never knew that.
>I don't like them to be mutually exclusive, there is no way to enforce this
>contract compile-time, even if the contract *is* checked at compile time
>(interface).
>
>
>
>
>>>There are cases inside the phoenix kernel where an object is both
>>>Configurable *AND* Parameterizable.
>>>
>>>
>>>
>>Not that I am aware of .
>>
>>
>
>In the Cocoon lifecycle helpers, this check is not done.
>It could create incompatibilities.
>
>Are there any *strong* reasons why this is necessary?
>
>"
>The Parameterizable interface is a light-weight alternative to the
>Configurable interface. As such, the Parameterizable interface and the
>Configurable interface are not compatible.
>"
>
>seems not really a big reason.
>
>I have alway used Configurable primarly for init time configuration and
>Parametrizable for runtime stuff.
>I don' see the incompatibility.
>
I don't see any "computational" reason why a component could be both
parameterizable and configurable - however, I do see see a logical
inconsitency. We are dealing with the phase in which the information
needed to configuration a component is supplied - Parameterizable is
appropriate in some cases, and Configuration instance is appriopriate in
others. I use both but only in the init time context. For runtime
stuff I use Contextualize.
However - if there are potential conflicts here relative to Cocoon then
the LifecycleHelper should perhaps revert back to the earlier form (i.e.
without checks). But we should also be consitent here in terms of CM/SM.
Should we allow (in LifecycleHelper) a component to implement both
Serviceable and Composable?
Something worth considering is to eliniate and logic concerning if(
something ) else if( somethingelse ) from LifecycleHelper and place this
inside ComponentVerifier. This would enable a more relaxed approach at
runtime, but the ability to do component verification at build time
(assuming we add an ant task to undertake component verification).
Thoughts?
Steve.
>
>--
>Nicola Ken Barozzi [EMAIL PROTECTED]
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
>---------------------------------------------------------------------
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
