1 Reply Latest reply on Jun 5, 2007 2:30 AM by ron_sigal

JBREM-645: Need to cleanup locatorURI parsing

ron_sigal May 1, 2007 4:46 AM

It looks like adhering strictly to RFC 2396 "Uniform Resource Identifiers (URI): Generic Syntax" will entail semantic changes to InvokerLocator. The example I see is the treatment of the path component. By definition, the URI path component begins with "/", but InvokerLocator.getPath() doesn't return the initial "/".

Is it likely that changing getPath() to return the initial "/" would break existing software? If so, a deprecated "classic" mode (settable by system property or static InvokerLocator switch) could be offered in the Remoting 2 InvokerLocator class and eliminated in Remoting 3.

1. Re: JBREM-645: Need to cleanup locatorURI parsing

ron_sigal Jun 5, 2007 2:30 AM (in response to ron_sigal)

By default, InvokerLocator uses the java.net.URI.URI parsing facilities to analyze the input locator string. Optionally, if (1) the static attribute InvokerLocator.useLegacyParsing is set to true or (2) useLegacyParsing is unset and the system property InvokerLocator.LEGACY_PARSING (actual value "legacyParsing") is set to true, the original parsing algorithm will be used instead, with a deprecation warning. (Note that the attribute useLegacyParsing takes precedence.) The difference, as noted above, is that the original algorithm does not include a "/" character at the beginning of a non-null path component.
Actions