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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
