date:20180525

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Paul McCulloch

Hibernate usually does a reasonable job of auto detecting the dialect, in
my experience. If you need to override this then Aries JPA supports
creating a configuration file /etc/org.apache.aries.jpa..cfg where
you can override hibernate.dialect. Beware if you have a "-" in the PU name
as I think fileinstall we try and create a factory config.

I can't recall where I got this info from. It might have been here:
http://karaf.922171.n3.nabble.com/Dynamic-parameters-in-persistence-xml-td4043602.html

On 25 May 2018 at 06:46, Jean-Baptiste Onofré  wrote:

> Hi Alex,
>
> the dialect HAS to be in the persistence.xml (it's in the JPA spec).
>
> AFAIK, Aries JPA doesn't provide a mechanism to provide the dialect
> externally from the persistence.xml.
>
> Even the Aries JPA itests define the dialect there:
>
> https://github.com/apache/aries-jpa/blob/master/itests/
> jpa-container-testbundle/src/main/resources/META-INF/persistence.xml#L40
>
> Further more, dialect also depends of the engine you are using
> (hibernate, openjpa, eclipselink).
>
> Regards
> JB
>
> On 24/05/2018 21:26, Alex Soto wrote:
> > If I change my persistence.xml to this:
> >
> >
> > 
> > osgi:service/javax.sql.DataSource/(osgi.
> jndi.service.name=responder)
> > osgi:service/javax.sql.DataSource/(osgi.
> jndi.service.name=responder)
> >
> > 
> >
> > And the configuration entries to:
> >
> > 
> >
> >   javax.persistence.provider=org.hibernate.jpa.
> HibernatePersistenceProvider
> > *javax.persistence.jdbc.driver=org.mariadb.jdbc.Driver*
> > hibernate.dialect=org.hibernate.dialect.MariaDBDialect
> > hibernate.show_sql=false
> > hibernate.format_sql=true
> > hibernate.hbm2ddl.auto=none
> > 
> >
> > Then the error Is:
> >
> >
> > java.lang.IllegalArgumentException: Cannot rebind to a different
> > database driver, as per the JPA service specification
> > at
> > org.apache.aries.jpa.container.impl.AriesEntityManagerFactoryBuild
> er.processProperties(AriesEntityManagerFactoryBuilder.java:225)
> > ~[?:?]
> > at
> > org.apache.aries.jpa.container.impl.AriesEntityManagerFactoryBuild
> er.createEntityManagerFactory(AriesEntityManagerFactoryBuild
> er.java:173) ~[?:?]
> > at
> > org.apache.aries.jpa.container.impl.ManagedEMF.
> updated(ManagedEMF.java:75)
> > ~[?:?]
> > at
> > org.apache.felix.cm.impl.helper.ManagedServiceTracker.
> updated(ManagedServiceTracker.java:189)
> > ~[8:org.apache.felix.configadmin:1.8.16]
> > at
> > org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(
> ManagedServiceTracker.java:152) [8:org.apache.felix.configadmin:1.8.16]
> > at
> > org.apache.felix.cm.impl.helper.ManagedServiceTracker.
> provideConfiguration(ManagedServiceTracker.java:85) [8:org.apache.felix.
> configadmin:1.8.16]
> > at
> > org.apache.felix.cm.impl.ConfigurationManager$
> ManagedServiceUpdate.provide(ConfigurationManager.java:
> 1479) [8:org.apache.felix.configadmin:1.8.16]
> > at
> > org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(
> ConfigurationManager.java:1435) [8:org.apache.felix.configadmin:1.8.16]
> > at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
> > [8:org.apache.felix.configadmin:1.8.16]
> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
> > [8:org.apache.felix.configadmin:1.8.16]
> > at java.lang.Thread.run(Thread.java:748) [?:?]
> >
> >
> > If I remove the
> > line *javax.persistence.jdbc.driver=org.mariadb.jdbc.Driver *from the
> > config file above, then I get the previous error about configuration not
> > being completed.  What I am trying to do is to not  hard code
> >  the /hibernate.dialect /inside the bundle, so I can switch to a
> > different database without having to rebuild.
> >
> > Also, my DataSource is already created by PAX JDBC Config and this I
> > don’t want to change, since I am using PreHook facility there to run
> > LiquiBase migrations.
> > Any hints or examples appreciated.
> >
> >
> > Best regards,
> > Alex soto
> >
> >
> >
> >
> >> On May 24, 2018, at 1:41 PM, Alex Soto  >> > wrote:
> >>
> >> Hello,
> >>
> >> I am using Aries JPA 2.7.0, I am trying provide the JPA persistence
> >> configuration using configuration file.  So my persistence.xml.
> >>
> >>  >> xmlns="http://java.sun.com/xml/ns/persistence";
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
> >> http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd";>
> >>
> >>  >> transaction-type="JTA">
> >> org.hibernate.jpa.HibernatePersistenceProvider
> >> 
> >> 
> >>
> >>
> >> I deploy config file as part of my feature:
> >>
> >> 
> >> hibernate.dialect=org.hibernate.dialect.MariaDBDialect
> >> hibernate.show_sql=false
> >> hibernate.format_sql=true
> >> hibernate.hbm2ddl.auto=none
> >>
> >>   jta-data-source=osgi:service/javax.sql.DataSource/(
> osgi.jndi.service.name=responder)
> >

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Jean-Baptiste Onofré

Hi Paul,

yes, I remember this discussion, but AFAIR, it's always overriden by the
dialect in the persistence.xml.

Regards
JB

On 25/05/2018 13:00, Paul McCulloch wrote:
> Hibernate usually does a reasonable job of auto detecting the dialect,
> in my experience. If you need to override this then Aries JPA supports
> creating a configuration file /etc/org.apache.aries.jpa..cfg
> where you can override hibernate.dialect. Beware if you have a "-" in
> the PU name as I think fileinstall we try and create a factory config.
> 
> I can't recall where I got this info from. It might have been
> here: 
> http://karaf.922171.n3.nabble.com/Dynamic-parameters-in-persistence-xml-td4043602.html
> 
> On 25 May 2018 at 06:46, Jean-Baptiste Onofré  > wrote:
> 
> Hi Alex,
> 
> the dialect HAS to be in the persistence.xml (it's in the JPA spec).
> 
> AFAIK, Aries JPA doesn't provide a mechanism to provide the dialect
> externally from the persistence.xml.
> 
> Even the Aries JPA itests define the dialect there:
> 
> 
> https://github.com/apache/aries-jpa/blob/master/itests/jpa-container-testbundle/src/main/resources/META-INF/persistence.xml#L40
> 
> 
> 
> Further more, dialect also depends of the engine you are using
> (hibernate, openjpa, eclipselink).
> 
> Regards
> JB
> 
> On 24/05/2018 21:26, Alex Soto wrote:
> > If I change my persistence.xml to this:
> > 
> > 
> > 
> > 
> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name
> =responder)
> > 
> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name
> =responder)  
> >  
> > 
> > 
> > And the configuration entries to:
> > 
> > 
> >  
> >   
> javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider
> >     *javax.persistence.jdbc.driver=org.mariadb.jdbc.Driver*
> >     hibernate.dialect=org.hibernate.dialect.MariaDBDialect
> >     hibernate.show_sql=false
> >     hibernate.format_sql=true
> >     hibernate.hbm2ddl.auto=none
> > 
> >
> > Then the error Is:
> >
> >
> > java.lang.IllegalArgumentException: Cannot rebind to a different
> > database driver, as per the JPA service specification
> > at
> >
> 
> org.apache.aries.jpa.container.impl.AriesEntityManagerFactoryBuilder.processProperties(AriesEntityManagerFactoryBuilder.java:225)
> > ~[?:?]
> > at
> >
> 
> org.apache.aries.jpa.container.impl.AriesEntityManagerFactoryBuilder.createEntityManagerFactory(AriesEntityManagerFactoryBuilder.java:173)
>  ~[?:?]
> > at
> >
> org.apache.aries.jpa.container.impl.ManagedEMF.updated(ManagedEMF.java:75)
> > ~[?:?]
> > at
> >
> 
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)
> > ~[8:org.apache.felix.configadmin:1.8.16]
> > at
> >
> 
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)
>  [8:org.apache.felix.configadmin:1.8.16]
> > at
> >
> 
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)
>  [8:org.apache.felix.configadmin:1.8.16]
> > at
> >
> 
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1479)
>  [8:org.apache.felix.configadmin:1.8.16]
> > at
> >
> 
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1435)
>  [8:org.apache.felix.configadmin:1.8.16]
> > at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
> > [8:org.apache.felix.configadmin:1.8.16]
> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
> > [8:org.apache.felix.configadmin:1.8.16]
> > at java.lang.Thread.run(Thread.java:748) [?:?]
> >
> >
> > If I remove the
> > line *javax.persistence.jdbc.driver=org.mariadb.jdbc.Driver *from the
> > config file above, then I get the previous error about configuration not
> > being completed.  What I am trying to do is to not  hard code
> >  the /hibernate.dialect /inside the bundle, so I can switch to a
> > different database without having to rebuild.
> > 
> > Also, my DataSource is already created by PAX JDBC Config and this I
> > don’t want to change, since I am using PreHook facility there to run
> > LiquiBase migrations.
> > Any hints or examples appreciated.
> > 
> > 
> > Best regards,
> > Alex soto
> > 
> > 
> > 
> > 
> >> On May 24, 2018, at 1:41 PM, Alex Soto  
> >> >> wrote:
> >>
>

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Paul McCulloch

The dialect can be left out of the pu.xml though. I started down this path,
but in the end have just relied on hibernate to select the correct dialect.
I deploy the same bundles on H2, Oracle & MSSQL with this approach.


On 25 May 2018 at 12:51, Jean-Baptiste Onofré  wrote:

> Hi Paul,
>
> yes, I remember this discussion, but AFAIR, it's always overriden by the
> dialect in the persistence.xml.
>
> Regards
> JB
>
> On 25/05/2018 13:00, Paul McCulloch wrote:
> > Hibernate usually does a reasonable job of auto detecting the dialect,
> > in my experience. If you need to override this then Aries JPA supports
> > creating a configuration file /etc/org.apache.aries.jpa..cfg
> > where you can override hibernate.dialect. Beware if you have a "-" in
> > the PU name as I think fileinstall we try and create a factory config.
> >
> > I can't recall where I got this info from. It might have been
> > here: http://karaf.922171.n3.nabble.com/Dynamic-parameters-
> in-persistence-xml-td4043602.html
> >
> > On 25 May 2018 at 06:46, Jean-Baptiste Onofré  > > wrote:
> >
> > Hi Alex,
> >
> > the dialect HAS to be in the persistence.xml (it's in the JPA spec).
> >
> > AFAIK, Aries JPA doesn't provide a mechanism to provide the dialect
> > externally from the persistence.xml.
> >
> > Even the Aries JPA itests define the dialect there:
> >
> > https://github.com/apache/aries-jpa/blob/master/itests/
> jpa-container-testbundle/src/main/resources/META-INF/persistence.xml#L40
> >  jpa-container-testbundle/src/main/resources/META-INF/persistence.xml#L40>
> >
> > Further more, dialect also depends of the engine you are using
> > (hibernate, openjpa, eclipselink).
> >
> > Regards
> > JB
> >
> > On 24/05/2018 21:26, Alex Soto wrote:
> > > If I change my persistence.xml to this:
> > >
> > >
> > >  transaction-type="JTA">
> > > osgi:service/javax.sql.DataSource/(osgi.
> jndi.service.name
> > =responder)
> > > osgi:service/javax.sql.DataSource/(osgi.
> jndi.service.name
> > =responder)
> > >
> > > 
> > >
> > > And the configuration entries to:
> > >
> > > 
> > >
> > >   javax.persistence.provider=org.hibernate.jpa.
> HibernatePersistenceProvider
> > > *javax.persistence.jdbc.driver=org.mariadb.jdbc.Driver*
> > > hibernate.dialect=org.hibernate.dialect.MariaDBDialect
> > > hibernate.show_sql=false
> > > hibernate.format_sql=true
> > > hibernate.hbm2ddl.auto=none
> > > 
> > >
> > > Then the error Is:
> > >
> > >
> > > java.lang.IllegalArgumentException: Cannot rebind to a different
> > > database driver, as per the JPA service specification
> > > at
> > >
> > org.apache.aries.jpa.container.impl.AriesEntityManagerFactoryBuild
> er.processProperties(AriesEntityManagerFactoryBuilder.java:225)
> > > ~[?:?]
> > > at
> > >
> > org.apache.aries.jpa.container.impl.AriesEntityManagerFactoryBuild
> er.createEntityManagerFactory(AriesEntityManagerFactoryBuild
> er.java:173) ~[?:?]
> > > at
> > >
> > org.apache.aries.jpa.container.impl.ManagedEMF.
> updated(ManagedEMF.java:75)
> > > ~[?:?]
> > > at
> > >
> > org.apache.felix.cm.impl.helper.ManagedServiceTracker.
> updated(ManagedServiceTracker.java:189)
> > > ~[8:org.apache.felix.configadmin:1.8.16]
> > > at
> > >
> > org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(
> ManagedServiceTracker.java:152) [8:org.apache.felix.configadmin:1.8.16]
> > > at
> > >
> > org.apache.felix.cm.impl.helper.ManagedServiceTracker.
> provideConfiguration(ManagedServiceTracker.java:85) [8:org.apache.felix.
> configadmin:1.8.16]
> > > at
> > >
> > org.apache.felix.cm.impl.ConfigurationManager$
> ManagedServiceUpdate.provide(ConfigurationManager.java:
> 1479) [8:org.apache.felix.configadmin:1.8.16]
> > > at
> > >
> > org.apache.felix.cm.impl.ConfigurationManager$
> ManagedServiceUpdate.run(ConfigurationManager.java:
> 1435) [8:org.apache.felix.configadmin:1.8.16]
> > > at org.apache.felix.cm.impl.UpdateThread.run0(
> UpdateThread.java:141)
> > > [8:org.apache.felix.configadmin:1.8.16]
> > > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.
> java:109)
> > > [8:org.apache.felix.configadmin:1.8.16]
> > > at java.lang.Thread.run(Thread.java:748) [?:?]
> > >
> > >
> > > If I remove the
> > > line *javax.persistence.jdbc.driver=org.mariadb.jdbc.Driver *from
> the
> > > config file above, then I get the previous error about
> configuration not
> > > being completed.  What I am trying to do is to not  hard code
> > >  the /hibernate.dialect /inside the bundle, so I can switch to a
> > > different database without having to rebuil

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Tim Ward

Hi Alex,

It looks like you’ve managed to slide into a slightly awkward gap between the 
expected ways of configuring your persistence unit.

The main issue here is that it is expected that you either include all 
DataSource information and configuration in the persistence.xml, or you don’t 
put anything into the persistence.xml at all and do everything in configuration 
admin. The problem is that the configuration admin model does not support 
setting JNDI names for the DataSources, only the use of DataSource factories. 
This is why you end up getting errors about the configuration being 
“incomplete” - the container gets confused about the mixture of sources of 
datasource configuration data.

The best option I can come up with at the moment is to actually use the builder 
yourself by doing something like:

@Component
public class EMFConfigurator {

@Reference
private EntityManagerFactoryBuilder emfb;

@Reference
private DataSource ds;

@Reference
private DataSource ds2;

private EntityManagerFactory emf;

@Activate
void start(Map props) {
   Map jpaProps = new HashMap<>(props);
   
  
   jpaProps.put(“javax.persistence.jtaDataSource”, ds);
   jpaProps.put(“javax.persistence.nonJtaDataSource, ds2);

   // Or for resource local just use one non-jta datasource
   // jpaProps.put(“javax.persistence.dataSource”, ds2);


   // This line also causes the emf to be registered as a service
   emf = emfb.createEntityManagerFactory(jpaProps);
}

@Deactivate
void stop() {
   // This unregisters the emf service
   emf.close();
}
}

With a persistence xml containing:




The configuration entries then target your component


emfb.target=(osgi.unit.name=responderPersistenUnit)
ds.target="(osgi.jndi.service.name=responder)”
ds2.target="(osgi.jndi.service.name=responder-non-jta)"
hibernate.dialect=org.hibernate.dialect.MariaDBDialect
hibernate.show_sql=false
hibernate.format_sql=true
hibernate.hbm2ddl.auto=none



Best Regards,

Tim

> On 25 May 2018, at 15:01, Paul McCulloch  wrote:
> 
> The dialect can be left out of the pu.xml though. I started down this path, 
> but in the end have just relied on hibernate to select the correct dialect. I 
> deploy the same bundles on H2, Oracle & MSSQL with this approach.
> 
> 
> On 25 May 2018 at 12:51, Jean-Baptiste Onofré  > wrote:
> Hi Paul,
> 
> yes, I remember this discussion, but AFAIR, it's always overriden by the
> dialect in the persistence.xml.
> 
> Regards
> JB
> 
> On 25/05/2018 13:00, Paul McCulloch wrote:
> > Hibernate usually does a reasonable job of auto detecting the dialect,
> > in my experience. If you need to override this then Aries JPA supports
> > creating a configuration file /etc/org.apache.aries.jpa..cfg
> > where you can override hibernate.dialect. Beware if you have a "-" in
> > the PU name as I think fileinstall we try and create a factory config.
> > 
> > I can't recall where I got this info from. It might have been
> > here: 
> > http://karaf.922171.n3.nabble.com/Dynamic-parameters-in-persistence-xml-td4043602.html
> >  
> > 
> > 
> > On 25 May 2018 at 06:46, Jean-Baptiste Onofré  > 
> > >> wrote:
> > 
> > Hi Alex,
> > 
> > the dialect HAS to be in the persistence.xml (it's in the JPA spec).
> > 
> > AFAIK, Aries JPA doesn't provide a mechanism to provide the dialect
> > externally from the persistence.xml.
> > 
> > Even the Aries JPA itests define the dialect there:
> > 
> > 
> > https://github.com/apache/aries-jpa/blob/master/itests/jpa-container-testbundle/src/main/resources/META-INF/persistence.xml#L40
> >  
> > 
> > 
> >  >  
> > >
> > 
> > Further more, dialect also depends of the engine you are using
> > (hibernate, openjpa, eclipselink).
> > 
> > Regards
> > JB
> > 
> > On 24/05/2018 21:26, Alex Soto wrote:
> > > If I change my persistence.xml to this:
> > > 
> > > 
> > >  > transaction-type="JTA">
> > > 
> > osgi:service/javax.sql.DataSource/(osgi.jndi.service.name 
> > 
> >  > >=responder)
> > > 
> > osgi:service/javax.sql.DataSource/(osgi.jndi.service.name 
> >

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Alex Soto

Hi All,

Thanks for input.  I think I found a sweet spot that seems to work, although I 
wish somebody from AriesJPA can confirm this is a valid approach.
I removed the Dialect and the other Hibernate specific settings out of my 
persistence.xml, but I have to keep the data source reference to JNDI:



osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)


The Pax-exam configuration file org.ops4j.datasource-responder.cfg remains the 
same:

osgi.jdbc.driver.name = mariadb
dataSourceName=responder
url = 
jdbc:mariadb://localhost:3306/responder?characterEncoding=UTF-8&useServerPrepStmts=true
user=XXX
password=XXX
databaseName=responder
ops4j.preHook=responderDB

AriesJPA configuration in my feature provides the dialect and the provider:



javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider
hibernate.dialect=org.hibernate.dialect.MariaDBDialect
hibernate.show_sql=false
hibernate.format_sql=true
hibernate.hbm2ddl.auto=none


When I run, first I can see in the log AriesJPA Container:

2018-05-25T09:01:22,580 | DEBUG | features-3-thread-1 | 
PersistenceBundleTracker | 46 - org.apache.aries.jpa.container - 2.7.0 
| Matching JPA contract for possible persistence bundle 
encryptedquery-responder-data
2018-05-25T09:01:22,594 | INFO  | features-3-thread-1 | 
PersistenceBundleTracker | 46 - org.apache.aries.jpa.container - 2.7.0 
| Found persistence unit responderPersistenUnit in bundle 
encryptedquery-responder-data with provider null.
2018-05-25T09:01:22,596 | INFO  | features-3-thread-1 | 
PersistenceProviderTracker   | 46 - org.apache.aries.jpa.container - 2.7.0 
| Found provider for responderPersistenUnit 
org.hibernate.jpa.HibernatePersistenceProvider
2018-05-25T09:01:22,618 | INFO  | features-3-thread-1 | LogHelper   
 | 134 - org.hibernate.core - 5.2.9.Final | HHH000204: Processing 
PersistenceUnitInfo [
name: responderPersistenUnit
...]
2018-05-25T09:01:22,688 | INFO  | features-3-thread-1 | Version 
 | 134 - org.hibernate.core - 5.2.9.Final | HHH000412: Hibernate Core 
{5.2.9.Final}
2018-05-25T09:01:22,691 | INFO  | features-3-thread-1 | Environment 
 | 134 - org.hibernate.core - 5.2.9.Final | HHH000206: 
hibernate.properties not found
2018-05-25T09:01:22,750 | INFO  | features-3-thread-1 | Version 
 | 133 - org.hibernate.common.hibernate-commons-annotations - 
5.0.1.Final | HCANN01: Hibernate Commons Annotations {5.0.1.Final}
2018-05-25T09:01:23,330 | WARN  | features-3-thread-1 | 
JdbcEnvironmentInitiator | 134 - org.hibernate.core - 5.2.9.Final | 
HHH000342: Could not obtain connection to query metadata : Unable to determine 
Dialect to use [name=, majorVersion=0]; user must register resolver or 
explicitly set 'hibernate.dialect'
2018-05-25T09:01:23,332 | DEBUG | features-3-thread-1 | 
PersistenceProviderTracker   | 46 - org.apache.aries.jpa.container - 2.7.0 
| Error while creating the Dummy EntityManagerFactory to allow weaving.
org.hibernate.service.spi.ServiceException: Unable to create requested service 
[org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]
at 
org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:271)
 ~[?:?]
