Thoughts on system properties for startup
Cantor, Scott
cantor.2 at osu.edu
Wed Jun 18 17:02:55 EDT 2014
On 6/18/14, 4:43 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>>
>> I think you end up there if you set idp.home to a path, but can't prefix
>> the uses of idp.home with an extra slash. I'd rather avoid that by
>>setting
>> the necessary properties in idp.properties that handle the cases that
>> aren't working. If we need idp.webflow.base=file:///${idp.home}/conf I'd
>> rather just do that.
>
>I don't think the "file:///" scheme prefix helps.
Yes, it's the opposite, actually, you just leave the slashes out:
file:${idp.home}/flows
But since that would still be a one-off expression, it's still as you say,
we can't just reuse an existing property.
>I think I am in agreement with you, the purpose of
>${idp.home.normalized} is just for the userFlowRegistry base-path,
>that's it. Maybe it should be renamed {$idp.home.webFlow.basePath} if
>that helps.
Yes, I prefer something along that line.
> The reason for that specific property is for string
>comparison of the "file path" to the "base path" when mapping flow IDs
>to flow definition file paths. The "file path" is returned by
>Resource.getPath(), and both the URLResource and FileSytemResource
>call StringUtils.cleanPath() [1] which converts Windows separators "\"
>to slashes "/". Consequently, the "base path" must also convert "\" to
>"/". So, call it what we want, but I think we need to do the
>conversion of the "base path".
Yes, but the slashes are really just a documentation thing. We just
document that no Windows deployer should be using backslashes anywhere,
ever. I believe that resolves that one specific issue.
-- Scott
More information about the dev
mailing list