Eclipse Checkstyle Plug-in

An additional bug was fixed:
https://sourceforge.net/tracker/?func=detail&atid=559494&aid=1843511&group_id=80344

Also improved error messages on occurance of UnknownHostException and
FileNotFoundException.

Closing as hopefully all issues have been resolved.

> Is there a proxy between your coworkers system and the remote location?
If there is could it possibly be, that the proxy connection settings are
not (properly) configured at your coworkers install (see
Window->Preferences->Internet or so)?

Unfortuntely, those connection settings are restricted from programmers
such that we are unable to view them. Internet Explorer does work properly
connecting to this same hostname and port. The connection should just be a
direct connect to our server as we use a transparent proxy between our
desktops and the Internet.


> Apart from that I see no particular reason why the authentication works
on some (most?) systems but not your coworkers...

I assumed that the condition was specific to WDz 7.0 as those machines
were the ones that experienced the problem; none of the WDz 6.0 machines
experienced this same issue. There are apparently some differences (as
discovered with another plugin) between WDz 7.0 and Eclipse 3.2, but I
don't have any specific information on what those might be.

It sounds like we will be falling back to WDz 6.0 after all (unrelated to
this plugin), but I hope this information helps.

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

Is there a proxy between your coworkers system and the remote location?
If there is could it possibly be, that the proxy connection settings are
not (properly) configured at your coworkers install (see
Window->Preferences->Internet or so)?
The stack trace you posted is just the hint that some system (proxy or
remote host) refuses the connection.
Apart from that I see no particular reason why the authentication works on
some (most?) systems but not your coworkers...

I'll look into giving better user feedback in the other thing you
reported.

I now have a co-worker using WDz7 (RAD7) with plugin Version 4.3.2 that is
experiencing problems I suspect are related to this fix. It does not seem
possible to use a remote configuration type as entering the information
requested (url, config name, description, username, and password) then
pressing "OK" results in this exception:

