I am writing this letter as I would like to participate in GSoC 2014
developing the following idea: "Bringing the goodness of Java 8 to
Hibernate Validator". I had a conversation with Gunnar Morling and he
suggested to write an introductory letter to this mailing list.
My name is Dmitri Maksimov. I am a Master's degree programme in Informatics
student at Tallinn University of Technology. Java is a primary programming
language in our university, thus I have learned/tried a lot of stuff from
Java itself (such as multithreading, reflection, custom classloaders etc.)
and some corresponding tools and frameworks (Spring, Hibernate etc.).
Currently I am employed as a Java developer and I am developing web-based
GUI using JavaEE 6, JSF + CDI (Weld implementation) for some SOAP service.
Input data validation is quite important for the GUI, so occasionally I
found out about JSR-303/JSR-349 and Hibernate Validator and I thinks it is
So, why am I applying for this idea?
I have a true interest, strong knowledge and some work experience in Java
I really would like to use the chance to gain real-world experience in
using new Java 8 features as well as get more experience with Java as
I like the idea and principles of JSR-303/JSR-349 and Hibernate Validator.
I will gladly answer any questions if necessary. And I look forward to hear
what you think.
Historically annotation binding within Hibernate made a huge assumption
that AccessType and PropertyAccessor were the same thing. They aren't
necessarily. AccessType is simply meant to dictate where to look for
annotations relating to "persistent attributes". PropertyAccessor is
Hibernate's way of accessing property values (getting/setting) at runtime.
Granted, AccessType *by default* should indicate the PropertyAccessor to
use. I am not arguing that. I am just suggesting that we should keep both
as distinct values. At the moment we collapse them into a single String
(we dump AccessType and keep "PropertyAccessor name").
The trouble is that later on we sometimes need to know the AccessType, at
which point we are forced to make a guess by interpreting the
PropertyAccessor in use and hoping that a custom PropertyAccessor was not
Keeping these as distinct values alleviates that. Thoughts?
We just hit the ClassCastException problem with 2nd level cache
reported by other people.
But... we're using *4.3.4.Final* so I'm not sure this issue has really
been fixed with 4.3.4.Final.
Typically, we have the following hierarchy:
TechnicalUser (id = 1)
AccountManager (id = 2)
entityManager.find(AccountManager.class, 1) returns the TechnicalUser
1 and not null if the 2nd level cache is enabled (and the object is in
I'm pretty sure it's not the expected behavior.
Should I open a JIRA issue or do you prefer to reopen an existing
issue? I'm not entirely sure it's due to the same problem so I thought
I might as well ask here.
Thanks for your feedback.
If you notice GitHub links no longer available from issues... well you
aren't alone :)
After then most recent Jira OnDemand update to 6.2 something went screwy in
our DVCS set up. I have engaged Atlassian to help sort it out.
I'm building a new dialect for the FoundationDB SQL layer. I've merged
in the recent metamodel merge into my working branch and ran across this
GeneratedIdColumnHbmTests#testNativeId() fails with an assertion error.
This is caused by
).isIdentity() returns false, which is should return true.
The only place the column.isIdentity() is set true is in
1491). And this is based upon if the
entityIdentifier.getIdentifierGenerator(), which in turn delegates to
Dialect#getNativeIdentifierGeneratorClass(), returns an
The problem here is that a dialect can support IDENTITY column, but not
use (or return) IdentityGenerator from the getNativeIdentifierClass().
FoundationdDB SQL layer supports both IDENTITY and sequences, as does
Is this a bug in Binder? that the test should be better formed to set
the identity column.
Is this a new limitation on Dialects, in that they can no longer
correctly support both IDENTITY and sequences?
What is the correct way to fix this problem?
Here are the meeting minutes.
I did add a manual summary since I don’t know how to effectively use the bot to its full potential.
5.1 is out and plan to push it to WildFly as soon as they permit.
Functional enough MoreLikeThis is out.
Emmanuel needs to open JIRa issues for the remaining work
Sanne needs to explore influence of minTermFreq / mindDocFreq over false positive due content pollution
Release 5.0 Alpha 2 planned for Wednesday. Still need:
- maybe HSEARCH-1508
Keep an eye on Infinispan 7 changes to be able to roll back to 6 if schedule clash
Sanne to update http://hibernate.org/search/roadmap/ or JIRA with tiered focus to reach 5.0 final
Sanne to place dates for each of these milestones to keep us honest. Might be kept team private to avoid noise.
Sanne to steal a bit of Brett’s time from Steve around OSGi
Emmanuel to focus next on free-form as soon as mininal work on MLT is done (identified embedded elements)
Worked on Wildfly module bug (protected visibility).
Davide to move forward to patch ORM to remove the OGM code duplication.
Redis is Davide’s relaxation task.
Davide to focus on Neo4J (rebase, remote support and query support)
### Next release
With Gunnar soon going dark (holiday and preparation for summit, things are a bit undefined.
All bets on Neo4J and Davide
Gunnar focuses on closing near-ending tasks by end of week (incl Adrian’s PR)
### Longer term
Gunnar to explore optimisation related to embedded associations
Gunnar to explore recovery API
Not planning to work actively on a OGM features in the next 2 months. Negotiable. Working on Search has priority.
Instabilities seen on Search should be gone now.
Gunnar and Sanne might be busy preparing Summit for a week. That’ll be a toll of 2 weeks off main project work.
Lots of very intimate back patting going on around performance improvement.
Someone needs to take the lead and write a blog post on 4.2 vs 4.3 perf wise and the performance improvements tricks used.
## Full Minutes
Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...
Shortly after releasing ORM 4.3.2.Final and 4.2.9.Final, a critical regression was found, caused by HHH-8961 and reverted/corrected by HHH-9010. Instead of creating service-pack builds, we decided to simply release the next versions. What happened to 4.3.3? Technically and unfortunately, 4.3.2 == 4.3.3 in Nexus and Central (directly my fault -- long story).
TL;DR: Avoid 4.2.9.Final, 4.3.2.Final, and 4.3.3.Final. Instead, upgrade to 4.2.10.Final or 4.3.4.Final. Apologies for the confusion this has already caused!
Red Hat, Hibernate ORM