Skip to main content

Can anyone get @Inheritance to work in b37?

7 replies [Last post]
cayhorstmann
Offline
Joined: 2003-06-13

I keep getting a NPE when deploying my app in b37. I have tracked it down to the use of @Inheritance (see https://glassfish.dev.java.net/issues/show_bug.cgi?id=267). I tinkered with this for a while, trying to give Toplink some hints, but had no success

Can anyone else get @Inheritance to work in b37? If so, could you post a sample?

Thanks,

Cay

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pramodgo
Offline
Joined: 2005-04-05

The bug that was reported where if you define @Inheritance w/o DiscriminatorColumn and DiscriminatorValue annotations has been fixed. The code changes were checked in today.

ss141213
Offline
Joined: 2005-03-30

Thank you very much for taking the time to report the logging issues. We have taken a note of it and they will be addressed soon. You are most welcome to prvide patches to improve it as well.

Thanks,
Sahoo

mperezma
Offline
Joined: 2005-03-22

I just came here to post about @Inheritance problems in b37 :)

b32d - Does not find any primary key in the subclasses (primary key is defined in the superclass).
b32g - Same as b32d
b33 - Same as b32g
b35 - All works fine
b36 - All works fine
b37 - If you don't use a JTA datasource, you MUST specify transaction-type="RESOURCE_LOCAL" in persistence.xml. Anyway, I'm getting this exception when using @Inheritance tag:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializerAgent.initializeFromAgent(JavaSECMPInitializerAgent.java:54)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializerAgent.premain(JavaSECMPInitializerAgent.java:47)
... 5 more
Caused by: java.lang.NullPointerException
at oracle.toplink.essentials.internal.annotations.EJBAnnotationsProcessor.processDiscriminatorValue(EJBAnnotationsProcessor.java:945)
at oracle.toplink.essentials.internal.annotations.EJBAnnotationsProcessor.processInheritance(EJBAnnotationsProcessor.java:1335)
at oracle.toplink.essentials.internal.annotations.EJBAnnotationsProcessor.processEntityClass(EJBAnnotationsProcessor.java:1144)
at oracle.toplink.essentials.internal.annotations.EJBAnnotationsProcessor.processEntity(EJBAnnotationsProcessor.java:1090)
at oracle.toplink.essentials.internal.annotations.EJBAnnotationsProcessor.processEntityClass(EJBAnnotationsProcessor.java:1125)
at oracle.toplink.essentials.internal.annotations.EJBAnnotationsProcessor.processORAnnotations(EJBAnnotationsProcessor.java:1848)
at oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:365)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.callPredeploy(JavaSECMPInitializer.java:147)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initPersistenceUnits(JavaSECMPInitializer.java:295)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initialize(JavaSECMPInitializer.java:314)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initializeFromAgent(JavaSECMPInitializer.java:331)
... 11 more
FATAL ERROR in native method: processing of -javaagent failed
Exception in thread "main"

mariO

pramodgo
Offline
Joined: 2005-04-05

There is a bug in our code if there is no DiscriminatorValue defined.
So until the code is fixed at our end, you should be able to continue working with your example by defining
DiscriminatorColumn and DiscriminatorValue annotations along with the Inheritance annotation.

cayhorstmann
Offline
Joined: 2003-06-13

Thank you very much! For the benefit of other GlassFish users, here is what you need to do:

In the superclass:

@Entity
@Inheritance(strategy=InheritanceType.JOINED) // or SINGLE_TABLE
@DiscriminatorValue(value="UserInfo") // <-- fixes bug in b37
public class UserInfo implements Serializable { ... }

Then, in each subclass:

@Entity
@DiscriminatorValue(value="Instructor") // <-- fixes bug in b37
public class Instructor extends UserInfo { ... }

BTW, I was amused to read in your issue tracker report that the stack traces don't work out for you either. I have a whole slew of ugly ones at http://www.horstmann.com/elvis/hated-error-messages.html (for vbkraemer's benefit who doesn't think there is much of a problem :-))

Thanks again for the prompt help,

Cay

pramodgo
Offline
Joined: 2005-04-05

