JPA Inheritance across DCs

[former_member182046]

Hi,

I'm trying to learn how to implement JPA inheritance across DCs.

For this purpose, I have created one application "base" (EAR + EJB) that contains a "Person" entity supporting inheritance type JOINED. This application contains also Stateless Session Bean for managing Persons.

A second application "top" contains an "Employee" entity that inherits from "Person". This application contains a Stateless Session Bean for managing Employees that delegates some of the calls to the Person DAO.

When everything is together in one application, it works perfectly well. Splitting it up in two applications, I left the data-source-aliases.xml and persistence.xml in the base application the same.

I created dependencies (both COMPILATION and ASSEMBLY) from the "top" application to the "base" application and exposed everything in these public parts.

I also created an application reference in the "top" application application-j2ee-engine.xml.

Now I'm getting various errors depending on how I modify the "top" application.

I tried adding identical data-source-aliases.xml and persistence.xml files - didn't work.

I tried adding "<jar-file>aoksystems.de_bottomearpp_ass.jar</jar-file>" in the persistence XML and removing the <jta-data-source> tag.

When deploying the "top" application, I get a warning in NWDS but errors in the log in NWA.

[ERROR CODE DPL.DS.5030] Clusterwide exception: [server ID 9858650:[ERROR CODE DPL.DS.5029] Exception in operation [startApp] with application [aoksystems.de/jpasecond~ear].

-> [ERROR CODE DPL.DS.5030] Clusterwide exception: [com.sap.engine.services.jndi.persistent.exceptions.NameNotFoundException: Object not found in lookup of JPA_DEFAULT.

I hope the JPA gurus can help me get this to work. Thanks a lot in advance!

Cheers,

Thorsten

[former_member182046]

Let me try to pose the question in a simpler way.

Is it possible to have an EAR application "1st EAR" which contains:

1. a JPA entity such as "Person"

2. a DAO SLSB with a "findPerson" method that loads this entity from the database

A second EAR application "2nd EAR" (or server library?) contains only a JPA entity "Employee" which is a subclass of Person, JPA inheritance type JOINED.

1st EAR does not know 2nd EAR statically but can look up the names of the EAR, DC, any classes etc. from configuration at run time.

The problem seems to be: When the EntityManager in "1st EAR" retrieves a record for an Employee and tries to instantiate that class, it won't find it in the classpath, so some mechanism for making a class from a statically not referenced deployment unit is required.

URLClassLoader? Or could "2nd EAR" make its entities known to the 1st EAR classloader at startup time?

Thanks a lot in advance,

Thorsten

[adrian_goerler]

Hi Thorsten,

what happens if a persistence unit spans two DCs is not really well-defined.

The case you are looking at is especially pathological:

The application 1stEAR does not know that Person is part of a hierarchy and hence will not populate the discriminator column. Moreover, as you observed, 1stEAR cannot create an instance of Employee as the class Employee is invisible.

Persistence units are not to be extended in a different DC and I can strongly recommend to collocate all entities in a single DC only.

-Adrian

[former_member182046]

Hi Adrian,

Thank you for your input. I hoped very much that you would reply.

I think I haven't motivated the situation sufficiently, so let me explain why it is not entirely pathological.

Suppose you're constructing a contract management application for an insurance company. There are different types of insurances (life insurance, car, building), each with different data structures and business processes, but with a common core.

Now you split the development up and say you create one component with the common core that is identical for all aspects of insurance contract management: a "contract" root entity with common attributes, DAOs for this entity, business partner management, a generic billing engine, etc.

Furthermore, in software components on top of the core/framework, you create components for the specialties of life insurance, building insurance, and car insurance. These are dependend on the core and use its generic functions but add extra functionalities such as life-specific business processes, UIs, business logic, contract attributes in additional database tables and attributes of subclasses or classes joined through composition.

Clearly, a cyclic dependency between life and core is not possible or desired. Core should not know life, car, and building, but its generic services should be able to operate on their objects. This architecture is quite common and nothing out of the ordinary. Life, car, and building would just use (implement) the interfaces provided by core and thus enable core to operate on their objects in a polymorphic fashion.

Take Web Dynpro as an example. Core provides a dialogue framework that leaves some things blank and exposes WD interfaces. Life implements these interfaces. At run time, core looks up the names of life's WD DCs and components and joins them in without any static references. The reference is entirely dynamical because it relies on a configuration that is deployed with Life and not with Core.

Now to get the same kind of behaviour for a core JPA entity and DAO seems to be problematic. The ability to operate on unknown (at design time/build time) subclasses of a known class that are deployed in an archive that is also unknown at design time but known at run time from a configuration (file, JNDI, ...) is quite normal in framework programming IMHO.

Thanks a lot for reading through all this.

Cheers,

Thorsten