Community
Participate
Working Groups
Currently, EJBClientCreationAction is tied into an EJB project being contained by an EAR project. An adopter (IBM) wants to loosen this restriction, allowing for an extension to provide alternate ways to specify the containment from the EJB to the EJB Client.
Created attachment 200763 [details] Add an extension point for adopters This adds in an extension point for adopters to hook into that action. The interface that is used adds two methods: boolean allowEJBClientCreation(IProject project); int showWizard(Shell shell, IProject project); The allowEJBClientCreation is a method to check to see if the extender handles EJB Client creation for this type of project. The showWizard pops up whatever wizard is needed to actually create the EJB Client. Note that this could just perform an action, but showWizard is used to pass through a shell, in case UI will be displayed.
Carl, I am fine with this change as long as the default behavior for adopters, who do not use this extension point, remains the same. I did a sanity check and it looks like this patch is OK with this. However, could you provide more descriptive documentation? IMHO, the one provided in the patch is not enough for other adopters to understand how to use this new extension point.
Hi Carl, I tried the patch. After I pop up and close the wizard (successful return), I'm getting a separate error dialog pop up saying: Cannot create a new EJB client JAR for a stand-alone project
The adopter has also asked that the same sort of reuse be allowed for the EJBClientRemovalAction. I will be updating the patch with this change, soon.
Created attachment 209346 [details] Add an extension point for adopters that handles both add and remove
More descriptive documentation has been added. Further improvements have been made. I am resubmitting this for review, and will then seek PMC approval.
PMC Review requested due to API change - this adds an extension point 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. Currently, there is no way for adopters to hook into the Add Client Jar and Remove Client Jar menu items and actions. As EJBs become more prevalent, they are being used in containers other than an EAR by adopter products. This change allows them to reuse the same menu items and actions for the same sort of behavior outside of an EAR. Is there a work-around? If so, why do you believe the work-around is insufficient? The current workaround is to add another "Add Client Jar" and "Remove Client Jar" menu item in the same menu for each type of container that is supported. That is not a good workaround. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? This has been tested by hand, and the Java EE Tools JUnit bucket (which covers EJBS) has been run against it. Give a brief technical overview. Who has reviewed this fix? An extension point and an interface are added that allow for adopters to hook into the Add and Remove Client Jar menu items associated with an EJB project, and into the associated actions. Kaloyan Raev has reviewed this. What is the risk associated with this fix? Low
Code committed and released to R3_3_maintenance and HEAD for WTP 3.3.2 and 3.4. Resolving bug.
