bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: build fails with OWB-1.7.3 and later
Date Mon, 10 Jul 2017 09:07:52 GMT
Oki, think I found the problem.
In a refactoring I seem to have trashed the OWB Arquillian OwbSWClassLoader. 

It currently does return new URL(null, "archive:" + nodes.iterator().next());
But should really be
return new URL(null, "archive:" + node, new ArchiveStreamHandler())
Will be fixed in OWB-2.0.0 and 1.7.5 releases.
Until then we gonna update to OWB-1.7.2 which runs stable.Again: it's actually not an OWB
core bug but just in the Arquillian container.


On Monday, 10 July 2017, 10:53:41 CEST, Mark Struberg <> wrote:

Currently using 2 boxes in parallel to spot the differences. 
It seems that in ValidationParser#applyConfigWithInstantiation the xmlConfig is null with
OWB-1.7.3 and above. No idea why yet ...

On Monday, 10 July 2017, 10:28:26 CEST, Romain Manni-Bucau <> wrote:

Ok, recall having done most of the setup so shout if you need me to reopen
it ;)

Le 10 juil. 2017 10:22, "Mark Struberg" <> a
écrit :

> Hi folks!
> BVal currently uses OWB-1.6.0 for the TCK. All works fine up to until
> OWB-1.7.2, but from 1.7.3 up it fails.
> I've now checked a few tests and I'm quite confused.
> For example in
> MessageInterpolatorSpecifiedInValidationXmlNoDefaultConstructorTest
> The config file validation-MessageInterpolatorSpecifiedIn
> ValidationXmlNoDefaultConstructorTest.xmlreferences a class
> org.hibernate.beanvalidation.tck.tests.xmlconfiguration.
> XmlDefinedMessageInterpolator.NoDefaultConstructorInterpolator
> But NoDefaultConstructorInterpolator is actually an inner class. And thus
> it must be configured as
> org.hibernate.beanvalidation.tck.tests.xmlconfiguration.
> XmlDefinedMessageInterpolator$NoDefaultConstructorInterpolator
> Note the '$' for inner classes.
> And of course since this is a dot instead a $ we blow up with a
> ClassNotFoundException.Now the weird thing is that this test expects a
> failure, and thus it is green - but certainly in a way which was not
> intended ;)
> I'm currently trying to figure why it fails with OWB-1.7.4 and then also
> will test with OWB-2.0.0.
> LieGrue,strub
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message