Community
Participate
Working Groups
I noticed that in the members calls for FlatComponentDeployable.members there is a call that checks if component.isBinary, if such is the case the code will go on to create ModuleFile using a java.io.File with no references to the workspace file. I am not sure why this was done this way, but our adopter product is breaking because in the case of binary EARs with a web module, we are expecting to have the in workspace resources instead of the file system resource. It seems that this is a change from the way that the old J2EEFlexibleProjDeployable used to do it as seen in the J2EEFlexibleProjDeployable.members call, which will call the getBinaryModuleMembers and checks for the existance of workspaces resources, first and then moves on to external files.
We are looking to get this fixed in 3.2, as this is a regression from 3.1
Rob, this was a change you had made. Is there a specific reason why it just returns java.io.File now?
The same check to determine if it is a workspace resource to return an IFile vs java.io.File could be done by clients. Is there some reason this can't be done Angel? We are late in the cycle and this code has been this way for a few milestones now.
We found this out during our adopters testing, although we could do the check in our side, I am not sure what other places could be broken. I vote for fixing it the JEE side since it is a regression from 3.1. Was there a reason for the change? We should determine why was the old code not ported so that we can make a decision.
Created attachment 168158 [details] conditionally changes the moduleFile's constructor This seems like a good patch but I haven't tested it since I don't have a test case. Let me know if this fixes your usecase.
Angel can you please test this as soon as possible? I would like to put this up for review today and get it in RC1 if possible.
Testing completed. This works fine now. Thanks for the patch.
approved
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. Adopter's are expecting an IFile as a parameter to the ModuleFile constructor when the resource is a workspace resource and are expecting a java.io.File for external resources. This issue exposes a regression issue where now only java.io.File is used regardless of whether the resource is a workspace or external resource. * Is there a work-around? If so, why do you believe the work-around is insufficient? The workaround would require adopters to know of the regression and code around it. This is not a sensible workaround. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? No unit tests for this bug. * Give a brief technical overview. Who has reviewed this fix? The fix is to simply call the right ModuleFile constructor based on whether the binary component's underlying resource is a workspace or external resource. This has been reviewed and approved by Chuck. Angel has tested that the patch solves the issue at hand. * What is the risk associated with this fix? I see little risk with this patch. It will now work as it did pre WTP 3.2
code checked into head for wtp 32 rc1
