[GLASSFISH-6782] Do not bundle JavaDB Created: 15/Nov/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: mkarg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,782

 Description   

Java SE 6 comes bundles with Java DB.
GlassFish v3 Prelude comes bundled with Java DB.
From the administrator's view it makes no sense to have twice the binaries.
Would be great to share a single Java DB installation.
At least of Microsoft Windows this is easy: Split the Java DB installation out
of the Java SE / GF installer and make it it's own product. So Windows will know
that there is a single "central" Java DB installation. Then tell Java SE's /
GlassFish's installer that it is dependent of this central installation. If it
is not there, add it to the central place. If it already is there, but has an
older version, add the new version. If it is already there but has the same or
later version, do not add your own version. It sounds just so simple, so why not
doing it?



 Comments   
Comment by naman_mehta [ 25/May/10 ]

Please assign this to appropriate owner.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4856] Improved warning text Created: 22/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: verifier
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: mkarg Assignee: mkarg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,856
Status Whiteboard:

v2.1.1_exclude


 Description   

Just got this message:

Exception Description: The @JoinColumns on the annotated element [private
de.quipsy.entities.person.Person de.quipsy.entities.groupuser.GroupUser.usexr]
from the entity class [class de.quipsy.entities.groupuser.GroupUser] is
incomplete. When the source entity class uses a composite primary key, a
@JoinColumn must be specified for each join column using the @JoinColumns. Both
the name and the referenceColumnName elements must be specified in each such
@JoinColumn.

The verifier complains that I am using a composite primary key. In fact, I do
not. My code is using an @Embeddable primary key class, but that class has only
one single non-transient field, so it is not a composite primary key but "just"
an embedded id.

Either the message should be changed to replace the work "composite primary key"
by "@EmbeddableId", or the verifier should just not complain (depending on
whether or not it is correct to complain is this case, since it makes no sense
to have JoinColumnS be used – as there is only ONE JoinColumn).



 Comments   
Comment by mkarg [ 24/Apr/08 ]

I checked the EJB 3.0 Persistence specification, and in chapter "9.1.6
JoinColumn Annotation" it says:

"If there is more than one join column, a JoinColumn annotation must be
specified for each join column using the JoinColumns annotation. Both the name
and the referencedColumnName elements must be specified in each such JoinColumn
annotation."

"(Optional) ... (Default only applies if single join column is being used.) The
same name as the primary key column of the referenced table."

The specification clearly says that it is solely about the number of join
columns ("single join column", "more than one join column") not about whether
that single column is inside of the entity itself or whether it is a
@EmbeddedId. That means, that the verifier does a failure when asking for
referencedColumnName to be specified in my case.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by mkarg [ 27/Apr/09 ]

Increased priority to P2 according to
https://glassfish.dev.java.net/public/IssueTrackerPriority.html as this is a
violation of the JPA specification. As I mentioned in my comments on April 25, 2008:

The specification clearly says that it is solely about the number of join
columns ("single join column", "more than one join column") not about whether
that single column is inside of the entity itself or whether it is a
@EmbeddedId. That means, that the verifier does a failure when asking for
referencedColumnName to be specified in my case.

Comment by Sanjeeb Sahoo [ 19/Sep/09 ]

Please attach a test case and assign the issue back to me.

Comment by mkarg [ 25/Sep/09 ]

Requested test case will get provided in October.

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by mkarg [ 25/Jul/11 ]

Sorry for not answering for so long time, but we had lots of other things to do.

Here is how to reproduce the problem:

Entity X references Entity Y using a column named "foo". Since the column has a different name ("foo") than the Java variable ("y"), the annotation @JoinColumn is used to specify that column name:

@Entity public class X

{ @Id private int id; @ManyToOne @JoinColumn(name = "foo") private Y y; }

Entity Y is (for design reasons) not using @Id but @EmbeddedId:

@Entity
public class Y

{ @EmbeddedId private YPK pk; }

The primary key class YPK looks like this:

@Embeddable public class YPK

{ private int id; }

Obviously this is a primary key class, but it is not NOT a COMPOUND key. All code is compliant to the JPA 1.0 and 2.0 specifications. A JPA provider should find all information needed since it is either explicitly provided or can be found implicitly.

But what TopLink did and what EclipseLink still does is to complain:

Exception [EclipseLink-7220] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The @JoinColumns on the annotated element [field y] from the entity class [class entities.X] is incomplete. When the source entity class uses a composite primary key, a @JoinColumn must be specified for each join column using the @JoinColumns. Both the name and the referencedColumnName elements must be specified in each such @JoinColumn.

This is just ridiculous and false. The @JoinColumns (look at the trailing s!) is not incomplete, as it is not provided at all. The source entity class is NOT using a composite primary key, so the need for referencedColumn name is NOT given.

This is a violation of the JPA specification, as it enforces referencedColumnName not only for COMPOUND keys (as per the spec) but also for SINGLE-COLUMN-EMBEDDED-KEYS (as NOT per the spec). Such, the application will run on other JPA providers, but enforces a source code change to run on EclipseLink. This breaks WORA and thus is inacceptable for ISVs.

Either change the JPA specification to clearly mandate that referenceColumnName is to be used for SINGLE-COLUMN-EMBEDDED-KEYS in addition to COMPOUND keys, OR fix EclipseLink to not complain about this. But in any case, you must change the text of the error message as it says the @JoinColumns (look a tht trailins!) annotations would be incomplete – it actually is not given at all, so it cannot be INCOMPLETE.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





Generated at Sun Apr 30 15:58:50 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.