AFAIK, the hibernate MBean is no longer maintained, hence why the new
properties such as hibernate.cache.region.jbc2.cfg.entity are not mapped
to Hibernate MBean attributes. Am I correct? Would someone from the
Hibernate team care to provide an answer?
Sr. Software Engineer
Infinispan, JBoss Cache
Just to let you know that I'm focusing on writing up the DSL asap. I
realise that since I've switched over to part-time due to university
term it's tough to keep in touch with everyone constantly. So I
thought I'd just drop the list a quick spam email.
Emmanuel, you had mentioned that you want this done fairly quick (from
other emails on the list) so I'm gonna push to do this as quick as I
can. The next couple of weeks are likely to be slightly busy but I
should have one or two Mondays off in the run-in to Devoxx so fingers
crossed over those I can sit down and hack through some coding. Also
since I'll be around for a full day it will be easier to communicate
via Skype etc etc.
I'll generally try and keep people updated as much as I can via
emailing the devlists so I can get some feedback/input/strokes of
genius from the various crews.
Intern JBoss Cache Searchable
For JPA2 support, I propose that Hibernate LockMode support the
following equivalents of JPA2 LockModeType locks:
Hibernate already supports NONE, so that doesn't need to be added. JPA2
defaults to LockModeType NONE.
JPA1 READ + WRITE will be supported respectively via LockMode.OPTIMISTIC
With this change, Hibernate (native (better term?)) applications would
be able to request JPA2 like locks. This also means that JPA2
applications running with the Hibernate Entity Manager, will see similar
locking behavior as native applications.
- Application developers will have a consistent set of locking options
in their JPA2 based applications and native Hibernate applications.
- This helps the application developer to prepare their native Hibernate
application to migrate to JPA2.
- This ties Hibernate core locking internals to the JPA2 specification.
As JPA continues to evolve, Hibernate core should follow in lockstep.
Although, that is not a hard requirement.
- An alternative would be introducing low level locking primitives that
could be combined to support JPA2 style locks. I can explore this path
if there is strong push back to the above proposal.
had a chat with Navin today, he was pinging me about HSEARCH-397. He
is needing that for the Infinispan release.
This issue was planned for Search 3.3 which is quite far away.. I've
just changed that to 3.2.0 but even so are you thinking in releasing
that before the end of this year (the Infinispan release timeframe) ?
Maybe we could start planning a beta release and define which issues
I've seen there are 30 issues open, some are trivial and some are
nearly done, like dynamic boosting is only missing documentation.
I'd suggest postponing the hard stuff like
HSEARCH-361 Only index an entity if an indexed property has changed
HSEARCH-275 support new NIOFSDirectory, a multithreaded optimized FSDirectory
HSEARCH-364 Make Hibernate Search fully mockable
unless you have concrete ideas about how to implement them.
HSEARCH-246 Run optimize at the end of the transaction even if
flushToIndexes() is used
I don't need this one anymore as MassIndexer has it's own concept of
queues. IMHO a Beta is needed so that somebody tries the MassIndexer
HSEARCH-392 JGroups based backend
Is Łukasz willing to write a documentation patch?
HSEARCH-370 Monitoring of batch indexer state and progress
I'm in need of some directions on this one from someone having tried
to use it; the prototype API was committed as part of HSEARCH-218
Mutual dependency: so Infinispan is needing a Search release, and
Search an Infinispan release? It's about a submodule from the one
depending on the core of the other, still we should release at least a
beta to make a deployment possible, or have Infinispan release
submodules later than core?
I was just wondering whether we have reached a decision yet for the 3.2.0
release of HSearch?
Some of the issues scheduled for this release and assigned to me do not
seem to be that important.
I will go through them in Jira.
I will also try to finish the DynamicBoost documentation over the weekend.
It will be another small
step towards the next release of HSearch :)
Some enforcer has been added to maven to avoid improper compilation
with the incorrect JDK.
One of the problem with that is I can't test annotations /
entitymanager (ie run tests) with JDK 6. Is there a way around that?
MassIndexerImpl is 100% dependent of Hibernate Core (you pass a
How realistic and doable is it to abstract that a bit. For example,
would an Infinispan based mass indexer make sense? If yes, what's
reusable in your impl (I mean aside from the MassIndexer interface).