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 ema
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 cu
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 clas
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
On Thu, 14 Jan 2010 15:14:16 -0300, Steve Ebersole
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 add/remove dependencies?
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 "othe
Speaking of plugins, what does the maven-test-ext-plugin do for us and why
is it needed in
the annotations module? The build seems to work fine even w/o.
--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailm
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
wrote:
>> even if this means that we increase the chance getting more
>> unreprod
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
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
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
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.
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
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?
-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 javax.persistence.PersistenceExcepti
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
We should probably just remove them I think. Pretty annoying to see the
same version output over and over and over.
On Thu, 2010-01-14 at 11:34 +0100, Emmanuel Bernard wrote:
> Yeah!
> I've just noticed one glitch (except the NPE I managed to add ;) ). The
> Version numbers in the logs are not u
Ah, backrefs!
Just disregarding them makes the most sense for sure from the JPA
perspective since they are "virtual attributes" and solely a hibernate
construct.
On Thu, 2010-01-14 at 11:29 +0100, Emmanuel Bernard wrote:
> On 13 janv. 2010, at 20:37, Hardy Ferentschik wrote:
> > I have a couple o
Oddly it does that already. Its just that only Serailaizable.class is
ever passed
http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/Hibernate.java?r=17767#l233
This has to do with the "static" nature of the type system.
On Thu, 2010-01-14 at 11:19 +0100, Emman
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
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
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 fai
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 wrote:
> Hello,
>
>> Though it uncovered a weird problem.
>> When I run the entire envers test suite, I pass with flags up.
>
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
__
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
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:
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
27 matches
Mail list logo
