Re: [hibernate-dev] Question regarding HHH-10229

[Christian Beikov]

Thanks Vlad,

and for what it's worth, the tests for H2 run through.

Am 19.09.2016 um 17:10 schrieb Vlad Mihalcea:
> I can take a look on it tomorrow and let you know.
>
> Vlad
>
> On Mon, Sep 19, 2016 at 5:50 PM, Christian Beikov 
> > wrote:
>
> Hey everyone,
>
> I'd like to get HHH-10229 fixed as I can't workaround it. I
> prepared the
> fix and a
> test(https://github.com/hibernate/hibernate-orm/pull/1558
> ),
> but I am not sure if that's the best way to do it.
>
> Basically what I did is to check if an IdentNode is an alias to an
> element collection and if so, resolve it to the element type when
> requested from the select clause. This is very similar to what is
> happening when a MapValueNode is used, in fact some of the code is
> copied.
> When I later encounter that a map or index function is around it, I
> resolve it as alias again.
>
> Any comments?
>
> Regards,
> Christian Beikov
> ___
> 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] Question regarding HHH-10229

[Vlad Mihalcea]

I can take a look on it tomorrow and let you know.

Vlad

On Mon, Sep 19, 2016 at 5:50 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> Hey everyone,
>
> I'd like to get HHH-10229 fixed as I can't workaround it. I prepared the
> fix and a test(https://github.com/hibernate/hibernate-orm/pull/1558),
> but I am not sure if that's the best way to do it.
>
> Basically what I did is to check if an IdentNode is an alias to an
> element collection and if so, resolve it to the element type when
> requested from the select clause. This is very similar to what is
> happening when a MapValueNode is used, in fact some of the code is copied.
> When I later encounter that a map or index function is around it, I
> resolve it as alias again.
>
> Any comments?
>
> Regards,
> Christian Beikov
> ___
> 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] Question regarding HHH-10229

[Christian Beikov]

Hey everyone,

I'd like to get HHH-10229 fixed as I can't workaround it. I prepared the 
fix and a test(https://github.com/hibernate/hibernate-orm/pull/1558), 
but I am not sure if that's the best way to do it.

Basically what I did is to check if an IdentNode is an alias to an 
element collection and if so, resolve it to the element type when 
requested from the select clause. This is very similar to what is 
happening when a MapValueNode is used, in fact some of the code is copied.
When I later encounter that a map or index function is around it, I 
resolve it as alias again.

Any comments?

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

Re: [hibernate-dev] OpenJDK proposal: JDK 9 modules and reflection

[Yoann Rodiere]

I'll try to jump in. I'm mainly providing an external point of view though,
since I didn't seriously follow the progress of Java 9.

If I understood correctly, modules containing entities would not need to be
weak; they *could* be, as a quick solution to migrating to Java 9, but
ultimately the clean way of (re-)writing them would be:

module foo.bar {
exports private com.foo.bar.model; // Exports to anyone, including
hibernate.*
requires javax.jpa;
}

(Assuming all classes needed by Hibernate are in `com.foo.bar.model`)

Then public classes of package `com.foo.bar.model` would be exported to any
module, and additionally package-protected classes from this package could
be made accessible by anyone using `AccessibleObject::setAccessible`. Which
seems to solve the issue at least in principle.

What I'm not sure about is if it couldn't be even stricter by using a
qualified export :

module foo.bar {
exports private com.foo.bar.model to hibernate.entitymanager;
exports private com.foo.bar.model to hibernate.core;
requires javax.jpa;
}

It has the advantage of not disclosing private code to the entire world,
but the disadvantage of referring to the JPA implementation explicitely,
which is a shame.

In an ideal world, it would be awesome to be able to not reference
Hibernate at all (as below) and still reduce the visibility of the
"private" package to only a select few modules. It doesn't seem to be
possible, and I guess the syntax below is wrong for many reasons. Not the
least being that there's no way for the JVM to connect the dots between JPA
and Hibernate.

module foo.bar {
exports private com.foo.bar.model to javax.jpa; // Won't work
requires javax.jpa;
}

In the end, isn't the issue also about the lack of a concept of "module
interface", which "implementation modules" may implement? I mean, here, a
developer may not want to say "I'm using Hibernate", just "I'm using JPA",
and let the consumer of the module choose the actual JPA implementation. It
would be a bit like the `uses` and `provides` keywords, except we would be
referring to entire modules instead of classes.
I guess that, of course, the full definition of such a feature might get
quite complex depending on what it provides exactly.

Yoann Rodière 
Hibernate NoORM Team

On 16 September 2016 at 19:27, Emmanuel Bernard 
wrote:

> No one ?
>
> > On 13 Sep 2016, at 10:19, Emmanuel Bernard 
> wrote:
> >
> > Hi all,
> >
> > Sanne kindly pointed out to me the latest proposal by the OpenJDK team
> > around JDK 9 module and how they would handle frameworks needing access
> > to non exported types (Hibernate, dependency injection, etc).
> >
> > If you are remotely into JDK9, please read it and provide feedback.
> > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
> 2016-September/000390.html
> >
> > It's better than before for sure. It feels to me that most applications
> > (the core of it) will end up being a weak module for this to work
> > though. I'm not sure whether it is good or bad, at least a isolation
> > concious person has the choice.
> >
> >export private some.package;
> >
> > Is essentially equivalent to what you can do for a given package in Java
> > 8.
> > What I am less clear about is what relation Hibernate * projects really
> > need with a module containing the entities. Do we still this proposal
> > still mandates to use
> >
> >requires hibernate.entitymanager;
> >requires hibernate.core;
> >
> > in the targeted module?
> >
> > Or would this be a usable module
> >
> >module foo.bar {
> >exports private com.foo.bar.model;
> >requires javax.jpa;
> >// requires hibernate.entitymanager/core; no longer needed thanks
> to export private?
> >}
> >
> > Mark proposes that in a container (EE or anything controlling module
> loading
> > really), the container adds dynamically the addExports to the relevant
> > framework. But that looks like a solution to limit exports private
> > implications.
> >
> > Comments?
> >
> > Emmanuel
> > ___
> > 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

Re: [hibernate-dev] Preparing to release 5.0.11 and 5.1.2

[Gail Badner]

I am having some trouble publishing the distributions for 5.0.11. I've
finished everything else except for announcements. I'll get everything
finished up later today.

On Sun, Sep 18, 2016 at 4:31 PM, Gail Badner  wrote:

> Please do not push anything to 5.1 or 5.0 branches as I am preparing to
> release  5.0.11 and 5.1.2.
>
> Thanks,
> Gail
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev