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.
Creating new cmp's in a J2EE 1.4 ejb module targeting Sun Appserver no longer creates the correct cmp-resource element. This regression is caused by the migration of datasource creation to the new data source api added to j2eeserver (ie implementations of [j2eeserver] ...plugins.api.ConfigurationSupport.createDataSource()). This migration failed to acount for the zero-config code that managed proper jndi-naming in server specific DD files. As that code is now disabled, proper jndi-names are no longer being set for cmp-resource. resource-ref for database resources is also affected, but the for now, the default jndi-name there is still correct. It is my opinion that it's correct by accident rather than by design, but for now, that part still works.
Nitya, I reassigned this to you and added Libor as CC. Could the two of you work out a solution? The biggest problem is the cmp-resource jndi-name issue. resource-ref is secondary but if the fix involves an api change (I suspect it will), this one should be addressed as well.
*** Issue 81176 has been marked as a duplicate of this issue. ***
Libor, this is the issue we were discussing this morning.
Created attachment 32289 [details] diff for trying the API change (API change and other related sources)
Reassigning back to nitya to evaluate the suggested API change, see the attachment . It solves the problem when CMPs are generated using 'CMP from DB' wizard. API change basically consists of passing JNDI name of the resource (data source) which the EJB classes are generated from to ensureResourceDefined method.
Comment about the Javadoc for the new method: can the JNDI name be null? If so, the Javadoc should state it, and say what happens if the client passes null.
JNDI name can be null. The patch attached cannot be considered as the common API review patch. Now it is only a proof of concept, all details will be done later after agreement on the changes.
I haven't reviewed the changes in the patch fully yet, but I will. Regarding the jndi name though... jndi name is a server specific field, and as such, whether it can be null or not can only be decided at runtime by the server plugin being called. For example, for J2EE 1.4 module running on AppServer 8.2, JNDI name for cmp-resource cannot be null. Same module on Glassfish might allow it (I don't know). If null support for this parameter is desired, then server plugins should be coded to handle null but the API should also allow an error to be returned somehow (exception or return code) so that the caller can be notified when a required field was not filled due to insufficient information.
I think the api should be more generic, say ensureResourceDefined(ddbean, jndiName) instead of ensureResourceDefinedforEjb. That way, it could also be used after the useDatabaseAction to pass the jndiName that needs to be set in the appropriate server descriptor's resource-ref. Also, the JNDI name should not be null. At this point in the workflow, the IDE has asked for a server resource with a specific jndiName to be created. There would have been a configuration exception in the DS Management API, if the jndiName was null. No such resource would have been created and no resource would have been added in the project either. In this scenario, ensureResourceDefined(ddbean, jndiName) should not be called.
I have problem with 'general' method ensureResourceDefined. It can be called this way in the ConfigurationSupport and its implementors but J2eeModuleProvider.ConfigSupport.ensureResourceDefinedForEjb cannot be easily generalized. It takes ejbname and ejbtype parameters - generalization has to count with the XPath and the location of DD instead of ejbtype. I am not sure whether we should design this change if there are plans to redesign the DD listening as a whole. I suggest to create ConfigurationSupport.ensureResourceDefined(ddbean, jndiname) method, but leave current J2eeModuleProvider.ConfigSupport.ensureResourceDefinedForEjb(ejbname, ejbtype, jndiname) for the reasons above. Of course, it does not allow to use it for other resource types but we don't need this for release 55.
I would mark the old J2eeModuleProvider.ConfigSupport.ensureResourceDefinedForEjb(ejbname, ejbtype) method deprecated, otherwise I agree with Libor.
I am fine with leaving ensureResourceDefinedForEjb as is and adding a new ConfigurationSupport.ensureResourceDefined(ddbean, jndiname)
Patched persistence and ejbcore IDE:------------------------------------------------- IDE: [9/1/06 2:30 PM] Committing Files started Checking in persistence/src/org/netbeans/modules/j2ee/persistence/wizard/fromdb/RelatedCMPHelper.java; /cvs/j2ee/persistence/src/org/netbeans/modules/j2ee/persistence/wizard/fromdb/Attic/RelatedCMPHelper.java,v <-- RelatedCMPHelper.java new revision: 1.1.2.2.2.10; previous revision: 1.1.2.2.2.9 done Checking in ejbcore/src/org/netbeans/modules/j2ee/ejbcore/ejb/wizard/cmp/CmpGenerator.java; /cvs/j2ee/ejbcore/src/org/netbeans/modules/j2ee/ejbcore/ejb/wizard/cmp/Attic/CmpGenerator.java,v <-- CmpGenerator.java new revision: 1.1.2.3.2.12; previous revision: 1.1.2.3.2.11 done IDE: [9/1/06 2:30 PM] Committing Files finished
Updated plugin with patch IDE:------------------------------------------------- IDE: [9/1/06 2:34 PM] Committing 2 Projects started Checking in appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/ConfigurationSupportImpl.java; /cvs/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/ConfigurationSupportImpl.java,v <-- ConfigurationSupportImpl.java new revision: 1.3.4.2.2.5; previous revision: 1.3.4.2.2.4 done Checking in sunddui/src/org/netbeans/modules/j2ee/sun/share/configbean/SunONEDeploymentConfiguration.java; /cvs/serverplugins/sun/sunddui/src/org/netbeans/modules/j2ee/sun/share/configbean/SunONEDeploymentConfiguration.java,v <-- SunONEDeploymentConfiguration.java new revision: 1.2.16.7.2.22; previous revision: 1.2.16.7.2.21 done IDE: [9/1/06 2:34 PM] Committing 2 Projects finished
Caused issue 84233.