I'm being bitten by HHH-3919 and figured I'd just fix it.
So I wrote a patch and had all kinds of fun trying to test it. Is there
some page that tells me what I should do to get started?
For references I'm on Ubuntu 8.10 with:
neverett@neverett-laptop:~$ mvn -version
Maven version: 2.0.9
Java version: 1.6.0_10
OS name: "linux" version: "2.6.27-14-generic" arch: "amd64" Family: "unix"
neverett@neverett-laptop:~$ svn --version
svn, version 1.5.1 (r32289)
compiled Jul 31 2008, 09:45:20
Here is what I did:
svn co http://anonsvn.jboss.org/repos/hibernate/core/trunk
<edit ~/.m2/settings.xml and add jboss repositories>
mvn clean install
That failed because I'm on Java 1.6 and there are JDBC incompatibilities.
I'm not sure how I'd have known that other than the comment at the bottom of
https://www.hibernate.org/422.html . So I installed Java 1.5 and tried
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun/ mvn clean install
That failed in testsuite with:
Tests in error:
Where should I go from here? Is there some kind of script I can follow?
Couldn't help to notice that Hibernate Core 3.2.7 which was released on
June 4th was not deployed to JBOSS maven repository (and still isn't in
central). When would this be added to JBOSS repo? Thanks
I think there is another error in the Validator javadoc. Probably a
* @throws IllegalArgumentException if object is null, if propertyName
* or not a valid object property
* or if null is passed to the varargs
* @throws ValidationException if a non recoverable error happens
* during the validation process
<T> Set<ConstraintViolation<T>> validateValue(Class<T> beanType, String
propertyName, Object value, Class<?>... groups);
IllegalArgumentException if object is null seems to be wrong. Probably
should be "if beanType is null". null as value seems to be a valid case.
Hibernate Shards is still in a beta version, and I have checked the project
has not had too much activity in the last two years. Are expected new
releases in a near future? Have the goals of the project been integrated in
I'm reviving previous discussion.
#3 Index copy
> this is what you are describing, copying the index using JGroups instead of
> my file system approach. This might have merits esp as we could diminish
> network traffic using multicast but it also require to rethink the master /
> slave modus operandi.
> Today the master copy on a regular basis a clean index to a shared
> On a regular basis, the slave go and copy the clean index from the shared
> In your approach, the master would send changes to the slaves and slaves
> would have to apply them "right away" (on their passive version)
> I have been discussing with Manik on #3 and we think that JBoss Cache /
> Infinispan are probably a better fit than plain JGroups for that as all the
> plumbing will be configured for you.
> When you reach this problem, let's revive this discussion.
I was thinking about possible ideas about this problem, but could I get some
directions and advices where to start. Does JBC/Infinispan job should be to
store index (kind of shared directory) copied from master, and makes it
available for slaves? Or maybe better idea is to write custom
DirectoryProvider based on JBC/Infinispan with passing over current
master/slave directory providers?
the code of Hibernate Search is very extensible, as nearly all
internal modules are "overridable" by user provided implementation;
this external classes are loaded by defining a short name (in case of
built-in extensions) or fully qualified names to load
whatever is on the classpath to replace internals.
For some issues I'll soon have to be copy-pasting the usual exception
handling code around, again..
A quick regex count on the code base reveals that this same code is
duplicated in other 25 places, mostly correct but sometimes
forgetting to handle one or two cases (for example ClassCastException
is not handled often)
I am building a util class to get some consistency, and plan to unit
test this extensively to make sure it throws understandable exceptions
for the most common mistakes (hey, I need a public no-args
constructor! / not implementing the X interface! / ...)
-> DRY, improve error messages.
would this be a good moment to apply such a refactoring? I don't need
to replace all cases, but would like to apply it on most,
or at least the new code going to be written.
Should I change all use cases I can find? I like consistency, not conflicts.
With Hibernate Core 3.3.2 just released, it seems like a relevant time
What happened to the ongoing struggle to get jboss artifacts synced to
Could we please have an update of what the current status is?
I just realized that PatternValidator checks if the String passed to it
is null or not before checking it's validity, but it doesn't check if the
String is empty. What if someone wants to put a regular expression
constraint on a non mandatory field, and the framework he uses sets this
empty field to an empty string? What do you think?