Adding WaffleInfo class

[ryantxu]

Like #14, but hopefully smaller and easier to digest. This just adds the helper class and a test to exercise it. I'll post a servlet to get this info after this gets in.

What is the expected behavior when you call IWindowsAuthProvider.getDomains() when you are in a workgroup? For me this throws an exception:

<domains>
<exception class="com.sun.jna.platform.win32.Win32Exception"> 
<message>The interface is unknown.</message> 
<trace>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(Unknown Source) at
waffle.util.WaffleInfo.getAuthProviderInfo(Unknown Source) at 
waffle.util.WaffleInfo.getWaffleInfo(Unknown Source) at 
waffle.util.WaffleInfo.main(Unknown Source) 
</trace> 
</exception> 
</domains>

[dblock]

Regarding getDomains: I think the expected behavior was to throw. The error is not helpful, but that's Windows :) You should basically first find out whether you have a machine in a domain, then you can invoke getDomains. This can be done by checking Netapi32Util.getJoinStatus() != LMJoin.NETSETUP_JOIN_STATUS.NetSetupDomainName via JNA.

[dblock]

I am going to nitpick, but the rest of the code tries to use a convention where there's a space after if and between !=, so if (version != null).

[dblock]

I only have one problem with this implementation: it wraps a lot of calls in a try/catch exception. None of this code is expected to fail (the domain one can be checked as I mentioned above). So why try to wrap the exception within the info class at all (makes sense in the main of course).

I'd be happy to merge without that, but of course I'd like to hear the counterarguments.

[dblock]

This also needs an update to CHANGELOG, please.

[ryantxu]

I'll clean some things up and add a note to the CHANGELOG later tonight...

So why try to wrap the exception within the info class at all

I originally wrote this while trying to debug problems that did throw exceptions and wanted to be able to collect the exceptions and ask a reasonable question... with the 1.5 branch, it no longer throws an exception, but very easily could if the wrong JNA .jar files are included

This is why I think it should catch the exceptions and present them in the XML rather then fail entirely. (Though I'm really fine either way)

[dblock]

Lets not catch them, or at least start with that. Don't you get a stack trace if you're missing or have the wrong JAR?

Maybe a demo or a diagnostics app can do the catching?

[ryantxu]

Hopefully everything looks good now -- let me know if anything else should change

[dblock]

Did you mean to leave this one here?

[ryantxu]

Yes -- this is expected to throw an error when the name you pass in is not found. There is even a test that makes sure it throws (and catches) an exception when you lookup an unknown name

[dblock]

I merged this, thank you.