By "non-jpa container managed deployments" you mean
injecting Hibernate
Sessions? Otherwise, I am not sure what this is supposed to mean. Nor
why it is a differentiator in how we use JtaPlatform / JtaPlatformInitiator.
Applications that deploy on WF, will use the WildFly
JtaPlatformInitiator, unless they add a persistence unit hint
"wildfly.jpa.jtaplatform" set to "false", in which case the WildFly
JtaPlatformInitiator will not be added for the deployment. We added
this for allowing applications to have more control over which
JtaPlatform is used (e.g. they can use an app configured JtaPlatform or
the determined correct ORM JtaPlatform).
I do see that Hibernate ORM will always succeed to use the
JBossAppServerJtaPlatform on WF, since we will only try using the
JBossStandalone if the JNDI lookup of the WF TM fails.
What happens if the deployment, is configured to use
JBossStandAloneJtaPlatform directly on WF? I assume they will need to
switch to use our new WildFlyStandAloneJtaPlatform class on ORM 5.3.2,
so that the app sees correct JTA TX status?
There is also now the problem that in 5.3.1, JBossStandAloneJtaPlatform
referred to the WildFly Transaction Client but is now reverted in 5.3.2,
to only refer to the Arjuna classes. Perhaps instead in 5.3.2, we
should delete WildFlyStandAloneJtaPlatform and merge the logic into the
existing JBossStandAloneJtaPlatform (so that we first check for WildFly
Transaction Client classes, failing that, we then try the Arjuna classes.)
On Mon, May 28, 2018 at 12:31 PM Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
A fix is merged to orm master branch, which should be in 5.3.2, as
soon as that is available.
On Sun, May 27, 2018, 7:06 PM Steve Ebersole <steve(a)hibernate.org
<mailto:steve@hibernate.org>> wrote:
JBossStandalone is meant for use of JBoss Transactions outside
of WildFly. Why are we using it inside WildFly.
WildFly also supports non-jpa container managed deployments, that
may not want to use the JtaPlatformInitiator. These apps can opt
out of the JtaPlatformInitiator but will need the correct TX status.
Inside WildFly, jipijapa ought to be defining that however it
needs through a custom JtaPlatform and probably the
JtaPlatformInitiator.
We do, by default.
On Sun, May 27, 2018, 3:58 PM Sanne Grinovero
<sanne(a)hibernate.org <mailto:sanne@hibernate.org>> wrote:
On 27 May 2018 at 15:29, Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
>
>
> On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero
<sanne(a)hibernate.org <mailto:sanne@hibernate.org>>
> wrote:
>>
>> On 27 May 2018 at 00:30, Scott Marlow
<smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote:
>> > Next idea, we should first look for the WFTC classes,
if not found, then
>> > look for Arjuna classes.
>>
>> +1 that would be nice and I see other implementations e.g.
>> JBossAppServerJtaPlatform have a precedent of attempting
multiple
>> strategies to maintain backward compatibility.
>>
>> Created:
>> -
https://hibernate.atlassian.net/browse/HHH-12640
>
>
>
https://github.com/hibernate/hibernate-orm/pull/2314
>
>>
>>
>>
>> Regarding the use of the old Arjuna name: you might be
right that it
>> shouldn't be used, but it's still very common:
>>
>> even the Narayana quickstarts using Hibernate are broken
by this
>> change, and so is any application running on WildFly
Swarm or
>> Thorntail.
>>
>> I suppose something should be improved on their side as
well, yet we
>> should give people time (by making it compatible like
you suggested)
>> and help at least with some documented guidance - the
fallback
>> strategy could log a warning to motivate people to
update but IMO we
>> should start bugging people with such messages only when
the other
>> runtimes and examples ship with the new defaults.
>>
>> Hibernate Search also has integration tests with
Narayana (standalone
>> JTA) and it's not clear to me now which dependencies I
should be
>> changing; I suppose I'll figure it out soon as I need to
release it
>> too :)
>>
>> The user experience after this error is quite bad:
applications now
>> simply fail to start with a confusing
>> "javax.persistence.PersistenceException: No Persistence
provider for
>> EntityManager named XYZ found", we give no better error
and no clue
>> about needing to look into the used transactions
implementation.
>>
>> Created:
>> -
https://hibernate.atlassian.net/browse/HHH-12639
>>
>> Thanks,
>> Sanne
>>
>>
>> >
>> > On Sat, May 26, 2018, 7:12 PM Scott Marlow
<smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote:
>> >>
>> >>
>> >>
>> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow
<smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote:
>> >>>
>> >>> Or, maybe we should just remove the
JBOSS_TM_CLASS_NAME +
>> >>> JBOSS_UT_CLASS_NAME class references and instead
JNDI lookup using the
>> >>> standard JBoss TM/UT JNDI names.
>> >>
>> >>
>> >> This wouldn't work for standard alone mode, as there
wouldn't be any
>> >> jndi
>> >> services. Guess, we are stuck with using class name
references.
>> >>
>> >>>
>> >>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow
<smarlow(a)redhat.com <mailto:smarlow@redhat.com>>
>> >>> wrote:
>> >>>>
>> >>>>
>> >>>> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero
>> >>>> <sanne(a)hibernate.org
<mailto:sanne@hibernate.org>>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi Scott,
>> >>>>>
>> >>>>> I see you changed JBossStandAloneJtaPlatform
to
use a new API in
>> >>>>> WildFly;
>> >>>>
>> >>>>
>> >>>> More that in WildFly 13, applications
shouldn't use
the Arjuna TM
>> >>>> classes directly anymore. The WildFly
Transaction
Client wraps the
>> >>>> Arjuna
>> >>>> TM and maintains correct TX status.
>> >>>>
>> >>>>>
>> >>>>> this breaks all existing applications using a
generic "JBoss -
>> >>>>> standalone" platform which isn't
using the very
latest WildFly.
>> >>>>
>> >>>>
>> >>>> Hmm, thinking more about this, also broken, are
any
ORM 5.1.x
>> >>>> applications that depend on
JBossStandAloneJtaPlatform to choose the
>> >>>> WildFly
>> >>>> TM. JPA container managed applications won't
have
this problem.
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> I see that in many cases this type is
auto-detected - and while
>> >>>>> JBossStandAloneJtaPlatform causes an
exception
this is swallowed by
>> >>>>> the HibernatePersistenceProvider as any
exception
is only mentioned
>> >>>>> at
>> >>>>> debug level (line 61).
>
>
> This sounds correct, as all persistence providers are
given a chance, to try
> deploying a persistence provider when
> Persistence.createEntityManagerFactory() (or other calls,
like
> generateSchema()) are made.
I'm aware of how the selection is meant to work, but
shouldn't we be
able to differentiate between the typical scenario "this
configuration
is not meant for me" vs the scenario of an unintended
failure because
of an internal exception?
Especially as in this case you claim it's the user's fault
that an
exception happens, as the user is having an out of date,
incompatible
library on the classpath. Clearly, we shouldn't swallow the
error as
it makes it massively difficult to suggest some upgrades
need to be
explored.
IMO it would be very reasonable to change the exception log
from debug
to warn/error but indeed I'm asking here as I understand the
TCK /
spec intent might disagree with this. I doubt the TCK tests for
absence of error messaged being logged though?
Thanks,
Sanne
>
>>
>> >>>>>
>> >>>>> So two questions:
>> >>>>> - could this be reverted and you introduce
some
new-gen
>> >>>>> WildflyStandAloneJtaPlatform instead?
>
>
> Yes, good idea
https://github.com/hibernate/hibernate-orm/pull/2314
>
>> >>>>
>> >>>>
>> >>>> Not sure, since the WildFly Transaction Client
(WFTC) module is also
>> >>>> in
>> >>>> earlier WF releases. I'm not exactly sure of
when
the WFTC TM
>> >>>> replaces
>> >>>> Arjuna TM. David, is that new for WF13?
>> >>>>
>> >>>> We can get more correct in ORM 5.3.x to align
with
WF 13, but not
>> >>>> sure
>> >>>> about ORM 5.1 JBossStandAloneJtaPlatform still
referencing Arjuna TM
>> >>>> directly. Seems like that is also a problem.
>> >>>>
>> >>>>>
>> >>>>> - bootstrap exceptions: may I change those
to
error level?
>> >>>>
>> >>>>
>> >>>> No idea.
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Sanne
>> >>>>
>> >>>>
>> >>>
>> >
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev