This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Consider *enforcing* placement of Remote EJB interfaces into separate EJB client jar. It does not make any sense to place Remote interfaces into the same jar which implements EJB. Allowing that only causes consequent error when user wants to call such EJB from other projects - only EJB Remote interface should be included in calling project and not whole EJB module. This problem got more visibility since EE 6 - if whole EJB module is included in Web Application then EE 6 compliant server will try to deploy EJBs instead of just referencing them (in case of standalone Web Application deployment). Or see bug 163083 for other illustration of potential problem.
On second thought this is a defect: not putting them into separate project is plain wrong. Wizard should display warning when Remote Interface option is selected and there is no suitable project, eg. "There is no J2SE Class Library project available into which Remote interface could be stored. Create one first." or something like that.
Probably we should remove the current project from the list of projects for remote interface generation. As for the J2SE Class Library projects could you please explain what do you mean? Are you requesting to show warning if there is no J2SE Library Project in the project list or selected project for remote interface generation is not a J2SE Library project?
(In reply to comment #2) > Probably we should remove the current project from the list of projects for > remote interface generation. yes > As for the J2SE Class Library projects could you please explain what do you > mean? Are you requesting to show warning if there is no J2SE Library Project in > the project list yes - if the list is empty we should indicate to user what's wrong and how could they amend it. > or selected project for remote interface generation is not a > J2SE Library project? that should never happen as list of projects is filtered and only acceptable projects are listed. That's why sometimes the list can be empty even if user has some other projects opened in the IDE.
I have pushed a partial fix which removes the current project from the list. I have a problem with identifying the project type.
I have pushed the second part: removing those projects from the suitable projects list which are providing J2eeModuleProvider.
Integrated into 'main-golden', will be available in build *201005300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8a51a59f8dd5 User: Andrey Yamkovoy <kaktus@netbeans.org> Log: Partial fix for #186332 - always put Remote interfaces to EJB jar client
I am still wrestling with this behavior. I have the situation where we have used Entity beans in the remote interface, so putting the remote interface in a separate SE jar lib causes the problem that how do you include the needed Entity beans now? If you move them from the EjbModule to the SE jar file you no longer have working Entity beans. If you try to point the SE jar project at the EjbModule project it won't do it because it is circular refrence. I am just trying to figure out clustering but I read that you need to use the Remote interface in order for your Enterprise application to have the the load balancing happen correctly. This means it would be correct to have Remote interfaces in your EjbModule because if you are not using the Remote interface your code really isn't running correctly in a cluster. I think this needs to be reopened? I think you need a project or ant task that will compile a jar file that can be used for a remote client. It needs to extract the appropriate remote interface classes and dependent entity objects.
> If you move them from the EjbModule to the SE jar file you no longer have working Entity beans. I don't think this is the case - they should be valid and working even if you put the entities into the SE jar file. This is the approach I would choose. I assume by "Entity beans" you mean JPA Entity classes, right?
I second what Petr Jiricka suggested - JPA entities in SE project. It should work otherwise please file a new issue and describe what does not work and assign it to me and I will help you resolve it. Thx.