IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
2 months, 3 weeks
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
5 months, 1 week
HHH-10162 Inheritance and L2 cache
by Christian Beikov
Hey guys,
Steve said I should start a discussion about the possible solution for
HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162> so here we go.
While debugging the issue, I found out that the proxy is created at
DefaultLoadEventListener.createProxyIfNecessary() where it IMO should
consult the 2L cache first by calling existing =
loadFromSecondLevelCache( event, persister, keyToLoad );. The fix looks
easy, but I am not sure of the implications. Obviously this will affect
performance a little since it has to consult the L2 cache now.
I tried to start a discussion in the Dev room, but so far only Andrea,
Vlad and Chris have commented this. Has anyone a different idea for
implementing this?
--
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
8 years, 4 months
Getting rid of our specific JavaDoc CSS?
by Guillaume Smet
Hi,
So, apparently, our JavaDoc CSS is a bit outdated as we now have a "Skip
navigation links" link at the top of our doc that should be hidden by
default.
Frankly, I see very little value in maintaining our own JavaDoc CSS. It
requires work (see above and the future JDK 9 upgrade - Marko did a first
pass on Validator but it required some time).
Moreover, I find the new default CSS much more readable and attractive than
ours.
Compare:
https://docs.jboss.org/hibernate/stable/search/api/
with:
http://docs.jboss.org/jberet/1.3.0.Beta2/javadoc/jberet-core/
I would say a JavaDoc is a JavaDoc and I would prefer if our users just got
the standard layout they are used to on other projects.
Bonus point: when we include external projects javadoc in ours, we end up
having both layouts mixed, which is not very nice.
And if it saves us some work, it's all good, isn't it?
Thoughts?
--
Guillaume
8 years, 4 months
JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
by Rory O'Donnell
Hi Sanne,
*JDK 10 Early Access build 33 is available at : - **jdk.java.net/10/*
Notable changes since previous email.
<http://bugs.openjdk.java.net/browse/JDK-8175094>JDK-8180019
<http://bugs.openjdk.java.net/browse/JDK-8180019> - *javadoc treats
failure to access a URL as an error , not a warning.*
If javadoc cannot access the contents of a URL provided with the -link
or -linkoffline options,the tool will now report an error.
Previously, the tool continued with a warning, producing incorrect
documentation output.
JDK-8175094 <http://bugs.openjdk.java.net/browse/JDK-8175094>*- **The
java.security.acl APIs are deprecated, for removal****
* The deprecated java.security.acl APIs are now marked with
forRemoval=true and are subject to removal in a future version of Java SE.
JDK-8175091 <http://bugs.openjdk.java.net/browse/JDK-8175091> *- The
java.security.{Certificate,Identity,IdentityScope,Signer} APIs are
deprecated, for removal*
The deprecated java.security.{Certificate, Identity, IdentityScope,
Signer} classes are now marked with forRemoval=true and are subject to
removal in a future version of Java SE.
JDK 10 Schedule, Status & Features are available [1]
Notes
* OpenJDK EA binaries will be available at a later date.
* Oracle has proposed: Newer version-string scheme for the Java SE
Platform and the JDK
o Please see Mark Reinhold's proposal [2]
*JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/*
<http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
*Feedback* - If you have suggestions or encounter bugs, please submit
them using the usual Java SE bug-reporting channel.
Be sure to include complete version information from the output of the
|java --version| command.
Regards,
Rory
[1] http://openjdk.java.net/projects/jdk/10/
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
8 years, 4 months
Why does the disassembledStateText in StandardCacheEntryImpl build from the actual state[] and not from disassembledState[]?
by Vlad Mihalcea
Hi,
While working on fixing https://hibernate.atlassian.net/browse/HHH-12107,
I realized that the way we create the disassembledStateText property of the
StandardCacheEntryImpl object does not resemble the name of the attribute.
Now, I wonder why we don't build the disassembledStateText from
disassembledState?
Currently, the disassembledStateText is built from the hydrated state
instead. Is there any reason why we do that? Is it for correlating the
disassembledState Object array that's contained in the
StandardCacheEntryImpl object with the original entity hydrated state?
The problem with HHH-12107 was that, from structured 2nd-level cache where
we content is saved as a Map, when we reconstruct the
StandardCacheEntryImpl object
from the Map we get from the 2nd-level cache, we only know the
disassembledState when building the StandardCacheEntryImpl object reference.
So, we can't construct the same disassembledStateText value until we have
the actual hydrated state.
We would not have this issue if the disassembledStateText was built from
the disassembledState Object array via a call to Arrays.deepToString. But
changing the way we build the disassembledStateText is problematic if the
2nd-level cache provider relies on that property.
Vlad
8 years, 4 months
JPA Compliance
by Steve Ebersole
Part of 5.2 was merging the JPA contracts into the corresponding Hibernate
ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of
EntityManagerFactory - instead, SessionFactory now extends
EntityManagerFactory.
This caused a few problems that we handled as they came up. In working on
the JPA 2.2 compatibility testing, I see that there are a few more still
that we need to resolve. Mostly they relate to JPA expecting exceptions in
certain cases where Hibernate has historically been lenient. E.g., JPA
says that calling EntityManagerFactory#close on an EMF that is already
closed should result in an exception. Historically, calling
SessionFactory#close on a SF that is already closed is simply ignored.
Philosophical debates aside[1], we need to decide how we want to handle
this situation such that we can throw the JPA-expected exceptions when
needed. Do we simply change SF#close to match the JPA expectation? Or do
we somehow
make SF#close aware of JPA versus "native" use? This latter option was the
intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly
continue to use that as the basis of the solution here for other cases.
This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if
the EMF is created in either of the 2 JPA-defined bootstrap mechanisms,
that flag is set to true. It's an ok solution, but it does have some
limitations - mainly, there was previously a distinction between SF#close
being called versus EMF#close being called (they were different classes, so
they could react differently). Therefore, regardless of bootstrap
mechanism, if the user unwrapped the EMF to a SF, they would always get the
legacy SF behavior.
So long story short, so we want to consider an alternative approach to
deciding what to do in "some"[2] of these cases? Again, we clearly need
these to throw the spec-mandated exceptions in certain "strict compliance"
situations. The question really is how to do that. Should we:
1. just completely change the behavior to align with the spec?
2. change the behavior to match the spec *conditionally*, where that
condition could be:
1. `#isJpaBootstrap`
2. some setting
3. some extension contract
4. something else?
Thoughts?
[1] It's not relevant e.g. that I think JPA is wrong here. We need to
comply with the spec, at least in certain cases ;)
[2] I say "some" here, because I think the spec is correct in some cases -
for example, I think its clearly correct that a closed EMF throws an
exception when `#createEntityManager` is called. Personally I think its
questionable whether closing an already closed EMF should be an exception.
8 years, 4 months
HHH-12125 - @GeneratedValue & 5.3
by Steve Ebersole
The background is all in the Jira, but the crux is this... it is better to
allow a user to do this:
@GeneratedValue( strategy=SEQUENCE, generator="my_seq")
rather than:
@GeneratedValue( strategy=SEQUENCE, generator="my_seq")
@SequenceGenerator( name="my_seq", sequenceName="my_seq" )
You can see that `SequenceGenerator` is completely unnecessary in this case
because it adds no new information beyond what is already available on the
`@GeneratedValue`.
This works great for `GeneratedValue#strategy=SEQUENCE` and
`GeneratedValue#strategy=TABLE`, however consider this mapping:
@GeneratedValue( strategy=AUTO, generator="increment" )
@GenericGenerator( name = "increment", strategy = "increment" )
Here we have the same underlying concern - the `@GenericGenerator` is just
noise, it adds no additional information. In keeping with the work done as
part of HHH-12125 it would be great to allow users to instead just say:
@GeneratedValue( strategy=AUTO, generator="increment" )
The problem here is that this last one is actually the responsibility of
`org.hibernate.boot.model.IdGeneratorStrategyInterpreter#determineGeneratorName`
to interpret, but it is not passed the `GeneratedValue#generator` value.
So the easiest solution would be to add an additional parameter to
`IdGeneratorStrategyInterpreter#determineGeneratorName` for passing in the
generator name. The concern here is that `IdGeneratorStrategyInterpreter`
is defined in the API space and could very well have custom impls.
A lesser solution wold be to add checks to the code that calls
`IdGeneratorStrategyInterpreter#determineGeneratorName` to check for
"magic" generator names before asking the
`IdGeneratorStrategyInterpreter`. This is just a very inflexible and
non-extensible solution, but maybe this works for 5.3 and we can adjust
`IdGeneratorStrategyInterpreter` as part of 6.0.
Thoughts?
8 years, 4 months
Auto run CI job
by Steve Ebersole
I am trying to set up a CI job against my personal ORM fork to
automatically trigger on push. I follow the configuration from jobs
against the main ORM repo which work, but mine does not. I assume it has
something to do with it being a personal branch. Is there something I need
to do on my repo to enable this?
8 years, 4 months
Relaxing JIRA assignment restrictions
by Sanne Grinovero
Hi all,
I'm being frequently asked to add new contributors to "the right
groups" on JIRA just for the sake of being able to assign issues to
them.
I'm not sure why it's useful to prevent this for anyone to do being
able to do this, and also I suspect some people might be more inclined
to "just do it" if they had a clearer, more welcoming approach to
signal that they're looking into the issue themselves.
Any objections to relax this requirement?
Thanks,
Sanne
8 years, 4 months
Legacy positional params and JPA "positional" params
by Steve Ebersole
I wont bore everyone with the history here, but long story short is that we
need to start treating JPA "positional" parameters as positional in the
`javax.persistence.Parameter#getPosition` sense. Even though there is
nothing positional about JPA's positional parameters, this has moved from a
philosophical discussion to a practical one as the JPA 2.2 TCK is testing
this, whereas older ones did not
To do that however, we need to drop our older positional parameter
support. That feature has been deprecated for quite some time now. Unless
there are objections, I will plan on dropping that in 5.3
8 years, 4 months
Re: [hibernate-dev] JDK 10 b29 Early Access is available on jdk.java.net
by Gunnar Morling
Hi Dalibor,
2017-11-20 10:24 GMT+01:00 dalibor topic <dalibor.topic(a)oracle.com>:
>
>
> On 19.11.2017 13:03, Gunnar Morling wrote:
>
>> Hi Rory,
>>
>> While updating my JDK API change report generator [1] for JDK 10, I
>> noticed that three modules aren't available in JDK 10 as of b32 which
>> existed in JDK 9:
>>
>> * jdk.management.cmm
>> * jdk.management.jfr
>> * jdk.management.resource
>>
>
> Hi Gunnar,
>
> the modules are there for (still) commercial features like the Java Flight
> Recorder. Commercial features not made available in JDK early access builds.
>
I see, thanks.
But why is then that other modules also marked as commercial in their
JavaDoc are part of the EA build (e.g. "jdk.jfr")? And why are the
non-available modules nevertheless parts of the API docs published at
http://download.java.net/java/jdk10/docs/api? It seems a bit inconsistent.
Really looking forward to the open-sourced JFR + MC btw., that's a
fantastic development!
>
> cheers,
> dalibor topic
>
>
>> Interestingly, these modules are contained in the published JDK 10
>> JavaDoc [3], but I couldn't find the jmod files in the "jmods" directory of
>> the preview build.
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1] https://github.com/gunnarmorling/jdkapidiff
>> [2] http://jdk.java.net/10/release-notes
>> [3] http://download.java.net/java/jdk10/docs/api/jdk.management.
>> cmm-summary.html
>>
>>
>>
>>
>> 2017-11-03 11:20 GMT+01:00 Rory O'Donnell <rory.odonnell(a)oracle.com
>> <mailto:rory.odonnell@oracle.com>>:
>>
>> Hi Sanne,
>>
>> JDK 10 Early Access build 29 is available at : - jdk.java.net/10/
>> <http://jdk.java.net/10/>
>>
>>
>> JDK 10 Early Access Release Notes are available [1]
>>
>> JDK 10 Schedule, Status & Features are available [2]
>>
>>
>> Notes
>>
>> * OpenJDK EA binaries will be available at a later date.
>> * Oracle has proposed: Newer version-string scheme for the Java SE
>> Platform and the JDK
>> o Please see Mark Reinhold's proposal [3] , feedback via the
>> mailing list to Mark please.
>>
>> <http://openjdk.java.net/projects/jdk8u/releases/8u162.html
>> <http://openjdk.java.net/projects/jdk8u/releases/8u162.html>>
>>
>> Feedback - If you have suggestions or encounter bugs, please submit
>> them
>> using the usual Java SE bug-reporting channel.
>> Be sure to include complete version information from the output of the
>> |java --version| command.
>>
>> Regards,
>> Rory
>>
>> [1] http://jdk.java.net/10/release-notes
>> <http://jdk.java.net/10/release-notes>
>> [2] http://openjdk.java.net/projects/jdk/10/
>> <http://openjdk.java.net/projects/jdk/10/>
>> [3]
>> http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November
>> /000089.html
>> <http://mail.openjdk.java.net/pipermail/jdk-dev/2017-Novembe
>> r/000089.html>
>>
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>
>>
>>
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
>
8 years, 4 months
HHH-10418 and Infinispan
by Gail Badner
Steve/Radim,
Is it OK if an entity and collection region have the same name, they will
use the same AdvancedCache? I realize that the key will be different (as
long as hibernate.cache.keys_factory != simple).
I'm assuming they use the same access strategies, etc. I know there would
be problems if they didn't (HHH-10707/HHH-11356).
I've been looking at how things are implemented in 5.2 to avoid the
ClassCacheException when an entity region and collection region has the
same name.
I see that org.hibernate.internal.CacheImpl has a separate map for each
type of cache (i.e., entity, collection, natural-id). [1]
I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory#
buildEntityRegion and #buildCollectionRegion both call #getCache. [2]
#getCache checks to see if there is already a cache with the specified
regionName, but does not take the type (i.e., entity, collection,
natural-id) into account. If there is already a cache with that region
name, it will be used.
In other words, it seems that if an entity and collection region have the
same name, they will use the same AdvancedCache.
I just want to confirm that this is intended and there is no problem with
having different types of data in the same AdvancedCache.
Thanks,
Gail
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
[2]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinisp...
8 years, 4 months
HHH-12007
by Gail Badner
Hi Steve,
The test case for HHH-12087 shows that executing a query that has a
transient entity bound to it will cause that transient entity to be
persisted.
Please take a look at the PR for HHH-12087:
https://github.com/hibernate/hibernate-orm/pull/2054
It removes IncrediblySillyJpaMapsIdMappedIdentifierValueMarshaller#persistTransientEntity
and, AFAICT, doesn't break anything.
Thanks,
Gail
8 years, 4 months
Natural IDs and inheritance (HHH-12085)
by Gail Badner
IIUC, a natural ID should apply to an entire entity hierarchy. Is that true?
HHH-12085 reports a "bug" when a natural ID is mapped on a non-root
entity. Is that expected? Is this something we may want to support in
the future?
Thanks,
Gail
8 years, 4 months
Re: [hibernate-dev] Hibernate CI is angry: ORM build job is failing since the 2nd of November
by Sanne Grinovero
Davide, checking the CI logs I see:
Not sending mail to user ggam@[edited] with no permission to view
hibernate-orm-master-h2-check #358
Not sending mail to user bogdan.stirbat@[edited] with no permission to
view hibernate-orm-master-h2-check #358
Not sending mail to user andrew_geery@[edited] with no permission to
view hibernate-orm-master-h2-check #358
An attempt to send an e-mail to empty list of recipients, ignored.
So nobody heard of this. Would be great if we could figure out a way
to notify the people who merged the PR, on top of trying to reach the
commit authors?
> On 6 November 2017 at 14:53, Vlad Mihalcea <mihalcea.vlad(a)gmail.com> wrote:
>> They are not working. I haven't got any alert about the build failure.
>>
>> Vlad
>>
>> On 6 Nov 2017 4:51 pm, "Sanne Grinovero" <sanne(a)hibernate.org> wrote:
>>>
>>> On 6 November 2017 at 14:41, Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>>> wrote:
>>> > Looks like there is some indentation issue:
>>> >
>>> >
>>> > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/ws/too...
>>> >
>>> > I'll fix it and see if the job runs fine afterward.
>>>
>>> Thanks! And let me know if the CI emails aren't working, we'll look into
>>> that.
>>>
>>> Sanne
>>>
>>> >
>>> > Vlad
>>> >
>>> > On Mon, Nov 6, 2017 at 4:38 PM, Sanne Grinovero <sanne(a)hibernate.org>
>>> > wrote:
>>> >>
>>> >> Vlad, according to CI looks like you are responsible for having merged
>>> >> the offending changes :)
>>> >> Would you mind fixing it? It just failed to build some local
>>> >> experiments and I wasn't sure what I was doing wrong.
>>> >>
>>> >> http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/358/
>>> >>
>>> >> You should have received automated nagging emails too, please let me
>>> >> know if you didn't?
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >
>>> >
8 years, 5 months
