Re: [hibernate-dev] EntityManagerFactoryBuilderImpl constructor is accessing the CDI BeanManager too early (during 1st phase) ...

[Scott Marlow]

On 05/21/2014 03:36 PM, Scott Marlow wrote:
> I started to push on Hibernate master integration for WildFly [1] +
> Jipijapa [2].
>
> http://pastie.org/9196859 is a NPE that occurs when the CDI BeanManager
> is accessed during the first (EntityManagerFactoryBuilder) phase.
> Hibernate ORM shouldn't use the BeanManager until the second phase.

I'll create a HHH jira for the BeanManager access issue.

I'm also hitting some issues in existing unit tests (WildFly + Jipijapa) 
that I worked around by commenting them out.  We can discuss on IRC 
sometime or I could give more details here.

After we get past these issues, I'll make the change to pass the Jandex 
CompositeIndex into Hibernate 5.x, so we can see how that works.

>
> Scott
>
> [1] https://github.com/scottmarlow/wildfly/tree/hibernate5
>
> [2] https://github.com/scottmarlow/jipijapa/tree/JIPI-31
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM and others] API, SPI and FPI

[Steve Ebersole]

The split packages were really a vehicle to make auto-generation of osgi
metatdata possible.  It is nice too that they offer a quick visual clue
into the intent.  I agree that an annotation would work as well for some
aspects of this.  But using annotations would make the osgi auto-gen harder
for sure (doable still, just harder).

I agree we are all describing the same thing: integration points between 2
things (sometimes 2 projects, sometimes 2 modules, sometimes just 2 classes
or "services").  Personally I like to call them "touch points" as in the
point were things touch.  I am much less interested in what we call them
versus doing them right :)  We all agreed 2-3 years ago to call them SPI.
 I see no reason to change that simply because there is not a "nice, neat
wikipedia page" to talks about our view of these concepts.



On Thu, May 22, 2014 at 11:03 AM, Sanne Grinovero wrote:

> Looks like we're all aligned?
> Steve made some concrete examples, Emmanuel pointed out how we have
> been defining this vs. apparently other people.
>
> I don't feel the need to change our interpretation, if that's what is
> being discussed.
>
> It's good to remember that there are different kinds of SPIs; we
> indeed came to the conclusion that it's often much nicer to have an
> abstract class when the SPI is meant to be provided by 3rd party code
> but I think we need an interface in that case as well (in addition to
> the abstract class).
>
> Also breaking an SPI could bring as much pain as an API change.. when
> an API changs the user is often in the position to be able to do
> something about it. More often people get in trouble because they are
> using a mixture of versions of different frameworks and libraries
> which are meant to work together, and they don't.. in such scenarios
> the user might not be able to do something about it, other than
> lobbying and begging for fixes and releases in projects out of his
> control.
> An API change just invalidates project for people who are not able to
> recompile, and makes books and training outdated :) Sure that's
> annoying too, my point is just that SPI is not less important
> *generally* but it depends on what API and what SPI we're talking
> about.
>
> But even when we discuss the same "kind" of SPIs, some are more
> critical than others, and some are "internal" SPIs (like
> hibernate-search to hibernate-search module), some are very close
> (hibernate-orm to hibernate-search) some are slightly further down
> (infinispan - hibernate-search).. others need critical stability
> (container integration, etc..). And of course it's less painfull when
> it affects something that 99% of users didn't know it existed in the
> first place.
>
> Conclusion, the package name will never set a rule: to me it's more
> like a reminder to be carefull in any way possible as "someone" is
> going to hate me. I am personally not even a fan of these specific
> package naming conventions, an annotation would be just as good,
> provided it gets somehow visibility in the javadoc (or even hides
> javadocs for internals).
>
>
> Sanne
>
> On 22 May 2014 15:32, Steve Ebersole  wrote:
> > Deja vu as we have had this exact discussion before (and actually, our
> > discussions pre-date those TAG discussions)
> >
> > You are basing your specific reading of what SPI means based on a single
> > wikipedia page that goes out of its way to point out its incompleteness
> :)
> >  And really even then in my opinion you are reading too much into its
> > mention of the JDK ServiceLoader.  What the wikiepdia says specifically
> is:
> >
> > *Service Provider Interface* (SPI) is an
> > API
> > intended
> >> to be implemented or extended by a third party. It can be used to enable
> >> framework extension and replaceable components
> >
> >
> > That's actually not much different (if at all) from how I use the term
> SPI.
> >  To me, SPI is simply "the API that is used between internal components
> to
> > accomplish something".  A specific important distinction here is that
> APIs
> > are meant for application code to bind to, SPIs are not.  As I have
> pointed
> > out probably 100 times already, yes there are 2 facets to this.  To me an
> > SPI is made up of:
> > 1) The SPI contracts that are meant to be extended by users and/or 3rd
> > parties.
> > 2) The SPI contracts that are not intended for extension.
> >
> > Another correlated break down is:
> > 1) SPI contracts that do things
> > 2) SPI contracts that are inputs/outputs to (1)
> >
> > Take for example, the idea of scanning deployments for annotated classes
> > (mainly because this one is fresh in my mind).  The main SPI contract
> here
> > is Scanner and ArchiveDescriptorFactory.  These are each intended as
> > extension points, they both "do stuff".  All the rest of the "scanning
> spi"
> > is inouts/outputs to these 2.  Why is this an important distinction?
>  Well,
> > generally speaking where

Re: [hibernate-dev] Changing method signatures in micro releases

[Gail Badner]

My changes for HHH-9204 and HHH-9205 need to be pushed to 4.2, 4.3, and master. 
This needs to happen by early next week so it can be released in 4.2.13.Final 
on Wednesday.

I want to make sure that my change fixes the regression introduced into 4.3.5 
and 4.2.12, without breaking the fix that Gunnar made for OGM.

Gunnar, can you check my pull request at 
https://github.com/hibernate/hibernate-orm/pull/747 and make sure it doesn't 
break something for you?

Thanks!
Gail

- Original Message -
> From: "Gail Badner" 
> To: "Steve Ebersole" 
> Cc: hibernate-dev@lists.jboss.org
> Sent: Monday, May 19, 2014 3:16:56 PM
> Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> 
> It was a simple matter to restore the old the method and provide a default
> implementation of the method added by HHH-9078.
> 
> I've create the following issues:
> 
> For master, 4.3, and 4.2 (because HHH-9078 was fixed on master, 4.3, and
> 4.2):
> HHH-9204: Restore
> AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> Serializable, SessionImplementor)
> HHH-9205: Deprecate
> AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> Serializable, int, SessionImplementor)
> 
> For master only:
> HHH-9206: Remove
> AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> Serializable, int, SessionImplementor)
> 
> Steve, I'm not 100% I did the right thing for HHH-9204 and HHH-9205, so
> please take a look at the pull request:
> https://github.com/hibernate/hibernate-orm/pull/747
> 
> Thanks,
> Gail
> 
> - Original Message -
> > From: "Gail Badner" 
> > To: "Gunnar Morling" 
> > Cc: hibernate-dev@lists.jboss.org
> > Sent: Monday, May 19, 2014 12:34:09 PM
> > Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> > 
> > Hi Gunnar,
> > 
> > Thanks for mentioning this. I believe that
> > org.hibernate.persister.collection
> > and org.hibernate.persister.entity are considered APIs, which should
> > definitely be backward-compatible for micro releases.
> > 
> > I'm looking at some alternatives to mitigate that. My first thought is that
> > the fix for HHH-9078 should have been made only to OneToManyPersister, so
> > that AbstractCollectionPersister would not be affected. If this is
> > possible,
> > I will add the old method back and deprecate the new one that caused you
> > trouble.
> > 
> > I'll let you know what I find.
> > 
> > Regards,
> > Gail
> > 
> > - Original Message -
> > > From: "Gunnar Morling" 
> > > To: hibernate-dev@lists.jboss.org
> > > Sent: Monday, May 19, 2014 12:28:38 AM
> > > Subject: [hibernate-dev] Changing method signatures in micro releases
> > > 
> > > Hi,
> > > 
> > > When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed
> > > method signature in AbstractCollectionPersister (abstract
> > > method doProcessQueuedOps() has a new parameter).
> > > 
> > > This causes a compilation failure in OGM, as we naturally still override
> > > the old signature. I can solve this particular case in a compatible
> > > manner
> > > by declaring both variants of the method in our sub-class (omitting the
> > > @Override annotation), but I'm wondering how we should generally deal
> > > with
> > > this kind of issue.
> > > 
> > > Are micro-releases considered strictly backwards-compatible, so that e.g.
> > > all of ORM 4.3.x should be useable together with an integrator (such as
> > > OGM) known to work with 4.3.0? This would have been my assumption
> > > originally.
> > > 
> > > Are there any rules for what kind of changes are to be expected by an ORM
> > > micro/minor/major update?
> > > 
> > > Thanks,
> > > 
> > > --Gunnar
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > 
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev