Community
Participate
Working Groups
Currently, when you create a session EJB with local and/or remote view and you do not implement any other interface, the remote and/or local interfaces are created with the proper annotation (@remote or @local), and the resulting bean only implements these interfaces. But if you implement an extra interface in the wizard, the resulting bean class will have the @Remote and/or @Local annotation as well, This enhancement proposes to change this behavior by default, or provide a way to change this behavior, to add to the bean class the @remote and @local annotations besides implementing the interfaces even when you do not implement an extra interface, something like this: /** * Session Bean implementation class MyBean */ @Stateless @LocalBean @Remote({com.test.MyBeanRemote.class}) @Local({com.test.MyBeanLocal.class}) public class MyBean implements MyBeanRemote, MyBeanLocal { ..... } The benefit to placing then annotations on the bean class is that it's clear what the business interfaces of an EJB are. Besides, this would help developers if they change their mind later and they want to implement an extra interface in their beans, or if they later want to add an extra remote/local business interface. This could also tools and application servers.
I'd like to make some points clear about the current behavior of the wizard and the proposed changes: Current behavior: 1. If a business interface is selected to be created (new interface) in the first page of the wizard, the interface is created with the @Remote or @Local annotation on the interface, not on the bean class 2. If an existing interface is selected in the second page of the wizard, then the @Remote or @Local annotation are added to the bean class So, if the user adds new and existing interfaces, they are specified in different ways. Proposed changes Option 1: Specify all the interfaces (new or existing) in the @Local and @Remote annotations in the bean class, and do not generate the @Remote/@Local annotations in the new interfaces Option 2: Specify all the interfaces (new or existing) in the @Local and @Remote annotations in the bean class, and continue generating the @Remote/@Local annotations in the new interfaces Any comments?
Created attachment 208415 [details] Add @Remote/@Local to bean class and new interfaces This patch changes the behavior of the wizard to include the @Remote/@Local annotations in both the bean class and the new interfaces
I am more in favor to Option 1. This way we will have the metadata (annotation) at only one place. Otherwise, if we have the annotation both in the bean class and the interface then this can lead to confusion and inconsistency (having a @Local annotation for an interface in the bean and @Remote in the interface itself).
I just realized I modified manually some files generated by JET. Now I'm changing the template files and trying to generate the code using JET. I see that the JET builder was disabled in bug 285502. How do I enable this builder again?
Created attachment 208701 [details] Add @Remote/@Local to bean class only I'm not sure if it is the best way, but I enabled the JET builder on the plugin project and it worked. This patch adds the @Local and @Remote annotations to the bean class only. If there is only one class, it generates an annotation like: @Remote(Test3Remote.class). If there are 2 or more interfaces, it generates an annotation like this: @Local({Test3Local.class, TestX.class})
I am not really into changing the current behavior. Let me explain why: Well it actually really depends on the usecase. If I want to reuse an interface in several beans the wizard will create @Local / @Remote annotation in every bean. The approach where the annotation is in the interface looks much cleaner. The approach where every interface is annotated looks better to me, but we must consider the case where the interface could be in a library that we can write in. This is why the current behavior writes in the bean class.
I can see your point. On the other hand, if I want to reuse an interface in a plain old java object (POJO), then the approach of not adding the annotation to the interface would be better. So, as you said, it depends on the use case. What do you think if I add a new preference which by default leaves this behavior unchanged, but that can be used by adopters to change the behavior?
Created attachment 209292 [details] Allow adopters to control where the @Local/Remote interfaces are placed through properties This new patch adds a couple of properties to allow adopter to determine where to place the @Local and @Remote annotations. If they are not set, the current behavior will be in place.
Changing the "Assigned To" field to the default again. I assigned this bug to me by accident.
Kaloyan, since this patch should not affect the current behavior, could you please review it to see if can be included in 3.3.2 and 3.4? Thank you.
Just reviewed the change, The code looks good, the behavior is the same while using default preference values. Change looks relatively safe. There are no UI changes. There are changes in j2ee and web, so I guess that the changes should be reviewed by the responsible project leads.
Approved for EJB Tools. Chuck, could you review the respective changes in JEE Tools?
Changes look good
Code committed to R3_3_maintenance and HEAD for WTP 3.3.2 and 3.4. Resolving defect