at 
org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:233)
 ~[?:?]
at 
org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:210)
 ~[?:?]
at 
org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:51)
 ~[?:?]
at 
org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:94)
 ~[?:?]
at 
org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:242)
 ~[?:?]
at 
org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:210)
 ~[?:?]
at 
org.hibernate.boot.model.process.spi.MetadataBuildingProcess.handleTypes(MetadataBuildingProcess.java:352)
 ~[?:?]
at 
org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:111)
 ~[?:?]
at 
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:858)
 ~[?:?]
at 
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:885)
 ~[?:?]
at 
org.hibernate.osgi.OsgiPersistenceProvider.createContainerEntityManagerFactory(OsgiPersistenceProvider.java:96)
 ~[?:?]
at 
org.apache.aries.jpa.container.impl.PersistenceProviderTracker.createAndCloseDummyEMF(PersistenceProviderTra

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Paul McCulloch

That's what I do Alex. I didn't think I needed the non-jta-datasource (&
everything seems to work), but this thread has made me think I should go
back & re-asses that.

I'll also look again at the Transaction Control stuff - it was at 0.0.1
when I last looked, so I was nervous about relying on it. It looks like it
will fix my hack for MSSQL of having to fake an XA datasource (as Aries JPA
transactions don't work with non XA datasources)..

On 25 May 2018 at 14:21, Alex Soto  wrote:

> Hi All,
>
> Thanks for input.  I think I found a sweet spot that seems to work,
> although I wish somebody from AriesJPA can confirm this is a valid approach.
> I removed the Dialect and the other Hibernate specific settings out of my
> persistence.xml, but I have to keep the data source reference to JNDI:
>
> 
>   osgi:service/javax.sql.DataSource/(osgi.
> jndi.service.name=responder)
>   
>
> The Pax-exam configuration file *org.ops4j.datasource-responder.cfg*
> remains the same:
>
> osgi.jdbc.driver.name = mariadb
> dataSourceName=responder
> url = jdbc:mariadb://localhost:3306/responder?characterEncoding=UTF-8&
> useServerPrepStmts=true
> user=XXX
> password=XXX
> databaseName=responder
> ops4j.preHook=responderDB
>
>
> AriesJPA configuration in my feature provides the dialect and the provider:
>
> 
>  javax.persistence.provider=org.hibernate.jpa.
> HibernatePersistenceProvider
>  hibernate.dialect=org.hibernate.dialect.MariaDBDialect
>  hibernate.show_sql=false
>  hibernate.format_sql=true
>  hibernate.hbm2ddl.auto=none
>   
>
> When I run, first I can see in the log AriesJPA Container:
>
> 2018-05-25T09:01:22,580 | DEBUG | features-3-thread-1 |
> PersistenceBundleTracker | 46 - org.apache.aries.jpa.container -
> 2.7.0 | Matching JPA contract for possible persistence
> bundle encryptedquery-responder-data
> 2018-05-25T09:01:22,594 | INFO  | features-3-thread-1 |
> PersistenceBundleTracker | 46 - org.apache.aries.jpa.container -
> 2.7.0 | Found persistence unit responderPersistenUnit in
> bundle encryptedquery-responder-data with provider null.
> 2018-05-25T09:01:22,596 | INFO  | features-3-thread-1 |
> PersistenceProviderTracker   | 46 - org.apache.aries.jpa.container -
> 2.7.0 | Found provider for responderPersistenUnit org.hibernate.jpa.
> HibernatePersistenceProvider
> 2018-05-25T09:01:22,618 | INFO  | features-3-thread-1 | LogHelper
>| 134 - org.hibernate.core - 5.2.9.Final | HHH000204:
> Processing PersistenceUnitInfo [
> name: responderPersistenUnit
> ...]
> 2018-05-25T09:01:22,688 | INFO  | features-3-thread-1 | Version
>| 134 - org.hibernate.core - 5.2.9.Final | HHH000412:
> Hibernate Core {5.2.9.Final}
> 2018-05-25T09:01:22,691 | INFO  | features-3-thread-1 | Environment
>| 134 - org.hibernate.core - 5.2.9.Final | HHH000206:
> hibernate.properties not found
> 2018-05-25T09:01:22,750 | INFO  | features-3-thread-1 | Version
>| 133 - org.hibernate.common.hibernate-commons-annotations
> - 5.0.1.Final | HCANN01: Hibernate Commons Annotations {5.0.1.Final}
> 2018-05-25T09:01:23,330 | WARN  | features-3-thread-1 |
> JdbcEnvironmentInitiator | 134 - org.hibernate.core - 5.2.9.Final |
> HHH000342: Could not obtain connection to query metadata : Unable to
> determine Dialect to use [name=, majorVersion=0]; user must register
> resolver or explicitly set 'hibernate.dialect'
> 2018-05-25T09:01:23,332 *| DEBUG |* features-3-thread-1 |
> PersistenceProviderTracker   | 46 - org.apache.aries.jpa.container -
> 2.7.0 | *Error while creating the Dummy EntityManagerFactory to allow
> weaving*.
> org.hibernate.service.spi.ServiceException: Unable to create requested
> service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.
> createService(AbstractServiceRegistryImpl.java:271) ~[?:?]
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.
> initializeService(AbstractServiceRegistryImpl.java:233) ~[?:?]
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(
> AbstractServiceRegistryImpl.java:210) ~[?:?]
> at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.
> configure(JdbcServicesImpl.java:51) ~[?:?]
> at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.
> configureService(StandardServiceRegistryImpl.java:94) ~[?:?]
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.
> initializeService(AbstractServiceRegistryImpl.java:242) ~[?:?]
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(
> AbstractServiceRegistryImpl.java:210) ~[?:?]
> at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.
> handleTypes(MetadataBuildingProcess.java:352) ~[?:?]
> at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(
> MetadataBuildingProcess.java:111) ~[?:?]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImp
> l.metadata(EntityManagerFactory

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Alex Soto

I will give a try to Tim’s suggestion, as it may be safer than what I am doing 
now (with the errors in the log I can’t feel comfortable) but I do agree there 
seems to be a gap.  To be clear, the gap (as indicated by Tim), is the 
inability of using a DataSource registered in JNDI when configuring the 
Persistence Unit via Configuration Admin, something that is supported when 
using the persistence.xml file.

Best regards,
Alex soto




> On May 25, 2018, at 9:37 AM, Paul McCulloch  wrote:
> 
> That's what I do Alex. I didn't think I needed the non-jta-datasource (& 
> everything seems to work), but this thread has made me think I should go back 
> & re-asses that. 
> 
> I'll also look again at the Transaction Control stuff - it was at 0.0.1 when 
> I last looked, so I was nervous about relying on it. It looks like it will 
> fix my hack for MSSQL of having to fake an XA datasource (as Aries JPA 
> transactions don't work with non XA datasources)..
> 
> On 25 May 2018 at 14:21, Alex Soto  > wrote:
> Hi All,
> 
> Thanks for input.  I think I found a sweet spot that seems to work, although 
> I wish somebody from AriesJPA can confirm this is a valid approach.
> I removed the Dialect and the other Hibernate specific settings out of my 
> persistence.xml, but I have to keep the data source reference to JNDI:
> 
>   
>   
> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name 
> =responder)
>   
> 
> The Pax-exam configuration file org.ops4j.datasource-responder.cfg remains 
> the same:
> 
> osgi.jdbc.driver.name  = mariadb
> dataSourceName=responder
> url = 
> jdbc:mariadb://localhost:3306/responder?characterEncoding=UTF-8&useServerPrepStmts=true
>  <>
> user=XXX
> password=XXX
> databaseName=responder
> ops4j.preHook=responderDB
> 
> AriesJPA configuration in my feature provides the dialect and the provider:
> 
>   
>   
> javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider
>   hibernate.dialect=org.hibernate.dialect.MariaDBDialect
>   hibernate.show_sql=false
>   hibernate.format_sql=true
>   hibernate.hbm2ddl.auto=none
>   
> 
> When I run, first I can see in the log AriesJPA Container:
> 
> 2018-05-25T09:01:22,580 | DEBUG | features-3-thread-1 | 
> PersistenceBundleTracker | 46 - org.apache.aries.jpa.container - 
> 2.7.0 | Matching JPA contract for possible persistence bundle 
> encryptedquery-responder-data
> 2018-05-25T09:01:22,594 | INFO  | features-3-thread-1 | 
> PersistenceBundleTracker | 46 - org.apache.aries.jpa.container - 
> 2.7.0 | Found persistence unit responderPersistenUnit in bundle 
> encryptedquery-responder-data with provider null.
> 2018-05-25T09:01:22,596 | INFO  | features-3-thread-1 | 
> PersistenceProviderTracker   | 46 - org.apache.aries.jpa.container - 
> 2.7.0 | Found provider for responderPersistenUnit 
> org.hibernate.jpa.HibernatePersistenceProvider
> 2018-05-25T09:01:22,618 | INFO  | features-3-thread-1 | LogHelper 
>| 134 - org.hibernate.core - 5.2.9.Final | HHH000204: Processing 
> PersistenceUnitInfo [
>   name: responderPersistenUnit
>   ...]
> 2018-05-25T09:01:22,688 | INFO  | features-3-thread-1 | Version   
>| 134 - org.hibernate.core - 5.2.9.Final | HHH000412: Hibernate 
> Core {5.2.9.Final}
> 2018-05-25T09:01:22,691 | INFO  | features-3-thread-1 | Environment   
>| 134 - org.hibernate.core - 5.2.9.Final | HHH000206: 
> hibernate.properties not found
> 2018-05-25T09:01:22,750 | INFO  | features-3-thread-1 | Version   
>| 133 - org.hibernate.common.hibernate-commons-annotations - 
> 5.0.1.Final | HCANN01: Hibernate Commons Annotations {5.0.1.Final}
> 2018-05-25T09:01:23,330 | WARN  | features-3-thread-1 | 
> JdbcEnvironmentInitiator | 134 - org.hibernate.core - 5.2.9.Final | 
> HHH000342: Could not obtain connection to query metadata : Unable to 
> determine Dialect to use [name=, majorVersion=0]; user must register resolver 
> or explicitly set 'hibernate.dialect'
> 2018-05-25T09:01:23,332 | DEBUG | features-3-thread-1 | 
> PersistenceProviderTracker   | 46 - org.apache.aries.jpa.container - 
> 2.7.0 | Error while creating the Dummy EntityManagerFactory to allow weaving.
> org.hibernate.service.spi.ServiceException: Unable to create requested 
> service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]
>   at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:271)
>  ~[?:?]
>   at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:233)
>  ~[?:?]
>   at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:210)
>  ~[?:?]
>   at 
> org.hibernate.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Jean-Baptiste Onofré

