Community
Participate
Working Groups
An adopter is requesting a way to change the default package used for interfaces when creating new session EJBs. Currently, if the ejb class is com.test.Bean1, the local interface will be com.test.Bean1Local. We need a way to change the default package so the package for the interfaces is different from the package for the bean class. Is jst.ejb the right component for this change?
(In reply to comment #0) > Is jst.ejb the right component for this change? Yes, the EJB wizards are in this component.
Created attachment 209454 [details] Proposed patch This patch adds a new preference that will allow the adopter to add a suffix to the default package name for interfaces when creating a new session EJB. If the property is null or "", the current behavior is done (same package for bean class and interfaces)
Roberto, could you give more background about this change? AFAIK, users can change the package of the generated EJB interfaces. It is not mandatory that the EJB interfaces have the same package as the EJB class. In fact every EJB interfaces can be generated in a package specified by the users. Is this not enough?
The problem here actually lies in the treatment of the interface and bean class by non-Java EE servers. The scenario could also impact Java EE servers. Simply put, we have found cases where, when classes in the same package exist in two different jars, we can encounter split packages (which has been a nightmare in java programming since jars were first used). Currently, our default setup for creation of a bean in an EJB project with an EJB Client jar puts us in exactly that scenario - the same exact package is used (by default) for both the bean class, in the EJB jar project, and the interface, in the EJB Client jar project. At this time, we do not wish to disrupt the current behavior of WTP 3.3.x in this regards, but an adopter would like the ability to change the suggested (default) package for the interface(s) in their product, such that the split packaging is not the default, suggested way of creating these artifacts.
Created attachment 209574 [details] Patch v2 I'm updating this patch because it touches some of the same classes changed by bug 366346
Carl, thanks for the details. This improvement really make sense in environments sensitive to the "split package" issue. However, I am changing the severity to "enhancement" to correspond better to the level of change.
By the way, this change can be considered as an API change (still backward-compatible). It should go through a PMC approval for the Indigo stream.
Thank you Kaloyan and Carl. I will request the PMC approval.
Created attachment 209630 [details] Patch v3 Updating the patch. The only difference between V2 and V3 of the patch is that in V2, I forgot to update the min version of plugin org.eclipse.wst.web required by org.eclipse.jst.j2ee and org.eclipse.jst.j2ee.ejb. In V3 of the patch, the min version is updated.
Requesting PMC approval for the Indigo stream (see comment#7) * 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 enhancement is about allowing adopters to change the suggested (default) package for session beans interfaces when creating EJB, by adding a new product preference. If the preference is not set, then the existing behavior should remain unchanged. I'm copying explanation from comment#4 for more details: "The problem here actually lies in the treatment of the interface and bean class by non-Java EE servers. The scenario could also impact Java EE servers. Simply put, we have found cases where, when classes in the same package exist in two different jars, we can encounter split packages (which has been a nightmare in java programming since jars were first used). Currently, our default setup for creation of a bean in an EJB project with an EJB Client jar puts us in exactly that scenario - the same exact package is used (by default) for both the bean class, in the EJB jar project, and the interface, in the EJB Client jar project. At this time, we do not wish to disrupt the current behavior of WTP 3.3.x in this regards, but an adopter would like the ability to change the suggested (default) package for the interface(s) in their product, such that the split packaging is not the default, suggested way of creating these artifacts." * Is there a work-around? If so, why do you believe the work-around is insufficient? The user can change the package manually in the UI, but having different default packages for beans and interfaces would be better to avoid the split packages problem. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? This was tested manually,and the complete JUnit bucket (org.eclipse.wtp.j2ee.headless.tests.plugin.AllTestsSuite) was run to make sure this change does not break existing behavior if the new preference is not set. * Give a brief technical overview. Who has reviewed this fix? A new product preference is created, allowing adopters to set the value of this preference to a suffix that is appended to the suggested package name of interfaces when creating session beans using the new EJB wizard, so the bean class and the interfaces have a different package by default. If this preference is not set, the current behavior is respected (both the bean class and the interfaces have the same package) Kaloyan reviewed the code. * What is the risk associated with this fix? Low.
I'm ok with this change, and has had an adequate amount of review. Thanks
Code committed to R3_3_maintenance and HEAD for WTP 3.3.2 and 3.4. Resolving bug.
Created attachment 209715 [details] Update plugin versions 3.3.2 Bug to update the plugin versions. This patch is for 3.3.2.
Created attachment 209716 [details] Update plugin version 3.4 Patch to update the plugin versions. This patch is for 3.4
The last two patches can be applied on top of the previous patches. They have been committed to their respective branches.
Created attachment 209718 [details] More update plugin version 3.3.2 More plugin version updates for 3.3.2. This patch can be applied on top of the other patches. It has been committed to R3_3__maintenance
Created attachment 209719 [details] More update plugin version 3.4 More plugin version updates for 3.4. This patch can be applied on top of the other patches. It has been committed to HEAD
