Community
Participate
Working Groups
In 3.2.4, bug 339131 introduced a couple of module artifacts adapters to allow WebDeployableArtifactUtil to understand SessionBeans and MessageDrivenBeans, and pass them along to servertools. But these adapters are causing that WebDeployableArtifactAdapterFactory is used for beans in EJB projects also. This is a regression in 3.2.4
To clarify, this is causing bad information to be passed from the WebDeployableArtifactUtil to the ServerTools code, and prevents proper deployment of EJB 3.x artifacts in an EJB project. This is a regression from WTP 3.2.3 functionality. No new module artifact adapters were created, but the existing Web artifact adapters were improved to handle beans in a Web module. In so doing, the code was made too permissive, and thus it attempts to handle all 3.x beans, and not just those in a Web module.
Created attachment 194993 [details] Verify that the Beans are in a Web project. If not, return null. Returning null allows the ModuleArtifactAdapter to continue searching until it finds the correct adapter for EJBs in an EJB project.
I agree with this fix - 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. A regression was introduced in the "Run on Server" scenario of 3.x EJBs. An adopter (IBM) is requesting that the regression be fixed. Is there a work-around? If so, why do you believe the work-around is insufficient? There is no work-around. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? The fix has been tested by hand both at the WTP level and in the adopter product. Give a brief technical overview. Who has reviewed this fix? All we did is add a check into WebDeployableArtifactAdapterFactory to ensure the project is a Web project. As per comment #2 - this change makes it so that the WebDeployableArtifactAdapterFactory returns null for non-Web projects, thus allowing the ModuleArtifactAdapter to continue searching until it finds the correct adapter for EJBs in an EJB project. Chuck Bridgham, Carl Anderson, and Roberto Sanchez have all reviewed this fix. What is the risk associated with this fix? The risk here is relatively low- the change is limited to WebDeployableArtifactAdapterFactory, and only adds one simple check.
I have reviewed this fix - approve.
Sounds important and is low risk. +1
Can you clarify explicitly ... this does occur in pure WTP-only, right? Not just adopter use? Similarly, occurs in any server that supports EJBs? Or ... some subset? [Sorry if obvious to most ... but, thought it best to ask since not obvious to me.]
Carl, can resource ever be null?
(In reply to comment #8) > Carl, can resource ever be null? resource should never be null. However, instead of using resource.getProject(), we could certainly just cast resource to be an IProject... then, if it is null, the isDynamicWebProject check will fail (instead of a possible NPE). That change should be minor enough that we wouldn't need a re-review of the patch.
Created attachment 195292 [details] Verify that the Beans are in a Web project. If not, return null . Cast Resource to IProject
(In reply to comment #7) > Can you clarify explicitly ... this does occur in pure WTP-only, right? Not > just adopter use? Similarly, occurs in any server that supports EJBs? Or ... > some subset? > > [Sorry if obvious to most ... but, thought it best to ask since not obvious to > me.] David, it happens in WTP alone, but only in conjunction with a Server Adapter that supports EJB 3.x (which we don't ship with WTP.)
Committed to 3.2_maintenance and HEAD
(In reply to comment #12) > Committed to 3.2_maintenance and HEAD Sorry, I meant R3_2_maintenance and HEAD