Hi Alex,

I think it's better to use cfg or persistence.xml, one or the other, not
a mix of both.

I'm using both in the samples, but I don't mix both in the same sample.

Regards
JB

On 25/05/2018 16:00, Alex Soto wrote:
> I will give a try to Tim’s suggestion, as it may be safer than what I am
> doing now (with the errors in the log I can’t feel comfortable) but I do
> agree there seems to be a gap.  To be clear, the gap (as indicated by
> Tim), is the inability of using a DataSource registered in JNDI when
> configuring the Persistence Unit via Configuration Admin, something that
> is supported when using the persistence.xml file.
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On May 25, 2018, at 9:37 AM, Paul McCulloch > > wrote:
>>
>> That's what I do Alex. I didn't think I needed the non-jta-datasource
>> (& everything seems to work), but this thread has made me think I
>> should go back & re-asses that. 
>>
>> I'll also look again at the Transaction Control stuff - it was at
>> 0.0.1 when I last looked, so I was nervous about relying on it. It
>> looks like it will fix my hack for MSSQL of having to fake an XA
>> datasource (as Aries JPA transactions don't work with non XA
>> datasources)..
>>
>> On 25 May 2018 at 14:21, Alex Soto > > wrote:
>>
>> Hi All,
>>
>> Thanks for input.  I think I found a sweet spot that seems to
>> work, although I wish somebody from AriesJPA can confirm this is a
>> valid approach.
>> I removed the Dialect and the other Hibernate specific settings
>> out of my persistence.xml, but I have to keep the data source
>> reference to JNDI:
>>
>> 
>>  
>> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name
>> =responder)
>>  
>>
>> The Pax-exam configuration file
>> /org.ops4j.datasource-responder.cfg/ remains the same:
>>
>> osgi.jdbc.driver.name  = mariadb
>> dataSourceName=responder
>> url
>> = 
>> jdbc:mariadb://localhost:3306/responder?characterEncoding=UTF-8&useServerPrepStmts=true
>> user=XXX
>> password=XXX
>> databaseName=responder
>> ops4j.preHook=responderDB
>>
>>
>> AriesJPA configuration in my feature provides the dialect and the
>> provider:
>>
>> 
>>  
>>   
>> javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider
>>     hibernate.dialect=org.hibernate.dialect.MariaDBDialect
>>     hibernate.show_sql=false
>>     hibernate.format_sql=true
>>     hibernate.hbm2ddl.auto=none
>>  
>>
>> When I run, first I can see in the log AriesJPA Container:
>>
>> 2018-05-25T09:01:22,580 | DEBUG | features-3-thread-1 |
>> PersistenceBundleTracker         | 46 -
>> org.apache.aries.jpa.container - 2.7.0 | Matching JPA contract for
>> possible persistence bundle encryptedquery-responder-data
>> 2018-05-25T09:01:22,594 | INFO  | features-3-thread-1 |
>> PersistenceBundleTracker         | 46 -
>> org.apache.aries.jpa.container - 2.7.0 | Found persistence unit
>> responderPersistenUnit in bundle encryptedquery-responder-data
>> with provider null.
>> 2018-05-25T09:01:22,596 | INFO  | features-3-thread-1 |
>> PersistenceProviderTracker       | 46 -
>> org.apache.aries.jpa.container - 2.7.0 | Found provider for
>> responderPersistenUnit org.hibernate.jpa.HibernatePersistenceProvider
>> 2018-05-25T09:01:22,618 | INFO  | features-3-thread-1 | LogHelper
>>                        | 134 - org.hibernate.core - 5.2.9.Final |
>> HHH000204: Processing PersistenceUnitInfo [
>> name: responderPersistenUnit
>> ...]
>> 2018-05-25T09:01:22,688 | INFO  | features-3-thread-1 | Version  
>>                        | 134 - org.hibernate.core - 5.2.9.Final |
>> HHH000412: Hibernate Core {5.2.9.Final}
>> 2018-05-25T09:01:22,691 | INFO  | features-3-thread-1 |
>> Environment                      | 134 - org.hibernate.core -
>> 5.2.9.Final | HHH000206: hibernate.properties not found
>> 2018-05-25T09:01:22,750 | INFO  | features-3-thread-1 | Version  
>>                        | 133 -
>> org.hibernate.common.hibernate-commons-annotations - 5.0.1.Final |
>> HCANN01: Hibernate Commons Annotations {5.0.1.Final}
>> 2018-05-25T09:01:23,330 | WARN  | features-3-thread-1 |
>> JdbcEnvironmentInitiator         | 134 - org.hibernate.core -
>> 5.2.9.Final | HHH000342: Could not obtain connection to query
>> metadata : Unable to determine Dialect to use [name=,
>> majorVersion=0]; user must register resolver or explicitly set
>> 'hibernate.dialect'
>> 2018-05-25T09:01:23,332 *| DEBUG |* features-3-thread-1 |
>> PersistenceProviderTracker       | 46 -
>> org.apache.aries.jpa.container - 2.7.0 | *Error while creating the
>> Dummy EntityManagerFactory to allow weaving*.
>

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Tim Ward

Alex,

As you’ve noticed in the log there are some “odd things” going on. What you’ve 
managed to do is to prod things in the correct order to reach a state that is 
not normally accessible!

So what’s happening is:

Error while creating the Dummy EntityManagerFactory to allow weaving. - This 
always happens for Hibernate can safely be ignored. Part of the JPA 
specification involves supporting load-time weaving of the entity types. This 
forces the Aries JPA container to eagerly create the EMF as early as possible 
to avoid “missing” the class load. This in turn means that Aries JPA can’t wait 
to locate the DataSource, and instead uses a “dummy”, which gets us far enough 
through the process to get a load-time weaver. Hibernate then explodes because 
it tries to do real things with the dummy datasource.
The persistence unit responderPersistenUnit has incomplete configuration and 
cannot be created. This is your persistence unit configuration being injected 
into Aries JPA - it fails because it is using a mixture of persistence xml and 
configuration, and the configuration properties therefore have no database 
connection details/
Found DataSource for responderPersistenUnit 
osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)Once 
PAX-JDBC registers the DataSource service it is located by Aries JPA and used 
to create the EMF

The critical point here is that Entry 2 happens before Entry 3, but Aries JPA 
remembers the configuration that was injected into it in Entry 2. Therefore 
once the DataSource is found Aries JPA still has the configuration details 
injected from before. If you reversed the order of 2 and 3 then it wouldn’t 
work.

As Configuration Admin is asynchronous in its delivery of Configurations it can 
be pretty unreliable to depend on this ordering, although you could probably 
contrive a way of activating features to encourage it to happen this way all 
the time. Programmatic assembly is probably your friend here. 

Best Regards,

Tim

> On 25 May 2018, at 17:09, Jean-Baptiste Onofré  wrote:
> 
> Hi Alex,
> 
> I think it's better to use cfg or persistence.xml, one or the other, not
> a mix of both.
> 
> I'm using both in the samples, but I don't mix both in the same sample.
> 
> Regards
> JB
> 
> On 25/05/2018 16:00, Alex Soto wrote:
>> I will give a try to Tim’s suggestion, as it may be safer than what I am
>> doing now (with the errors in the log I can’t feel comfortable) but I do
>> agree there seems to be a gap.  To be clear, the gap (as indicated by
>> Tim), is the inability of using a DataSource registered in JNDI when
>> configuring the Persistence Unit via Configuration Admin, something that
>> is supported when using the persistence.xml file.
>> 
>> Best regards,
>> Alex soto
>> 
>> 
>> 
>> 
>>> On May 25, 2018, at 9:37 AM, Paul McCulloch >> >> wrote:
>>> 
>>> That's what I do Alex. I didn't think I needed the non-jta-datasource
>>> (& everything seems to work), but this thread has made me think I
>>> should go back & re-asses that. 
>>> 
>>> I'll also look again at the Transaction Control stuff - it was at
>>> 0.0.1 when I last looked, so I was nervous about relying on it. It
>>> looks like it will fix my hack for MSSQL of having to fake an XA
>>> datasource (as Aries JPA transactions don't work with non XA
>>> datasources)..
>>> 
>>> On 25 May 2018 at 14:21, Alex Soto >> 
>>> >> wrote:
>>> 
>>>Hi All,
>>> 
>>>Thanks for input.  I think I found a sweet spot that seems to
>>>work, although I wish somebody from AriesJPA can confirm this is a
>>>valid approach.
>>>I removed the Dialect and the other Hibernate specific settings
>>>out of my persistence.xml, but I have to keep the data source
>>>reference to JNDI:
>>> 
>>>
>>> 
>>> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name
>>>>> >=responder)
>>> 
>>> 
>>>The Pax-exam configuration file
>>>/org.ops4j.datasource-responder.cfg/ remains the same:
>>> 
>>>osgi.jdbc.driver.name >> > = mariadb
>>>dataSourceName=responder
>>>url
>>>= 
>>> jdbc:mariadb://localhost:3306/responder?characterEncoding=UTF-8&useServerPrepStmts=true
>>>  
>>> 
>>>user=XXX
>>>password=XXX
>>>databaseName=responder
>>>ops4j.preHook=responderDB
>>> 
>>> 
>>>AriesJPA configuration in my feature provides the dialect and the
>>>provider:
>>> 
>>>
>>> 
>>>  
>>> javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider
>>>hibernate.dialect=org.hibernate.dialect.MariaDBDialect
>>>hibernate.show_sql=false
>>>hibernate.format_sql=true
>>>hibernate.hbm2ddl.auto=none
>>> 
>>> 
>>>Wh

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Alex Soto

Hi Tim:

Agreed, it is brittle to depend on timing, I had arrived at the same conclusion 
looking a the Aries JPA code, but my experiment shows it is kind of possible, I 
was so close :)

I am now (happily) using your suggested approach and it is working without any 
errors/warnings.   Now, I would like to request for this feature/enhancement 
(i.e. support JNDI DataSources) but I am not sure where to make it.  Is this 
something  controlled by the OSGi committee or is it an Aries JPA thing? 

Thank you for the help.

Best regards,
Alex soto




> On May 25, 2018, at 11:06 AM, Tim Ward  wrote:
> 
> Alex,
> 
> As you’ve noticed in the log there are some “odd things” going on. What 
> you’ve managed to do is to prod things in the correct order to reach a state 
> that is not normally accessible!
> 
> So what’s happening is:
> 
> Error while creating the Dummy EntityManagerFactory to allow weaving. - This 
> always happens for Hibernate can safely be ignored. Part of the JPA 
> specification involves supporting load-time weaving of the entity types. This 
> forces the Aries JPA container to eagerly create the EMF as early as possible 
> to avoid “missing” the class load. This in turn means that Aries JPA can’t 
> wait to locate the DataSource, and instead uses a “dummy”, which gets us far 
> enough through the process to get a load-time weaver. Hibernate then explodes 
> because it tries to do real things with the dummy datasource.
> The persistence unit responderPersistenUnit has incomplete configuration and 
> cannot be created. This is your persistence unit configuration being injected 
> into Aries JPA - it fails because it is using a mixture of persistence xml 
> and configuration, and the configuration properties therefore have no 
> database connection details/
> Found DataSource for responderPersistenUnit 
> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)Once 
> PAX-JDBC registers the DataSource service it is located by Aries JPA and used 
> to create the EMF
> 
> The critical point here is that Entry 2 happens before Entry 3, but Aries JPA 
> remembers the configuration that was injected into it in Entry 2. Therefore 
> once the DataSource is found Aries JPA still has the configuration details 
> injected from before. If you reversed the order of 2 and 3 then it wouldn’t 
> work.
> 
> As Configuration Admin is asynchronous in its delivery of Configurations it 
> can be pretty unreliable to depend on this ordering, although you could 
> probably contrive a way of activating features to encourage it to happen this 
> way all the time. Programmatic assembly is probably your friend here. 
> 
> Best Regards,
> 
> Tim
> 
> 
>> On 25 May 2018, at 17:09, Jean-Baptiste Onofré > > wrote:
>> 
>> Hi Alex,
>> 
>> I think it's better to use cfg or persistence.xml, one or the other, not
>> a mix of both.
>> 
>> I'm using both in the samples, but I don't mix both in the same sample.
>> 
>> Regards
>> JB
>> 
>> On 25/05/2018 16:00, Alex Soto wrote:
>>> I will give a try to Tim’s suggestion, as it may be safer than what I am
>>> doing now (with the errors in the log I can’t feel comfortable) but I do
>>> agree there seems to be a gap.  To be clear, the gap (as indicated by
>>> Tim), is the inability of using a DataSource registered in JNDI when
>>> configuring the Persistence Unit via Configuration Admin, something that
>>> is supported when using the persistence.xml file.
>>> 
>>> Best regards,
>>> Alex soto
>>> 
>>> 
>>> 
>>> 
 On May 25, 2018, at 9:37 AM, Paul McCulloch >>> 
 >> wrote:
 
 That's what I do Alex. I didn't think I needed the non-jta-datasource
 (& everything seems to work), but this thread has made me think I
 should go back & re-asses that. 
 
 I'll also look again at the Transaction Control stuff - it was at
 0.0.1 when I last looked, so I was nervous about relying on it. It
 looks like it will fix my hack for MSSQL of having to fake an XA
 datasource (as Aries JPA transactions don't work with non XA
 datasources)..
 
 On 25 May 2018 at 14:21, Alex Soto >>> 
 >> wrote:
 
Hi All,
 
Thanks for input.  I think I found a sweet spot that seems to
work, although I wish somebody from AriesJPA can confirm this is a
valid approach.
I removed the Dialect and the other Hibernate specific settings
out of my persistence.xml, but I have to keep the data source
reference to JNDI:
 

 
 osgi:service/javax.sql.DataSource/(osgi.jndi.service.name
>=responder)
 
 
The Pax-exam configuration file
/org.ops4j.datasource-responder.cfg/ remains the sam

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Tim Ward

The configuration mode isn’t part of the specification, it’s just something 
that Aries JPA has as a feature. The right place for feature requests would 
therefore be the Apache Aries JIRA.

Tim

> On 25 May 2018, at 18:19, Alex Soto  wrote:
> 
> Hi Tim:
> 
> Agreed, it is brittle to depend on timing, I had arrived at the same 
> conclusion looking a the Aries JPA code, but my experiment shows it is kind 
> of possible, I was so close :)
> 
> I am now (happily) using your suggested approach and it is working without 
> any errors/warnings.   Now, I would like to request for this 
> feature/enhancement (i.e. support JNDI DataSources) but I am not sure where 
> to make it.  Is this something  controlled by the OSGi committee or is it an 
> Aries JPA thing? 
> 
> Thank you for the help.
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On May 25, 2018, at 11:06 AM, Tim Ward > > wrote:
>> 
>> Alex,
>> 
>> As you’ve noticed in the log there are some “odd things” going on. What 
>> you’ve managed to do is to prod things in the correct order to reach a state 
>> that is not normally accessible!
>> 
>> So what’s happening is:
>> 
>> Error while creating the Dummy EntityManagerFactory to allow weaving. - This 
>> always happens for Hibernate can safely be ignored. Part of the JPA 
>> specification involves supporting load-time weaving of the entity types. 
>> This forces the Aries JPA container to eagerly create the EMF as early as 
>> possible to avoid “missing” the class load. This in turn means that Aries 
>> JPA can’t wait to locate the DataSource, and instead uses a “dummy”, which 
>> gets us far enough through the process to get a load-time weaver. Hibernate 
>> then explodes because it tries to do real things with the dummy datasource.
>> The persistence unit responderPersistenUnit has incomplete configuration and 
>> cannot be created. This is your persistence unit configuration being 
>> injected into Aries JPA - it fails because it is using a mixture of 
>> persistence xml and configuration, and the configuration properties 
>> therefore have no database connection details/
>> Found DataSource for responderPersistenUnit 
>> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)Once 
>> PAX-JDBC registers the DataSource service it is located by Aries JPA and 
>> used to create the EMF
>> 
>> The critical point here is that Entry 2 happens before Entry 3, but Aries 
>> JPA remembers the configuration that was injected into it in Entry 2. 
>> Therefore once the DataSource is found Aries JPA still has the configuration 
>> details injected from before. If you reversed the order of 2 and 3 then it 
>> wouldn’t work.
>> 
>> As Configuration Admin is asynchronous in its delivery of Configurations it 
>> can be pretty unreliable to depend on this ordering, although you could 
>> probably contrive a way of activating features to encourage it to happen 
>> this way all the time. Programmatic assembly is probably your friend here. 
>> 
>> Best Regards,
>> 
>> Tim
>> 
>> 
>>> On 25 May 2018, at 17:09, Jean-Baptiste Onofré >> > wrote:
>>> 
>>> Hi Alex,
>>> 
>>> I think it's better to use cfg or persistence.xml, one or the other, not
>>> a mix of both.
>>> 
>>> I'm using both in the samples, but I don't mix both in the same sample.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 25/05/2018 16:00, Alex Soto wrote:
 I will give a try to Tim’s suggestion, as it may be safer than what I am
 doing now (with the errors in the log I can’t feel comfortable) but I do
 agree there seems to be a gap.  To be clear, the gap (as indicated by
 Tim), is the inability of using a DataSource registered in JNDI when
 configuring the Persistence Unit via Configuration Admin, something that
 is supported when using the persistence.xml file.
 
 Best regards,
 Alex soto
 
 
 
 
