On 13 janv. 2010, at 19:10, Steve Ebersole wrote:
So, getReturnedClass().getClassLoader() is not the answer here.
There is the only answer unfortunately. Really you'd want the Class of
the class implementing Serializable, but given how Hibernate's type
system works currently, that's not
On 13 janv. 2010, at 20:37, Hardy Ferentschik wrote:
I have a couple of question regarding some recent code changes. The first one
seems to be the cause of a
test failure in VersionsJoinTableRangeComponentNamingTest (Envers). It
actually causes a NullPointerException.
Have a look at:
Yeah!
I've just noticed one glitch (except the NPE I managed to add ;) ). The Version
numbers in the logs are not updated for annotations and entity manager.
We should add them to the release procedure.
Or simply remove them now that ANN and HEM are part of Core. The only drawback
I see is that
Hello,
Though it uncovered a weird problem.
When I run the entire envers test suite, I pass with flags up.
When I specifically run VersionsJoinTableRangeComponentNamingTest
That's probably because the test is disabled in the suite :).
--
Adam
___
We disabled the test yesterday in order to do the release.
It was failing in w/ and w/o a fix to Emmanuel's code.
--Hardy
On Thu, 14 Jan 2010 09:24:23 -0300, Adam Warski a...@warski.org wrote:
Hello,
Though it uncovered a weird problem.
When I run the entire envers test suite, I pass with
Right, I tried to explain the failure in the first email. But AFAIK the bug has
been there for a little while (ie before the work i've done in the last couple
of days).
On 14 janv. 2010, at 13:54, Hardy Ferentschik wrote:
We disabled the test yesterday in order to do the release.
It was
Hello,
Right, I tried to explain the failure in the first email. But AFAIK the bug
has been there for a little while (ie before the work i've done in the last
couple of days).
yes, it's there for at least two weeks. I mentioned it on IRC before but I
guess it didn't draw any attention.
I
I think we could do the same with the version string as we do in Validator
( and maybe Search, not sure ). There we
read the version string from the MANIFEST file. The nice things about this
is that the version in the MANIFEST is
dynamically created during the build.
Generally there are quite
On Thu, 2010-01-14 at 10:17 -0300, Hardy Ferentschik wrote:
I think we could do the same with the version string as we do in Validator
( and maybe Search, not sure ). There we
read the version string from the MANIFEST file. The nice things about this
is that the version in the MANIFEST is
-until 3.5.0-Beta-2 a ConstraintViolationException during commit caused
an implicite rollback and the exception was wrapped into a
javax.persistence.RollbackException
-now with 3.5.0-Beta-3 the same ConstraintViolationException during
commit is wrapped into a
On 01/14/2010 05:34 AM, Emmanuel Bernard wrote:
Or simply remove them now that ANN and HEM are part of Core. The only
drawback I see is that HEM runs before Core but I guess we could
trigger the call to the static version display from HEM to Core.
They're still separate jars though, right? If
On 14 janv. 2010, at 15:35, Steve Ebersole wrote:
Ah, backrefs!
Something you want to confess Steve? ;)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Hello,
I cannot reproduce what you are describing.
Here are the two tests I have on the subject.
http://fisheye.jboss.org/browse/Hibernate/core/trunk/entitymanager/src/test/java/org/hibernate/ejb/test/beanvalidation/BeanValidationTest.java?r=18556
How is your configuration different?
On 14 janv.
I agree. As long as they are separate jars it makes sense to have different
version strings. It makes it easier to detect if someone has library
problems, eg
an old annotations jar in a shared server lib.
However, we should align the version string creation with whatever happens
in Core,
even
Good point.
On Thu, 2010-01-14 at 09:57 -0500, Chris Bredesen wrote:
On 01/14/2010 05:34 AM, Emmanuel Bernard wrote:
Or simply remove them now that ANN and HEM are part of Core. The only
drawback I see is that HEM runs before Core but I guess we could
trigger the call to the static
On Thu, 2010-01-14 at 13:06 -0300, Hardy Ferentschik wrote:
However, we should align the version string creation with whatever happens
in Core,
I agree
even if this means that we increase the chance getting more unreproducible
build problems
using Steve's magic plugin.
Btw when was the
That's right. I was already wondering why it stopped failing. I was always
hoping
that it would happen so that I could bug you :) Now you destroyed my hopes.
On Thu, 14 Jan 2010 14:52:14 -0300, Steve Ebersole st...@hibernate.org
wrote:
even if this means that we increase the chance getting
Its there to mimic behavior JVZ promised me he would add to Maven but
never has (in 3 years). Basically it allows you to *dynamically* alter
the test classpath. We don't use it per se because its not really
intended for us. Its intended for people running the hibernate
testsuite(s) against
On Thu, 14 Jan 2010 15:14:16 -0300, Steve Ebersole st...@hibernate.org
wrote:
Its there to mimic behavior JVZ promised me he would add to Maven but
never has (in 3 years). Basically it allows you to *dynamically* alter
the test classpath.
Interesting. Does it mean I can dynamically
Also, you seem to have a quite elaborate functional test that simply
checks whether SerializationHelper is able to handle deserialing a class
from an isolated classloader via the SerializableType. Couldn't we
just have a simple unit test that asserted exactly that?
On Wed, 2010-01-13 at 20:25
FYI
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4799
On Thu, 2010-01-14 at 13:23 -0600, Steve Ebersole wrote:
Also, you seem to have a quite elaborate functional test that simply
checks whether SerializationHelper is able to handle deserialing a class
from an isolated
Hmm, I think I may have dropped something in translation when I ported
this test from the JBoss AS/EJB3 testsuite.
These tests originate in AS tests that check whether the JBC 2nd level
cache integration handles cases where the key Hibernate passes as a
param to cache write operations uses
Unsubscribe
On Jan 14, 2010, at 10:27 AM, hibernate-dev-requ...@lists.jboss.org wrote:
Send hibernate-dev mailing list submissions to
hibernate-dev@lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/hibernate-dev
or, via
23 matches
Mail list logo
