Community
Participate
Working Groups
Build Identifier: WTP 3.2 While tracing a publishing problem in a WTP adopter product I noticed a lot of tracing messages saying "Could not find <name> Reverting to default behaviour". It turns out that this tracing message is happening because of binary JEE 5 modules. If you have a binary JEE 5 module then it is not a project and therefore causes an IllegalArgumentException on the call to getWorkspaceRoot().getProject(id); I think a better way to handle this implementation would be to check the number of segments in the specified id. If it is more than 1 then the id cannot be a project so the logic in ProjectModuleFactoryDelegate#findModule(String) should not be executed. Only the call to super.findModule(id) should happen in this situation and no trace string should be printed since it's not an error situation. Reproducible: Always
Created attachment 168009 [details] Possible patch
The removal of the try catch block may cause a change in behaviour. For example, the existing code used to catch some exceptions before the change, the new code will now causes an uncaught exception and throw to the downstream code. Therefore, in order to avoid regression or change in behaviour in the existing API, we shouldn't remove the try catch blocks on the exceptions.
Good point Elson. I am committing the code without the removal of the try/catch
Changes committed and released to 32M and HEAD(3.3)
Fixed.
New Gerrit change created: https://git.eclipse.org/r/108982