> On May 25, 2018, at 9:37 AM, Paul McCulloch  
> >> wrote:
> 
> That's what I do Alex. I didn't think I needed the non-jta-datasource
> (& everything seems to work), but this thread has made me think I
> should go back & re-asses that. 
> 
> I'll also look again at the Transaction Control stuff - it was at
> 0.0.1 when I last looked, so I was nervous about relying on it. It
> looks like it will fix my hack for MSSQL of having to fake an XA
> datasource (as Aries JPA transactions don't work with non XA
> datasources)..
> 
> On 25 May 2018 at 14:21, Alex Soto  
> >> wrote:
> 
>Hi All,
> 
>Thanks for input.  I think I found a sweet spot that seems to
>work, although I wish somebody from AriesJPA can confirm this is a
>valid approach.
>I removed the Dialect and the other Hiberna

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

2018-05-25 Thread Jean-Baptiste Onofré

That's on the Aries JPA scope.

I'm suggesting to create a Jira at Aries, we will tackle that.

Thanks,
Regards
JB

On 25/05/2018 17:19, Alex Soto wrote:
> Hi Tim:
> 
> Agreed, it is brittle to depend on timing, I had arrived at the same
> conclusion looking a the Aries JPA code, but my experiment shows it is
> kind of possible, I was so close :)
> 
> I am now (happily) using your suggested approach and it is working
> without any errors/warnings.   Now, I would like to request for this
> feature/enhancement (i.e. support JNDI DataSources) but I am not sure
> where to make it.  Is this something  controlled by the OSGi committee
> or is it an Aries JPA thing? 
> 
> Thank you for the help.
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On May 25, 2018, at 11:06 AM, Tim Ward > > wrote:
>>
>> Alex,
>>
>> As you’ve noticed in the log there are some “odd things” going on.
>> What you’ve managed to do is to prod things in the correct order to
>> reach a state that is not normally accessible!
>>
>> So what’s happening is:
>>
>>  1. *Error while creating the Dummy EntityManagerFactory to allow
>> weaving*. - This always happens for Hibernate can safely be
>> ignored. Part of the JPA specification involves supporting
>> load-time weaving of the entity types. This forces the Aries JPA
>> container to eagerly create the EMF as early as possible to avoid
>> “missing” the class load. This in turn means that Aries JPA can’t
>> wait to locate the DataSource, and instead uses a “dummy”, which
>> gets us far enough through the process to get a load-time weaver.
>> Hibernate then explodes because it tries to do real things with
>> the dummy datasource.
>>  2. *The persistence unit responderPersistenUnit has incomplete
>> configuration and cannot be created. *This is your persistence
>> unit configuration being injected into Aries JPA - it fails
>> because it is using a mixture of persistence xml and
>> configuration, and the configuration properties therefore have no
>> database connection details/
>>  3. *Found DataSource for responderPersistenUnit
>> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)*Once
>> PAX-JDBC registers the DataSource service it is located by Aries
>> JPA and used to create the EMF
>>
>>
>> The critical point here is that Entry 2 happens before Entry 3, but
>> Aries JPA remembers the configuration that was injected into it in
>> Entry 2. Therefore once the DataSource is found Aries JPA still has
>> the configuration details injected from before. If you reversed the
>> order of 2 and 3 then it wouldn’t work.
>>
>> As Configuration Admin is asynchronous in its delivery of
>> Configurations it can be pretty unreliable to depend on this ordering,
>> although you could probably contrive a way of activating features to
>> encourage it to happen this way all the time. Programmatic assembly is
>> probably your friend here. 
>>
>> Best Regards,
>>
>> Tim
>>
>>
>>> On 25 May 2018, at 17:09, Jean-Baptiste Onofré >> > wrote:
>>>
>>> Hi Alex,
>>>
>>> I think it's better to use cfg or persistence.xml, one or the other, not
>>> a mix of both.
>>>
>>> I'm using both in the samples, but I don't mix both in the same sample.
>>>
>>> Regards
>>> JB
>>>
>>> On 25/05/2018 16:00, Alex Soto wrote:
 I will give a try to Tim’s suggestion, as it may be safer than what I am
 doing now (with the errors in the log I can’t feel comfortable) but I do
 agree there seems to be a gap.  To be clear, the gap (as indicated by
 Tim), is the inability of using a DataSource registered in JNDI when
 configuring the Persistence Unit via Configuration Admin, something that
 is supported when using the persistence.xml file.

 Best regards,
 Alex soto




> On May 25, 2018, at 9:37 AM, Paul McCulloch  
> > wrote:
>
> That's what I do Alex. I didn't think I needed the non-jta-datasource
> (& everything seems to work), but this thread has made me think I
> should go back & re-asses that. 
>
> I'll also look again at the Transaction Control stuff - it was at
> 0.0.1 when I last looked, so I was nervous about relying on it. It
> looks like it will fix my hack for MSSQL of having to fake an XA
> datasource (as Aries JPA transactions don't work with non XA
> datasources)..
>
> On 25 May 2018 at 14:21, Alex Soto  
> > wrote:
>
>    Hi All,
>
>    Thanks for input.  I think I found a sweet spot that seems to
>    work, although I wish somebody from AriesJPA can confirm this is a
>    valid approach.
>    I removed the Dialect and the other Hibernate specific settings
>    out of my persistence.xml, but I have to keep the data source
>    refer

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

12 matches

Site Navigation

Mail list logo

Footer information