Community
Participate
Working Groups
Build ID: WTP 2.0 RC3 Steps To Reproduce: Run on server for EE5 modules calls J2EEDeployOperation.execute which uses artifact edit 1. This method needs to be changed to use the model provider org.eclipse.jst.j2ee.internal.deploy.J2EEDeployOperation.java 2. 3. More information:
Created attachment 71524 [details] patch to use modelprovider
Hi Angel, I have added you to this, as you probably want to know what changes are made in the deploy class.
Hi Jason, I made the fix for the J2EEDeployOperation I did notice one thing for the EE5 projects (say a EJB 3.0 module with no ejb-jar.xml file) calling IModelProvider modelProvider = ModelProviderManager.getModelProvider(proj); // we just happen to know it EObject eObject = (EObject) modelProvider.getModelObject(); ICommandContext ctx = new CommandContext(monitor, null, eObject.eResource().getResourceSet()); eObject is Null, Is that because the models are not ready yet ? or am I supposed to use another api ?
Created attachment 71630 [details] patch to use modelprovider with null check
I have tested this and approve... This blocks our adopter scenario publishing EAR's
Testing the patch..
+1. Fix looks safe and I believe this should have come in as an adopter bug.
Please provide a better description of the bug. What feature is affected? Why is this critical? We have done limited testing by applying this patch and don't see an issue.
It does seem the patch does more than is described. Is there anyway to split this up to what's minimal essential change? Or is it all required, if all required, please spell it out for us why so much is changing.
The patch makes following changes 1. J2EEDeployOperation.execute/deploy methods were retrieving EnterpriseArtifactEdit objects for a given project. Like this EnterpriseArtifactEdit edit = null; - edit = (EnterpriseArtifactEdit)ComponentUtilities.getArtifactEditForRead(component); Now this will not work if the project happens to be a EE5 project (a ejb, web module with no deployment descriptor), we need to use model provider api that abstracts that information IModelProvider modelProvider = ModelProviderManager.getModelProvider(proj);
The changes made were mainly in changing ArtifactEdit to ModelProvider, then we had to change method signature and some refactoring and such to make that possible.
I assume there is no workaround for this. Seems risky, but I will hesitantly approve given that it seems like a major functional issue. I hope that there has been ample testing to find any possible regressions.
I'm with Neil :) But will count on Tim's (and Chuck's (and Raj's)) assurance of "looks safe". But please, in future, make last minute fix's like this more understandable to reviewers. For example, getSelectedModules used to have two arrayLists, now it has one? I suspect that's some sort of great cleanup, but I've spent 10 minutes or so trying to figure out how related to this issue and just don't see it. (I suspect it's there, so that's not the issue, I'm just asking that the code and/or fix be documented in more detail so everyone knows what we are getting).
My understanding is that this bug prevents an EE5 EAR being published in the adopter product. Also, I am assumig WTP can still deploy an EE5 EAR without this fix. Have we verified this code doesn't regress WTP funcationlaity? Are we approving this because its a 'blocker' for the adapter code that can't wait for the maintenance release? Please clarify.
This patch seems major and not enough time to test, but I will trust Chuck's assessment and approve. We will have the next week to test any undesired impact.
Created attachment 71932 [details] more updated patch I know this does not inspire a lot of confidence. But I had to get some of these changes in. With these changes I performed the following tests 'Run on server' & 'Prepare for deployment' for all the projects below. Ear50 ejb30 web24 Ear14 ejb21 web24 And all of it worked without any errors.
I am pulling this defect from 2.0 release and moving to 2.0.1 With the recent changes... This is not worthy of dropping at this stage. Thanks everyone!
(In reply to comment #17) > I am pulling this defect from 2.0 release and moving to 2.0.1 > With the recent changes... This is not worthy of dropping at this stage. > Thanks everyone! Thanks, I think it is the right decision. I was about to ask time for me to verify this patch on web25+jSF1.2.
dropped to 2.0.1
Verified that J2EEDeployOperation no longer calls ArtifactEdit
