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.
1. Deploy attached ear file to remote GlassFish. 2. Download stub client and extract ejb-jar-ic.jar from it. 3. Rightclick "Enterprise Java Beans" node and select "Add Set of Session EJBs...". 4. Add extracted ejb-jar-ic.jar as client jar, leave default values in the rest of fields and click next. 5. In "Configure Methods" enter java.lang.String for method_Collection_String_Object_double and for method_Collection_String_UserInfo_double. 6. Click "Finish" button. 7. Create J2EE 1.4 web application with "Visual Web JSF" framework. 8. Add EJB to the page. 9. Add button component to the page and add action event handler for it, that uses EJB method. 10. Deploy application to Tomcat 5.0. 11. Open application in browser and click button. Result: Message "HTTP Status 500" appears in browser and exception arises in server log. The same for Tomcat 5.5, Tomcat 6.0. And even Java EE 5 application fails on Tomcat 6.0 with the same exception. See logs in attach.
Created attachment 44251 [details] EAR file of enterprise application
Created attachment 44252 [details] Logs of application servers
This issue is showstopper for M10. Please integrate the fix into the trunk and "release60-m10" branch.
In Creator 2, the IDE generates a standalone EJB client wrapper. There are two ways to get a reference to the client stub. One is to use JNDI to get a fixed reference name and require the container to map this reference name to the actual stub. This is how the original Creator EJB module was written. This means the container must have JNDI configured to map this reference to an EJB endpoint. If you are using tomcat, then JNDI needs to be configured. Supported containers like glassfish do support JNDI and there is an IDE plugin that allows the IDE to configure them. Since the goal of issue #90455 is to provide a migration path for Creator users and this scenario was not supported in Creator, I am making this an RFE and lowering the priority. BTW, one way to fix this is to generate a hard-coded address in the wrapper code and not use JNDI, but that would be a significant change.
will manual configuration in the descriptor help for servers other than Glassfish ? For Creator 2 users this may be considered an enchancement but for NetBeans users I think this issue should be P2 because we support containers other than Glassfish. Are you saying we cannot support other servers because we don't have the necessary APIs from server plugins ? thanks
The scenario in this bug report is not supported in Creator 2 so if the goal is to port the Creator 2 features to NB6 (issue #90455), then we're done. If the goal is to support more such as this scenario, then that would require adding a new feature so I marked it as an RFE. Feel free to mark it as you think is appropriate, but I don't think it's a showstopper for M10 because of the original plan.
jayashri: I hit submit too fast. To answer the other questions, Creator would test deploy a webapp to the bundled Sun app server. The webapp could automatically access EJB session beans hosted on other app servers like from Sun, Weblogic, and Websphere. All that should continue to work. If you want to deploy the webapp to another container, then you would export the webapp and the deployer would have to then manually configure and deploy it to that container. This is still true today.
Visual Consumption of EJB 2.1 in Visual web apps issue #90455 is supported in NetBeans 6 as a migration path for Creator users. Creator ships with a bundled Sun App Server where web apps are test deployed to. This feature allows the web app to consume Session EJBs hosted on other app servers such as Sun, WebLogic, and WebSphere; however a limitation still remains, the web app itself needs to be test deployed on a Sun app server for the automatic configuration to work. If you want to host the web app in another app server, you must manually configure the EJB reference to JNDI binding which is container specific. When deploying your web app on a production server using the export war feature, this manual configuration step is part of the Java EE deployment process which is container specific.