Hi all, Just a quick announcement on this thread to let you know that I committed Jim Marshall's changes to the Java client. These changes reflect the work he did to remove message escaping code as discussed on this thread. They also remove the dependency on log4j in favor of the Java internal logging framework. Thanks Jim! The Java client is a better solution now, due to your efforts.
John > -----Original Message----- > From: Jim Marshall [mailto:jim.marsh...@wbemsolutions.com] > Sent: Tuesday, September 20, 2011 2:20 PM > To: John Calcote > Cc: openslp-us...@lists.sourceforge.net > Subject: Re: [Openslp-users] Attribute values with comma's treated differently > between Java and C > > John Calcote wrote: > > > > That's exactly what I meant. In fact, there's no other way to do it > > when using slptool, as it accepts full element lists on the command > > line - if the user doesn't escape strings manually when passing the > > list, how will any of the code know which commas are element separators and > which are embedded? > Yes, your previous follow-up clarifying what you meant made that evident. I > agree with what you are saying here. > > > > ... > > > > The problem appears to be that the Java API takes more upon itself > > than it should. > Yes the Java API escapes all strings, see ServiceLocationAttribute.escapeString. > It seems the fix is to remove the calls to this function (and the associated > unEscape function) and just leave that function exposed for applications to call > themselves. > > Jim > > > >>> On the other hand, receiving code must be careful to parse lists > >>> into elements before decoding them so that the element list can be > >>> parsed properly. If decoding is done first, then the receiver won't > >>> know which commas are meant to separate elements, and which ones are > >>> part of data strings. > >> I think the cause of my concern is the following statement from > >> section 5 > >> > >> "The<attr-list>, if present, MUST be scanned prior to evaluation for > >> all occurrences of the escape character `\'. Reserved characters > >> MUST be escaped (other characters MUST NOT be escaped). All escaped > >> characters must be restored to their value before attempting string > >> matching." > > Yes, this is a sore point and one of those places where the slp > > designers probably disagreed and missed the lack of alignment in the final > analysis. > > This paragraph is not even self-consistent. Consider: The subject is > > "<attr-list>", which by definition contains characters that must not > > be escaped, but which are reserved characters (e.g., the element > > separator - comma). In other words, it must contain unescaped reserved > > characters, but it also must be processed at this point to escape all reserved > characters. > > The only reasonable way to manage this is to have<attr-list> be fully > > escaped before being processed at this level. > > > >> This seems to imply that the server and the client have to scan the > >> list > > and > >> convert escaped/reserved characters, at least the '\' character, but > >> I > > think the > >> second sentence indicates all reserved characters MUST be dealt with. > >> It > > doesn't > >> appear OpenSLP is doing that. > > A very literal interpretation that also works would have the caller > > escaping only those characters that make the caller's intent unclear - > > embedded list element separators. Then the slp UA would escape the > > rest. That seems wrong in several ways (to me). > > > > I think we need to remove the internal escaping code from the Java API > > and provide escaping functions in the public interface, like the C API does. > > > > Regards, > > John > > > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Openslp-devel mailing list Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
