Community
Participate
Working Groups
wtp-sdk-I-I200611300401-200611300401.zip When editing a JSP within a targetted dynamic web project, choosing Run/Debug/Profile on Server from the editor's context menu fails immediately with a dialog stating "The selection is not within a valid module." It works fine from the file's context menu in the Project Explorer.
I've only seen this in one editor in the past, and it was a bug in the editor. I'll need to reproduce and debug it. Which editor are you using - the JSP source editor?
The bug I was referring to is bug 116217, fixed in 3.2 and above. I tested this in WTP 2.0 and could not reproduce. Nitin - I was in the JSP source editor, right clicking and selecting Run As > Run on Server, and this works fine for me. Is this what you were doing? Please let me know if you were doing something different or the steps you are taking to reproduce this.
I have also encountered this symptom. On my Linux Laptop I have a WTP 2.0M3 test installation that does this consistently. The cause is that for reasons I have yet to determine, webstatic1 and webstatic2 appear first in the list of moduleArtifactAdapters as displayed by ServerPlugin.loadModuleArtifactAdapters() with tracing enabled. The remaining moduleArtifactAdapters appear in the "usual" order, "ejb", "ear" , "cactus", and "webresource". Because the "cactus" entry is the only one with a priority other than zero, the sort that follows loading swaps the "webstatic1" entry with the "cactus" entry and "webstatic2" remains as the second entry. The criteria for "webstatic2" looks like it will grab most anything in an editor and because it doesn't contain a module, prevents the Run/Debug/Profile from succeeding. It's unclear to me why this installation has the "webstatic" entries first when many others have them last. I routinely use a "links" directory with "*.link" files under the "eclipse" directory to connect the eclipse installation to the various dependencies. I'm not sure if that approach lends itself to this occurring. I think I have seen this with Windows, but I can't confirm with any of my current Windows Eclipse installations. Given that there appears to be some variability, perhaps the priority setting on the moduleArtifactAdapters could be used to ensure the desired order.
Thanks, Larry - that's exactly what I needed to reproduce the problem and see what the problem is. Looking at the StaticWebDeployableObjectAdapterUtil (impl behind webstatic1 and webstatic2), it's just some logic (checking that the project is a valid static web project) that's missing in the case where the file is adapted from another object. I'll send this the wst.web team and attach a patch that I've tested.
Created attachment 55431 [details] Patch to check whether the project is valid in all cases The attached patch cleans up the code a little to make the logic clearer, but it's really just making sure that the following code is executed in the case where the resource is received from the IAdaptable: IProject project = ProjectUtilities.getProject(resource); if (project != null && !hasInterestedComponents(project)) return null;
I have confirmed the patch fixes the issue on my Linux Laptop.
Pinging. :) It would be nice if this could be included in WTP 2.0RC0. I never found a way to "fix" the order of the moduleArtifactAdapters, so users who encounter the odd order won't be able to use this feature.
Hi Raj - another related run-on bug possibly for RC0
Patch looks good - I approve.... We missed RC0 - but we'll get in first thing RC1
Approved.
this was dropped couple days ago
closed
