You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@realityforge.org> on 2003/04/06 05:35:37 UTC
[phoenix] isFeasiblyValid
Hi Peter,
Can you tell me the reasoning behind isFeasiblyValid - What was original
intention and does it still hold valid? Personally I would think that we
would only ever want to deploy an application which had 100% valid
configuration (Or as valid as we could test for). isFeasiblyValid always
returns true anyways so effectively at this stage it is a noop and validation
occurs at runtime.
I would prefer to do it during deployment. Any objections?
--
Cheers,
Peter Donald
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [phoenix] isFeasiblyValid
Posted by Peter Royal <pr...@apache.org>.
On Saturday, April 5, 2003, at 10:35 PM, Peter Donald wrote:
> Can you tell me the reasoning behind isFeasiblyValid - What was
> original
> intention and does it still hold valid? Personally I would think that
> we
> would only ever want to deploy an application which had 100% valid
> configuration (Or as valid as we could test for). isFeasiblyValid
> always
> returns true anyways so effectively at this stage it is a noop and
> validation
> occurs at runtime.
>
> I would prefer to do it during deployment. Any objections?
No objections to removing. It was an idea that never materialized.
The relax-ng validator that Phoenix is using supports feasibility
validation. I'm not sure if this is exposed via the JARV implementation
though. This was to work in conjunction with the
FileSystemPersistentConfigurationRepository, where the configuration
that was in the SAR would only be partial (and thus feasibly valid),
but when combined with the configuration from the repo, it would form a
complete config.
Thus there would be two phases of validation:
(1) Upon retrieving from the SAR, checking feasibility
and
(2) Upon getting from the repo, before passing to the block.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org