Add Debug Helper Classes

[ryantxu]

This adds a helper class that collects system information and lets you see see it within a servlet

[hazendaz]

Line ending issues seem to be a common problem! I'm using github for windows and just found information about it proposing normalizing line endings being set on. Maybe that will fix the issue. I have this problem everything I upload something. Looks good until the commit is hit...

[ryantxu]

Line ending issues seem to be a common problem!

see #16

[hazendaz]

Ryan,

I tried to pull your code over into my version and play around with it. I ran findbugs / pmd against it which lead me to clean some things up. Specifically, the catch statements were catching throwable. When I corrected these to be DOMException, the domain piece fails with "com.sun.jna.platform.win32.Win32Exception: The interface is unknown.". Now maybe this is my fault as I cleaned up various other items for findbugs / pmd throwout. Can you fix your exceptions to DOMException and let me know if you run into the same error?

Also, I didn't see test case for the servlet code. Maybe I missed it. If not, shouldn't there be? Since I'm on test cases, I've got all of them throughout the project updated to full junit 4 type using annotation (no pull request yet). That said, they all will be changing from using extends TestCase to stand alone classes using @test, @before, @after annotations.

Thanks,

Jeremy

[hazendaz]

Here is the stack trace of what I'm seeing in the domain piece. Looks like this is an issue in JNA potentially since that is where the issue occurs.

com.sun.jna.platform.win32.Win32Exception: The interface is unknown.
at com.sun.jna.platform.win32.Netapi32Util.getDomainTrusts(Netapi32Util.java:625)
at com.sun.jna.platform.win32.Netapi32Util.getDomainTrusts(Netapi32Util.java:609)
at waffle.windows.auth.impl.WindowsAuthProviderImpl.getDomains(WindowsAuthProviderImpl.java:145)
at waffle.util.WaffleInfo.getAuthProviderInfo(WaffleInfo.java:156)
at waffle.util.WaffleInfo.getSystemInfo(WaffleInfo.java:81)
at waffle.util.WaffleInfo.main(WaffleInfo.java:226)

[ryantxu]

Yes, the reason I added the stack trace information is that I am getting errors on every system I run on. The errors a different on different systems with different workgroup/domain settings.

I'll post more information later, but for sure there is a stack trace when you call IWindowsAuthProvider.getDomains() from a computer that is not on a domain

[hazendaz]

Thanks. I didn't think I messed anything up but wanted to be sure. Interesting enough, my machine says it is part of a domain (myself that is). Anyway, two suggestions based on my learning experience... 1) Catch only exceptions that are thrown not throwable as that hides other issues and catches runtime exceptions that shouldn't be caught like null pointer exception. In this case, DOMException on all of them in waffleInfo. On the last one, need to have Win32Exception as well for this above stack trace. That seems to allow everything to work. For the waffle info servlet, the exceptions would be DOMException and TransformerException. 2) Although "main" is nice in waffleInfo, probably should remove it as junit test case should handle running tests rather than putting them directly in the code. I don't see any other mains throughout the project so this seems like it would make it in line with everything else.

Anyway, this looks very promising in that it appears to sort of replace the first demo it is attached to for the most part.

[ryantxu]

1. Catch only exceptions that are thrown not throwable as that hides other issues

Usually I agree... this case is kind of special though. I want to return as much information is possible even when underlying system fails. My motivation for adding this class was to help debug systems that were behaving differently and failing in different ways. (everything works now, so its not an issue for me anymore)

2. Although "main" is nice in waffleInfo, probably should remove

My thought with adding the main() is to let you check status with:

java -cp xxxx waffle.util.WaffleInfo

I find this kind of thing useful when on client sites with limited tools.

It may be overkill, but we could even set the manifest Main-Class so that double clicking the .jar would spit out the debug information.

It would be great to have a single test that (non-developers) can run that would collect as much debug info as possible. This can include stuff like the registry settings for Kerberose logging and the output from setspn

[dblock]

I am going to close this for now, but I welcome a pull request that does the functionality here.

On the comment of hiding errors, I don't want something that has generic catch-alls. There's no reason for the overall system to fail and we want to find and fix those errors rather than hide them.

This most definitely needs some docs on what to do with this. Thx.