Hmm, if that's a regression due to openejb.scan.webapp.container change we should fix it otherwise we'll break a lot of users.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le sam. 9 juin 2018 à 18:48, Mark Struberg <[email protected]> a écrit : > It also picks it up as 2 deplorable a... > > Mit autocorrect gesendet > > > Am 09.06.2018 um 18:02 schrieb Romain Manni-Bucau <[email protected] > >: > > > > What is suspicious is that: > > 1. was working well for years > > 2. it is already isolated in tomee since we scan the deployable and not > the > > classpath for that reason > > > > maybe the default scanning of the container change? > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le sam. 9 juin 2018 à 16:20, Mark Struberg <[email protected]> a > > écrit : > > > >> commenting out adding the persistence.xml to the arquillian test makes > it > >> pass: > >> @Deployment > >> public static WebArchive archive() { > >> return new WebModule(SubjectServiceTomEETest.class).getArchive() > >> .addClass(VoteCounter.class) > >> .addPackage(Subject.class.getPackage()) // domain > >> //X .addAsWebInfResource(new > >> ClassLoaderAsset("META-INF/persistence.xml"), "persistence.xml") > >> > >> We had such problems in OpenWebBeans as well. There we opted to isolate > >> the app away completely.That's one of the shortcomings of Arquilian in > >> practice. It sadly makes a difference whether you run it embedded vs > >> in-container vs remote-container :( > >> LieGrue,strub > >> > >> On Saturday, 9 June 2018, 16:13:52 CEST, Mark Struberg > >> <[email protected]> wrote: > >> > >> It seems like one is coming from > >> > file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#pollingthe > >> other from > >> > >> > file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#polling > >> > >> > >> As if it would be an Arquillian setup issue.I compared fb8 with master > but > >> could not find any differences though. > >> LieGrue,strub > >> On Saturday, 9 June 2018, 14:28:38 CEST, Romain Manni-Bucau < > >> [email protected]> wrote: > >> > >> Can be a classloader change with a recent upgrade. > >> > >> Le sam. 9 juin 2018 13:23, Mark Struberg <[email protected]> a > >> écrit : > >> > >>> > >>> I get a duplicate unit exception in > >>> jug.rest.arquillian.SubjectServiceTomEETest which is in > polling-web.This > >>> happens in the fb_tomee8 branch. > >>> > >>> 0 = {TreeMap$Entry@5654} > >>> > >> > "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#client1" > >>> -> > >>> 1 = {TreeMap$Entry@5655} > >>> > >> > "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#client2" > >>> -> > >>> 2 = {TreeMap$Entry@5656} > >>> > >> > "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#polling" > >>> -> > >>> 3 = {TreeMap$Entry@5657} > >>> > >> > "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#client1" > >>> -> > >>> 4 = {TreeMap$Entry@5658} > >>> > >> > "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#client2" > >>> -> > >>> 5 = {TreeMap$Entry@5659} > >>> > >> > "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#polling" > >>> -> > >>> > >>> > >>> Anyone has an idea why? > >>> txs and LieGrue,strub > >>> > >
