Unable to go further with Bug 254831

Posted in open-source, update on June 11, 2009 by nkhan26

After more testing, I’m still at the same par that I was for a few weeks now. Debug points are being hit, except at the exact location before the error. I am unable to determine where exactly the error coming from, and will be selecting a new bug to work on due to the complexity of this bug, following Jordan’s advice. There is also a similar bug Bug 251637, which gives basically the same problem. I also noticed that one of my classmate Tommy Lo, is listed in the bug report list. However, it seems that he is not working on this bug currently. I will post a bugzilla report and move on to a different bug.

Bug 254831 Code Location

Posted in open-source, update on May 27, 2009 by nkhan26

After more debugging, it is safe to say that the files related to bug 254831 is located in the “org.eclipse.wst.server.ui” package. There are more file related to this bug within this package, especially in the “org.eclipse.wst.server.ui.internal.wizard” package.

As the previous post mentions about the wizard startup, through more debugging, I was able to locate file relating to the wizard itself. These files are located primarily in the “org.eclipse.wst.server.ui.internal.wizard” package and the “org.eclipse.wst.server.ui.wizard” package. After a new wizard is started, it goes in to the “TaskWizard.java” class, which is directly related to the “WizardFragment.java” class. These two classes are called on repeatedly, as there are many iterations in the “TaskWizard” class that links them together. For example:

