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.
[build 20051120] Steps to reproduce: 1) create EJB module 2) generate some CMP beans from database 3) check sun-cmp-mappings.xml file. All required elements for beans are generated. 4) generate other CMP beans from database 5) new dbschema is created, all elements in ejb-jar.xml file are created as well ERROR: Elements fro these new beans are missing in sun-cmp-mappings.xml file.
I marked this bug dependent on bug #59343. I did confirm that the changes to sun-cmp-mappings.xml for the second set of beans are not added. But also, for this test case, you get the multiple schema files as described in 59343 and this is the likely cause. We may need an api upgrade here, because the way the wizard initializes sun-cmp-mappings is to call our ConfigurationSupport.setMappingInfo() which may be doing a block write, expecting the mappings passed in to be complete set (I still have to confirm this part). I still need to confirm if we are being called with the mappings for the new beans or not.
Petr, can you add explicit details to the steps above: A) Specifically, for which tables from which DB did you create CMP bean in step 2. B) Which additional tables were used in step 4 and do they have interrelationships or not with any of the tables from step 2. C) Finally, what elements did you expect to see in sun-cmp-mappings.xml at the end that were not there (if the answer here is multiple relationships, just listing one should be fine.)
Requested details: A) I created these beans from jdbc:pointbase://localhost:9092/sample. This DB is bundled in Sun Application Server 8.1. I generated beans for these tables first: CUSTOMER_TBL, MICRO-MARKETS_TBL, DISCOUNT_CODE-TBL. I selected only CUSTOMER_TBL table, others were generted since they are referenced from this table. Then I selected SALES_REP-TBL table and these table were generated: SALES_REP_TBL, OFFICE_TBL, OFFICE_TYPE_CODE_TBL. Tables that were generated in step 4 don't have any relationships to tables from step 2. C) I expext these elements in sun-cmp-mappings.xml: <sun-cmp-mapping> <schema>PBPUBLIC_EJBModule1_1</schema> <entity-mapping> <ejb-name>SalesRepTblBean</ejb-name> ....... </entity-mapping> ........ </sun-cmp-mapping>
The new mapping info is sent to the plugin properly. What appears to be happening is that the existing code does not merge this new information properly with the existing information. I'm going to ask Rochelle to take a look at this one, as there are very possibly edge cases that I wouldn't know about. The workaround of course is to generate all required beans at once. This also workarounds bug #59343 at the same time.
I don't think that this is corner edge. I'm thinking about folowing scenarion: I have exsiting database with many tables and then decide create EJB module that uses this database. User can select one table and the right and referenced beans are generated. But, he realized that some requested beans are not generated since they don't have reference to existing beans. What he/she should do now? Delete existing project or write missing beans manually? I can't agree that this scenario is corner case.
I tested this scenario in NetBeans 4.1 and here it's working. Therefor, I marked issue as regression.
To clarify: I didn't mean edge case to user. I meant edge cases regarding various states of CMP mapping structures in the code depending on when the two cmp create events occurred, such as during same IDE session, two separate IDE sessions, configuration edit as text event in between create events, etc. The reason is that these distinctions alter the impact of certain initializations present in the code and have to be accounted for in the fix. It may be that under some scenarios I outlined above, this problem does not even occur, due to the distinct initialization path. It is good to know it is a regression from 4.1 though. That is very strange because no CMP mapping changes have been made to the plugin at this point. However there are some changes made elsewhere that could have altered the initialization code path for the mapping update function and broken this. I will investigate this possiblity by examining what happens in 4.1.
What I've found is that the mapping is actually done and shown properly if you open it in the config ui, but the xml does not contain the new updates and the save all button is disabled. Peter just replied to me that he made a major overhaul of the saving code due to the number of bugs and inefficiencies it had and that might have caused a regression in this area.
It turns out that no property change events were formally sent by the DConfigBeans to the rest of the world when CMP properties were initialized en masse by mapCmpBeans, as in this case. So when the second batch of CMP's were created, their relationships were initialized, but never saved to disk. The first set of CMP relationships was saved as a side effect of seting the CmpResource property. Had there already been a CmpResource property, the first set wouldn't have been saved either. So this bug surfaced when I cleaned up the extraneous events a few months ago. It worked in 4.1 since there were extra change events being sent that caused the data to be saved for the wrong reasons. I added an explicit change event for mapCmpBeans that is fired if the new mappings cause any changes. http://serverplugins.netbeans.org/source/browse/serverplugins/sun/sunddui/src/org/netbeans/modules/j2ee/sun/share/configbean/EjbJarRoot.java?r1=1.11&r2=1.12
[build 20051207]