Concur with Sahoo and thanks for reporting the error messages that you have seen with Glassfish.

Wanted to reply to one error message section that you had reported about the SQL Keyword "USER" :
-------------------------------------------------
Encountered "USER"
Scenario:
Naming an entity User is fatal (at least with Derby) because USER is a SQL keyword.
Message:
[sun-appserv-deploy] Command deploy executed successfully with following warning messages:

[sun-appserv-deploy] JDO76614: Deployment encountered SQL Exceptions:
[sun-appserv-deploy] JDO76609: Got SQLException executing statement "CREATE TABLE QUIZFORM (ID INTEGER NOT NULL,

TITLE VARCHAR(255), PRIMARY KEY (ID))": org.apache.derby.client.am.SqlException: Table/View 'QUIZFORM' already

exists in Schema 'APP'.
[sun-appserv-deploy] JDO76609: Got SQLException executing statement "CREATE TABLE USER (USERID VARCHAR(255) NOT

NULL, TYPE VARCHAR(255), EMAIL VARCHAR(255), PASSWORD VARCHAR(255), LASTNAME VARCHAR(255), FIRSTNAME VARCHAR(255),

MIDDLENAME VARCHAR(255), PRIMARY KEY (USERID))": org.apache.derby.client.am.SqlException: Syntax error: Encountered

"USER" at line 1, column 14.
(many more)
Comment:

1. This is an error; it should not be reported as successful deployment
2. The first error message (which is reported for every table other than USER) is misleading
3. It is not clear how Elvis can figure out from Syntax error: Encountered "USER" at line 1, column 14 that the

solution is to rename the User entity

The desired error message would be:
File elvis/entity/User.java line 13: Entity name User conflicts with SQL keyword
-------------------------------------------------

Our thinking is that failure to create/drop tables (which we refer to as java2db) should not affect the deployment
of the application. By deployment we mean that the application is registered to the server and once the application is registered, loaded and enabled, users can start using the application. This is the reason you see the message stating
[sun-appserv-deploy] Command deploy executed successfully

We deploy the application to the server and then try to create/drop the tables into the relevant database, using the corresponding jdbc driver. But we also wanted to ensure that the users do see any errors that we run into when trying to create/drop the tables. The thinking is that if the creation/drop of the tables failed, it is easier for the users to connect to the correct database and do the needful activity to rectify the problem, outside the scope of the application server environment.

For creating/dropping tables from the database we delegate the calls to the jdbc driver that has been specified in the database connection pool section of the server. When we get a SQLException back from the underlying jdbc driver
we just return the message back to the user as is. This is the reason that you see "org.apache.derby.client.am.SQLException" part in the error messages. Also if you look we have just one error
message "JDO76609" that returns any SQLException back to the user. Generally the SQLException reported by the jdbc
driver are self explanatory.

For comment 2:
If the asadmin option "--createtables=true", is used during deployment we do not drop any existing tables from the db. This would result in the message from the jdbc driver indicating that the table already exists.

The option "--dropandcreatetables=true" is valid for an application redeployment scenario, where we try to drop the existing table and create a new one based on the latest entities in your application. If this option is used for the first time with an application deployment scenario we treat it internally as "--createtables=true".

To get the desired error message that you have indicated, it would require us to introspect each and every message
being returned back by the jdbc driver and try to convert it to a meaningful message. I do not think we would want
to do this for each and every type of jdbc driver and message.

cayhorstmann
Offline
Joined: 2003-06-13

pramodgo writes: "To get the desired error message that you have indicated, it would require us to introspect each and every message being returned back by the jdbc driver and try to convert it to a meaningful message. I do not think we would want to do this for each and every type of jdbc driver and message."

I can see why you would not want to do that :-), but it still needs to be done.

Specifically, a productive developer needs two modes for GlassFish: 1) Development 2) Deployment.

In deployment mode, performance and security are paramount. Log the exception and move on.

The mantra in development mode is "file name...line number...file name...line number". EVERY error should be thrown into the developer's face, traced back to the offending file and line. That's what makes a developer productive.

Cheers,

Cay