private void addSubWizardFragments(WizardFragment fragment, List<WizardFragment> list) {
    Iterator iterator = fragment.getChildFragments().iterator();
    while (iterator.hasNext()) {
       WizardFragment child = (WizardFragment) iterator.next();
       addSubWizardFragments(child, list);

After running through loops between the TaskWizard andWizardFragment class, it goes to the “TaskWizardPage.java” class, and then to a “TomcatRuntimeWizard.class” file, that displays “source not found”. This occurs in more than one occasion.

Continuing the wizard, after selecting “Download & Install” and selecting “Agree”, it goes to TaskWizard.java class then to the same “TomcatRuntimeWizard.class”.

When the user clicks “Finish” to the agreement to start the install, it then iterates through the “TaskWizard.java” and the “WizardFragment.java” classes. It then goes to the same “TomcatRuntimeWizard.class” file that displays the error.

After completing this and continuing with the wizard, when the user selects the folder to install the Tomcat files to it once again iterates through the “TaskWizard.java” and the “WizardFragment.java” classes, and touches the “TaskWizardPage.java” class. It also displays the “TomcatRuntimeWizard.class” file.

When the user selects “OK” after selecting the folder, the same action as mentioned above occurs. This is where my debugger freezes, which is around the point the error occurs. These findings gives me an understanding of where the files relating to the wizard is located. Hopefully, playing around with these files can help lead to a solution.

Debugging & Bug 254831

Posted in open-source, update on May 24, 2009 by nkhan26

I’m still trying to source the location of bug 254831. I have posted the errors recieved on the bug page for bug 254831. In debugging and trying to locate breakpoints, I was able to locate where the new server wizard is called, and where servers are called from, but still unable to locate the primary code related to the bug.

In debug mode, when the “Add New Server” wizard is started, it is being called from the “NewServerWizard.java” class in the “org.eclipse.wst.server.ui” cvs package. The actual package is “org.eclipse.wst.server.ui.internal”, which relates to the servers. After this class, it then goes into the “NewServerWizardAction.java” class, followed by the “LaunchWizardAction.java” class, both located in the “org.eclipse.wst.server.ui.internal.actions” package.

After these, when someone selects a server from the list, for example Apache Tomcat v6.0″, it then calls the “Server.java” class in the “org.eclipse.wst.servercore.internal” package. This is then followed by the “ServerType.java” class in the same package. After these, I’m unable to hit further breakpoints, to locate just before the error message.

The findings so far are important, as I have a general idea of where to start from. I have to continue check out packages, to locate more breakpoint closer to the errors. I will update when more findings are found.

Testing Scenarios with Bug 254831

Posted in open-source, update on May 20, 2009 by nkhan26

I’ve tested various scenarios with bug 254831. First of all I tested the scenarios in the “Web” perspective, then in the “J2EE” perspective. Both revealed same results. Then I tested using different servers. I received error message for all Apache Tomcat servers, but the error message were different for each. As mentioned in the previous post, the error mesage appears when using the “Download & Install” method in the “Add New Server” wizard. The error messages were of the same type, but pointed to different folder.

Trying to Download and Install “Apache Tomcat v6.0”, the error message displays:

The Tomcat installation directory is not valid. It is missing expected file or
folder lib/jasper-el.jar.

Trying to Download and Install “Apache Tomcat v5.5”, the error message displays:

The Tomcat installation directory is not valid. It is missing expected file or
folder common/il8n.

Trying to Download and Install “Apache Tomcat v5.0”, the error message displays:

The Tomcat installation directory is not valid. It is missing expected file or
folder common/lib/servlet-api.jar.

Trying to Download and Install “Apache Tomcat v4.1”, the error message displays:

The Tomcat installation directory is not valid. It is missing expected file or
folder lib/naming-factor.jar.

Trying to Download and Install “Apache Tomcat v4.0”, the error message displays:

The Tomcat installation directory is not valid. It is missing expected file or
folder lib/naming-factor.jar.

As shown, the error occurs for each version of the server, but the directory varies for all. For the remaing servers on the list in the wizard (for example, IBM), you have to manually download them yourself, and point the wizard towards that specific folder. The “Download & Install” feature is only available for the Apache servers, so this cannot be specific error cannot be tested this way with other servers.

For all servers, including Apache, when downloading them manually, and pointing the wizard towards that folder, the server wizard completes successfully. Only when using the “Download & Install” feature, the wizard does not complete. More research into why the different directories is needed, as well as some debugging. I will update when more information is found.

Replication of Bug 254831

Posted in open-source, update on May 19, 2009 by nkhan26

As mentioned earlier, the bug I’ve chosen to work with is bug 254831. It is a P3 WTP ServerTools bug. The steps below are how to replicate this bug successfully.

The first step is to open the “Web” perspective. This is found in Window>Open Perspective>Other>Web


Then in the “Servers” tab at the bottom right, right click in and add new server, which will initiliaze the “Add New Server Wizard”.


Select Apache>Tomcat 6.0 Server and click “Next”. Then select “Download & Install” in the new window.


Choose an empty directory/create a new directory for it to install the files into.


Upon selecting okay, an error message occurs.


The error message says:

The Tomcat installation directory is not valid. It is missing expected file or
folder lib/jasper-el.jar.

The wizard then gives the user the options of “Back” or “Cancel”, even though the files were downloaded into the directory selected.

Files were saves

Files were saved

This should not happen, and I will start testing different scenarios in different perspectives, with different servers to see the behavior. I will update with the results of my findings.

When I published this bug replication, I forgot to mention at that time that there is a workaround. I have stopped working on this bug for quite some time now, but forgot to talk about a work around as some people are requesting.

When you click “Download and Install”, the files actually downloads and install to the directory that you point the installation towards. After you get the error message mentioned above, cancel the wizard and start the “Add New Server” wizard again. This time click “Browse” instead of “Download and Install”. Find the directory that Tomcat was downloaded to and click “OK”. It will now detect the server correctly, and you can complete the wizard.

DPS911 – Chosen Bug 254831

Posted in open-source, update on May 19, 2009 by nkhan26

One of the bugs I’ve chosen to work on for DPS911 is bug 254831. It is an error message that occurs when using the “Add New Server” wizard. I will be posting more information and replications soon.

Debugging the Fix

Posted in open-source, update on April 6, 2009 by nkhan26

I’ve created and uploaded a patch for bug 227760, and also a wiki page.

Debugging with the fix, signals a slight different behaviour in the way classes are called upon. Since the

if (!ServerUIPlugin.saveEditors())

is not being used anymore, the classes are called a bit differently. Previously, you started at the “start(server, launchMode, shell);” in StartACtion.java, before going to the “if” condition mentioned above. This condition led to the “ServerUIPlugin.java” class, then to “Server.java” class breifly, then to the “ServerUIPreferences.java” class (see post: Bug 227760 Source Code Location for more details). When this was was implemented, the “ServerUIPlugin.java” class led to various preference classes being called upon, before the first prompt is received. This being is being carried out in the “SaveEditors()” method:

public static boolean saveEditors() {
        byte b = ServerUIPlugin.getPreferences().getSaveEditors();
        if (b == ServerUIPreferences.SAVE_EDITORS_NEVER)
            return true;
        return ServerUIPlugin.getInstance().getWorkbench().saveAllEditors(b == ServerUIPreferences.SAVE_EDITORS_PROMPT);

This then led to the return statement, before finishing the “start(IServer server, String launchMode, final Shell shell)” method in “StartAction.java”. This then led from the “StartAction.java” class, to the “Server.java” class, then to various preferences class (like EclipsePreference.class), then to “handleStatus(IStatus status, Object source)” method in the “SaveScopeResourceHandler.java”, which led to the second prompt.

When the fix was applied, the behaviour was more like the latter behaviour mentioned. Since there is no “if (!ServerUIPlugin.saveEditors())”, the “ServerUIPlugin.java” class is not called upon. This is what removes the first “save dialogue”, and the latter behaviour ensues. Therefore, the “StartAction.java” class is called upon, which leads to the “Server.java” class, which goes through various prefrences “.class” files, which leads to the “SaveResourceHandler.java”, which leads to the “DebugUIPlugin.java”, where the preLaunchSave method checks and calls for the save dialogue prompt:

public static boolean preLaunchSave() {
        String saveDirty = getDefault().getPreferenceStore().getString(IInternalDebugUIConstants.PREF_SAVE_DIRTY_EDITORS_BEFORE_LAUNCH);
        if (saveDirty.equals(MessageDialogWithToggle.NEVER)) {
            return true;
        return saveAllEditors(saveDirty.equals(MessageDialogWithToggle.PROMPT));

This shows exactly the effect of making the changes to the “StartAction.java” to remove the uneccesary check. The methods being called in the “ServerUIPlugin.java” class, and the “ServerUIPreferences.java” class, are all related to saving open editors. Other methods in these two classes are not being used for this step. Since the save dialogue is prompted later in the pre-launch, the first check is not required. Therefore, thepatch, that was attached through bugzilla, should be a possible fix.