com.atlassw.tools.eclipse.checkstyle.util.CheckstylePluginException: 401:
Authentication failed
at
com.atlassw.tools.eclipse.checkstyle.util.CheckstylePluginException.rethrow(Unknown
Source)
at
com.atlassw.tools.eclipse.checkstyle.util.CheckstylePluginException.rethrow(Unknown
Source)
at
com.atlassw.tools.eclipse.checkstyle.config.configtypes.RemoteConfigurationType.getCheckstyleConfiguration(Unknown
Source)
at
com.atlassw.tools.eclipse.checkstyle.config.CheckConfigurationWorkingCopy.getCheckstyleConfiguration(Unknown
Source)
at
com.atlassw.tools.eclipse.checkstyle.config.CheckConfigurationWorkingCopy.setLocation(Unknown
Source)
at
com.atlassw.tools.eclipse.checkstyle.config.configtypes.RemoteConfigurationEditor.getEditedWorkingCopy(Unknown
Source)
at
com.atlassw.tools.eclipse.checkstyle.config.gui.CheckConfigurationPropertiesDialog.okPressed(Unknown
Source)
at org.eclipse.jface.dialogs.Dialog.buttonPressed(Unknown Source)
at org.eclipse.jface.dialogs.Dialog$3.widgetSelected(Unknown Source)
at org.eclipse.swt.widgets.TypedListener.handleEvent(Unknown Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.jface.window.Window.runEventLoop(Unknown Source)
at org.eclipse.jface.window.Window.open(Unknown Source)
at
com.atlassw.tools.eclipse.checkstyle.config.gui.CheckConfigurationWorkingSetEditor.addCheckConfig(Unknown
Source)
at
com.atlassw.tools.eclipse.checkstyle.config.gui.CheckConfigurationWorkingSetEditor.access$300(Unknown
Source)
at
com.atlassw.tools.eclipse.checkstyle.config.gui.CheckConfigurationWorkingSetEditor$PageController.widgetSelected(Unknown
Source)
at org.eclipse.swt.widgets.TypedListener.handleEvent(Unknown Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.jface.window.Window.runEventLoop(Unknown Source)
at org.eclipse.jface.window.Window.open(Unknown Source)
at org.eclipse.ui.internal.OpenPreferencesAction.run(Unknown Source)
at org.eclipse.jface.action.Action.runWithEvent(Unknown Source)
at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(Unknown
Source)
at org.eclipse.jface.action.ActionContributionItem.access$2(Unknown
Source)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(Unknown
Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.ui.internal.Workbench.runEventLoop(Unknown Source)
at org.eclipse.ui.internal.Workbench.runUI(Unknown Source)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Unknown
Source)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(Unknown Source)
at org.eclipse.ui.internal.ide.IDEApplication.run(Unknown Source)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(Unknown
Source)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Unknown
Source)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Unknown
Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.invokeFramework(Unknown Source)
at org.eclipse.core.launcher.Main.basicRun(Unknown Source)
at org.eclipse.core.launcher.Main.run(Unknown Source)
at org.eclipse.core.launcher.Main.main(Unknown Source)
Caused by: java.io.IOException: 401: Authentication failed
at
com.atlassw.tools.eclipse.checkstyle.config.configtypes.RemoteConfigurationType.getBytesFromURLConnection(Unknown
Source)
... 51 more


We've ran this a few times and verified that the password works when
making a direct connection to the system in question. We've also tested
the same 4.3.2 release on a WDz6 install with identical settings (url,
username, password, etc.) and everything works fine.

In the process of testing this, I also found a very small potentially
related bug that is present running on WDz6. If an invalid URL is entered,
there is no response from the GUI (other than a short wait while the
connection is attempted) and only an error message "Checkstyle-Plugin:
null" with no stack trace in the error log. I don't think invalid
hostname/port combinations had any error feedback either, but there is at
least a stacktrace in the log for those cases.

I grabbed the new build and everything looks good in the normal (correct
password) case this time. I get IOExceptions logged at info-level, but I
think they are just relating to files that cannot be found during
CheckStyle execution (no stack-traces available to me) and can safely be
ignored.

I'll fully test the behavior on the expired password case near the end of
the month when my password has to be rotated(getting everything reset after
a lockout takes about 30-45min and entials bothering others to get the
account unlocked).

Thank you again for the update.

Uploaded a (hopefully) fixed new snapshot build, same URL.
Pls make sure you use the -clean flag for the first restart, like you
already did before.

To test this change, I shut down RAD/WDz, then removed the old plugins and
feature and replaced them with the new copies. Then, I started the IDE
with the -clean flag.

I'm getting this stack trace:

Warning May 07, 2007 10:53:58.607 java.lang.NullPointerException
encountered while running Checkstyle Builder.
java.lang.NullPointerException
at org.eclipse.core.runtime.Path.append(Unknown Source)
at
com.atlassw.tools.eclipse.checkstyle.config.configtypes.RemoteConfigurationType.writeToCacheFile(RemoteConfigurationType.java:284)
at
com.atlassw.tools.eclipse.checkstyle.config.configtypes.RemoteConfigurationType.getCheckstyleConfiguration(RemoteConfigurationType.java:159)
at
com.atlassw.tools.eclipse.checkstyle.config.CheckConfiguration.getCheckstyleConfiguration(CheckConfiguration.java:205)
at
com.atlassw.tools.eclipse.checkstyle.builder.Auditor.runAudit(Auditor.java:178)
at
com.atlassw.tools.eclipse.checkstyle.builder.CheckstyleBuilder.handleBuildSelection(CheckstyleBuilder.java:343)
at
com.atlassw.tools.eclipse.checkstyle.builder.CheckstyleBuilder.build(CheckstyleBuilder.java:212)
at org.eclipse.core.internal.events.BuildManager$2.run(Unknown Source)
at org.eclipse.core.internal.runtime.InternalPlatform.run(Unknown Source)
at org.eclipse.core.runtime.Platform.run(Unknown Source)
at org.eclipse.core.internal.events.BuildManager.basicBuild(Unknown
Source)
at org.eclipse.core.internal.events.BuildManager.basicBuild(Unknown
Source)
at org.eclipse.core.internal.events.BuildManager.basicBuild(Unknown
Source)
at org.eclipse.core.internal.events.BuildManager$1.run(Unknown Source)
at org.eclipse.core.internal.runtime.InternalPlatform.run(Unknown Source)
at org.eclipse.core.runtime.Platform.run(Unknown Source)
at org.eclipse.core.internal.events.BuildManager.basicBuild(Unknown
Source)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(Unknown
Source)
at org.eclipse.core.internal.events.BuildManager.build(Unknown Source)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(Unknown Source)
at org.eclipse.core.internal.events.AutoBuildJob.run(Unknown Source)
at org.eclipse.core.internal.jobs.Worker.run(Unknown Source)


Error May 07, 2007 13:00:21.280 Unhandled event loop exception


java.lang.NullPointerException
at org.eclipse.core.runtime.Path.append(Unknown Source)
at
com.atlassw.tools.eclipse.checkstyle.config.configtypes.RemoteConfigurationType.writeToCacheFile(RemoteConfigurationType.java:284)
at
com.atlassw.tools.eclipse.checkstyle.config.configtypes.RemoteConfigurationType.getCheckstyleConfiguration(RemoteConfigurationType.java:159)
at
com.atlassw.tools.eclipse.checkstyle.config.CheckConfigurationWorkingCopy.getCheckstyleConfiguration(CheckConfigurationWorkingCopy.java:420)
at
com.atlassw.tools.eclipse.checkstyle.config.gui.CheckConfigurationWorkingSetEditor.configureCheckConfig(CheckConfigurationWorkingSetEditor.java:515)
at
com.atlassw.tools.eclipse.checkstyle.config.gui.CheckConfigurationWorkingSetEditor.access$800(CheckConfigurationWorkingSetEditor.java:77)
at
com.atlassw.tools.eclipse.checkstyle.config.gui.CheckConfigurationWorkingSetEditor$PageController.widgetSelected(CheckConfigurationWorkingSetEditor.java:382)
at org.eclipse.swt.widgets.TypedListener.handleEvent(Unknown Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.jface.window.Window.runEventLoop(Unknown Source)
at org.eclipse.jface.window.Window.open(Unknown Source)
at org.eclipse.ui.internal.OpenPreferencesAction.run(Unknown Source)
at org.eclipse.jface.action.Action.runWithEvent(Unknown Source)
at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(Unknown
Source)
at org.eclipse.jface.action.ActionContributionItem.access$2(Unknown
Source)
at org.eclipse.jface.action.ActionContributionItem$7.handleEvent(Unknown
Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.ui.internal.Workbench.runEventLoop(Unknown Source)
at org.eclipse.ui.internal.Workbench.runUI(Unknown Source)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Unknown
Source)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(Unknown Source)
at org.eclipse.ui.internal.ide.IDEApplication.run(Unknown Source)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(Unknown
Source)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
at java.lang.reflect.Method.invoke(Method.java:391)
at org.eclipse.core.launcher.Main.basicRun(Main.java:185)
at org.eclipse.core.launcher.Main.run(Main.java:704)
at org.eclipse.core.launcher.Main.main(Main.java:688)



The earliest stage I see problems is when I attempt to go into the
configuration choice off of window -> preferences -> checkstyle or if I
press "okay" off the properties dialog located at the same place. I get
this error when using a valid username/password, but the 401 error message
also sticks if I enter a bad one first, then change it.

Snapshot build uploaded to:
http://eclipse-cs.sf.net/com.atlassw.tools.eclipse.checkstyle_4.3.1-bin.zip

I'd gladly test such a snapshot release, but we have a really restrictive
white-list only firewall and a mail server that refuses attachments, so
getting the snapshot might be a pain. Could you upload the snapshot to a
location on sourceforge where I could download it?
(http://eclipse-cs.sourceforge.net works too). If not, I can just check
once the next release comes out.

Implementation has been greatly improved to reduce unnecessary access to
the remote location.

The problem with HttpURLConnection has been worked around by locally
setting the "http.maxRedirects" proeprty to 2. The previous value of this
property is restored afterwards.

Would you like to test the current state before it gets released. If so
please drop me a note and I'll build a snapshot release.

After digging a little deeper it seems that URLConnection, more
specifically java.net.HttpURLConnection, is the main culprit, as it retries
on its own up to a configured amount of times.
This amount is controlled by the "http.maxRedirects" system property,
whose default is 20.

This means for each connection I try to establish in my code,
java.net.HttpURLConnection does 20 retries internally on its own.

A simple workaround until a proper solution is implemented would be to
lower the described system property to a value which is acceptable to your
server.
You can do this by passing the value as a -D command line argument to
Eclipse,
for instance:
../eclipse.exe -vmargs -Dhttp.maxRedirects=1

Hmm, this won't be a easy fix since connections to the target URL are
opened for various reasons (loading of the config file, getting
modification timestamp, trying to load additional properties files) - these
might be the retries you see.
On top of that the implementation is currently not quite efficient, since
the plugin loads the configuration file more often than actually needed.