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
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
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
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
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
>
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
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.
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
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
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
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
12 matches
Mail list logo