Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369985

Summary: Component interfaces for EJB 3.x beans are created with wrong package declaration if default package is changed in wizard
Product: [WebTools] WTP EJB Tools Reporter: Roberto Sanchez Herrera <shr31223>
Component: jst.ejbAssignee: Roberto Sanchez Herrera <shr31223>
Status: RESOLVED FIXED QA Contact: Kaloyan Raev <kaloyan>
Severity: normal    
Priority: P3 CC: cbridgha, ccc, neil.hauge
Version: 3.2.5PFlags: shr31223: pmc_approved? (david_williams)
shr31223: pmc_approved? (raghunathan.srinivasan)
shr31223: pmc_approved? (naci.dai)
shr31223: pmc_approved? (deboer)
neil.hauge: pmc_approved+
shr31223: pmc_approved? (kaloyan)
shr31223: pmc_approved? (cbridgha)
kaloyan: review+
Target Milestone: 3.3.2   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_Approved
Bug Depends on:    
Bug Blocks: 370256    
Attachments:
Description Flags
Proposed patch none

Description Roberto Sanchez Herrera CLA 2012-01-27 13:01:36 EST 
If the default package for component interfaces of a EJB 3.x session bean is changed in the wizard, the interface is created in the correct package, but the package statement in the interface is wrong: the package of the bean class is always used. 

I do not know if this error has been there since the creation of the wizard, but it is more evident now that the default package for interfaces can be changed by adopters (see bug 368506)

Steps to recreate:

1. In an EB 3.0 or 3.1 project, open the new session bean wizard
2. Type the name and the package (use com.test) for the bean class and click next
3. In the Home and Component interfaces (EJB 2.x) section, select bot the local and remote views. 
4. Click on the name of the local component interface, and change the package to com.test2). Do the same with the remote component interface.
5. Click finish. Both component interfaces are created inside the com.test2 package, but the package declaration in both interfaces is com.test.
Comment 1 Roberto Sanchez Herrera CLA 2012-01-27 13:08:32 EST 
Created attachment 210209 [details]
Proposed patch
Comment 2 Roberto Sanchez Herrera CLA 2012-01-30 10:25:28 EST 
    * 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. 
This defect generates code with compilation errors. This bug is more likely to occur if a default package for component interfaces different than the default package for bean class is used (see description in this bug)

    * Is there a work-around? If so, why do you believe the work-around is insufficient? 
The only work-around would be to either always use the same package for bean class and for component interfaces, or edit the generated component interfaces so the package declaration matches the package in which the interface was created. I do not think either is acceptable. 


    * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? 
Tested manually and ran the existing JUnits to make sure the change does not break existing testing. 

    * Give a brief technical overview. Who has reviewed this fix? 
The new EJB 3.x session bean wizard gives the user the option to add legacy (EJB 2.x) home and component interfaces to the session bean. The wizard also allows the user to specify in which  package these legacy interfaces will be created. But for component interfaces, the wizard ignores the package specified by the user, and always uses the same package than the bean class. This is because while the component interfaces are generated using JET templates, the bean package is always used. The change consists on changing the JET template to use the right method from the model to pick the package specified by the user. 
Kaloyan Raev reviewed the fix.

    * What is the risk associated with this fix? 
Low.
Comment 3 Roberto Sanchez Herrera CLA 2012-01-31 13:25:18 EST 
Code committed to R3_3_maintenance and HEAD for WTP 3.3.2 and 3.4. Resolving bug