Problems building Core
by Hardy Ferentschik
Hi,
just wondering whether someone could confirm that the reactor build of
Core is broken.
There is a sort of expected failure in
EmbeddedTypeTest.testSingularAttributeAccessByNameFailureExpected
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
OutOfMemoryError:
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
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)
at java.lang.StringBuffer.append(StringBuffer.java:225)
at
org.testng.reporters.SuiteHTMLReporter.generateMethodsChronologically(SuiteHTMLReporter.java:429)
at
org.testng.reporters.SuiteHTMLReporter.generateReport(SuiteHTMLReporter.java:67)
at org.testng.TestNG.generateReports(TestNG.java:735)
at org.testng.TestNG.run(TestNG.java:721)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74)
at
org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
--Hardy
14 years, 11 months
Hibernate as a persistence engine
by Adam Warski
Hello,
I took a look at the new meta-model proposed by Steve; in case anybody hasn't seen it it's here:
http://anonsvn.jboss.org/repos/hibernate/sandbox/trunk/new-metadata/
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:
1) database
2) mapping
3) java
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()
4c) xml
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! :)
Adam
15 years
Missing setLoadedPersister() and this.loadedKey = loadedKey in CollectionEntry constructor ?
by Florent Bayle
Hi,
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,
PersistentCollection collection).
It seems that in this constructor, setLoadedPersister(loadedPersister)
isn't called, nor this.loadedKey = loadedKey, contrary to the other
constructors.
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 ?
Thanks.
--
Florent Bayle
15 years
trunk test failure...
by Scott Marlow
I updated trunk and get the following test failure during build:
"
Failed tests:
init(org.hibernate.envers.test.integration.naming.VersionsJoinTableRangeComponentNamingTest)
"
I don't see any details about this failure and cannot seem to run
VersionsJoinTableRangeComponentNamingTest as a unit test within
intellij.
Any ideas?
Scott
15 years
new generation of spambots in forums
by Sanne Grinovero
Hello,
since some months I've seen a raising rate of weird posts, like this one today:
https://forum.hibernate.org/viewtopic.php?f=9&t=1001443
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.
Sad.
Sanne
15 years
Returned mail: Data format error
by The Post Office
The original message was received at Sun, 20 Dec 2009 12:47:47 +0530 from lists.jboss.org [81.60.39.171]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
----- Transcript of session follows -----
... while talking to 175.209.140.172:
554 5.0.0 Service unavailable; [161.40.136.29] blocked using bl.spamcop.net
Session aborted
15 years
Fwd: Re: No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
by Galder Zamarreno
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?
No idea....
> 2. Why is there a hint on how to use JTA environment, just using
> hibernate without JTA?
No idea...
> 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
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
15 years, 1 month
Hibernate & Java 5 ?
by Alex Snaps
Hey,
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
that patch...
Btw do you guys have a contributor agreement somewhere, I couldn't find it.
Thanks,
Alex
--
Alex Snaps <alex.snaps(a)gmail.com>
Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
15 years, 1 month
