[jira] Commented: (BEEHIVE-254) Control Property Constraint Validator does not validate FilePath property correctly

["Hoi Lam (JIRA)" <be...@incubator.apache.org>]

     [ http://issues.apache.org/jira/browse/BEEHIVE-254?page=comments#action_58984 ]
     
Hoi Lam commented on BEEHIVE-254:
---------------------------------

The following comments were provided by Lawrence Jones:

> A few comments on the apparent error (sorry for the length but I 
> wanted to get everything in):
> 
> 1. The error message indicates that it objects if the file does not exist.
> This was _not_ what I thought the purpose of that annotation was - my 
> understanding was that the FilePath meta-annotation's sole purpose was 
> to insist that the value to which it referred consisted of a _possible_ path.
> Whether it's an error if that file exists or not seems like it should 
> be left up to that control's checker to me. I could be wrong, but I'd 
> like to discuss - either way I think it is useful for us to have a 
> meta-annotation which does have the "check whether this path is 
> consistent with a file- path on my current system but don't check 
> whether that file actually exists" functionality even if this is not 
> it - you might for instance want an annotation for a file path to which you plan to write at runtime.
> 
> 2. Interpretation of the phrase " this path is consistent with a 
> file-path on my current system above." This could mean we always 
> insist on Unix separators ("/") and Windows style paths would lead to 
> an error even on Windows (I think this is what we did in 8.1 - for a 
> discussion of why we never had problems with e.g. "C:" drives at 
> beginning of the path see #3 below). Or we could insist on Windows 
> style paths on Windows machines and Unix style paths on Unix machines. 
> Or we could accept either (and internally convert) on either platform 
> (not sure what happens if you try and interpret "C:" on a Unix 
> platform). The reason I mention this is that I have a CR open against 
> me (CR210564) on this subject. I had planned on replying to this CR by 
> simply saying "the annotation has the @FilePath meta-annotation on it 
> - I obey whatever its rules are". The advantage of the first and third 
> options over the second are that if you move the control from one 
> platform to another you don't have to re-write the annotation. The 
> advantage of the first over the third is a) consistency across all 
> apps b) not having people mistakenly writing real absolute paths i.e. 
> those starting with "C:\..." which i) have trouble being interpreted 
> on Unix and ii) can refer to something outside the current project/app 
> which may not be there at runtime. Hence I endorse the first option.
> 
> 3. You mention fixing the annotation for relative paths. Here we get a 
> bit mixed up in interpretation of the phrase "absolute path" or 
> "relative path". The WSDL annotation in Service Control has been set 
> up to be consistent with 8.1. In 8.1 the phrase "absolute path" is 
> misleading. It appears that in 8.1 the path member was always a Unix 
> style path (even on
> Windows) and that the phrase "absolute path" simply referred to paths 
> which started with "/". An "absolute path" was interpreted as relative 
> to the project directory of the file the annotation was in (for 9.0 
> I'm assuming the project _source_ directory), whereas a "relative 
> path" (one that did not begin with "/") was relative to the parent 
> directory of the file in which the annotation was defined. This 
> interpretation is not obvious and clearly does not allow for "real" 
> absolute paths or indeed reference to anything outside of the project 
> itself (you were also banned from using lots of "../"'s to go outside 
> the project dir) . In 8.1 this was seen as a strength as the app (or 
> project) could be moved to a different directory at any time without 
> needing to edit that file. This interpretation is not necessarily what 
> one might think of immediately on being told that the annotation is a 
> "file path" (and especially of the phrase "absolute path") and this is 
> one of the reasons why I think it's a mistake for the meta-annotation to insist on existence of the file.


> Control Property Constraint Validator does not validate FilePath property correctly
> -----------------------------------------------------------------------------------
>
>          Key: BEEHIVE-254
>          URL: http://issues.apache.org/jira/browse/BEEHIVE-254
>      Project: Beehive
>         Type: Bug
>   Components: Controls
>     Versions: V1Beta
>  Environment: Windows XP
>     Reporter: Hoi Lam
>     Assignee: Hoi Lam
>      Fix For: V1Beta

>
> The control constraint validator does not validate the FilePath property correctly when the value represents a relative path.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira