just wondering whether someone could confirm that the reactor build of
Core is broken.
There is a sort of expected failure in
in the entitymanager module. But even after commenting out this test I am
not able to complete the build.
I am having problems with the Envers test suite where I am getting an
org.apache.maven.surefire.booter.SurefireExecutionException: Java heap
space; nested exception is java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I took a look at the new meta-model proposed by Steve; in case anybody hasn't seen it it's here:
If I correctly understood Steve and the code, the model builds on the JPA2 meta-model. In the proposition there are three levels of meta-data:
However as Steve mentioned on IRC, there is a problem with alternate entity modes (today these are "map" and "xml").
(For me they are very useful, as Envers uses the "map" entity mode to dynamically generate the audit entities.)
Don't you think that an "entity" meta-data level would be useful?
The basic layers would then be:
1) database - information about tables, columns, foreign keys, indexes
2) mapping - binding between levels 1 and 3, that is, assignment from properties to columns, from entities to tables etc
3) entity - information about entity names, property names, property types (a property can be a simple value, many-to-one, one-to-many, (...) relation, a component etc). For example, a many-to-many relation property would have no idea that it's mapped using a join table.
Now there could be several layers that build on that. Each such layer would have to specify what is an entity and what is a property; how to get/set a property from an entity; how to read other meta-data (from annotations? or from xml?)
4a) java - an entity is a class; holds information if properties are accessed using fields or getters/setters
4b) map - an entity is a map; properties accessed using Map.get()
In the longer run, maybe Hibernate could become more of a "persistence engine".
That is, it would provide a nice entity abstraction of a database (so abstracting level 1 using level 3 as the access point).
It would play nicely with another project that I have in mind, namely an ORM for Scala that would use Hibernate. Only a new entity mode (level 4) would have to be written, which would be a translation from Scala constructs to entities, properties, relations. (Maybe that would even be something that Bob could use in TorqueBox.)
What do you think?
Merry Christmas! :)
While testing one of our app, I found a problem : after saving a pojo
with a new HashSet, the saved pojo PersistentSet role/key were null.
I tracked the problem down to one of the CollectionEntry constructors:
public CollectionEntry(CollectionPersister persister,
It seems that in this constructor, setLoadedPersister(loadedPersister)
isn't called, nor this.loadedKey = loadedKey, contrary to the other
Thus, when collection.setSnapshot(loadedKey, role, snapshot) is
called at the end of the constructor, role and loadedKey are null and
so, the PersistentSet role/key are null.
Is there a reason for that, and is it possible to patch it ?
I updated trunk and get the following test failure during build:
I don't see any details about this failure and cannot seem to run
VersionsJoinTableRangeComponentNamingTest as a unit test within
since some months I've seen a raising rate of weird posts, like this one today:
It looks like there's some clever bot agent, as the post makes
_almost_ sense in the context but they always have a signature linking
to some website as advertising
They're not very frequent AFAIK, still annoying.
I'm thinking the goal for such a bot is likely to rise the pagerank
than to make real advertising, also considering they're not very
frequent. It could make sense to ban links in posts, forcing people to
write them as text.
The original message was received at Sun, 20 Dec 2009 12:47:47 +0530 from lists.jboss.org [22.214.171.124]
----- The following addresses had permanent fatal errors -----
----- Transcript of session follows -----
... while talking to 126.96.36.199:
554 5.0.0 Service unavailable; [188.8.131.52] blocked using bl.spamcop.net
On 12/14/2009 01:59 PM, Guenther Demetz wrote:
> Hi hibernate developers,
> Since various hibernate releases (3.2, 3.3 , 3.5beta2) I'm still
> wondering about following warning when using hibernate with
> JDBCTransactionFactory (= without JTA integration):
> TransactionManagerLookupFactory:80 - No TransactionManagerLookup
> configured (in JTA environment, use of read-write or transactional
> second-level cache is not recommended)
> 1. According documentation configuration of a TransactionManagerLookup
> is (only) required when using JTA environment, so why this warning?
> 2. Why is there a hint on how to use JTA environment, just using
> hibernate without JTA?
> 3. "transactional" concurrency strategy is supported by JBossCache and
> Infinispan and both require integration with JTA,
> so why should transactional second-level cache not be recommended ?!
Hmmm, the warning message looks rather confusing IMO. From what I
understand, it is, at least, trying to say that using a transactional
cache strategy when you haven't configured transaction manager lookup
class is not recommended. Not sure why it also refers to read-write. I
don't know that strategy that well.
> best regards
> Guenther D.
> hibernate-dev mailing list
Doing a svn update of the Hibernate trunk, I realized I probably had
changed the project to be Java5 manually as it reverted to 1.4
(because of some pom.xml change) in IntelliJ.
Talking to Max and Emmanuel at Devoxx I thought trunk was now to be
Java 5? Is this not the case after all, or are poms only update when
the first Java5 language/jdk feature sneaks in?
As discussed we discussed, all the statistics work heavily rely on
java.util.concurrent classes, so that is "more or less" important for
Btw do you guys have a contributor agreement somewhere, I couldn't find it.
Alex Snaps <alex.snaps(a)gmail.com>
Software Engineer - Terracotta