Re: Online XML validation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Online XML validation

Mikael Carneholm-3
(Kohsuke: assuming the previous mail got stuck in your spam filter :) )

Hi,

I finally got some spare time to fix the issue mentioned here: https://hudson.dev.java.net/servlets/ReadMsg?listName=users&msgNo=5530

The fix involves a patch for hudson/main/core/src/main/java
/hudson/tasks/junit/SuiteResult.java (just a few lines), and a new class called XMLEntityResolver in the same package. (See attachement)

The fix is tested and is working fine on my laptop when I disconnect it from the network, but since I haven't yet figured out how to emulate a network outage in a unit test there's no test code to prove it - you'll have to try it out for yourself, I guess...

Comments?

Ciao,
Mikael


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

mikaelc-testng-resolver.patch (1K) Download Attachment
XMLEntityResolver.java (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Online XML validation

Kohsuke Kawaguchi
Administrator
Thanks. My apologies that I couldn't reply to you in time. I did see
your e-mail in the inbox but between traveling and preparation for
JavaPolis, I didn't get to it.

I just committed this patch toward 1.161. One question though ---
where does Hudson find testng-1.0.dtd? I mean, I don't think we are
putting it in the classpath.

Should I put it in hudson-core.jar? How did you test it? By running
this code stand-alone on TestNG?

2007/12/14, Mikael Carneholm <[hidden email]>:

> (Kohsuke: assuming the previous mail got stuck in your spam filter :) )
>
> Hi,
>
> I finally got some spare time to fix the issue mentioned here:
> https://hudson.dev.java.net/servlets/ReadMsg?listName=users&msgNo=5530
>
> The fix involves a patch for hudson/main/core/src/main/java
> /hudson/tasks/junit/SuiteResult.java (just a few lines),
> and a new class called XMLEntityResolver in the same package. (See
> attachement)
>
> The fix is tested and is working fine on my laptop when I disconnect it from
> the network, but since I haven't yet figured out how to emulate a network
> outage in a unit test there's no test code to prove it - you'll have to try
> it out for yourself, I guess...
>
> Comments?
>
>  Ciao,
> Mikael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Online XML validation

Mikael Carneholm-3
In reply to this post by Mikael Carneholm-3
> On Sat, 15 Dec 2007 18:21:07 -0800, Kohsuke Kawaguchi wrote:
>I just committed this patch toward 1.161. One question though ---
>where does Hudson find testng-1.0.dtd? I mean, I don't think we are
>putting it in the classpath.

This was one of the things I thought about for some time, but for the time being I left it for each installation to discover where to look for it (when you turn on the FINE log level, you can see where it's looking) With my local tomcat installation, it works when you're putting the .dtd in $TOMCAT_HOME/common/classes

My first idea was to include the .dtd in the hudson/tasks/junit package, but I had some doubts about the licensing implications so I avoided that until I have a better understanding of that area. Furthermore, we would then have to add new .dtd:s whenever TestNG changed the format, and that would probably
cause some lag in the future that wouldn't be appreciated by the users.

A future improvement could be to add the possibility to make it configurable (eg reading a system property like "dtd.lookup.path" or something like that), but for now I leave it as it is.

>How did you test it? By running
>this code stand-alone on TestNG?

I have an example project that I used to test it, but it bundles testng-5.6-jdk15.jar (it's built with Ant) and I didn't want to post a 750K .zip to the mailinglist :) I can send it to you off-list, if you want it?

Regards,
Mikael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Online XML validation

Kohsuke Kawaguchi
Administrator
Mikael Carneholm wrote:

>> On Sat, 15 Dec 2007 18:21:07 -0800, Kohsuke Kawaguchi wrote:
>>I just committed this patch toward 1.161. One question though ---
>>where does Hudson find testng-1.0.dtd? I mean, I don't think we are
>>putting it in the classpath.
>
> This was one of the things I thought about for some time, but for the time
> being I left it for each installation to discover where to look for it (when
> you turn on the FINE log level, you can see where it's looking) With my
> local tomcat installation, it works when you're putting the .dtd in
> $TOMCAT_HOME/common/classes
 >
> My first idea was to include the .dtd in the hudson/tasks/junit package, but
> I had some doubts about the licensing implications so I avoided that until I
> have a better understanding of that area. Furthermore, we would then have to
> add new .dtd:s whenever TestNG changed the format, and that would
> probably cause
> some lag in the future that wouldn't be appreciated by the users.

Hmm, but without bundling it, this is not going to fix the problem for
users.

I think we should really bundle DTD in Hudson. The file is licensed
under ASL, so license-wise I don't see any problem. The file is
versioned, too, so if a new drastic change comes along, it will have a
different version number and so we should be safe.

Also, we run the parser in the non-validating mode, so most of the
changes in DTD shouldn't stop the processing even if the XML report file
  evolves beyond our copy.

Finally, the file isn't changing rapidly, looking at its history. Try

 svn log http://testng.googlecode.com/svn/trunk/src/main/testng-1.0.dtd


> A future improvement could be to add the possibility to make it configurable
> (eg reading a system property like "dtd.lookup.path" or something like
> that), but for now I leave it as it is.

Ah, I hate configuration entries :-)

I think things should just work...


>>How did you test it? By running
>>this code stand-alone on TestNG?
>
> I have an example project that I used to test it, but it bundles
> testng-5.6-jdk15.jar (it's built with Ant) and I didn't want to post a 750K
> .zip to the mailinglist :) I can send it to you off-list, if you want it?

No, it's just that I saw that this wouldn't work unless you have
testng-1.0.dtd somewhere, so I thought maybe you run it in an
environment where this DTD is provided by the environment. I didn't
realize you put that in $TOMCAT_HOME/common/classes.


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


smime.p7s (4K) Download Attachment
Loading...