Created attachment 31773 [details]
stack trace

I am able to reproduce this issue with this table only:

CREATE TABLE `ACCOUNT` (
  `ID_ACCOUNT` int(11) NOT NULL default '0',
  `MESTO` char(1) NOT NULL default '',
  `ID_UZIVATEL` int(11) NOT NULL default '0',
  `AMOUNT` float default NULL,
  PRIMARY KEY  (`ID_ACCOUNT`,`MESTO`),
  KEY `ID_UZIVATEL` (`ID_UZIVATEL`),
  KEY `MESTO` (`MESTO`),
  CONSTRAINT `ACCOUNT_ibfk_1` FOREIGN KEY (`ID_UZIVATEL`) REFERENCES `UZIVATEL`
(`ID`),
  CONSTRAINT `ACCOUNT_ibfk_2` FOREIGN KEY (`MESTO`) REFERENCES `MESTO` (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

The NPE is at the line that contained a hotfix and was removed when issue 74117
was fixed.

Didn't look at it yet, but it is probably different from 74117 (ACCOUNT does not
reference itself). I would say it has something to do with a part of the primary
key being also a foreign key. But just wildly guessing, I will look at it tomorrow.

I'm not saying it's the same bug, just that the null check for finding any 
columns that was the hotfix for that bug also prevented the NPE here.

It is indeed caused by a part of the composite primary key (MESTO) being also a
foreign key. Both a CMP and a CMR field are generated in the maping model for
the MESTO column and the uniquing algorithm causes the CMR field to be renamed
to mesto-1, for which there are of course no mappings. The mapping model tries
to work around this situation (see DbSchemaEjbGenerator.java:355), but it
probably fails when the name of the foreign key column (here "MESTO") is the
same as the name of the referenced table ("MESTO"). An approach to fix this
would be to detect the conflict and generate another name for the CMR field,
like "mestoRef" or something.

The workaround is to use a different name than the referenced table name for the
foreign key column name. 

When I applied the workaround the generation process didn't fail, but a a
setMesto() method was generated in Account which allows changing the primary key
value. But in 2.1.4. the JPA spec says the application should not change the
primary key value. Should we then not generate the setter for mesto? I think the
situation is similar in EJB 2.1, isn't it? 

Should be fixed for 5.5.

Pavle, Rochelle, please comment.

Can you attach the full DB script for Java DB so that it would be easily
reproducible? I tried to create a script with part of PK being a foreign key but
entity generation works OK. What did I miss?

DROP TABLE "ACCOUNT";  DROP TABLE "UZIVATEL";

CREATE TABLE "UZIVATEL" ( "ID" int not null,  "JMENO" varchar(40),  PRIMARY KEY
("ID"));

CREATE TABLE "ACCOUNT" (  "ID_ACCOUNT" int NOT NULL, "ID_UZIVATEL" int NOT NULL,
  "AMOUNT" float default NULL,   PRIMARY KEY  ("ID_ACCOUNT","ID_UZIVATEL"),
  CONSTRAINT "ACCOUNT_ibfk_1" FOREIGN KEY ("ID_UZIVATEL") REFERENCES "UZIVATEL"
("ID")
);

sorry, I was not reading carefully, I got it now. The script for Java DB:

DROP TABLE "ACCOUNT"; DROP TABLE "UZIVATEL";

CREATE TABLE "UZIVATEL" (  "ID" int not null,   "JMENO" varchar(40), 
  PRIMARY KEY ("ID") );

CREATE TABLE "ACCOUNT" (   "ID_ACCOUNT" int NOT NULL,   "UZIVATEL" int NOT NULL,
  "AMOUNT" float default NULL,   PRIMARY KEY  ("ID_ACCOUNT","UZIVATEL"),
  CONSTRAINT "ACCOUNT_ibfk_1" FOREIGN KEY ("UZIVATEL") REFERENCES "UZIVATEL" ("ID")
);

We currently (also) generate public setter methods for pk fields when it's not
overlapping with a fk.  When I asked about whether we should generate those with
a different modifier, we decided not to because of the different id/generator
strategies.  So, I'm not sure how generation of a setter is different in this
case...

I'll ask for more input from the rest of the persistence team.

Please also see issue 77730 which is related to overlapping pk/fk.

Marina confirmed that we should not worry about skipping the set method
generated that affects the pk. This is because there are no managed
relationships in Java Persistence spec, and that requires the user to set it on
all sides.

*** Issue 82382 has been marked as a duplicate of this issue. ***

When renaming a field during the uniquifying process, its mapping in
CMPMappingModel.getCmrFieldMapping() should be updated accordingly, which
currently it is not. This will cause a getUzivatel1() method to be generated for
the schema in this issue, which is not 100% perfect, but at least does not cause
the generation process to fail.

Fixed.

Checking in
src/org/netbeans/modules/j2ee/persistence/entitygenerator/DbSchemaEjbGenerator.java;
/cvs/j2ee/persistence/src/org/netbeans/modules/j2ee/persistence/entitygenerator/Attic/DbSchemaEjbGenerator.java,v
 <-- DbSchemaEjbGenerator.java
new revision: 1.1.2.1.2.11; previous revision: 1.1.2.1.2.10
done