perfsonar development work

[Roman Lapacz <>]

Tsompanidis Ilias wrote:
> Loukik Kudarimoti wrote:
> > Hi guys,
> >
> > I just spent quite a while trying to debug a problem where in I was 
> > unable to get responses from SQL MA. Turns out, its all because of 
> > new line characters in xml tag contents which were introduced either 
> > in the store or in the request message.
> >
> > When any part of the service implementation is trying to compare two 
> > strings - one hardcoded within the implementation (such as eventType 
> > value) and the second one coming from the xml message (via the 
> > Message bean), even if the strings are similar except for new-line 
> > characters, the checks fail. This definitely needs to be taken care of.
> >
> > Initially I thought that we could take care of this at the Message 
> > bean level (by stripping empty strings around a text). But I am not 
> > 100% sure of the outcome. I am not sure because for some strings, 
> > white spaces *between the text* are important (command line mp for 
> > example). Jason, what do you think? I found out the String.trim() 
> > method will remove leading and trailing white spaces but not sure 
> > about white lines?
> >
> > Any thoughts anybody? This bug can cause problems because the 
> > configurations at least are created by the users and its difficult to 
> > get them to remove such white spaces and new lines. It affects SQL MA 
> > for sure and maybe RRD MA (Ilias?)
> RRDMA is affected too. The easiest way to see it is to test the Echo 
> functionality :
> "http://schemas.perfsonar.net/tools/admin/echo/2.0   "
> instead of the working event_type
> "http://schemas.perfsonar.net/tools/admin/echo/2.0"; .


Fixed (see svn log r2250). So far only in the trunk.


Roman

> One way to come around it would be using regular expression match, 
> instead of .equals(). In perl it would be something like:
> $string =~ m/something_interesting/
>
> I know that java has a reg exp engine of equal strength to perl's. 
> Maybe it could come in handy.
>
> Ilias
>
> > Loukik.