In order to validate that unifying the event listener impls between
"native" and "jpa" is actually workable I applied that idea on top of 5.2.
And it works. ANd since I did the work, I created a PR from it for us to:
1. review that specific set of changes (slightly different accounting
for
> Do we want to change JpaIntegrator#integrate signature to pass its
context
> as a parameter object
If you think that's the better approach, I'd say 6 is the right time to do
it. Users (or integrators) will be prepared for this sort of breakage in a
major.
> do other projects supply custom
> org
One contract I would need to adjust for this
is org.hibernate.service.spi.SessionFactoryServiceInitiator#initiateService.
I can find all the implementations of that in ORM, but do other projects
supply custom org.hibernate.service.spi.SessionFactoryServiceInitiator
impls?
On Wed, Aug 31, 2016 at
I'm fine with combining native and JPA events handling, about the second
point, ideally I would change the signature but due to the problems you
listed I vote for the in-line solution.
On 30 August 2016 at 19:20, Steve Ebersole wrote:
> Any thoughts on the JpaIntegrator parts of the discussion?
Any thoughts on the JpaIntegrator parts of the discussion? Specifically
there are 2 main considerations:
1. To change the Integrator#integrate contract - ideally, in retrospect,
#integrate probably should have taken a "parameter object" to help insulate
from these types of changes. But
On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero wrote:
> On 30 August 2016 at 10:09, Emmanuel Bernard
> wrote:
> > I am not sure if that is still relevant but in the past, either HSEARCH
> > or HV were keeping the ReflectionManager around to use it at runtime
> > (either because metadata was loa
> So we need to check that losing access to ReflectionManager after SF is
created won't be problematic for these projects.
In HV there is no reference to ReflectionManager whatsoever (same for OGM).
2016-08-30 11:09 GMT+02:00 Emmanuel Bernard :
> I am not sure if that is still relevant but in
On 30 August 2016 at 10:09, Emmanuel Bernard wrote:
> I am not sure if that is still relevant but in the past, either HSEARCH
> or HV were keeping the ReflectionManager around to use it at runtime
> (either because metadata was loaded lazily or because of a reboot of the
> factories due to a confi
I am not sure if that is still relevant but in the past, either HSEARCH
or HV were keeping the ReflectionManager around to use it at runtime
(either because metadata was loaded lazily or because of a reboot of the
factories due to a configuration change.
So we need to check that losing access to R
We have a number of resources whose references are valid only during
bootstrap. This includes things like:
- ClassmateContext
- JPA temp ClassLoader
- Scanner and related
- HCANN ReflectionManager (eventually Jandex)
- etc
The problem is that as currently handled (via
MetadataBuil
10 matches
Mail list logo
