Participation in GSoC 2014
by Dmitri Maksimov
Hello!
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
great.
So, why am I applying for this idea?
I have a true interest, strong knowledge and some work experience in Java
platform.
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
general.
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.
--
Yours faithfully,
Dmitri Maksimov.
12 years, 2 months
Separating javax.persistence.AccessType and org.hibernate.property.PropertyAccessor
by Steve Ebersole
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
supplied.
Keeping these as distinct values alleviates that. Thoughts?
12 years, 2 months
ClassCastException with 2nd level cache not entirely gone?
by Guillaume Smet
Hi all,
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:
AbstractUser
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
the cache).
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.
--
Guillaume
12 years, 3 months
GitHub links in Jira
by Steve Ebersole
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.
12 years, 3 months
GeneratedIdColumnHbmTests#testNativeId test fails with dialect supporting both IDENTITY and SEQUNCES
by Thomas Jones-Low
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
new failure.
GeneratedIdColumnHbmTests#testNativeId() fails with an assertion error.
This is caused by
entityBinding.getPrimaryTable().getPrimaryKey().getColumns().get( 0
).isIdentity() returns false, which is should return true.
The only place the column.isIdentity() is set true is in
org.hibernate.metamodel.internal.Binder#bindIdentifierGenerator(line
1491). And this is based upon if the
entityIdentifier.getIdentifierGenerator(), which in turn delegates to
Dialect#getNativeIdentifierGeneratorClass(), returns an
IdentityGenerator.class
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
the PostgreSQLDialect.
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?
12 years, 3 months
Team meeting minutes
by Emmanuel Bernard
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.
## Validator
5.1 is out and plan to push it to WildFly as soon as they permit.
## Search
### MoreLikeThis
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
Release 5.0 Alpha 2 planned for Wednesday. Still need:
- HSEARCH-1513
- maybe HSEARCH-1508
Keep an eye on Infinispan 7 changes to be able to roll back to 6 if schedule clash
### Roadmap
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
### free-form
Emmanuel to focus next on free-form as soon as mininal work on MLT is done (identified embedded elements)
## OGM
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.
### Neo4J
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
### Emmanuel
Not planning to work actively on a OGM features in the next 2 months. Negotiable. Working on Search has priority.
## CI
Instabilities seen on Search should be gone now.
## Summit
Gunnar and Sanne might be busy preparing Summit for a week. That’ll be a toll of 2 weeks off main project work.
## ORM
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: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...
Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...
Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...
12 years, 3 months
