[
https://issues.apache.org/jira/browse/ARIES-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091693#comment-13091693
]
Timothy Ward edited comment on ARIES-736 at 8/26/11 9:37 AM:
-------------------------------------------------------------
As for ARIES-735:
---------------
The Aries JPA container is not actually an implementation of the OSGi JPA
Service specification. It provides managed JPA, not the unmanged support
described in the spec. Part of providing this managed support means that the
persistence unit lifecycle in Aries does not really fit with the concept of the
EntityManagerFactoryBuilder, or with incomplete persistence units.
Effectively this support is intentionally missing from Aries because
implementing it would prevent us from providing container-managed JPA. As Aries
is trying to provide a container-managed programming model this would be a
significant issue. I'm happy to look again into whether providing an
EntityManagerFactoryBuilder is technically feasible, but as we still won't
attempt to pass the current JPA service specification I don't know if providing
it would actually help you.
---------------
The reasoning for not linking with Data Source Factory services is that for
managed JPA one uses managed resources. In the JPA spec (the Java one, not the
OSGi one) this is done through JNDI using the <jta-data-source> and
<non-jta-data-source> elements. As a result this is also what the Aries
container uses. The Aries container offers no integration with the JDBC
service, though this could theoretically be added (hopefully without further
complicating the lifecycle of the EntityManagerFactory services).
One question I do have is the following - How should the Aries container decide
when to wait for a DataSourceFactory service rather than passing the JDBC
properties on to the persistence provider? It is entirely possible that the
user has packaged their JDBC driver along with the persistence unit and does
not want to use the JDBC service, just to load the classes as in the JPA spec
(again, the Java one).
Tim
was (Author: timothyjward):
As for ARIES-635:
---------------
The Aries JPA container is not actually an implementation of the OSGi JPA
Service specification. It provides managed JPA, not the unmanged support
described in the spec. Part of providing this managed support means that the
persistence unit lifecycle in Aries does not really fit with the concept of the
EntityManagerFactoryBuilder, or with incomplete persistence units.
Effectively this support is intentionally missing from Aries because
implementing it would prevent us from providing container-managed JPA. As Aries
is trying to provide a container-managed programming model this would be a
significant issue. I'm happy to look again into whether providing an
EntityManagerFactoryBuilder is technically feasible, but as we still won't
attempt to pass the current JPA service specification I don't know if providing
it would actually help you.
---------------
The reasoning for not linking with Data Source Factory services is that for
managed JPA one uses managed resources. In the JPA spec (the Java one, not the
OSGi one) this is done through JNDI using the <jta-data-source> and
<non-jta-data-source> elements. As a result this is also what the Aries
container uses. The Aries container offers no integration with the JDBC
service, though this could theoretically be added (hopefully without further
complicating the lifecycle of the EntityManagerFactory services).
One question I do have is the following - How should the Aries container decide
when to wait for a DataSourceFactory service rather than passing the JDBC
properties on to the persistence provider? It is entirely possible that the
user has packaged their JDBC driver along with the persistence unit and does
not want to use the JDBC service, just to load the classes as in the JPA spec
(again, the Java one).
Tim
> Aries does not take into account the concept of complete/incomplete
> Persistence Units
> -------------------------------------------------------------------------------------
>
> Key: ARIES-736
> URL: https://issues.apache.org/jira/browse/ARIES-736
> Project: Aries
> Issue Type: Bug
> Components: JPA
> Affects Versions: 0.3
> Reporter: Christoph Läubrich
>
> The OSGi spec states (r4.2 127.3.1):
> "Entity Manager Factory service - Provides an EntityManagerFactory object
> that depends on a complete
> Persistence Unit. That is, it is associated with a registered Data Source
> Factory service."
> The current behaiviour is, that aries registers a Entity Manager Factory
> service regardles of the precence of a matching Data Source Factory service
> (Also see 127.5.3 Data Source Factory Service Matching).
> If no such matching is performed, it alternateively must register a Entity
> Manager Factory Builder service (not currently supported by Aries see
> ARIES-735 for reference).
> What infact is unclear to me is:
> 127.5.3 states that: "Once the Data Source Factory is obtained, the JPA
> Provider must obtain a DataSource object. This
> Data Source object must then be used for all relational database access."
> It does not state how this DataSource could be handed over to the
> PersistenceProvider for later usage.
> It might be suitable to insert a level of indirection here:
> - Aries just reads the persitence units and registers an Entity Manager
> Factory Builder service
> - PersistencProvider specific bundles match these with the required data
> source and register the Entity Manager Factory service
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
