From gtrikler at redhat.com Mon Jul 4 09:11:14 2016 From: gtrikler at redhat.com (Gytis Trikleris) Date: Mon, 4 Jul 2016 15:11:14 +0200 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown Message-ID: Hello, I?m in the process of writing an analysis document for https://issues.jboss.org/browse/EAP7-459 and need your input. Specifically I?m looking for the list of subsystems which might need to create new transactions during the graceful shutdown. Normally new transactions would not be allowed then, but this might stop other subsystems to shutdown properly. If such subsystems exist we?ll need to think of the way how to filter out their requests (e.g. providing SPI for them). Thanks, Gytis From darran.lofthouse at jboss.com Tue Jul 5 05:13:17 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 5 Jul 2016 10:13:17 +0100 Subject: [wildfly-dev] WildFly 11 Model and Schema Version Bumps In-Reply-To: <565D87F0.7030605@jboss.com> References: <565D87F0.7030605@jboss.com> Message-ID: Just sending this again as a quick reminder as some conflicts are appearing. On 01/12/15 11:43, Darran Lofthouse wrote: > Just a FYI, > > In preparation for WildFly 11 I already have bumped the schema versions > and model for numerous parts of WildFly - if you plan to work on any > WildFly 11 changes that would also require a bump of any of these let me > know and I can point you to a branch where the changes have already been > made. > > The models bumped so far are: - > > - Core Management Model and Schema > - Remoting Subsystem > - Undertow Subsystem > - EJB Subsystem > - Security Subsystem > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Tue Jul 5 13:30:16 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 5 Jul 2016 12:30:16 -0500 Subject: [wildfly-dev] Versions in JBoss Modules Message-ID: <577BEEA8.1030909@redhat.com> With this PR [1] for issue MODULES-257 [2], JBoss Modules (as of version 1.6.0) will gain the ability to associate a version string with each module that is defined. I have not yet merged this PR; I want to see if anyone has any feedback on the change first. Of note is that I define a syntax for versions, as well as a sort order that should be largely Maven-compatible. The module version can be queried at run time, will appear in modules' toString(), and starting in Java 9, should also appear in stack traces (though this is not certain yet). Ideally we will be able to copy version information into our shipped modules when we build feature packs. If nobody has any feedback in the next few days, I will go ahead and merge the change. [1] https://github.com/jboss-modules/jboss-modules/pull/101 [2] https://issues.jboss.org/browse/MODULES-257 -- - DML From stuart.w.douglas at gmail.com Tue Jul 5 19:00:48 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 6 Jul 2016 09:00:48 +1000 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: Local transaction creation has to be allowed during graceful shutdown. e.g. if a web request is in the process of running and it attempts to start a transaction this must be allowed (the core requirement of graceful shutdown is that requests that have already been accepted continue to run as normal). The only case when transactions should be disallowed are remote transactions, such as remote EJB and CORBA, which I think should already be dealt with at the respective endpoints (in terms of disallowing new transaction creation). I think the main thing that needs consideration here is what to do with EJB requests that would otherwise be rejected that are part of an existing remote transaction. We probably need some way of identifying these requests and allowing them to proceed. Stuart On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris wrote: > Hello, > > I?m in the process of writing an analysis document for > https://issues.jboss.org/browse/EAP7-459 and need your input. > Specifically I?m looking for the list of subsystems which might need to > create new transactions during the graceful shutdown. Normally new > transactions would not be allowed then, but this might stop other > subsystems to shutdown properly. If such subsystems exist we?ll need to > think of the way how to filter out their requests (e.g. providing SPI for > them). > > Thanks, > Gytis > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160706/39724366/attachment.html From wfink at redhat.com Wed Jul 6 04:37:46 2016 From: wfink at redhat.com (Wolf Fink) Date: Wed, 6 Jul 2016 10:37:46 +0200 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: Also I expect EJB chains working, I mean the following sequences - remote->EJB (@NotSupported @Supports - no Tx started) -> internal EJB (no matter whether called via Local/Remote interface) with @ReqNew or @Required - remote->EJB (any Tx started @Supports @Required @RequiresNew @Mandatory) -> internal EJB (no matter whether called via Local/Remote interface) @RequiresNew I'm not sure about this use-case with a client (no matter whether it is a standalone app or another server) - client starts a Tx - client call EJB1 in Tx which return - -> start Graceful shutdown - client call EJB2 in the same Tx - maybe EJB2 is annotated with @RequiresNew and need to suspend Tx1 and start a new one to succeed My expectation and hope is that such scenario is possible to continue and finish successfully. Wolf On Wed, Jul 6, 2016 at 1:00 AM, Stuart Douglas wrote: > Local transaction creation has to be allowed during graceful shutdown. > e.g. if a web request is in the process of running and it attempts to start > a transaction this must be allowed (the core requirement of graceful > shutdown is that requests that have already been accepted continue to run > as normal). > > The only case when transactions should be disallowed are remote > transactions, such as remote EJB and CORBA, which I think should already be > dealt with at the respective endpoints (in terms of disallowing new > transaction creation). I think the main thing that needs consideration here > is what to do with EJB requests that would otherwise be rejected that are > part of an existing remote transaction. We probably need some way of > identifying these requests and allowing them to proceed. > > Stuart > > > > On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris > wrote: > >> Hello, >> >> I?m in the process of writing an analysis document for >> https://issues.jboss.org/browse/EAP7-459 and need your input. >> Specifically I?m looking for the list of subsystems which might need to >> create new transactions during the graceful shutdown. Normally new >> transactions would not be allowed then, but this might stop other >> subsystems to shutdown properly. If such subsystems exist we?ll need to >> think of the way how to filter out their requests (e.g. providing SPI for >> them). >> >> Thanks, >> Gytis >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160706/c4c6b873/attachment-0001.html From stuart.w.douglas at gmail.com Wed Jul 6 05:14:45 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 06 Jul 2016 09:14:45 +0000 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: This works fine at the moment, anything that stopped this I would consider to be a regression. Stuart On Wed, 6 Jul 2016, 18:37 Wolf Fink wrote: > Also I expect EJB chains working, I mean the following sequences > - remote->EJB (@NotSupported @Supports - no Tx started) -> internal EJB > (no matter whether called via Local/Remote interface) with @ReqNew or > @Required > - remote->EJB (any Tx started @Supports @Required @RequiresNew @Mandatory) > -> internal EJB (no matter whether called via Local/Remote interface) > @RequiresNew > > I'm not sure about this use-case with a client (no matter whether it is a > standalone app or another server) > - client starts a Tx > - client call EJB1 in Tx which return > - -> start Graceful shutdown > - client call EJB2 in the same Tx > - maybe EJB2 is annotated with @RequiresNew and need to suspend Tx1 and > start a new one to succeed > > My expectation and hope is that such scenario is possible to continue and > finish successfully. > > Wolf > > > > > On Wed, Jul 6, 2016 at 1:00 AM, Stuart Douglas > wrote: > >> Local transaction creation has to be allowed during graceful shutdown. >> e.g. if a web request is in the process of running and it attempts to start >> a transaction this must be allowed (the core requirement of graceful >> shutdown is that requests that have already been accepted continue to run >> as normal). >> >> The only case when transactions should be disallowed are remote >> transactions, such as remote EJB and CORBA, which I think should already be >> dealt with at the respective endpoints (in terms of disallowing new >> transaction creation). I think the main thing that needs consideration here >> is what to do with EJB requests that would otherwise be rejected that are >> part of an existing remote transaction. We probably need some way of >> identifying these requests and allowing them to proceed. >> >> Stuart >> >> >> >> On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris >> wrote: >> >>> Hello, >>> >>> I?m in the process of writing an analysis document for >>> https://issues.jboss.org/browse/EAP7-459 and need your input. >>> Specifically I?m looking for the list of subsystems which might need to >>> create new transactions during the graceful shutdown. Normally new >>> transactions would not be allowed then, but this might stop other >>> subsystems to shutdown properly. If such subsystems exist we?ll need to >>> think of the way how to filter out their requests (e.g. providing SPI for >>> them). >>> >>> Thanks, >>> Gytis >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160706/83fa7098/attachment.html From mmusgrov at redhat.com Wed Jul 6 05:15:28 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Wed, 6 Jul 2016 10:15:28 +0100 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: On Wed, Jul 6, 2016 at 12:00 AM, Stuart Douglas wrote: > Local transaction creation has to be allowed during graceful shutdown. > e.g. if a web request is in the process of running and it attempts to start > a transaction this must be allowed (the core requirement of graceful > shutdown is that requests that have already been accepted continue to run > as normal). > > The only case when transactions should be disallowed are remote > transactions, such as remote EJB and CORBA, which I think should already be > dealt with at the respective endpoints (in terms of disallowing new > transaction creation). I think the main thing that needs consideration here > is what to do with EJB requests that would otherwise be rejected that are > part of an existing remote transaction. We probably need some way of > identifying these requests and allowing them to proceed. > Such requests will result in us creating a subordinate transaction on the shutting down server. If we allow these requests then we may never be able to shut down the transaction system but on the other hand if there isn't much traffic then we should allow the remote transaction to continue. Therefore I think we should make the behaviour configurable. Mike > > Stuart > > > > On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris > wrote: > >> Hello, >> >> I?m in the process of writing an analysis document for >> https://issues.jboss.org/browse/EAP7-459 and need your input. >> Specifically I?m looking for the list of subsystems which might need to >> create new transactions during the graceful shutdown. Normally new >> transactions would not be allowed then, but this might stop other >> subsystems to shutdown properly. If such subsystems exist we?ll need to >> think of the way how to filter out their requests (e.g. providing SPI for >> them). >> >> Thanks, >> Gytis >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160706/9d6b93c8/attachment.html From gtrikler at redhat.com Thu Jul 7 06:02:35 2016 From: gtrikler at redhat.com (Gytis Trikleris) Date: Thu, 7 Jul 2016 12:02:35 +0200 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: Sounds that we shouldn?t do extra shutdown logic for JTA and JTS other than possibly provide SPI for EJB and CORBA? Gytis > On 6 Jul 2016, at 01:00, Stuart Douglas wrote: > > Local transaction creation has to be allowed during graceful shutdown. e.g. if a web request is in the process of running and it attempts to start a transaction this must be allowed (the core requirement of graceful shutdown is that requests that have already been accepted continue to run as normal). > > The only case when transactions should be disallowed are remote transactions, such as remote EJB and CORBA, which I think should already be dealt with at the respective endpoints (in terms of disallowing new transaction creation). I think the main thing that needs consideration here is what to do with EJB requests that would otherwise be rejected that are part of an existing remote transaction. We probably need some way of identifying these requests and allowing them to proceed. > > Stuart > > > > On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris > wrote: > Hello, > > I?m in the process of writing an analysis document for https://issues.jboss.org/browse/EAP7-459 and need your input. Specifically I?m looking for the list of subsystems which might need to create new transactions during the graceful shutdown. Normally new transactions would not be allowed then, but this might stop other subsystems to shutdown properly. If such subsystems exist we?ll need to think of the way how to filter out their requests (e.g. providing SPI for them). > > Thanks, > Gytis > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160707/1eb016d5/attachment.html From smarlow at redhat.com Thu Jul 7 12:23:45 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 7 Jul 2016 12:23:45 -0400 Subject: [wildfly-dev] Seeing NPE in org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved() during NoSQL testing, how to fix? Message-ID: Often when running a NoSQL unit test, I'm seeing a NPE in org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(). I understand that we should never allow a NullPointerException to be thrown, however, does anyone know what the correct course of action should be? Ensuring that ejbComponent.getCache() never returns null could be one approach. Or perhaps callers to ejbComponent.getCache() should check for null being returned. Could there be a missing application dependency on the cache? StatefulSessionObjectReferenceImpl currently contains: @Override public boolean isRemoved() { if (!removed) { return !ejbComponent.getCache().contains(id); } return true; } Thanks, Scott [1] https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9 From jperkins at redhat.com Thu Jul 7 13:13:01 2016 From: jperkins at redhat.com (James Perkins) Date: Thu, 7 Jul 2016 10:13:01 -0700 Subject: [wildfly-dev] Seeing NPE in org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved() during NoSQL testing, how to fix? In-Reply-To: References: Message-ID: I think you need to look at why the cache is null. In the org.jboss.as.ejb3.component.stateful.StatefulSessionComponent it's only null if the start of the component hasn't been invoked or the done method was invoked. On Thu, Jul 7, 2016 at 9:23 AM, Scott Marlow wrote: > Often when running a NoSQL unit test, I'm seeing a NPE in > org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(). I > understand that we should never allow a NullPointerException to be > thrown, however, does anyone know what the correct course of action > should be? Ensuring that ejbComponent.getCache() never returns null > could be one approach. Or perhaps callers to ejbComponent.getCache() > should check for null being returned. Could there be a missing > application dependency on the cache? > > StatefulSessionObjectReferenceImpl currently contains: > > @Override > public boolean isRemoved() { > if (!removed) { > return !ejbComponent.getCache().contains(id); > } > return true; > } > > Thanks, > Scott > > [1] https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160707/9edc9b65/attachment.html From smarlow at redhat.com Thu Jul 7 13:27:13 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 7 Jul 2016 13:27:13 -0400 Subject: [wildfly-dev] Seeing NPE in org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved() during NoSQL testing, how to fix? In-Reply-To: References: Message-ID: On 07/07/2016 01:13 PM, James Perkins wrote: > I think you need to look at why the cache is null. In > the org.jboss.as.ejb3.component.stateful.StatefulSessionComponent it's > only null if the start of the component hasn't been invoked or the done > method was invoked. From the call stack, we must of called "done" already, as the cache would of been used previously during the test (implying that it was non-null previously). [1] https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9#file-gistfile1-txt-L41 > > On Thu, Jul 7, 2016 at 9:23 AM, Scott Marlow > wrote: > > Often when running a NoSQL unit test, I'm seeing a NPE in > org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(). I > understand that we should never allow a NullPointerException to be > thrown, however, does anyone know what the correct course of action > should be? Ensuring that ejbComponent.getCache() never returns null > could be one approach. Or perhaps callers to ejbComponent.getCache() > should check for null being returned. Could there be a missing > application dependency on the cache? > > StatefulSessionObjectReferenceImpl currently contains: > > @Override > public boolean isRemoved() { > if (!removed) { > return !ejbComponent.getCache().contains(id); > } > return true; > } > > Thanks, > Scott > > [1] https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > James R. Perkins > JBoss by Red Hat From smarlow at redhat.com Thu Jul 7 15:50:37 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 7 Jul 2016 15:50:37 -0400 Subject: [wildfly-dev] Seeing NPE in org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved() during NoSQL testing, how to fix? In-Reply-To: References: Message-ID: https://issues.jboss.org/browse/WFLY-5208 seems to be related and mention that we can't fix the NPE and if we did fix it, there would be other errors, caused by "deployment is being torn down while the app is still processing requests". On 07/07/2016 01:27 PM, Scott Marlow wrote: > > > On 07/07/2016 01:13 PM, James Perkins wrote: >> I think you need to look at why the cache is null. In >> the org.jboss.as.ejb3.component.stateful.StatefulSessionComponent it's >> only null if the start of the component hasn't been invoked or the done >> method was invoked. > > From the call stack, we must of called "done" already, as the cache > would of been used previously during the test (implying that it was > non-null previously). > > > [1] > https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9#file-gistfile1-txt-L41 >> >> On Thu, Jul 7, 2016 at 9:23 AM, Scott Marlow > > wrote: >> >> Often when running a NoSQL unit test, I'm seeing a NPE in >> org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(). I >> understand that we should never allow a NullPointerException to be >> thrown, however, does anyone know what the correct course of action >> should be? Ensuring that ejbComponent.getCache() never returns null >> could be one approach. Or perhaps callers to ejbComponent.getCache() >> should check for null being returned. Could there be a missing >> application dependency on the cache? >> >> StatefulSessionObjectReferenceImpl currently contains: >> >> @Override >> public boolean isRemoved() { >> if (!removed) { >> return !ejbComponent.getCache().contains(id); >> } >> return true; >> } >> >> Thanks, >> Scott >> >> [1] https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9 >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> -- >> James R. Perkins >> JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jperkins at redhat.com Thu Jul 7 16:32:18 2016 From: jperkins at redhat.com (James Perkins) Date: Thu, 7 Jul 2016 13:32:18 -0700 Subject: [wildfly-dev] Seeing NPE in org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved() during NoSQL testing, how to fix? In-Reply-To: References: Message-ID: Yes I think that makes sense. On Thu, Jul 7, 2016 at 12:50 PM, Scott Marlow wrote: > https://issues.jboss.org/browse/WFLY-5208 seems to be related and mention > that we can't fix the NPE and if we did fix it, there would be other > errors, caused by "deployment is being torn down while the app is still > processing requests". > > > On 07/07/2016 01:27 PM, Scott Marlow wrote: > >> >> >> On 07/07/2016 01:13 PM, James Perkins wrote: >> >>> I think you need to look at why the cache is null. In >>> the org.jboss.as.ejb3.component.stateful.StatefulSessionComponent it's >>> only null if the start of the component hasn't been invoked or the done >>> method was invoked. >>> >> >> From the call stack, we must of called "done" already, as the cache >> would of been used previously during the test (implying that it was >> non-null previously). >> >> >> [1] >> >> https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9#file-gistfile1-txt-L41 >> >>> >>> On Thu, Jul 7, 2016 at 9:23 AM, Scott Marlow >> > wrote: >>> >>> Often when running a NoSQL unit test, I'm seeing a NPE in >>> >>> org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(). I >>> understand that we should never allow a NullPointerException to be >>> thrown, however, does anyone know what the correct course of action >>> should be? Ensuring that ejbComponent.getCache() never returns null >>> could be one approach. Or perhaps callers to ejbComponent.getCache() >>> should check for null being returned. Could there be a missing >>> application dependency on the cache? >>> >>> StatefulSessionObjectReferenceImpl currently contains: >>> >>> @Override >>> public boolean isRemoved() { >>> if (!removed) { >>> return !ejbComponent.getCache().contains(id); >>> } >>> return true; >>> } >>> >>> Thanks, >>> Scott >>> >>> [1] >>> https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9 >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >>> >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160707/e627095b/attachment.html From sstark at redhat.com Thu Jul 7 17:17:53 2016 From: sstark at redhat.com (Scott Stark) Date: Thu, 7 Jul 2016 17:17:53 -0400 (EDT) Subject: [wildfly-dev] wildfly-10.0.0.Final and jdk9 In-Reply-To: <1690293951.4245620.1467925751015.JavaMail.zimbra@redhat.com> Message-ID: <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> I'm looking into the current state of issues around our CDI and JEE containers and JDK9, and looking through the links that Dimitris sent me regarding the issues we are tracking, I don't see a recipe for running wildfly-10.0.0.Final, so I just gave it a try and see it is failing early on in several modules due to class instantiation. Is there a way to get wildfly booted under jdk9? What is the best way for me to help out getting these jdk9 issues resolved? [bin 516]$ $JAVA_HOME/bin/java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+125) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+125, mixed mode) [bin 517]$ ./standalone.sh ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final JAVA: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true ========================================================================= 14:07:36,467 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.1.Final 14:07:37,116 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final 14:07:37,211 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) starting 14:07:38,500 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) 14:07:38,518 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.3.4.Final 14:07:38,526 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.3.4.Final 14:07:38,552 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 4.0.18.Final 14:07:38,567 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 38) WFLYCLINF0001: Activating Infinispan subsystem. 14:07:38,569 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 37) WFLYIO001: Worker 'default' has auto-configured to 8 core threads with 64 task threads based on your 4 available processors 14:07:38,587 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 44) WFLYJSF0007: Activated the following JSF Implementations: [main] 14:07:38,589 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) 14:07:38,601 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 54) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. 14:07:38,602 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 46) WFLYNAM0001: Activating Naming Subsystem 14:07:38,617 INFO [org.jboss.as.connector] (MSC service thread 1-8) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.2.Final) 14:07:38,632 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 56) WFLYWS0002: Activating WebServices Extension 14:07:38,633 INFO [org.jboss.as.security] (ServerService Thread Pool -- 53) WFLYSEC0002: Activating Security Subsystem 14:07:38,637 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-6) WFLYJCA0018: Started Driver service with driver-name = h2 14:07:38,641 INFO [org.jboss.as.security] (MSC service thread 1-2) WFLYSEC0001: Current PicketBox version=4.9.4.Final 14:07:38,680 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55) WFLYUT0003: Undertow 1.3.15.Final starting 14:07:38,680 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0003: Undertow 1.3.15.Final starting 14:07:38,746 INFO [org.jboss.as.naming] (MSC service thread 1-6) WFLYNAM0003: Starting Naming Service 14:07:38,749 INFO [org.jboss.as.mail.extension] (MSC service thread 1-5) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] 14:07:38,823 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55) WFLYUT0014: Creating file handler for path '/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] 14:07:38,862 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0012: Started server default-server. 14:07:38,864 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0018: Host default-host starting 14:07:38,877 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 55) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "undertow")]): java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native Method) at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea/Unsafe.java:1204) at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea/ClassDefiner.java:63) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:400) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:394) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea/MethodAccessorGenerator.java:393) at jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea/MethodAccessorGenerator.java:92) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:55) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at __redirected.__XMLInputFactory.(__XMLInputFactory.java:111) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:62) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea/FactoryFinder.java:193) at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea/FactoryFinder.java:152) at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea/FactoryFinder.java:265) at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea/FactoryFinder.java:227) at javax.xml.stream.XMLInputFactory.newInstance(java.xml at 9-ea/XMLInputFactory.java:154) at org.jboss.as.web.common.SharedTldsMetaDataBuilder.parseTLD(SharedTldsMetaDataBuilder.java:98) at org.jboss.as.web.common.SharedTldsMetaDataBuilder.init(SharedTldsMetaDataBuilder.java:72) at org.jboss.as.web.common.SharedTldsMetaDataBuilder.(SharedTldsMetaDataBuilder.java:63) at org.wildfly.extension.undertow.UndertowSubsystemAdd$1.execute(UndertowSubsystemAdd.java:110) at org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:50) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.ClassNotFoundException: jdk.internal.reflect.ConstructorAccessorImpl from [Module "org.codehaus.woodstox:main" from local module loader @3427b02d (finder: local module finder @647e447 (roots: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 35 more 14:07:38,880 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 44) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "jsf")]): java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native Method) at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea/Unsafe.java:1204) at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea/ClassDefiner.java:63) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:400) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:394) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea/MethodAccessorGenerator.java:393) at jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea/MethodAccessorGenerator.java:92) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:55) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at __redirected.__XMLInputFactory.(__XMLInputFactory.java:111) at jdk.internal.reflect.GeneratedConstructorAccessor2.newInstance(Unknown Source) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea/FactoryFinder.java:193) at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea/FactoryFinder.java:152) at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea/FactoryFinder.java:265) at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea/FactoryFinder.java:227) at javax.xml.stream.XMLInputFactory.newInstance(java.xml at 9-ea/XMLInputFactory.java:154) at org.jboss.as.jsf.deployment.JSFSharedTldsProcessor.parseTLD(JSFSharedTldsProcessor.java:89) at org.jboss.as.jsf.deployment.JSFSharedTldsProcessor.init(JSFSharedTldsProcessor.java:73) at org.jboss.as.jsf.deployment.JSFSharedTldsProcessor.(JSFSharedTldsProcessor.java:59) at org.jboss.as.jsf.subsystem.JSFSubsystemAdd$1.execute(JSFSubsystemAdd.java:60) at org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:50) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.ClassNotFoundException: jdk.internal.reflect.ConstructorAccessorImpl from [Module "org.codehaus.woodstox:main" from local module loader @3427b02d (finder: local module finder @647e447 (roots: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 34 more 14:07:38,890 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping 14:07:38,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:90) at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:66) at org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:79) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) ... 3 more Caused by: java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native Method) at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea/Unsafe.java:1204) at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea/ClassDefiner.java:63) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:400) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:394) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea/MethodAccessorGenerator.java:393) at jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea/MethodAccessorGenerator.java:92) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:55) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at java.lang.reflect.Proxy.newProxyInstance(java.base at 9-ea/Proxy.java:989) at java.lang.reflect.Proxy.newProxyInstance(java.base at 9-ea/Proxy.java:975) at sun.reflect.annotation.AnnotationParser$1.run(java.base at 9-ea/AnnotationParser.java:305) at sun.reflect.annotation.AnnotationParser$1.run(java.base at 9-ea/AnnotationParser.java:303) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at sun.reflect.annotation.AnnotationParser.annotationForMap(java.base at 9-ea/AnnotationParser.java:303) at sun.reflect.annotation.AnnotationParser.parseAnnotation2(java.base at 9-ea/AnnotationParser.java:293) at sun.reflect.annotation.AnnotationParser.parseAnnotations2(java.base at 9-ea/AnnotationParser.java:120) at sun.reflect.annotation.AnnotationParser.parseAnnotations(java.base at 9-ea/AnnotationParser.java:72) at java.lang.reflect.Field.declaredAnnotations(java.base at 9-ea/Field.java:1132) at java.lang.reflect.Field.declaredAnnotations(java.base at 9-ea/Field.java:1130) at java.lang.reflect.Field.getAnnotation(java.base at 9-ea/Field.java:1099) at java.lang.reflect.AnnotatedElement.isAnnotationPresent(java.base at 9-ea/AnnotatedElement.java:258) at java.lang.reflect.AccessibleObject.isAnnotationPresent(java.base at 9-ea/AccessibleObject.java:250) at com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:169) at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87) ... 7 more Caused by: java.lang.ClassNotFoundException: jdk.internal.reflect.ConstructorAccessorImpl from [Module "org.jboss.jts:main" from local module loader @3427b02d (finder: local module finder @647e447 (roots: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 34 more 14:07:38,932 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 56) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "webservices")]): java.lang.NoClassDefFoundError: jdk/internal/reflect/MethodAccessorImpl at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native Method) at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea/Unsafe.java:1204) at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea/ClassDefiner.java:63) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:400) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:394) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea/MethodAccessorGenerator.java:393) at jdk.internal.reflect.MethodAccessorGenerator.generateMethod(java.base at 9-ea/MethodAccessorGenerator.java:75) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:53) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.as.webservices.parser.WSDeploymentAspectParser.parseProperty(WSDeploymentAspectParser.java:186) at org.jboss.as.webservices.parser.WSDeploymentAspectParser.parseDeploymentAspect(WSDeploymentAspectParser.java:162) at org.jboss.as.webservices.parser.WSDeploymentAspectParser.parseDeploymentAspects(WSDeploymentAspectParser.java:118) at org.jboss.as.webservices.parser.WSDeploymentAspectParser.parse(WSDeploymentAspectParser.java:96) at org.jboss.as.webservices.parser.WSDeploymentAspectParser.parse(WSDeploymentAspectParser.java:73) at org.jboss.as.webservices.deployers.deployment.DeploymentAspectsProvider.getDeploymentAspects(DeploymentAspectsProvider.java:68) at org.jboss.as.webservices.deployers.deployment.DeploymentAspectsProvider.getSortedDeploymentAspects(DeploymentAspectsProvider.java:53) at org.jboss.as.webservices.dmr.WSDeploymentActivator.addDeploymentProcessors(WSDeploymentActivator.java:84) at org.jboss.as.webservices.dmr.WSDeploymentActivator.activate(WSDeploymentActivator.java:78) at org.jboss.as.webservices.dmr.WSSubsystemAdd$1.execute(WSSubsystemAdd.java:82) at org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:50) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.ClassNotFoundException: jdk.internal.reflect.MethodAccessorImpl from [Module "org.jboss.ws.common:main" from local module loader @3427b02d (finder: local module finder @647e447 (roots: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 30 more 14:07:38,948 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080 14:07:38,951 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0008: Undertow HTTP listener default suspending 14:07:38,956 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080 14:07:38,957 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0004: Undertow 1.3.15.Final stopping 14:07:38,957 INFO [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 64 (per class), which is derived from thread worker pool sizing. 14:07:38,958 INFO [org.jboss.as.ejb3] (MSC service thread 1-3) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 16 (per class), which is derived from the number of CPUs on this host. 14:07:38,979 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 36) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "ejb3"), ("service" => "timer-service"), ("file-data-store" => "default-file-store") ]): java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native Method) at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea/Unsafe.java:1204) at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea/ClassDefiner.java:63) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:400) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:394) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea/MethodAccessorGenerator.java:393) at jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea/MethodAccessorGenerator.java:92) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:55) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at __redirected.__XMLInputFactory.(__XMLInputFactory.java:111) at jdk.internal.reflect.GeneratedConstructorAccessor2.newInstance(Unknown Source) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea/FactoryFinder.java:193) at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea/FactoryFinder.java:152) at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea/FactoryFinder.java:265) at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea/FactoryFinder.java:227) at javax.xml.stream.XMLInputFactory.newInstance(java.xml at 9-ea/XMLInputFactory.java:154) at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.(FileTimerPersistence.java:85) at org.jboss.as.ejb3.subsystem.FileDataStoreAdd.performRuntime(FileDataStoreAdd.java:76) at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:363) at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.ClassNotFoundException: jdk.internal.reflect.ConstructorAccessorImpl from [Module "org.codehaus.woodstox:main" from local module loader @3427b02d (finder: local module finder @647e447 (roots: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 34 more 14:07:38,987 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "infinispan"), ("cache-container" => "server"), ("local-cache" => "default") ]): java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native Method) at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea/Unsafe.java:1204) at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea/ClassDefiner.java:63) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:400) at jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea/MethodAccessorGenerator.java:394) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea/MethodAccessorGenerator.java:393) at jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea/MethodAccessorGenerator.java:92) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:55) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at org.jboss.logging.Logger$1.run(Logger.java:2565) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529) at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516) at org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:17) at org.infinispan.transaction.lookup.GenericTransactionManagerLookup.(GenericTransactionManagerLookup.java:27) at org.infinispan.configuration.cache.TransactionConfiguration.(TransactionConfiguration.java:30) at org.infinispan.configuration.cache.TransactionConfigurationBuilder.(TransactionConfigurationBuilder.java:37) at org.infinispan.configuration.cache.ConfigurationBuilder.(ConfigurationBuilder.java:60) at org.jboss.as.clustering.infinispan.subsystem.CacheConfigurationBuilder.configure(CacheConfigurationBuilder.java:102) at org.jboss.as.clustering.infinispan.subsystem.CacheServiceHandler.installServices(CacheServiceHandler.java:70) at org.jboss.as.clustering.controller.AddStepHandler.performRuntime(AddStepHandler.java:148) at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.ClassNotFoundException: jdk.internal.reflect.ConstructorAccessorImpl from [Module "org.infinispan:main" from local module loader @3427b02d (finder: local module finder @647e447 (roots: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 33 more 14:07:38,990 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations" 14:07:38,991 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem infinispan boot operations" 14:07:38,991 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem jsf boot operations" 14:07:38,991 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem undertow boot operations" 14:07:38,992 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem webservices boot operations" 14:07:38,992 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\"" 14:07:39,037 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/standalone/deployments 14:07:39,108 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "undertow")]) - failure description: "WFLYCTL0158: Operation handler failed: java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl" 14:07:39,108 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: "WFLYCTL0158: Operation handler failed: java.lang.NoClassDefFoundError: jdk/internal/reflect/MethodAccessorImpl" 14:07:39,110 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl Caused by: java.lang.NoClassDefFoundError: jdk/internal/reflect/ConstructorAccessorImpl Caused by: java.lang.ClassNotFoundException: jdk.internal.reflect.ConstructorAccessorImpl from [Module \"org.jboss.jts:main\" from local module loader @3427b02d (finder: local module finder @647e447 (roots: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))]"}} 14:07:39,131 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report WFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service 14:07:39,206 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management 14:07:39,206 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 14:07:39,206 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) started (with errors) in 3398ms - Started 121 of 153 services (23 services failed or missing dependencies, 29 services are lazy, passive or on-demand) ^C14:07:43,367 INFO [org.jboss.as.server] (Thread-1) WFLYSRV0220: Server shutdown has been requested. 14:07:43,380 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = h2 14:07:43,392 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) stopped in 19ms [bin 518]$ From stuart.w.douglas at gmail.com Thu Jul 7 18:55:09 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 8 Jul 2016 08:55:09 +1000 Subject: [wildfly-dev] wildfly-10.0.0.Final and jdk9 In-Reply-To: <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> References: <1690293951.4245620.1467925751015.JavaMail.zimbra@redhat.com> <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> Message-ID: Wildfly upstream should be mostly working on JDK9: https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea There is no released version that will work at the moment (and even if we did release a version that worked there is no guarantee it would continue to work past the next JDK9 ea release). Stuart On Fri, Jul 8, 2016 at 7:17 AM, Scott Stark wrote: > I'm looking into the current state of issues around our CDI and JEE > containers and JDK9, and looking through the links that Dimitris sent me > regarding the issues we are tracking, I don't see a recipe for running > wildfly-10.0.0.Final, so I just gave it a try and see it is failing early > on in several modules due to class instantiation. > > Is there a way to get wildfly booted under jdk9? > > What is the best way for me to help out getting these jdk9 issues resolved? > > > [bin 516]$ $JAVA_HOME/bin/java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+125) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+125, mixed mode) > [bin 517]$ ./standalone.sh > ========================================================================= > > JBoss Bootstrap Environment > > JBOSS_HOME: /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final > > JAVA: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java > > JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M > -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true > -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > > ========================================================================= > > 14:07:36,467 INFO [org.jboss.modules] (main) JBoss Modules version > 1.5.1.Final > 14:07:37,116 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 14:07:37,211 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: > WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) starting > 14:07:38,500 INFO [org.jboss.as.server] (Controller Boot Thread) > WFLYSRV0039: Creating http management service using socket-binding > (management-http) > 14:07:38,518 INFO [org.xnio] (MSC service thread 1-2) XNIO version > 3.3.4.Final > 14:07:38,526 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO > Implementation Version 3.3.4.Final > 14:07:38,552 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss > Remoting version 4.0.18.Final > 14:07:38,567 INFO [org.jboss.as.clustering.infinispan] (ServerService > Thread Pool -- 38) WFLYCLINF0001: Activating Infinispan subsystem. > 14:07:38,569 INFO [org.wildfly.extension.io] (ServerService Thread Pool > -- 37) WFLYIO001: Worker 'default' has auto-configured to 8 core threads > with 64 task threads based on your 4 available processors > 14:07:38,587 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 44) > WFLYJSF0007: Activated the following JSF Implementations: [main] > 14:07:38,589 INFO [org.jboss.as.connector.subsystems.datasources] > (ServerService Thread Pool -- 33) WFLYJCA0004: Deploying JDBC-compliant > driver class org.h2.Driver (version 1.3) > 14:07:38,601 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 54) > WFLYTX0013: Node identifier property is set to the default value. Please > make sure it is unique. > 14:07:38,602 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 46) > WFLYNAM0001: Activating Naming Subsystem > 14:07:38,617 INFO [org.jboss.as.connector] (MSC service thread 1-8) > WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.2.Final) > 14:07:38,632 INFO [org.jboss.as.webservices] (ServerService Thread Pool > -- 56) WFLYWS0002: Activating WebServices Extension > 14:07:38,633 INFO [org.jboss.as.security] (ServerService Thread Pool -- > 53) WFLYSEC0002: Activating Security Subsystem > 14:07:38,637 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service > thread 1-6) WFLYJCA0018: Started Driver service with driver-name = h2 > 14:07:38,641 INFO [org.jboss.as.security] (MSC service thread 1-2) > WFLYSEC0001: Current PicketBox version=4.9.4.Final > 14:07:38,680 INFO [org.wildfly.extension.undertow] (ServerService Thread > Pool -- 55) WFLYUT0003: Undertow 1.3.15.Final starting > 14:07:38,680 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-3) WFLYUT0003: Undertow 1.3.15.Final starting > 14:07:38,746 INFO [org.jboss.as.naming] (MSC service thread 1-6) > WFLYNAM0003: Starting Naming Service > 14:07:38,749 INFO [org.jboss.as.mail.extension] (MSC service thread 1-5) > WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 14:07:38,823 INFO [org.wildfly.extension.undertow] (ServerService Thread > Pool -- 55) WFLYUT0014: Creating file handler for path > '/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/welcome-content' > with options [directory-listing: 'false', follow-symlink: 'false', > case-sensitive: 'true', safe-symlink-paths: '[]'] > 14:07:38,862 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-7) WFLYUT0012: Started server default-server. > 14:07:38,864 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-7) WFLYUT0018: Host default-host starting > 14:07:38,877 ERROR [org.jboss.as.controller.management-operation] > (ServerService Thread Pool -- 55) WFLYCTL0013: Operation ("add") failed - > address: ([("subsystem" => "undertow")]): java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl > at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native > Method) > at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea > /Unsafe.java:1204) > at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea > /ClassDefiner.java:63) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:400) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:394) > at java.security.AccessController.doPrivileged(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea > /MethodAccessorGenerator.java:393) > at > jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea > /MethodAccessorGenerator.java:92) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea > /NativeConstructorAccessorImpl.java:55) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at > __redirected.__XMLInputFactory.(__XMLInputFactory.java:111) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea > /NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) > at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea > /FactoryFinder.java:193) > at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea > /FactoryFinder.java:152) > at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea > /FactoryFinder.java:265) > at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea > /FactoryFinder.java:227) > at javax.xml.stream.XMLInputFactory.newInstance(java.xml at 9-ea > /XMLInputFactory.java:154) > at > org.jboss.as.web.common.SharedTldsMetaDataBuilder.parseTLD(SharedTldsMetaDataBuilder.java:98) > at > org.jboss.as.web.common.SharedTldsMetaDataBuilder.init(SharedTldsMetaDataBuilder.java:72) > at > org.jboss.as.web.common.SharedTldsMetaDataBuilder.(SharedTldsMetaDataBuilder.java:63) > at > org.wildfly.extension.undertow.UndertowSubsystemAdd$1.execute(UndertowSubsystemAdd.java:110) > at > org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:50) > at > org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at > org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at > org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at > org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea > /ThreadPoolExecutor.java:1158) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea > /ThreadPoolExecutor.java:632) > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.ClassNotFoundException: > jdk.internal.reflect.ConstructorAccessorImpl from [Module > "org.codehaus.woodstox:main" from local module loader @3427b02d (finder: > local module finder @647e447 (roots: > /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) > ... 35 more > > 14:07:38,880 ERROR [org.jboss.as.controller.management-operation] > (ServerService Thread Pool -- 44) WFLYCTL0013: Operation ("add") failed - > address: ([("subsystem" => "jsf")]): java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl > at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native > Method) > at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea > /Unsafe.java:1204) > at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea > /ClassDefiner.java:63) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:400) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:394) > at java.security.AccessController.doPrivileged(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea > /MethodAccessorGenerator.java:393) > at > jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea > /MethodAccessorGenerator.java:92) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea > /NativeConstructorAccessorImpl.java:55) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at > __redirected.__XMLInputFactory.(__XMLInputFactory.java:111) > at > jdk.internal.reflect.GeneratedConstructorAccessor2.newInstance(Unknown > Source) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) > at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea > /FactoryFinder.java:193) > at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea > /FactoryFinder.java:152) > at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea > /FactoryFinder.java:265) > at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea > /FactoryFinder.java:227) > at javax.xml.stream.XMLInputFactory.newInstance(java.xml at 9-ea > /XMLInputFactory.java:154) > at > org.jboss.as.jsf.deployment.JSFSharedTldsProcessor.parseTLD(JSFSharedTldsProcessor.java:89) > at > org.jboss.as.jsf.deployment.JSFSharedTldsProcessor.init(JSFSharedTldsProcessor.java:73) > at > org.jboss.as.jsf.deployment.JSFSharedTldsProcessor.(JSFSharedTldsProcessor.java:59) > at > org.jboss.as.jsf.subsystem.JSFSubsystemAdd$1.execute(JSFSubsystemAdd.java:60) > at > org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:50) > at > org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at > org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at > org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at > org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea > /ThreadPoolExecutor.java:1158) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea > /ThreadPoolExecutor.java:632) > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.ClassNotFoundException: > jdk.internal.reflect.ConstructorAccessorImpl from [Module > "org.codehaus.woodstox:main" from local module loader @3427b02d (finder: > local module finder @647e447 (roots: > /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) > ... 34 more > > 14:07:38,890 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-1) WFLYUT0019: Host default-host stopping > 14:07:38,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) > MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: > org.jboss.msc.service.StartException in service > jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea > /ThreadPoolExecutor.java:1158) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea > /ThreadPoolExecutor.java:632) > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl > at > com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:90) > at > com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:66) > at > org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:79) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > Caused by: java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl > at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native > Method) > at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea > /Unsafe.java:1204) > at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea > /ClassDefiner.java:63) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:400) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:394) > at java.security.AccessController.doPrivileged(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea > /MethodAccessorGenerator.java:393) > at > jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea > /MethodAccessorGenerator.java:92) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea > /NativeConstructorAccessorImpl.java:55) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at java.lang.reflect.Proxy.newProxyInstance(java.base at 9-ea > /Proxy.java:989) > at java.lang.reflect.Proxy.newProxyInstance(java.base at 9-ea > /Proxy.java:975) > at sun.reflect.annotation.AnnotationParser$1.run(java.base at 9-ea > /AnnotationParser.java:305) > at sun.reflect.annotation.AnnotationParser$1.run(java.base at 9-ea > /AnnotationParser.java:303) > at java.security.AccessController.doPrivileged(java.base at 9-ea/Native > Method) > at > sun.reflect.annotation.AnnotationParser.annotationForMap(java.base at 9-ea > /AnnotationParser.java:303) > at > sun.reflect.annotation.AnnotationParser.parseAnnotation2(java.base at 9-ea > /AnnotationParser.java:293) > at > sun.reflect.annotation.AnnotationParser.parseAnnotations2(java.base at 9-ea > /AnnotationParser.java:120) > at > sun.reflect.annotation.AnnotationParser.parseAnnotations(java.base at 9-ea > /AnnotationParser.java:72) > at java.lang.reflect.Field.declaredAnnotations(java.base at 9-ea > /Field.java:1132) > at java.lang.reflect.Field.declaredAnnotations(java.base at 9-ea > /Field.java:1130) > at java.lang.reflect.Field.getAnnotation(java.base at 9-ea > /Field.java:1099) > at > java.lang.reflect.AnnotatedElement.isAnnotationPresent(java.base at 9-ea > /AnnotatedElement.java:258) > at > java.lang.reflect.AccessibleObject.isAnnotationPresent(java.base at 9-ea > /AccessibleObject.java:250) > at > com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:169) > at > com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87) > ... 7 more > Caused by: java.lang.ClassNotFoundException: > jdk.internal.reflect.ConstructorAccessorImpl from [Module > "org.jboss.jts:main" from local module loader @3427b02d (finder: local > module finder @647e447 (roots: > /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) > ... 34 more > > 14:07:38,932 ERROR [org.jboss.as.controller.management-operation] > (ServerService Thread Pool -- 56) WFLYCTL0013: Operation ("add") failed - > address: ([("subsystem" => "webservices")]): > java.lang.NoClassDefFoundError: jdk/internal/reflect/MethodAccessorImpl > at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native > Method) > at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea > /Unsafe.java:1204) > at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea > /ClassDefiner.java:63) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:400) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:394) > at java.security.AccessController.doPrivileged(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea > /MethodAccessorGenerator.java:393) > at > jdk.internal.reflect.MethodAccessorGenerator.generateMethod(java.base at 9-ea > /MethodAccessorGenerator.java:75) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea > /NativeMethodAccessorImpl.java:53) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea > /DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) > at > org.jboss.as.webservices.parser.WSDeploymentAspectParser.parseProperty(WSDeploymentAspectParser.java:186) > at > org.jboss.as.webservices.parser.WSDeploymentAspectParser.parseDeploymentAspect(WSDeploymentAspectParser.java:162) > at > org.jboss.as.webservices.parser.WSDeploymentAspectParser.parseDeploymentAspects(WSDeploymentAspectParser.java:118) > at > org.jboss.as.webservices.parser.WSDeploymentAspectParser.parse(WSDeploymentAspectParser.java:96) > at > org.jboss.as.webservices.parser.WSDeploymentAspectParser.parse(WSDeploymentAspectParser.java:73) > at > org.jboss.as.webservices.deployers.deployment.DeploymentAspectsProvider.getDeploymentAspects(DeploymentAspectsProvider.java:68) > at > org.jboss.as.webservices.deployers.deployment.DeploymentAspectsProvider.getSortedDeploymentAspects(DeploymentAspectsProvider.java:53) > at > org.jboss.as.webservices.dmr.WSDeploymentActivator.addDeploymentProcessors(WSDeploymentActivator.java:84) > at > org.jboss.as.webservices.dmr.WSDeploymentActivator.activate(WSDeploymentActivator.java:78) > at > org.jboss.as.webservices.dmr.WSSubsystemAdd$1.execute(WSSubsystemAdd.java:82) > at > org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:50) > at > org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at > org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at > org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at > org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea > /ThreadPoolExecutor.java:1158) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea > /ThreadPoolExecutor.java:632) > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.ClassNotFoundException: > jdk.internal.reflect.MethodAccessorImpl from [Module > "org.jboss.ws.common:main" from local module loader @3427b02d (finder: > local module finder @647e447 (roots: > /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) > ... 30 more > > 14:07:38,948 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-5) WFLYUT0006: Undertow HTTP listener default listening on > 127.0.0.1:8080 > 14:07:38,951 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-5) WFLYUT0008: Undertow HTTP listener default suspending > 14:07:38,956 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-5) WFLYUT0007: Undertow HTTP listener default stopped, was bound to > 127.0.0.1:8080 > 14:07:38,957 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-8) WFLYUT0004: Undertow 1.3.15.Final stopping > 14:07:38,957 INFO [org.jboss.as.ejb3] (MSC service thread 1-6) > WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size > of 64 (per class), which is derived from thread worker pool sizing. > 14:07:38,958 INFO [org.jboss.as.ejb3] (MSC service thread 1-3) > WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size > of 16 (per class), which is derived from the number of CPUs on this host. > 14:07:38,979 ERROR [org.jboss.as.controller.management-operation] > (ServerService Thread Pool -- 36) WFLYCTL0013: Operation ("add") failed - > address: ([ > ("subsystem" => "ejb3"), > ("service" => "timer-service"), > ("file-data-store" => "default-file-store") > ]): java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl > at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native > Method) > at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea > /Unsafe.java:1204) > at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea > /ClassDefiner.java:63) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:400) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:394) > at java.security.AccessController.doPrivileged(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea > /MethodAccessorGenerator.java:393) > at > jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea > /MethodAccessorGenerator.java:92) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea > /NativeConstructorAccessorImpl.java:55) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at > __redirected.__XMLInputFactory.(__XMLInputFactory.java:111) > at > jdk.internal.reflect.GeneratedConstructorAccessor2.newInstance(Unknown > Source) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) > at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea > /FactoryFinder.java:193) > at javax.xml.stream.FactoryFinder.newInstance(java.xml at 9-ea > /FactoryFinder.java:152) > at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea > /FactoryFinder.java:265) > at javax.xml.stream.FactoryFinder.find(java.xml at 9-ea > /FactoryFinder.java:227) > at javax.xml.stream.XMLInputFactory.newInstance(java.xml at 9-ea > /XMLInputFactory.java:154) > at > org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.(FileTimerPersistence.java:85) > at > org.jboss.as.ejb3.subsystem.FileDataStoreAdd.performRuntime(FileDataStoreAdd.java:76) > at > org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:363) > at > org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) > at > org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at > org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at > org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at > org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at > org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea > /ThreadPoolExecutor.java:1158) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea > /ThreadPoolExecutor.java:632) > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.ClassNotFoundException: > jdk.internal.reflect.ConstructorAccessorImpl from [Module > "org.codehaus.woodstox:main" from local module loader @3427b02d (finder: > local module finder @647e447 (roots: > /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) > ... 34 more > > 14:07:38,987 ERROR [org.jboss.as.controller.management-operation] > (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("add") failed - > address: ([ > ("subsystem" => "infinispan"), > ("cache-container" => "server"), > ("local-cache" => "default") > ]): java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl > at jdk.internal.misc.Unsafe.defineClass0(java.base at 9-ea/Native > Method) > at jdk.internal.misc.Unsafe.defineClass(java.base at 9-ea > /Unsafe.java:1204) > at jdk.internal.reflect.ClassDefiner.defineClass(java.base at 9-ea > /ClassDefiner.java:63) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:400) > at > jdk.internal.reflect.MethodAccessorGenerator$1.run(java.base at 9-ea > /MethodAccessorGenerator.java:394) > at java.security.AccessController.doPrivileged(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.MethodAccessorGenerator.generate(java.base at 9-ea > /MethodAccessorGenerator.java:393) > at > jdk.internal.reflect.MethodAccessorGenerator.generateConstructor(java.base at 9-ea > /MethodAccessorGenerator.java:92) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea > /NativeConstructorAccessorImpl.java:55) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at org.jboss.logging.Logger$1.run(Logger.java:2565) > at java.security.AccessController.doPrivileged(java.base at 9-ea/Native > Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516) > at > org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:17) > at > org.infinispan.transaction.lookup.GenericTransactionManagerLookup.(GenericTransactionManagerLookup.java:27) > at > org.infinispan.configuration.cache.TransactionConfiguration.(TransactionConfiguration.java:30) > at > org.infinispan.configuration.cache.TransactionConfigurationBuilder.(TransactionConfigurationBuilder.java:37) > at > org.infinispan.configuration.cache.ConfigurationBuilder.(ConfigurationBuilder.java:60) > at > org.jboss.as.clustering.infinispan.subsystem.CacheConfigurationBuilder.configure(CacheConfigurationBuilder.java:102) > at > org.jboss.as.clustering.infinispan.subsystem.CacheServiceHandler.installServices(CacheServiceHandler.java:70) > at > org.jboss.as.clustering.controller.AddStepHandler.performRuntime(AddStepHandler.java:148) > at > org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) > at > org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at > org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at > org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at > org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at > org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea > /ThreadPoolExecutor.java:1158) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea > /ThreadPoolExecutor.java:632) > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.ClassNotFoundException: > jdk.internal.reflect.ConstructorAccessorImpl from [Module > "org.infinispan:main" from local module loader @3427b02d (finder: local > module finder @647e447 (roots: > /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) > ... 33 more > > 14:07:38,990 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot > operations" > 14:07:38,991 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem > infinispan boot operations" > 14:07:38,991 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem jsf boot > operations" > 14:07:38,991 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem undertow > boot operations" > 14:07:38,992 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem > webservices boot operations" > 14:07:38,992 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") > failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed > executing subsystem ejb3 boot operations\"" > 14:07:39,037 INFO [org.jboss.as.server.deployment.scanner] (MSC service > thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory > /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/standalone/deployments > 14:07:39,108 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: > ([("subsystem" => "undertow")]) - failure description: "WFLYCTL0158: > Operation handler failed: java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl" > 14:07:39,108 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: > ([("subsystem" => "webservices")]) - failure description: "WFLYCTL0158: > Operation handler failed: java.lang.NoClassDefFoundError: > jdk/internal/reflect/MethodAccessorImpl" > 14:07:39,110 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: > ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: > Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => > "org.jboss.msc.service.StartException in service > jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl > Caused by: java.lang.NoClassDefFoundError: > jdk/internal/reflect/ConstructorAccessorImpl > Caused by: java.lang.ClassNotFoundException: > jdk.internal.reflect.ConstructorAccessorImpl from [Module > \"org.jboss.jts:main\" from local module loader @3427b02d (finder: local > module finder @647e447 (roots: > /Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base/.overlays/layer-base-wildfly-10-weld-3.0,/Users/starksm/Dev/JBoss/Wildfly/wildfly-10.0.0.Final/modules/system/layers/base))]"}} > 14:07:39,131 INFO [org.jboss.as.controller] (Controller Boot Thread) > WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service > jboss.txn.ArjunaObjectStoreEnvironment: > org.jboss.msc.service.StartException in service > jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > > 14:07:39,206 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: > Http management interface listening on http://127.0.0.1:9990/management > 14:07:39,206 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: > Admin console listening on http://127.0.0.1:9990 > 14:07:39,206 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: > WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) started (with errors) > in 3398ms - Started 121 of 153 services (23 services failed or missing > dependencies, 29 services are lazy, passive or on-demand) > ^C14:07:43,367 INFO [org.jboss.as.server] (Thread-1) WFLYSRV0220: Server > shutdown has been requested. > 14:07:43,380 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service > thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 14:07:43,392 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: > WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) stopped in 19ms > [bin 518]$ > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160708/6814c839/attachment-0001.html From sstark at redhat.com Thu Jul 7 19:38:50 2016 From: sstark at redhat.com (Scott Stark) Date: Thu, 7 Jul 2016 19:38:50 -0400 (EDT) Subject: [wildfly-dev] wildfly-10.0.0.Final and jdk9 In-Reply-To: References: <1690293951.4245620.1467925751015.JavaMail.zimbra@redhat.com> <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> Message-ID: <47922156.4303193.1467934730909.JavaMail.zimbra@redhat.com> Ok, got the master branch running under jdk9. So is the issues list given at the end of the Java 9 Problems & Solutions FAQ doc the best place to pitch in? ----- Original Message ----- From: "Stuart Douglas" To: "Scott Stark" Cc: wildfly-dev at lists.jboss.org Sent: Thursday, July 7, 2016 3:55:09 PM Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 Wildfly upstream should be mostly working on JDK9: https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea There is no released version that will work at the moment (and even if we did release a version that worked there is no guarantee it would continue to work past the next JDK9 ea release). Stuart On Fri, Jul 8, 2016 at 7:17 AM, Scott Stark wrote: > I'm looking into the current state of issues around our CDI and JEE > containers and JDK9, and looking through the links that Dimitris sent me > regarding the issues we are tracking, I don't see a recipe for running > wildfly-10.0.0.Final, so I just gave it a try and see it is failing early > on in several modules due to class instantiation. > > Is there a way to get wildfly booted under jdk9? > > What is the best way for me to help out getting these jdk9 issues resolved? From jason.greene at redhat.com Thu Jul 7 21:00:47 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Thu, 7 Jul 2016 21:00:47 -0400 (EDT) Subject: [wildfly-dev] wildfly-10.0.0.Final and jdk9 In-Reply-To: <47922156.4303193.1467934730909.JavaMail.zimbra@redhat.com> References: <1690293951.4245620.1467925751015.JavaMail.zimbra@redhat.com> <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> <47922156.4303193.1467934730909.JavaMail.zimbra@redhat.com> Message-ID: <8FD4D391-26D5-44F5-9CB3-27B9073C9A1F@redhat.com> Is that the modular JDK build? IIRC there was still some issues there. Our big challenge will be using jigsaw modules as part of a deployment of as a library in the server. > On Jul 7, 2016, at 6:39 PM, Scott Stark wrote: > > Ok, got the master branch running under jdk9. So is the issues list given at the end of the Java 9 Problems & Solutions FAQ doc the best place to pitch in? > > ----- Original Message ----- > From: "Stuart Douglas" > To: "Scott Stark" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, July 7, 2016 3:55:09 PM > Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 > > Wildfly upstream should be mostly working on JDK9: > > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea > > There is no released version that will work at the moment (and even if we > did release a version that worked there is no guarantee it would continue > to work past the next JDK9 ea release). > > Stuart > >> On Fri, Jul 8, 2016 at 7:17 AM, Scott Stark wrote: >> >> I'm looking into the current state of issues around our CDI and JEE >> containers and JDK9, and looking through the links that Dimitris sent me >> regarding the issues we are tracking, I don't see a recipe for running >> wildfly-10.0.0.Final, so I just gave it a try and see it is failing early >> on in several modules due to class instantiation. >> >> Is there a way to get wildfly booted under jdk9? >> >> What is the best way for me to help out getting these jdk9 issues resolved? > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From stuart.w.douglas at gmail.com Thu Jul 7 21:23:56 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 8 Jul 2016 11:23:56 +1000 Subject: [wildfly-dev] wildfly-10.0.0.Final and jdk9 In-Reply-To: <8FD4D391-26D5-44F5-9CB3-27B9073C9A1F@redhat.com> References: <1690293951.4245620.1467925751015.JavaMail.zimbra@redhat.com> <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> <47922156.4303193.1467934730909.JavaMail.zimbra@redhat.com> <8FD4D391-26D5-44F5-9CB3-27B9073C9A1F@redhat.com> Message-ID: There are definitely still some issues (as can be seen from the CI failures), however it will boot. Stuart On Fri, Jul 8, 2016 at 11:00 AM, Jason T. Greene wrote: > Is that the modular JDK build? IIRC there was still some issues there. Our > big challenge will be using jigsaw modules as part of a deployment of as a > library in the server. > > > On Jul 7, 2016, at 6:39 PM, Scott Stark wrote: > > > > Ok, got the master branch running under jdk9. So is the issues list > given at the end of the Java 9 Problems & Solutions FAQ doc the best place > to pitch in? > > > > ----- Original Message ----- > > From: "Stuart Douglas" > > To: "Scott Stark" > > Cc: wildfly-dev at lists.jboss.org > > Sent: Thursday, July 7, 2016 3:55:09 PM > > Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 > > > > Wildfly upstream should be mostly working on JDK9: > > > > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea > > > > There is no released version that will work at the moment (and even if we > > did release a version that worked there is no guarantee it would continue > > to work past the next JDK9 ea release). > > > > Stuart > > > >> On Fri, Jul 8, 2016 at 7:17 AM, Scott Stark wrote: > >> > >> I'm looking into the current state of issues around our CDI and JEE > >> containers and JDK9, and looking through the links that Dimitris sent me > >> regarding the issues we are tracking, I don't see a recipe for running > >> wildfly-10.0.0.Final, so I just gave it a try and see it is failing > early > >> on in several modules due to class instantiation. > >> > >> Is there a way to get wildfly booted under jdk9? > >> > >> What is the best way for me to help out getting these jdk9 issues > resolved? > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160708/70494487/attachment.html From sstark at redhat.com Thu Jul 7 23:02:17 2016 From: sstark at redhat.com (Scott Stark) Date: Thu, 7 Jul 2016 23:02:17 -0400 (EDT) Subject: [wildfly-dev] wildfly-10.0.0.Final and jdk9 In-Reply-To: References: <1690293951.4245620.1467925751015.JavaMail.zimbra@redhat.com> <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> <47922156.4303193.1467934730909.JavaMail.zimbra@redhat.com> <8FD4D391-26D5-44F5-9CB3-27B9073C9A1F@redhat.com> Message-ID: <1430553261.4341798.1467946937017.JavaMail.zimbra@redhat.com> I guess not as I got build 125 from https://jdk9.java.net/download/. I'll try https://jdk9.java.net/jigsaw/ instead. ----- Original Message ----- From: "Stuart Douglas" To: "Jason T. Greene" Cc: "Scott Stark" , wildfly-dev at lists.jboss.org Sent: Thursday, July 7, 2016 6:23:56 PM Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 There are definitely still some issues (as can be seen from the CI failures), however it will boot. Stuart On Fri, Jul 8, 2016 at 11:00 AM, Jason T. Greene wrote: > Is that the modular JDK build? IIRC there was still some issues there. Our > big challenge will be using jigsaw modules as part of a deployment of as a > library in the server. > > > On Jul 7, 2016, at 6:39 PM, Scott Stark wrote: > > > > Ok, got the master branch running under jdk9. So is the issues list > given at the end of the Java 9 Problems & Solutions FAQ doc the best place > to pitch in? > > > > ----- Original Message ----- > > From: "Stuart Douglas" > > To: "Scott Stark" > > Cc: wildfly-dev at lists.jboss.org > > Sent: Thursday, July 7, 2016 3:55:09 PM > > Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 > > > > Wildfly upstream should be mostly working on JDK9: > > > > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea > > > > There is no released version that will work at the moment (and even if we > > did release a version that worked there is no guarantee it would continue > > to work past the next JDK9 ea release). > > > > Stuart > > > >> On Fri, Jul 8, 2016 at 7:17 AM, Scott Stark wrote: > >> > >> I'm looking into the current state of issues around our CDI and JEE > >> containers and JDK9, and looking through the links that Dimitris sent me > >> regarding the issues we are tracking, I don't see a recipe for running > >> wildfly-10.0.0.Final, so I just gave it a try and see it is failing > early > >> on in several modules due to class instantiation. > >> > >> Is there a way to get wildfly booted under jdk9? > >> > >> What is the best way for me to help out getting these jdk9 issues > resolved? > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tomaz.cerar at gmail.com Fri Jul 8 04:47:02 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 8 Jul 2016 10:47:02 +0200 Subject: [wildfly-dev] wildfly-10.0.0.Final and jdk9 In-Reply-To: <1430553261.4341798.1467946937017.JavaMail.zimbra@redhat.com> References: <1690293951.4245620.1467925751015.JavaMail.zimbra@redhat.com> <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> <47922156.4303193.1467934730909.JavaMail.zimbra@redhat.com> <8FD4D391-26D5-44F5-9CB3-27B9073C9A1F@redhat.com> <1430553261.4341798.1467946937017.JavaMail.zimbra@redhat.com> Message-ID: All builds after b111 are jigsaw modulized JDK builds. There is no more non-jigsaw jdk9 build. Our CI currently uses b125 to test. There are some known issues, mostly related to jigsaw issues http://openjdk.java.net/projects/jigsaw/spec/issues/ We do have some issues also in our jira https://issues.jboss.org/browse/WFCORE-1374 for core and https://issues.jboss.org/browse/WFLY-3854 for full Also as we now have code split in two, the most important part is wildfly-core where we have our core runtime. Which also has separate ci jobs, which look quite good atm https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 Google docs Dimitris shared, would be the good place to add extra issues or any other observation. You could also file issue in jira and assign it to David or me. Just bit of heads up, the upcoming b126 will change names of new jigsaw related parameters that gets passed to jvm. As such, WildFly wont properly build and pass testsuite until we have code updated. -- tomaz On Fri, Jul 8, 2016 at 5:02 AM, Scott Stark wrote: > I guess not as I got build 125 from https://jdk9.java.net/download/. I'll > try https://jdk9.java.net/jigsaw/ instead. > > ----- Original Message ----- > From: "Stuart Douglas" > To: "Jason T. Greene" > Cc: "Scott Stark" , wildfly-dev at lists.jboss.org > Sent: Thursday, July 7, 2016 6:23:56 PM > Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 > > There are definitely still some issues (as can be seen from the CI > failures), however it will boot. > > Stuart > > On Fri, Jul 8, 2016 at 11:00 AM, Jason T. Greene > wrote: > > > Is that the modular JDK build? IIRC there was still some issues there. > Our > > big challenge will be using jigsaw modules as part of a deployment of as > a > > library in the server. > > > > > On Jul 7, 2016, at 6:39 PM, Scott Stark wrote: > > > > > > Ok, got the master branch running under jdk9. So is the issues list > > given at the end of the Java 9 Problems & Solutions FAQ doc the best > place > > to pitch in? > > > > > > ----- Original Message ----- > > > From: "Stuart Douglas" > > > To: "Scott Stark" > > > Cc: wildfly-dev at lists.jboss.org > > > Sent: Thursday, July 7, 2016 3:55:09 PM > > > Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 > > > > > > Wildfly upstream should be mostly working on JDK9: > > > > > > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea > > > > > > There is no released version that will work at the moment (and even if > we > > > did release a version that worked there is no guarantee it would > continue > > > to work past the next JDK9 ea release). > > > > > > Stuart > > > > > >> On Fri, Jul 8, 2016 at 7:17 AM, Scott Stark > wrote: > > >> > > >> I'm looking into the current state of issues around our CDI and JEE > > >> containers and JDK9, and looking through the links that Dimitris sent > me > > >> regarding the issues we are tracking, I don't see a recipe for running > > >> wildfly-10.0.0.Final, so I just gave it a try and see it is failing > > early > > >> on in several modules due to class instantiation. > > >> > > >> Is there a way to get wildfly booted under jdk9? > > >> > > >> What is the best way for me to help out getting these jdk9 issues > > resolved? > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160708/ca15b479/attachment-0001.html From sstark at redhat.com Fri Jul 8 12:22:48 2016 From: sstark at redhat.com (Scott Stark) Date: Fri, 8 Jul 2016 12:22:48 -0400 (EDT) Subject: [wildfly-dev] wildfly-10.0.0.Final and jdk9 In-Reply-To: References: <1690293951.4245620.1467925751015.JavaMail.zimbra@redhat.com> <339466747.4248063.1467926273409.JavaMail.zimbra@redhat.com> <47922156.4303193.1467934730909.JavaMail.zimbra@redhat.com> <8FD4D391-26D5-44F5-9CB3-27B9073C9A1F@redhat.com> <1430553261.4341798.1467946937017.JavaMail.zimbra@redhat.com> Message-ID: <1435863367.4548477.1467994968145.JavaMail.zimbra@redhat.com> There are some additional failures using the https://jdk9.java.net/jigsaw/ version of b125. Presumably this is just additional jigsaw related changes. For example: 09:18:16,212 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 36) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]): java.util.MissingResourceException: Can't find com.sun.corba.se.impl.logging.LogStrings bundle from at java.util.logging.Logger.setupResourceInfo(java.logging at 9-ea/Logger.java:2096) at java.util.logging.Logger.setupResourceInfo(java.logging at 9-ea/Logger.java:2052) at java.util.logging.Logger.getLogger(java.logging at 9-ea/Logger.java:607) at java.util.logging.Logger.getLogger(java.logging at 9-ea/Logger.java:572) at com.sun.corba.se.spi.orb.ORB.getCORBALogger(ORB.java:510) at com.sun.corba.se.spi.orb.ORB.staticGetLogger(ORB.java:502) at com.sun.corba.se.spi.orb.ORB.staticGetLogWrapper(ORB.java:540) at com.sun.corba.se.impl.logging.ORBUtilSystemException.get(ORBUtilSystemException.java:63) at com.sun.corba.se.impl.presentation.rmi.StubFactoryFactoryDynamicBase.(StubFactoryFactoryDynamicBase.java:53) at org.jboss.as.ejb3.iiop.stub.DynamicStubFactoryFactory.(DynamicStubFactoryFactory.java:35) at org.jboss.as.ejb3.subsystem.EJB3SubsystemAdd.performBoottime(EJB3SubsystemAdd.java:226) at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performBoottime(AbstractBoottimeAddStepHandler.java:157) at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:116) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) at org.jboss.threads.JBossThread.run(JBossThread.java:320) ----- Original Message ----- From: "Toma? Cerar" To: "Scott Stark" Cc: "Stuart Douglas" , wildfly-dev at lists.jboss.org Sent: Friday, July 8, 2016 1:47:02 AM Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 All builds after b111 are jigsaw modulized JDK builds. There is no more non-jigsaw jdk9 build. Our CI currently uses b125 to test. There are some known issues, mostly related to jigsaw issues http://openjdk.java.net/projects/jigsaw/spec/issues/ We do have some issues also in our jira https://issues.jboss.org/browse/WFCORE-1374 for core and https://issues.jboss.org/browse/WFLY-3854 for full Also as we now have code split in two, the most important part is wildfly-core where we have our core runtime. Which also has separate ci jobs, which look quite good atm https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 Google docs Dimitris shared, would be the good place to add extra issues or any other observation. You could also file issue in jira and assign it to David or me. Just bit of heads up, the upcoming b126 will change names of new jigsaw related parameters that gets passed to jvm. As such, WildFly wont properly build and pass testsuite until we have code updated. -- tomaz On Fri, Jul 8, 2016 at 5:02 AM, Scott Stark wrote: > I guess not as I got build 125 from https://jdk9.java.net/download/. I'll > try https://jdk9.java.net/jigsaw/ instead. > > ----- Original Message ----- > From: "Stuart Douglas" > To: "Jason T. Greene" > Cc: "Scott Stark" , wildfly-dev at lists.jboss.org > Sent: Thursday, July 7, 2016 6:23:56 PM > Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 > > There are definitely still some issues (as can be seen from the CI > failures), however it will boot. > > Stuart > > On Fri, Jul 8, 2016 at 11:00 AM, Jason T. Greene > wrote: > > > Is that the modular JDK build? IIRC there was still some issues there. > Our > > big challenge will be using jigsaw modules as part of a deployment of as > a > > library in the server. > > > > > On Jul 7, 2016, at 6:39 PM, Scott Stark wrote: > > > > > > Ok, got the master branch running under jdk9. So is the issues list > > given at the end of the Java 9 Problems & Solutions FAQ doc the best > place > > to pitch in? > > > > > > ----- Original Message ----- > > > From: "Stuart Douglas" > > > To: "Scott Stark" > > > Cc: wildfly-dev at lists.jboss.org > > > Sent: Thursday, July 7, 2016 3:55:09 PM > > > Subject: Re: [wildfly-dev] wildfly-10.0.0.Final and jdk9 > > > > > > Wildfly upstream should be mostly working on JDK9: > > > > > > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea > > > > > > There is no released version that will work at the moment (and even if > we > > > did release a version that worked there is no guarantee it would > continue > > > to work past the next JDK9 ea release). > > > > > > Stuart > > > > > >> On Fri, Jul 8, 2016 at 7:17 AM, Scott Stark > wrote: > > >> > > >> I'm looking into the current state of issues around our CDI and JEE > > >> containers and JDK9, and looking through the links that Dimitris sent > me > > >> regarding the issues we are tracking, I don't see a recipe for running > > >> wildfly-10.0.0.Final, so I just gave it a try and see it is failing > > early > > >> on in several modules due to class instantiation. > > >> > > >> Is there a way to get wildfly booted under jdk9? > > >> > > >> What is the best way for me to help out getting these jdk9 issues > > resolved? > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From smarlow at redhat.com Fri Jul 8 12:24:18 2016 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 8 Jul 2016 12:24:18 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> Message-ID: The NoSQL prototype now has transaction enlistment for Neo4j (one phase wrapper). Test example link [1] shows a CMT test bean method and [2] shows a BMT test bean method. Currently, in a JTA transaction the Neo4j Session survives ending the JTA transaction. It might be better to close the Neo4j Session when the JTA transaction ends, which would require the application to get a new Session, this would ensure that applications don't forget to close the session, with the down side that with BMT, application code would need to call the Neo4j Driver.session(), to get a new Session instance after each JTA transaction ends. After a session is closed, there is no guarantee that another session can be obtained, as the next Driver.session() may time out if the internal pool of Driver sessions, is empty and the configured time limit (neo4j.driver.acquireSessionTimeout) is exceeded (defaults to 30 seconds). So, there are costs to automatically closing Neo4j Sessions at JTA transaction end time. Although, you could say that closing the Session, after each transaction, gives other threads a change to use the Session that isn't really closed, but instead is really returned to the internal Driver sessions pool. By the way, the Neo4j Session class, is what applications use to access the database. Thanks, Scott [1] https://github.com/scottmarlow/wildfly/blob/nosql-dev9/testsuite/nosql/src/test/java/org/jboss/as/test/compat/nosql/neo4j/StatefulTestBean.java#L85 [2] https://github.com/scottmarlow/wildfly/blob/nosql-dev9/testsuite/nosql/src/test/java/org/jboss/as/test/compat/nosql/neo4j/BMTStatefulTestBean.java#L54 On 06/29/2016 09:50 AM, Scott Marlow wrote: > I think that we will move forward now and prototype the transaction > enlistment for ACID NoSQL databases. This is important to nail down > now, as we would like forward application compatibility. We need to > choose now, whether MySLSB.myMethod() performs the Neo4j database update > immediately when (#4) tx.close() is called or when the JTA transaction > completes. By now, I mean that we need to decide before a release of > WildFly that contains the NoSQL integration is released, so that we know > that future releases will be compatible. > > I don't think that transaction enlistment should be allowed for BASE > NoSQL databases, which is why I mentioned ACID above. With BASE > databases, the application code is responsible for dealing with dirty > data. As such, I think it would be misleading to enlist BASE operations > into a JTA transaction. This means that BASE NoSQL database profiles > will not allow 1-phase/2-phase transaction attribute to be specified. > > We started to write some design notes [1] for NoSQL integration. We > will update the design notes after hearing more feedback on the above. > > Scott > > [1] https://developer.jboss.org/wiki/DesignNotesForNoSQLIntegrationOnWildFly > From sstark at redhat.com Mon Jul 11 03:15:32 2016 From: sstark at redhat.com (Scott Stark) Date: Mon, 11 Jul 2016 03:15:32 -0400 (EDT) Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 In-Reply-To: <2032117863.4933577.1468219284803.JavaMail.zimbra@redhat.com> Message-ID: <1633402839.4936392.1468221332903.JavaMail.zimbra@redhat.com> I'm looking into why the cdi-tck is failing to run on wildfly-10.1.0.Final-SNAPSHOT using java 9 and a common issue that I don't see in the Java 9 Problems & Solutions FAQ is illustrated by the following exception trace. It appears that the class loader that org.arquillian.container.chameleon.ContainerLoader is using is associated with the java.base module, and thus cannot see anything but the java.base classes. Once I figure out how the class loader for java.base is being obtained I'll raise a general FAQ for the problems/solutions doc, but I thought I might be able to work around this by using the -XaddReads:java.sql=java.base to allow java.base to see java.sql, but it does not work. Similarly, -XaddExports:java.sql/java.sql=java.base does not work. Is there a check to prevent circular references or am I just not understanding how these calls change the module graph? Tests run: 4, Failures: 1, Errors: 0, Skipped: 3, Time elapsed: 1.121 sec <<< FAILURE! arquillianBeforeSuite(org.jboss.arq_wf_test.CDITest) Time elapsed: 0.63 sec <<< FAILURE! java.lang.NoClassDefFoundError: java/sql/Date at org.yaml.snakeyaml.nodes.Tag.(Tag.java:64) at org.yaml.snakeyaml.constructor.SafeConstructor.(SafeConstructor.java:52) at org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:77) at org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:64) at org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:54) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:62) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) at org.arquillian.container.chameleon.ContainerLoader.loadContainers(ContainerLoader.java:71) at org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:45) at org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:117) at org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81) at org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:70) at org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:39) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:62) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:55) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachContainer(ContainerLifecycleController.java:209) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.setupContainers(ContainerLifecycleController.java:54) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:85) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) at org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:71) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:514) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:215) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.run(TestNG.java:1064) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110) at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: java.lang.ClassNotFoundException: java.sql.Date at java.net.URLClassLoader.findClass(java.base at 9-ea/URLClassLoader.java:384) at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:486) at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) ... 85 more From sstark at redhat.com Mon Jul 11 04:36:43 2016 From: sstark at redhat.com (Scott Stark) Date: Mon, 11 Jul 2016 04:36:43 -0400 (EDT) Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 In-Reply-To: <1633402839.4936392.1468221332903.JavaMail.zimbra@redhat.com> References: <1633402839.4936392.1468221332903.JavaMail.zimbra@redhat.com> Message-ID: <1543655717.4951760.1468226203603.JavaMail.zimbra@redhat.com> So the problem is a change in behavior of a URLClassLoader that has a null parent class loader. This seems like it is a big compatibility problem as classes defined by such a class loader only have visibility into the java.base module rather than the entire platform. The simple fix is to pass in the new ClassLoader.getPlatformClassLoader() as the URLClassLoader parent rather than null. However, this seems like what the ClassLoader should be doing itself as I would expect a lot of code will break. I'll create a bug report for the simple test case I have that shows the problem. ----- Original Message ----- From: "Scott Stark" To: wildfly-dev at lists.jboss.org Sent: Monday, July 11, 2016 12:15:32 AM Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 I'm looking into why the cdi-tck is failing to run on wildfly-10.1.0.Final-SNAPSHOT using java 9 and a common issue that I don't see in the Java 9 Problems & Solutions FAQ is illustrated by the following exception trace. It appears that the class loader that org.arquillian.container.chameleon.ContainerLoader is using is associated with the java.base module, and thus cannot see anything but the java.base classes. Once I figure out how the class loader for java.base is being obtained I'll raise a general FAQ for the problems/solutions doc, but I thought I might be able to work around this by using the -XaddReads:java.sql=java.base to allow java.base to see java.sql, but it does not work. Similarly, -XaddExports:java.sql/java.sql=java.base does not work. Is there a check to prevent circular references or am I just not understanding how these calls change the module graph? Tests run: 4, Failures: 1, Errors: 0, Skipped: 3, Time elapsed: 1.121 sec <<< FAILURE! arquillianBeforeSuite(org.jboss.arq_wf_test.CDITest) Time elapsed: 0.63 sec <<< FAILURE! java.lang.NoClassDefFoundError: java/sql/Date at org.yaml.snakeyaml.nodes.Tag.(Tag.java:64) at org.yaml.snakeyaml.constructor.SafeConstructor.(SafeConstructor.java:52) at org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:77) at org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:64) at org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:54) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:62) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) at org.arquillian.container.chameleon.ContainerLoader.loadContainers(ContainerLoader.java:71) at org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:45) at org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:117) at org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81) at org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:70) at org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:39) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:62) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:55) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachContainer(ContainerLifecycleController.java:209) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.setupContainers(ContainerLifecycleController.java:54) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:85) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) at org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:71) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:514) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:215) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.run(TestNG.java:1064) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110) at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: java.lang.ClassNotFoundException: java.sql.Date at java.net.URLClassLoader.findClass(java.base at 9-ea/URLClassLoader.java:384) at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:486) at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) ... 85 more _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Mon Jul 11 09:44:36 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 11 Jul 2016 15:44:36 +0200 Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 In-Reply-To: <1543655717.4951760.1468226203603.JavaMail.zimbra@redhat.com> References: <1633402839.4936392.1468221332903.JavaMail.zimbra@redhat.com> <1543655717.4951760.1468226203603.JavaMail.zimbra@redhat.com> Message-ID: This is one of known issues, see for details: http://openjdk.java.net/projects/jigsaw/spec/issues/#module-graphs http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader Some of this is being addressed as part upcoming jigsaw b126 -- tomaz On Mon, Jul 11, 2016 at 10:36 AM, Scott Stark wrote: > So the problem is a change in behavior of a URLClassLoader that has a null > parent class loader. This seems like it is a big compatibility problem as > classes defined by such a class loader only have visibility into the > java.base module rather than the entire platform. > > The simple fix is to pass in the new ClassLoader.getPlatformClassLoader() > as the URLClassLoader parent rather than null. However, this seems like > what the ClassLoader should be doing itself as I would expect a lot of code > will break. I'll create a bug report for the simple test case I have that > shows the problem. > > ----- Original Message ----- > From: "Scott Stark" > To: wildfly-dev at lists.jboss.org > Sent: Monday, July 11, 2016 12:15:32 AM > Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 > > I'm looking into why the cdi-tck is failing to run on > wildfly-10.1.0.Final-SNAPSHOT using java 9 and a common issue that I don't > see in the Java 9 Problems & Solutions FAQ is illustrated by the following > exception trace. It appears that the class loader that > org.arquillian.container.chameleon.ContainerLoader is using is associated > with the java.base module, and thus cannot see anything but the java.base > classes. Once I figure out how the class loader for java.base is being > obtained I'll raise a general FAQ for the problems/solutions doc, but I > thought I might be able to work around this by using the > -XaddReads:java.sql=java.base to allow java.base to see java.sql, but it > does not work. Similarly, -XaddExports:java.sql/java.sql=java.base does not > work. > > Is there a check to prevent circular references or am I just not > understanding how these calls change the module graph? > > Tests run: 4, Failures: 1, Errors: 0, Skipped: 3, Time elapsed: 1.121 sec > <<< FAILURE! > arquillianBeforeSuite(org.jboss.arq_wf_test.CDITest) Time elapsed: 0.63 > sec <<< FAILURE! > java.lang.NoClassDefFoundError: java/sql/Date > at org.yaml.snakeyaml.nodes.Tag.(Tag.java:64) > at > org.yaml.snakeyaml.constructor.SafeConstructor.(SafeConstructor.java:52) > at > org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:77) > at > org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:64) > at > org.yaml.snakeyaml.constructor.Constructor.(Constructor.java:54) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea > /NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea > /DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base at 9-ea > /Constructor.java:453) > at java.lang.Class.newInstance(java.base at 9-ea/Class.java:569) > at > org.arquillian.container.chameleon.ContainerLoader.loadContainers(ContainerLoader.java:71) > at > org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:45) > at > org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:117) > at > org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81) > at > org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:70) > at > org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:39) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea > /NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea > /DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at > org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:62) > at > org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:55) > at > org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachContainer(ContainerLifecycleController.java:209) > at > org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.setupContainers(ContainerLifecycleController.java:54) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea > /NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea > /DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at > org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:85) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea > /NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea > /DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at > org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea > /NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea > /DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at > org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at > org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:71) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea > /NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea > /DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) > at > org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86) > at > org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:514) > at > org.testng.internal.Invoker.invokeConfigurations(Invoker.java:215) > at > org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305) > at org.testng.SuiteRunner.run(SuiteRunner.java:268) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) > at org.testng.TestNG.run(TestNG.java:1064) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110) > at > org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea > /NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea > /DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:533) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) > Caused by: java.lang.ClassNotFoundException: java.sql.Date > at java.net.URLClassLoader.findClass(java.base at 9-ea > /URLClassLoader.java:384) > at java.lang.ClassLoader.loadClass(java.base at 9-ea > /ClassLoader.java:486) > at java.lang.ClassLoader.loadClass(java.base at 9-ea > /ClassLoader.java:419) > ... 85 more > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160711/b14328f5/attachment.html From jesper.pedersen at redhat.com Mon Jul 11 13:38:19 2016 From: jesper.pedersen at redhat.com (Jesper Pedersen) Date: Mon, 11 Jul 2016 13:38:19 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> Message-ID: Hi, On 07/08/2016 12:24 PM, Scott Marlow wrote: > The NoSQL prototype now has transaction enlistment for Neo4j (one phase > wrapper). > > Test example link [1] shows a CMT test bean method You should add a comment that tx.success() / tx.failure() is tied to the out-come of the JTA transaction. And tx.close() is done in afterCompletion. > and [2] shows a BMT test bean method. > This test case highlights the problem of checking for enlistment in 2 places, as the Session is obtained before the transaction is started, and there is no way to get the session reference from the transaction instance. So, you can manage the transaction lifecycle, but not the session lifecycle. > Currently, in a JTA transaction the Neo4j Session survives ending the > JTA transaction. It might be better to close the Neo4j Session when the > JTA transaction ends, which would require the application to get a new > Session, this would ensure that applications don't forget to close the > session, with the down side that with BMT, application code would need > to call the Neo4j Driver.session(), to get a new Session instance after > each JTA transaction ends. After a session is closed, there is no > guarantee that another session can be obtained, as the next > Driver.session() may time out if the internal pool of Driver sessions, > is empty and the configured time limit > (neo4j.driver.acquireSessionTimeout) is exceeded (defaults to 30 > seconds). So, there are costs to automatically closing Neo4j Sessions > at JTA transaction end time. Although, you could say that closing the > Session, after each transaction, gives other threads a change to use the > Session that isn't really closed, but instead is really returned to the > internal Driver sessions pool. As you are enlisting the Neo4J resources into the transaction, I think that you should define driver.session() as the enlistment barrier, and therefore also close the session in afterCompletion. That makes it more clear in what scenarios the resources are managed. In JDBC you inject the DataSource instance, and obtain a Connection, so it would be parallel to this case Driver vs. Session. This means that people needs to be more careful in the BMT case to get the Session within an active transaction. JCA has CachedConnectionManager to verify these cases, so you could add a similar concept. Best regards, Jesper From sstark at redhat.com Mon Jul 11 13:48:37 2016 From: sstark at redhat.com (Scott Stark) Date: Mon, 11 Jul 2016 13:48:37 -0400 (EDT) Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 In-Reply-To: References: <1633402839.4936392.1468221332903.JavaMail.zimbra@redhat.com> <1543655717.4951760.1468226203603.JavaMail.zimbra@redhat.com> Message-ID: <1533816591.5086775.1468259317649.JavaMail.zimbra@redhat.com> Ok, I'll look at those, but I am using the b126 build. Maybe the fix slipped. [tmp 512]$ java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+126) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode) ----- Original Message ----- From: "Toma? Cerar" To: "Scott Stark" Cc: wildfly-dev at lists.jboss.org Sent: Monday, July 11, 2016 6:44:36 AM Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9 This is one of known issues, see for details: http://openjdk.java.net/projects/jigsaw/spec/issues/#module-graphs http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader Some of this is being addressed as part upcoming jigsaw b126 -- tomaz On Mon, Jul 11, 2016 at 10:36 AM, Scott Stark wrote: > So the problem is a change in behavior of a URLClassLoader that has a null > parent class loader. This seems like it is a big compatibility problem as > classes defined by such a class loader only have visibility into the > java.base module rather than the entire platform. > > The simple fix is to pass in the new ClassLoader.getPlatformClassLoader() > as the URLClassLoader parent rather than null. However, this seems like > what the ClassLoader should be doing itself as I would expect a lot of code > will break. I'll create a bug report for the simple test case I have that > shows the problem. > From sstark at redhat.com Mon Jul 11 14:59:36 2016 From: sstark at redhat.com (Scott Stark) Date: Mon, 11 Jul 2016 14:59:36 -0400 (EDT) Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 In-Reply-To: <1533816591.5086775.1468259317649.JavaMail.zimbra@redhat.com> References: <1633402839.4936392.1468221332903.JavaMail.zimbra@redhat.com> <1543655717.4951760.1468226203603.JavaMail.zimbra@redhat.com> <1533816591.5086775.1468259317649.JavaMail.zimbra@redhat.com> Message-ID: <901229420.5093367.1468263576458.JavaMail.zimbra@redhat.com> I don't see that those issues deal with the change in behavior regarding a null parent class loader. They deal with the inability to add reads that are apparent cycles and the addition of a ClassLoader.get PlatformClassLoader() method, which has been added in build 126. I have submitted a bug with the test example found here: https://github.com/RedHatJava9Testing/URLClassLoader.git ----- Original Message ----- From: "Scott Stark" To: "Toma? Cerar" Cc: wildfly-dev at lists.jboss.org Sent: Monday, July 11, 2016 10:48:37 AM Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9 Ok, I'll look at those, but I am using the b126 build. Maybe the fix slipped. [tmp 512]$ java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+126) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode) ----- Original Message ----- From: "Toma? Cerar" To: "Scott Stark" Cc: wildfly-dev at lists.jboss.org Sent: Monday, July 11, 2016 6:44:36 AM Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9 This is one of known issues, see for details: http://openjdk.java.net/projects/jigsaw/spec/issues/#module-graphs http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader Some of this is being addressed as part upcoming jigsaw b126 -- tomaz On Mon, Jul 11, 2016 at 10:36 AM, Scott Stark wrote: > So the problem is a change in behavior of a URLClassLoader that has a null > parent class loader. This seems like it is a big compatibility problem as > classes defined by such a class loader only have visibility into the > java.base module rather than the entire platform. > > The simple fix is to pass in the new ClassLoader.getPlatformClassLoader() > as the URLClassLoader parent rather than null. However, this seems like > what the ClassLoader should be doing itself as I would expect a lot of code > will break. I'll create a bug report for the simple test case I have that > shows the problem. > _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Mon Jul 11 15:22:34 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 11 Jul 2016 21:22:34 +0200 Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 In-Reply-To: <1533816591.5086775.1468259317649.JavaMail.zimbra@redhat.com> References: <1633402839.4936392.1468221332903.JavaMail.zimbra@redhat.com> <1543655717.4951760.1468226203603.JavaMail.zimbra@redhat.com> <1533816591.5086775.1468259317649.JavaMail.zimbra@redhat.com> Message-ID: On Mon, Jul 11, 2016 at 7:48 PM, Scott Stark wrote: > [tmp 512]$ java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+126) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode) > You are using "wrong" b126, this is from main line, grab b126 jigsaw build that was just published to https://jdk9.java.net/jigsaw/ C:\development\tools\jdk\jdk-9\bin> ./java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+ 126-2016-07-10-164835.javare.5266.nc) Java HotSpot(TM) Client VM (build 9-ea+126-2016-07-10-164835.javare.5266.nc, mixed mode) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160711/2fa5179c/attachment.html From sstark at redhat.com Mon Jul 11 15:38:37 2016 From: sstark at redhat.com (Scott Stark) Date: Mon, 11 Jul 2016 15:38:37 -0400 (EDT) Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9 In-Reply-To: References: <1633402839.4936392.1468221332903.JavaMail.zimbra@redhat.com> <1543655717.4951760.1468226203603.JavaMail.zimbra@redhat.com> <1533816591.5086775.1468259317649.JavaMail.zimbra@redhat.com> Message-ID: <364669837.5097677.1468265917568.JavaMail.zimbra@redhat.com> Ok, I just tried it and I don't see the --add-reads changing the behavior as I would expect: [URLClassLoader 558]$ $JAVA9_HOME/bin/java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+126-2016-07-10-165150.javare.5266.nc) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126-2016-07-10-165150.javare.5266.nc, mixed mode) [URLClassLoader 557]$ $JAVA9_HOME/bin/java -Xdiag --add-reads java.sql=java.base -cp bin TestURLClassLoader ... [Resolver] jdk.zipfs rootURL=file:/private/tmp/URLClassLoader/bin/ Loaded class: class JavaSqlUser, loader=java.net.URLClassLoader at 51565ec2 Exception in thread "main" java.lang.reflect.InvocationTargetException at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:62) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:453) at TestURLClassLoader.main(TestURLClassLoader.java:26) Caused by: java.lang.NoClassDefFoundError: java/sql/Date at SqlDateUser.(SqlDateUser.java:7) at JavaSqlUser.(JavaSqlUser.java:12) ... 5 more Caused by: java.lang.ClassNotFoundException: java.sql.Date at java.net.URLClassLoader.findClass(java.base at 9-ea/URLClassLoader.java:384) at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:486) at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) ... 7 more ----- Original Message ----- From: "Toma? Cerar" To: "Scott Stark" Cc: wildfly-dev at lists.jboss.org Sent: Monday, July 11, 2016 12:22:34 PM Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9 On Mon, Jul 11, 2016 at 7:48 PM, Scott Stark wrote: > [tmp 512]$ java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+126) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode) > You are using "wrong" b126, this is from main line, grab b126 jigsaw build that was just published to https://jdk9.java.net/jigsaw/ C:\development\tools\jdk\jdk-9\bin> ./java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+ 126-2016-07-10-164835.javare.5266.nc) Java HotSpot(TM) Client VM (build 9-ea+126-2016-07-10-164835.javare.5266.nc, mixed mode) From jai.forums2013 at gmail.com Tue Jul 12 05:57:21 2016 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 12 Jul 2016 15:27:21 +0530 Subject: [wildfly-dev] Versions in JBoss Modules In-Reply-To: <577BEEA8.1030909@redhat.com> References: <577BEEA8.1030909@redhat.com> Message-ID: <5784BF01.9030500@gmail.com> Hi David, - In the absence of an explicit module version (given that it is noted as optional) on module A and at the same time there being a module which is also module A with version 1.0.1, what would be semantics in terms of module resolution when this module A is added as an dependency in some other module? - Would a module dependency (via ) have to explicitly list a module version? I guess not - in which case what would be the module resolution logic when more than 1 module with different versions are present in the system? - In the updated module.xml schema, I don't see a way to specify the version of a dependency. Is it even possible to refer to a specific versioned module in the dependency? -Jaikiran On Tuesday 05 July 2016 11:00 PM, David M. Lloyd wrote: > With this PR [1] for issue MODULES-257 [2], JBoss Modules (as of version > 1.6.0) will gain the ability to associate a version string with each > module that is defined. I have not yet merged this PR; I want to see if > anyone has any feedback on the change first. Of note is that I define a > syntax for versions, as well as a sort order that should be largely > Maven-compatible. The module version can be queried at run time, will > appear in modules' toString(), and starting in Java 9, should also > appear in stack traces (though this is not certain yet). Ideally we > will be able to copy version information into our shipped modules when > we build feature packs. > > If nobody has any feedback in the next few days, I will go ahead and > merge the change. > > [1] https://github.com/jboss-modules/jboss-modules/pull/101 > [2] https://issues.jboss.org/browse/MODULES-257 > From david.lloyd at redhat.com Tue Jul 12 08:53:16 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 12 Jul 2016 07:53:16 -0500 Subject: [wildfly-dev] Versions in JBoss Modules In-Reply-To: <5784BF01.9030500@gmail.com> References: <577BEEA8.1030909@redhat.com> <5784BF01.9030500@gmail.com> Message-ID: <5784E83C.9010405@redhat.com> Hi Jaikiran. Module versions are not used in resolution in any way, at the moment. They're purely informational at runtime; the idea is that under Java 9, the stack trace will include the version string (though this isn't working yet). It follows that you cannot have more than one version of a module with a given name; the modules still need different names in this case and there are no plans to change this. On 07/12/2016 04:57 AM, Jaikiran Pai wrote: > Hi David, > > - In the absence of an explicit module version (given that it is noted > as optional) on module A and at the same time there being a module which > is also module A with version 1.0.1, what would be semantics in terms of > module resolution when this module A is added as an dependency in some > other module? > > - Would a module dependency (via ) have to explicitly list > a module version? I guess not - in which case what would be the module > resolution logic when more than 1 module with different versions are > present in the system? > > - In the updated module.xml schema, I don't see a way to specify the > version of a dependency. Is it even possible to refer to a specific > versioned module in the dependency? > > -Jaikiran > > On Tuesday 05 July 2016 11:00 PM, David M. Lloyd wrote: >> With this PR [1] for issue MODULES-257 [2], JBoss Modules (as of version >> 1.6.0) will gain the ability to associate a version string with each >> module that is defined. I have not yet merged this PR; I want to see if >> anyone has any feedback on the change first. Of note is that I define a >> syntax for versions, as well as a sort order that should be largely >> Maven-compatible. The module version can be queried at run time, will >> appear in modules' toString(), and starting in Java 9, should also >> appear in stack traces (though this is not certain yet). Ideally we >> will be able to copy version information into our shipped modules when >> we build feature packs. >> >> If nobody has any feedback in the next few days, I will go ahead and >> merge the change. >> >> [1] https://github.com/jboss-modules/jboss-modules/pull/101 >> [2] https://issues.jboss.org/browse/MODULES-257 >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From mmusgrov at redhat.com Tue Jul 12 09:38:56 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Tue, 12 Jul 2016 14:38:56 +0100 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: If a remote server has created a transaction and made an ejb call into the shutting down server then initially our (CORBA) interceptors will trigger and we will create a subordinate transaction and put that on the thread. So provided the EJB subsystem checks the association and lets the request through if it finds a transaction then we will be covered. Does the EJB subsystem perform this check? On Thu, Jul 7, 2016 at 11:02 AM, Gytis Trikleris wrote: > Sounds that we shouldn?t do extra shutdown logic for JTA and JTS other > than possibly provide SPI for EJB and CORBA? > > Gytis > > On 6 Jul 2016, at 01:00, Stuart Douglas > wrote: > > Local transaction creation has to be allowed during graceful shutdown. > e.g. if a web request is in the process of running and it attempts to start > a transaction this must be allowed (the core requirement of graceful > shutdown is that requests that have already been accepted continue to run > as normal). > > The only case when transactions should be disallowed are remote > transactions, such as remote EJB and CORBA, which I think should already be > dealt with at the respective endpoints (in terms of disallowing new > transaction creation). I think the main thing that needs consideration here > is what to do with EJB requests that would otherwise be rejected that are > part of an existing remote transaction. We probably need some way of > identifying these requests and allowing them to proceed. > > Stuart > > > > On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris > wrote: > >> Hello, >> >> I?m in the process of writing an analysis document for >> https://issues.jboss.org/browse/EAP7-459 and need your input. >> Specifically I?m looking for the list of subsystems which might need to >> create new transactions during the graceful shutdown. Normally new >> transactions would not be allowed then, but this might stop other >> subsystems to shutdown properly. If such subsystems exist we?ll need to >> think of the way how to filter out their requests (e.g. providing SPI for >> them). >> >> Thanks, >> Gytis >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160712/57096de2/attachment-0001.html From smarlow at redhat.com Tue Jul 12 11:36:10 2016 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 12 Jul 2016 11:36:10 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> Message-ID: On 07/11/2016 01:38 PM, Jesper Pedersen wrote: > Hi, > > On 07/08/2016 12:24 PM, Scott Marlow wrote: >> The NoSQL prototype now has transaction enlistment for Neo4j (one phase >> wrapper). >> >> Test example link [1] shows a CMT test bean method > > You should add a comment that tx.success() / tx.failure() is tied to the > out-come of the JTA transaction. And tx.close() is done in afterCompletion. Comment added, thanks for noticing the absence. :) > >> and [2] shows a BMT test bean method. >> > > This test case highlights the problem of checking for enlistment in 2 > places, as the Session is obtained before the transaction is started, > and there is no way to get the session reference from the transaction > instance. > > So, you can manage the transaction lifecycle, but not the session > lifecycle. In [1], when we get the Neo4j Session, we enlist it within the JTA transaction. We also enlist the Neo4j transaction at the same time (during the call to Driver.session() inside of a JTA transaction.) For the duration of the JTA transaction, attempts to get the Session/Transaction for the named Neo4j profile, will return the already JTA enlisted Session/Transaction. > >> Currently, in a JTA transaction the Neo4j Session survives ending the >> JTA transaction. It might be better to close the Neo4j Session when the >> JTA transaction ends, which would require the application to get a new >> Session, this would ensure that applications don't forget to close the >> session, with the down side that with BMT, application code would need >> to call the Neo4j Driver.session(), to get a new Session instance after >> each JTA transaction ends. After a session is closed, there is no >> guarantee that another session can be obtained, as the next >> Driver.session() may time out if the internal pool of Driver sessions, >> is empty and the configured time limit >> (neo4j.driver.acquireSessionTimeout) is exceeded (defaults to 30 >> seconds). So, there are costs to automatically closing Neo4j Sessions >> at JTA transaction end time. Although, you could say that closing the >> Session, after each transaction, gives other threads a change to use the >> Session that isn't really closed, but instead is really returned to the >> internal Driver sessions pool. > > As you are enlisting the Neo4J resources into the transaction, I think > that you should define driver.session() as the enlistment barrier, and > therefore also close the session in afterCompletion. I pushed an update [1] that includes auto closing the session, when the transaction ends. I didn't add a Synchronization yet, to handle closing the session when the transaction manager doesn't call XAResourceWrapper.commit/rollback. I agree that will introduce an extra layer of safety to ensure that resources are closed. > > That makes it more clear in what scenarios the resources are managed. > > In JDBC you inject the DataSource instance, and obtain a Connection, so > it would be parallel to this case Driver vs. Session. > > This means that people needs to be more careful in the BMT case to get > the Session within an active transaction. JCA has > CachedConnectionManager to verify these cases, so you could add a > similar concept. Attempts to call Neo4j transaction/session "close", within the JTA transaction are ignored. How about calls to "close" after the JTA transaction ends, should they also be ignored? Is there a JCA equivalent of ignoring "close" after the transaction ends? I think that Hibernate ORM is or was, closing DataSource's after the transaction ends, so I assume that JCA ignores "close" after the JTA transaction ends. Thanks again for the feedback! Scott [1] https://github.com/scottmarlow/wildfly/commit/bfecbe881e6a16548b9712b3e52ff7acdd3142b4 From stuart.w.douglas at gmail.com Tue Jul 12 17:44:28 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 13 Jul 2016 07:44:28 +1000 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: Not at the moment. Stuart On Tue, Jul 12, 2016 at 11:38 PM, Michael Musgrove wrote: > If a remote server has created a transaction and made an ejb call into the > shutting down server then initially our (CORBA) interceptors will trigger > and we will create a subordinate transaction and put that on the thread. So > provided the EJB subsystem checks the association and lets the request > through if it finds a transaction then we will be covered. Does the EJB > subsystem perform this check? > > On Thu, Jul 7, 2016 at 11:02 AM, Gytis Trikleris > wrote: > >> Sounds that we shouldn?t do extra shutdown logic for JTA and JTS other >> than possibly provide SPI for EJB and CORBA? >> >> Gytis >> >> On 6 Jul 2016, at 01:00, Stuart Douglas >> wrote: >> >> Local transaction creation has to be allowed during graceful shutdown. >> e.g. if a web request is in the process of running and it attempts to start >> a transaction this must be allowed (the core requirement of graceful >> shutdown is that requests that have already been accepted continue to run >> as normal). >> >> The only case when transactions should be disallowed are remote >> transactions, such as remote EJB and CORBA, which I think should already be >> dealt with at the respective endpoints (in terms of disallowing new >> transaction creation). I think the main thing that needs consideration here >> is what to do with EJB requests that would otherwise be rejected that are >> part of an existing remote transaction. We probably need some way of >> identifying these requests and allowing them to proceed. >> >> Stuart >> >> >> >> On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris >> wrote: >> >>> Hello, >>> >>> I?m in the process of writing an analysis document for >>> https://issues.jboss.org/browse/EAP7-459 and need your input. >>> Specifically I?m looking for the list of subsystems which might need to >>> create new transactions during the graceful shutdown. Normally new >>> transactions would not be allowed then, but this might stop other >>> subsystems to shutdown properly. If such subsystems exist we?ll need to >>> think of the way how to filter out their requests (e.g. providing SPI for >>> them). >>> >>> Thanks, >>> Gytis >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160713/2a83f34e/attachment.html From jai.forums2013 at gmail.com Wed Jul 13 00:38:50 2016 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 13 Jul 2016 10:08:50 +0530 Subject: [wildfly-dev] Versions in JBoss Modules In-Reply-To: <5784E83C.9010405@redhat.com> References: <577BEEA8.1030909@redhat.com> <5784BF01.9030500@gmail.com> <5784E83C.9010405@redhat.com> Message-ID: <5785C5DA.6050506@gmail.com> Got it. Thanks David. -Jaikiran On Tuesday 12 July 2016 06:23 PM, David M. Lloyd wrote: > Hi Jaikiran. > > Module versions are not used in resolution in any way, at the moment. > They're purely informational at runtime; the idea is that under Java 9, > the stack trace will include the version string (though this isn't > working yet). It follows that you cannot have more than one version of > a module with a given name; the modules still need different names in > this case and there are no plans to change this. > > On 07/12/2016 04:57 AM, Jaikiran Pai wrote: >> Hi David, >> >> - In the absence of an explicit module version (given that it is noted >> as optional) on module A and at the same time there being a module which >> is also module A with version 1.0.1, what would be semantics in terms of >> module resolution when this module A is added as an dependency in some >> other module? >> >> - Would a module dependency (via ) have to explicitly list >> a module version? I guess not - in which case what would be the module >> resolution logic when more than 1 module with different versions are >> present in the system? >> >> - In the updated module.xml schema, I don't see a way to specify the >> version of a dependency. Is it even possible to refer to a specific >> versioned module in the dependency? >> >> -Jaikiran >> >> On Tuesday 05 July 2016 11:00 PM, David M. Lloyd wrote: >>> With this PR [1] for issue MODULES-257 [2], JBoss Modules (as of version >>> 1.6.0) will gain the ability to associate a version string with each >>> module that is defined. I have not yet merged this PR; I want to see if >>> anyone has any feedback on the change first. Of note is that I define a >>> syntax for versions, as well as a sort order that should be largely >>> Maven-compatible. The module version can be queried at run time, will >>> appear in modules' toString(), and starting in Java 9, should also >>> appear in stack traces (though this is not certain yet). Ideally we >>> will be able to copy version information into our shipped modules when >>> we build feature packs. >>> >>> If nobody has any feedback in the next few days, I will go ahead and >>> merge the change. >>> >>> [1] https://github.com/jboss-modules/jboss-modules/pull/101 >>> [2] https://issues.jboss.org/browse/MODULES-257 >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> From jesper.pedersen at redhat.com Wed Jul 13 10:44:42 2016 From: jesper.pedersen at redhat.com (Jesper Pedersen) Date: Wed, 13 Jul 2016 10:44:42 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> Message-ID: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> On 07/12/2016 11:36 AM, Scott Marlow wrote: >> As you are enlisting the Neo4J resources into the transaction, I think >> that you should define driver.session() as the enlistment barrier, and >> therefore also close the session in afterCompletion. > > I pushed an update [1] that includes auto closing the session, when the > transaction ends. > > I didn't add a Synchronization yet, to handle closing the session when > the transaction manager doesn't call XAResourceWrapper.commit/rollback. > I agree that will introduce an extra layer of safety to ensure that > resources are closed. > I think you can use the XAResource instance for that at the moment. >> >> That makes it more clear in what scenarios the resources are managed. >> >> In JDBC you inject the DataSource instance, and obtain a Connection, so >> it would be parallel to this case Driver vs. Session. >> >> This means that people needs to be more careful in the BMT case to get >> the Session within an active transaction. JCA has >> CachedConnectionManager to verify these cases, so you could add a >> similar concept. > > Attempts to call Neo4j transaction/session "close", within the JTA > transaction are ignored. How about calls to "close" after the JTA > transaction ends, should they also be ignored? Hopefully the underlying implementation will ignore multiple close() calls, and throw an exception on any other call. You will have to test the behaviour of each NoSQL store. > Is there a JCA > equivalent of ignoring "close" after the transaction ends? I think that > Hibernate ORM is or was, closing DataSource's after the transaction > ends, so I assume that JCA ignores "close" after the JTA transaction ends. > You probably mean Connection.close() -- if all connections are closed in afterCompletion then the connection is returned to the pool. Otherwise, it waits until ref count becomes 0, e.g. c.close() after the transaction has ended. http://www.ironjacamar.org/doc/roadto12/txtracking.html Best regards, Jesper From smarlow at redhat.com Wed Jul 13 11:25:24 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 13 Jul 2016 11:25:24 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> Message-ID: <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> On 07/13/2016 10:44 AM, Jesper Pedersen wrote: > On 07/12/2016 11:36 AM, Scott Marlow wrote: >>> As you are enlisting the Neo4J resources into the transaction, I think >>> that you should define driver.session() as the enlistment barrier, and >>> therefore also close the session in afterCompletion. >> >> I pushed an update [1] that includes auto closing the session, when the >> transaction ends. >> >> I didn't add a Synchronization yet, to handle closing the session when >> the transaction manager doesn't call XAResourceWrapper.commit/rollback. >> I agree that will introduce an extra layer of safety to ensure that >> resources are closed. >> > > I think you can use the XAResource instance for that at the moment. Yes, we are doing this currently. > >>> >>> That makes it more clear in what scenarios the resources are managed. >>> >>> In JDBC you inject the DataSource instance, and obtain a Connection, so >>> it would be parallel to this case Driver vs. Session. >>> >>> This means that people needs to be more careful in the BMT case to get >>> the Session within an active transaction. JCA has >>> CachedConnectionManager to verify these cases, so you could add a >>> similar concept. >> >> Attempts to call Neo4j transaction/session "close", within the JTA >> transaction are ignored. How about calls to "close" after the JTA >> transaction ends, should they also be ignored? > > Hopefully the underlying implementation will ignore multiple close() > calls, and throw an exception on any other call. isOpen is currently returning false instead of throwing an exception. We are ignoring multiple close() calls and do throw an exception on any other call. > > You will have to test the behaviour of each NoSQL store. > >> Is there a JCA >> equivalent of ignoring "close" after the transaction ends? I think that >> Hibernate ORM is or was, closing DataSource's after the transaction >> ends, so I assume that JCA ignores "close" after the JTA transaction >> ends. >> > > You probably mean Connection.close() -- if all connections are closed in > afterCompletion then the connection is returned to the pool. Otherwise, > it waits until ref count becomes 0, e.g. c.close() after the transaction > has ended. > > http://www.ironjacamar.org/doc/roadto12/txtracking.html > > Best regards, > Jesper > From gunnar at hibernate.org Wed Jul 13 13:16:54 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 13 Jul 2016 18:16:54 +0100 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> Message-ID: Hi Scott, I had a short look at the tests you pointed to; in the one using BMT, why is it that the UserTransaction *and* the Neo4j TX API are used? I'd have expected it to be only one *or* the other? In the one using CMT, there are also calls to the Neo4j TX API which apparently are ignored. What's the rationale behind that? Wouldn't it make more sense to raise an exception, similar to when EntityManager#getTransaction() is invoked for a JTA entity manager? In the CMT case, did you consider to inject the Neo4j Session instead of Driver into the bean, again akin to injection of JTA entity managers? All in all, I'm wondering whether things couldn't be handled analogous to the usage of entity managers: * For a JTA-enabled NoSQL persistence unit, obtain the Session via injection (its lifecycle is controlled by the container and bound to the managed transaction), any manual interaction with the Neo4j TX API is forbidden, instead the container manages transactions or the user is (via UserTransaction) * For a non-JTA-enabled NoSQL persistence unit, obtain the Driver via injection, and the user is in charge of Session lifecycle and transaction control I hope that'd make sense for actually transactional stores such as Neo4j, for non-TX stores such as MongoDB thinks look different. --Gunnar 2016-07-13 16:25 GMT+01:00 Scott Marlow : > > > On 07/13/2016 10:44 AM, Jesper Pedersen wrote: > > On 07/12/2016 11:36 AM, Scott Marlow wrote: > >>> As you are enlisting the Neo4J resources into the transaction, I think > >>> that you should define driver.session() as the enlistment barrier, and > >>> therefore also close the session in afterCompletion. > >> > >> I pushed an update [1] that includes auto closing the session, when the > >> transaction ends. > >> > >> I didn't add a Synchronization yet, to handle closing the session when > >> the transaction manager doesn't call XAResourceWrapper.commit/rollback. > >> I agree that will introduce an extra layer of safety to ensure that > >> resources are closed. > >> > > > > I think you can use the XAResource instance for that at the moment. > > Yes, we are doing this currently. > > > > >>> > >>> That makes it more clear in what scenarios the resources are managed. > >>> > >>> In JDBC you inject the DataSource instance, and obtain a Connection, so > >>> it would be parallel to this case Driver vs. Session. > >>> > >>> This means that people needs to be more careful in the BMT case to get > >>> the Session within an active transaction. JCA has > >>> CachedConnectionManager to verify these cases, so you could add a > >>> similar concept. > >> > >> Attempts to call Neo4j transaction/session "close", within the JTA > >> transaction are ignored. How about calls to "close" after the JTA > >> transaction ends, should they also be ignored? > > > > Hopefully the underlying implementation will ignore multiple close() > > calls, and throw an exception on any other call. > > isOpen is currently returning false instead of throwing an exception. > We are ignoring multiple close() calls and do throw an exception on any > other call. > > > > > You will have to test the behaviour of each NoSQL store. > > > >> Is there a JCA > >> equivalent of ignoring "close" after the transaction ends? I think that > >> Hibernate ORM is or was, closing DataSource's after the transaction > >> ends, so I assume that JCA ignores "close" after the JTA transaction > >> ends. > >> > > > > You probably mean Connection.close() -- if all connections are closed in > > afterCompletion then the connection is returned to the pool. Otherwise, > > it waits until ref count becomes 0, e.g. c.close() after the transaction > > has ended. > > > > http://www.ironjacamar.org/doc/roadto12/txtracking.html > > > > Best regards, > > Jesper > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160713/b6b2794e/attachment.html From emmanuel at hibernate.org Wed Jul 13 13:39:31 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 13 Jul 2016 19:39:31 +0200 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> Message-ID: <76C2442B-0D1F-43AD-A25A-C5B111813181@hibernate.org> I haven't looked in detail but +1 to what Gunnar says. I would add that the WF Neo4j confuguration should have an option to either treat Neo4j as a JTA enlisted source or not. In the former, the behavior would be as Gunnar suggests. In the latter, direct Neo4j session creation and transaction would be used. > On 13 juil. 2016, at 19:16, Gunnar Morling wrote: > > Hi Scott, > > I had a short look at the tests you pointed to; in the one using BMT, why is it that the UserTransaction *and* the Neo4j TX API are used? I'd have expected it to be only one *or* the other? > > In the one using CMT, there are also calls to the Neo4j TX API which apparently are ignored. What's the rationale behind that? Wouldn't it make more sense to raise an exception, similar to when EntityManager#getTransaction() is invoked for a JTA entity manager? > > In the CMT case, did you consider to inject the Neo4j Session instead of Driver into the bean, again akin to injection of JTA entity managers? > > All in all, I'm wondering whether things couldn't be handled analogous to the usage of entity managers: > > * For a JTA-enabled NoSQL persistence unit, obtain the Session via injection (its lifecycle is controlled by the container and bound to the managed transaction), any manual interaction with the Neo4j TX API is forbidden, instead the container manages transactions or the user is (via UserTransaction) > * For a non-JTA-enabled NoSQL persistence unit, obtain the Driver via injection, and the user is in charge of Session lifecycle and transaction control > > I hope that'd make sense for actually transactional stores such as Neo4j, for non-TX stores such as MongoDB thinks look different. > > --Gunnar > > > > 2016-07-13 16:25 GMT+01:00 Scott Marlow : >> >> >> On 07/13/2016 10:44 AM, Jesper Pedersen wrote: >> > On 07/12/2016 11:36 AM, Scott Marlow wrote: >> >>> As you are enlisting the Neo4J resources into the transaction, I think >> >>> that you should define driver.session() as the enlistment barrier, and >> >>> therefore also close the session in afterCompletion. >> >> >> >> I pushed an update [1] that includes auto closing the session, when the >> >> transaction ends. >> >> >> >> I didn't add a Synchronization yet, to handle closing the session when >> >> the transaction manager doesn't call XAResourceWrapper.commit/rollback. >> >> I agree that will introduce an extra layer of safety to ensure that >> >> resources are closed. >> >> >> > >> > I think you can use the XAResource instance for that at the moment. >> >> Yes, we are doing this currently. >> >> > >> >>> >> >>> That makes it more clear in what scenarios the resources are managed. >> >>> >> >>> In JDBC you inject the DataSource instance, and obtain a Connection, so >> >>> it would be parallel to this case Driver vs. Session. >> >>> >> >>> This means that people needs to be more careful in the BMT case to get >> >>> the Session within an active transaction. JCA has >> >>> CachedConnectionManager to verify these cases, so you could add a >> >>> similar concept. >> >> >> >> Attempts to call Neo4j transaction/session "close", within the JTA >> >> transaction are ignored. How about calls to "close" after the JTA >> >> transaction ends, should they also be ignored? >> > >> > Hopefully the underlying implementation will ignore multiple close() >> > calls, and throw an exception on any other call. >> >> isOpen is currently returning false instead of throwing an exception. >> We are ignoring multiple close() calls and do throw an exception on any >> other call. >> >> > >> > You will have to test the behaviour of each NoSQL store. >> > >> >> Is there a JCA >> >> equivalent of ignoring "close" after the transaction ends? I think that >> >> Hibernate ORM is or was, closing DataSource's after the transaction >> >> ends, so I assume that JCA ignores "close" after the JTA transaction >> >> ends. >> >> >> > >> > You probably mean Connection.close() -- if all connections are closed in >> > afterCompletion then the connection is returned to the pool. Otherwise, >> > it waits until ref count becomes 0, e.g. c.close() after the transaction >> > has ended. >> > >> > http://www.ironjacamar.org/doc/roadto12/txtracking.html >> > >> > Best regards, >> > Jesper >> > >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160713/2b0e17a9/attachment.html From smarlow at redhat.com Wed Jul 13 15:05:45 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 13 Jul 2016 15:05:45 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> Message-ID: <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> Hi Gunnar/Emmanuel, The Ne04j profile can either be "transaction=1pc" (JTA transaction enlisted) or "transaction=none" (will not be enlisted into JTA transaction). I think this covers what Emmanuel suggested (I didn't get Emmanuel's email yet for some unknown reason). It sounds like we aren't yet connecting on what the WF Neo4j profile is doing, so I'll respond below and we can continue from there. :) On 07/13/2016 01:16 PM, Gunnar Morling wrote: > Hi Scott, > > I had a short look at the tests you pointed to; in the one using BMT, > why is it that the UserTransaction *and* the Neo4j TX API are used? I'd > have expected it to be only one *or* the other? With both container managed transactions and bean managed transactions (BMT), a JTA transaction is in control of the transaction. With BMT, UserTransaction is used by the application code to start/end the transaction. In either case (BMT or CMT), the Neo4j TX API is controlled by the JTA transaction. If there isn't an active JTA transaction, the Ne04j TX API is in control of the Neo4j transaction. With one caveat, that the Ne04j transaction should be ended by the application code, before entering into a JTA transaction (since it won't be joined into the JTA transaction). Users can also disable the JTA transaction enlistment by using a NoSQL profile with "transaction=none", instead of "transaction=1pc". > > In the one using CMT, there are also calls to the Neo4j TX API which > apparently are ignored. With CMT + BMT, the JTA transaction is in control, when the JTA transaction ends, the Neo4j transaction ends as well and not before then. If the application calls the Neo4j TX API, our TXProxy ignores calls to TX.success/failure/close, other calls are passed through to the underlying Neo4j Transaction object (e.g. run(String statement)), since that is where the work actually occurs. When the JTA transaction commits, the underlying Neo4j tx.success() + tx.close() are called. If the JTA transaction rolls back, the underlying Neo4j tx.failure() + tx.close() are called. > What's the rationale behind that? To enlist the Neo4j transaction into the JTA transaction via a one phase wrapper. > Wouldn't it > make more sense to raise an exception, similar to when > EntityManager#getTransaction() is invoked for a JTA entity manager? If the NoSQL profile is JTA enabled, it should be enlisted into the JTA transaction, allowing the application to control all of the database operations that occur within the JTA transaction. We also have the equivalent of JPA RESOURCE_LOCAL, via NoSQL profiles that are not JTA enabled ("transaction=none" in the profile definition). > > In the CMT case, did you consider to inject the Neo4j Session instead of > Driver into the bean, again akin to injection of JTA entity managers? It is possible that we could also look at TransactionScoped injection of sessions, but not sure yet. We started with (RequestScoped) Session injection but commented that out [1] when we added JTA enlistment. TransactionScoped injection of Sessions could be yet another way to write CMT/BMT code. > > All in all, I'm wondering whether things couldn't be handled analogous > to the usage of entity managers: > > * For a JTA-enabled NoSQL persistence unit, obtain the Session via > injection (its lifecycle is controlled by the container and bound to the > managed transaction), any manual interaction with the Neo4j TX API is > forbidden, instead the container manages transactions or the user is > (via UserTransaction) > * For a non-JTA-enabled NoSQL persistence unit, obtain the Driver via > injection, and the user is in charge of Session lifecycle and > transaction control Well, you haven't yet seen the above responses yet, I think the TransactionScoped Session injection idea is good but also introduces a different way to write CMT/BMT code for Ne04j. I disagree on making the current (WF NoSQL/Ne04j TX enlistment) approach illegal, as I don't yet see a problem with the current approach. Are there difficulties with Hibernate OGM that you anticipate with either approach of JTA TX enlistment for Neo4j? > > I hope that'd make sense for actually transactional stores such as > Neo4j, for non-TX stores such as MongoDB thinks look different. Agreed, for MongoDB, we treat that as "transaction=none", meaning no JTA transaction enlistment for MongoDB. > > --Gunnar > Scott [1] https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/neo4j/src/main/java/org/wildfly/extension/nosql/cdi/Neo4jExtension.java#L172 From brian.stansberry at redhat.com Thu Jul 14 10:41:48 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 14 Jul 2016 09:41:48 -0500 Subject: [wildfly-dev] Reading Mgt Model from a Servlet In-Reply-To: References: <5564DCDC.4070405@redhat.com> <5564F115.3010900@redhat.com> Message-ID: So you want to invoke a :read-attribute management op from a servlet initializer? That shouldn?t deadlock, as it?s a read that won?t need the exclusive management lock that the thread controlling the deploy controls. It won?t see the correct value at boot though, or in any composite op (e.g. CLI batch) where the attribute you are reading has been modified in the same overall op as the deploy step. That change is not visible to other threads until the op that made it commits. And it won?t commit until deploy completes. > On May 28, 2015, at 5:37 AM, Toma? Cerar wrote: > > > On Wed, May 27, 2015 at 12:17 AM, Stan Silvert > wrote: > Thanks. I just need the servlet to read a flag that I put into the > owner attribute of the deployment. So I should be OK. > > Incidentally, I find that this is something I run into once in awhile. > I need a subsystem to communicate with a deployment's application code. > The other way I've done this is to stuff things into the ServletContext > using a DeploymentUnitProcessor and the JBossWebMetaData. > > If anyone knows a third option I'd love to hear it. > > > The DPU with extra jbossmetadata sounds a reasonable way to do this. > > you could even go further and provide this data only to your servlet instead whole ServletContext > > but if all you need is to pass one attribute around, no need to complicate it more. > > -- > tomaz > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160714/035e7dbf/attachment.html From ssilvert at redhat.com Thu Jul 14 10:26:50 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 14 Jul 2016 10:26:50 -0400 Subject: [wildfly-dev] Reading Mgt Model from a Servlet In-Reply-To: References: <5564DCDC.4070405@redhat.com> Message-ID: <5787A12A.5030204@redhat.com> So now I need to do this from the Keycloak Server WAR. If I assume that my Keycloak WAR is the only application running on WildFly, can I safely use Mazzitelli's approach? I need to read and write the management model from Keycloak. On 5/26/2015 5:51 PM, Jason Greene wrote: > Nope. Although I would use newCachedThreadPool instead, as the fixed thread pool of 5 is just wasteful. > > Keep in mind this API is not something we encourage people to use from deployments, as any management op that acquires a write lock (some sort of modification), will deadlock the server if it used in the initialization path of a deployment. For this reason, we don?t publish it via any simple means >> On May 26, 2015, at 3:51 PM, Stan Silvert wrote: >> >> Some time ago, John Mazzitelli wrote a blog on how to get a local >> ModelControllerClient from within a servlet. >> http://management-platform.blogspot.com/2012/07/co-located-management-client-for.html >> >> Is there an easier way to do it these days? >> >> I need to read the attributes under /deployment=mydeployment.war/. Is >> there an easier way to do that from the WAR than using a >> ModelControllerClient? >> >> Thanks, >> >> Stan >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > From brian.stansberry at redhat.com Thu Jul 14 11:08:28 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 14 Jul 2016 10:08:28 -0500 Subject: [wildfly-dev] Reading Mgt Model from a Servlet In-Reply-To: References: <5564DCDC.4070405@redhat.com> <5564F115.3010900@redhat.com> Message-ID: <0010A6CD-C548-48A4-AB8A-24F4B4F9E8F3@redhat.com> The DUP approach you mention may be best anyway. If we add a mechanism to do an async read of the model held by an uncommitted op, the hook to let your initializer do that will very likely involve a DUP passing in some object anyway. To avoid that there would need to be some ?read uncommitted? API added to ModelController that anyone could use. > On Jul 14, 2016, at 9:41 AM, Brian Stansberry wrote: > > So you want to invoke a :read-attribute management op from a servlet initializer? > > That shouldn?t deadlock, as it?s a read that won?t need the exclusive management lock that the thread controlling the deploy controls. > > It won?t see the correct value at boot though, or in any composite op (e.g. CLI batch) where the attribute you are reading has been modified in the same overall op as the deploy step. That change is not visible to other threads until the op that made it commits. And it won?t commit until deploy completes. > >> On May 28, 2015, at 5:37 AM, Toma? Cerar > wrote: >> >> >> On Wed, May 27, 2015 at 12:17 AM, Stan Silvert > wrote: >> Thanks. I just need the servlet to read a flag that I put into the >> owner attribute of the deployment. So I should be OK. >> >> Incidentally, I find that this is something I run into once in awhile. >> I need a subsystem to communicate with a deployment's application code. >> The other way I've done this is to stuff things into the ServletContext >> using a DeploymentUnitProcessor and the JBossWebMetaData. >> >> If anyone knows a third option I'd love to hear it. >> >> >> The DPU with extra jbossmetadata sounds a reasonable way to do this. >> >> you could even go further and provide this data only to your servlet instead whole ServletContext >> >> but if all you need is to pass one attribute around, no need to complicate it more. >> >> -- >> tomaz >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160714/98582924/attachment.html From elielmsouza at gmail.com Fri Jul 15 17:50:55 2016 From: elielmsouza at gmail.com (Eliel) Date: Fri, 15 Jul 2016 18:50:55 -0300 Subject: [wildfly-dev] Unicast (TCPPING) HA Full wildFly 10.0.0. Message-ID: Hi everyone, I believe this is not the right forum, but how do I set tcpping (jgroups) in wildfly-10.0.0 HA FULL (standalone-full-ha.xml). If someone can help thank you. PS .: My network does not accept multicast Thanks Eliel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160715/45f5e77b/attachment-0001.html From amostech at gmail.com Fri Jul 15 17:59:57 2016 From: amostech at gmail.com (Arthur Morales Sampaio) Date: Fri, 15 Jul 2016 21:59:57 +0000 Subject: [wildfly-dev] Unicast (TCPPING) HA Full wildFly 10.0.0. In-Reply-To: References: Message-ID: Hi man, I havent done this with Wildfly 10 yet, but I figured this hasnt changed very much since JBoss 7.2 so take a look at this discussion. Maybe this can help you out. https://developer.jboss.org/message/959921 On Fri, Jul 15, 2016 at 6:53 PM Eliel wrote: > Hi everyone, > I believe this is not the right forum, but how do I set tcpping (jgroups) > in wildfly-10.0.0 HA FULL (standalone-full-ha.xml). > If someone can help thank you. > > PS .: My network does not accept multicast > > Thanks > > Eliel > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160715/30db71bc/attachment.html From paul.ferraro at redhat.com Sun Jul 17 09:03:27 2016 From: paul.ferraro at redhat.com (Paul Ferraro) Date: Sun, 17 Jul 2016 09:03:27 -0400 Subject: [wildfly-dev] Unicast (TCPPING) HA Full wildFly 10.0.0. In-Reply-To: References: Message-ID: On Fri, Jul 15, 2016 at 5:50 PM, Eliel wrote: > Hi everyone, > I believe this is not the right forum You are correct. Please use: https://developer.jboss.org/en/wildfly , but how do I set tcpping (jgroups) in > wildfly-10.0.0 HA FULL (standalone-full-ha.xml). > If someone can help thank you. > > PS .: My network does not accept multicast > > Thanks > > Eliel > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From emmanuel at hibernate.org Mon Jul 18 09:24:00 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 18 Jul 2016 15:24:00 +0200 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> References: <5731F8E5.7030609@redhat.com> <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> Message-ID: <20160718132400.GH69003@hibernate.org> I'm lost. What is the expected code a developer will write ? If that' something along the lines of: jta.beginTx() // declaratively or imperatively neo4j.beginTx() ... neo4j.commit() jta.commit() //declaratively or imperatively then I find it very user unfriendly to force the code to call both Tx APIs. It should be one or the other. On Wed 2016-07-13 15:05, Scott Marlow wrote: > Hi Gunnar/Emmanuel, > > The Ne04j profile can either be "transaction=1pc" (JTA transaction enlisted) > or "transaction=none" (will not be enlisted into JTA transaction). I think > this covers what Emmanuel suggested (I didn't get Emmanuel's email yet for > some unknown reason). > > It sounds like we aren't yet connecting on what the WF Neo4j profile is > doing, so I'll respond below and we can continue from there. :) > > On 07/13/2016 01:16 PM, Gunnar Morling wrote: > > Hi Scott, > > > > I had a short look at the tests you pointed to; in the one using BMT, > > why is it that the UserTransaction *and* the Neo4j TX API are used? I'd > > have expected it to be only one *or* the other? > > With both container managed transactions and bean managed transactions > (BMT), a JTA transaction is in control of the transaction. With BMT, > UserTransaction is used by the application code to start/end the > transaction. In either case (BMT or CMT), the Neo4j TX API is controlled by > the JTA transaction. > > If there isn't an active JTA transaction, the Ne04j TX API is in control of > the Neo4j transaction. With one caveat, that the Ne04j transaction should > be ended by the application code, before entering into a JTA transaction > (since it won't be joined into the JTA transaction). > > Users can also disable the JTA transaction enlistment by using a NoSQL > profile with "transaction=none", instead of "transaction=1pc". > > > > > In the one using CMT, there are also calls to the Neo4j TX API which > > apparently are ignored. > > With CMT + BMT, the JTA transaction is in control, when the JTA transaction > ends, the Neo4j transaction ends as well and not before then. If the > application calls the Neo4j TX API, our TXProxy ignores calls to > TX.success/failure/close, other calls are passed through to the underlying > Neo4j Transaction object (e.g. run(String statement)), since that is where > the work actually occurs. > > When the JTA transaction commits, the underlying Neo4j tx.success() + > tx.close() are called. If the JTA transaction rolls back, the underlying > Neo4j tx.failure() + tx.close() are called. > > > What's the rationale behind that? > > To enlist the Neo4j transaction into the JTA transaction via a one phase > wrapper. > > > Wouldn't it > > make more sense to raise an exception, similar to when > > EntityManager#getTransaction() is invoked for a JTA entity manager? > > If the NoSQL profile is JTA enabled, it should be enlisted into the JTA > transaction, allowing the application to control all of the database > operations that occur within the JTA transaction. > > We also have the equivalent of JPA RESOURCE_LOCAL, via NoSQL profiles that > are not JTA enabled ("transaction=none" in the profile definition). > > > > > In the CMT case, did you consider to inject the Neo4j Session instead of > > Driver into the bean, again akin to injection of JTA entity managers? > > It is possible that we could also look at TransactionScoped injection of > sessions, but not sure yet. We started with (RequestScoped) Session > injection but commented that out [1] when we added JTA enlistment. > TransactionScoped injection of Sessions could be yet another way to write > CMT/BMT code. > > > > > All in all, I'm wondering whether things couldn't be handled analogous > > to the usage of entity managers: > > > > * For a JTA-enabled NoSQL persistence unit, obtain the Session via > > injection (its lifecycle is controlled by the container and bound to the > > managed transaction), any manual interaction with the Neo4j TX API is > > forbidden, instead the container manages transactions or the user is > > (via UserTransaction) > > * For a non-JTA-enabled NoSQL persistence unit, obtain the Driver via > > injection, and the user is in charge of Session lifecycle and > > transaction control > > Well, you haven't yet seen the above responses yet, I think the > TransactionScoped Session injection idea is good but also introduces a > different way to write CMT/BMT code for Ne04j. I disagree on making the > current (WF NoSQL/Ne04j TX enlistment) approach illegal, as I don't yet see > a problem with the current approach. > > Are there difficulties with Hibernate OGM that you anticipate with either > approach of JTA TX enlistment for Neo4j? > > > > > I hope that'd make sense for actually transactional stores such as > > Neo4j, for non-TX stores such as MongoDB thinks look different. > > Agreed, for MongoDB, we treat that as "transaction=none", meaning no JTA > transaction enlistment for MongoDB. > > > > > --Gunnar > > > > Scott > > [1] https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/neo4j/src/main/java/org/wildfly/extension/nosql/cdi/Neo4jExtension.java#L172 From smarlow at redhat.com Mon Jul 18 12:20:15 2016 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 18 Jul 2016 12:20:15 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <20160718132400.GH69003@hibernate.org> References: <5731F8E5.7030609@redhat.com> <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> Message-ID: <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> Thanks for the feedback. On 07/18/2016 09:24 AM, Emmanuel Bernard wrote: > I'm lost. > > What is the expected code a developer will write ? > > If that' something along the lines of: > > jta.beginTx() // declaratively or imperatively > neo4j.beginTx() > ... > neo4j.commit() > jta.commit() //declaratively or imperatively They are not limited to writing the above code. In addition, the developer can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like: jta.beginTx() // declaratively or imperatively session = driver.session() // internally does session.beginTransaction() ... jta.commit() //declaratively or imperatively The calls to neo4j.beginTx()/commit() are ignored. The choice of ignoring those calls, is made against the alternative of throwing an exception. The reason for ignoring the neo4j transactional calls, is to be more compatible with existing ne04j code that may be using the neo4j transactional code, with the goal that the JTA transaction controls the underlying ne04j transaction. Neo4j transactional code also runs the statements against the neo4j transaction class, instead of the neo4j session class. > > then I find it very user unfriendly to force the code to call both Tx > APIs. It should be one or the other. Do you really want to rewrite your neo4j code to avoid the neo4j tx APIs when enlisted into a JTA transaction? Or should the neo4j tx API calls be ignored when enlisted into a JTA transaction (as we are doing now)? If we throw exceptions from Transaction.run(), developers may have to rewrite more code for use with JTA. If this is still confusing, we can have a call to discuss. :) Scott From smarlow at redhat.com Mon Jul 18 13:53:56 2016 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 18 Jul 2016 13:53:56 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> References: <5731F8E5.7030609@redhat.com> <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> Message-ID: <88875f0b-71a5-b56a-4b36-eb5ec58a3246@redhat.com> > > The choice of ignoring those calls, is made against the alternative of > throwing an exception. The reason for ignoring the neo4j transactional > calls, is to be more compatible with existing ne04j code that may be > using the neo4j transactional code, with the goal that the JTA > transaction controls the underlying ne04j transaction. Neo4j > transactional code also runs the statements against the neo4j > transaction class, instead of the neo4j session class. > In a JTA transaction, instead of ignoring calls to org.neo4j.driver.v1.Transaction.failure(), we could call setRollbackOnly() on the JTA transaction. So, the existing neo4j code can influence a JTA rollback. IMO, this would improve our compatibility with existing neo4j. In our neo4j XAResource wrapper, we handle commit() by calling neo4j Transaction.success(). We handle rollback() by calling neo4j Transaction.failure(). For both cases, we call Transaction.close(). Scott From emmanuel at hibernate.org Tue Jul 19 04:17:43 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 19 Jul 2016 10:17:43 +0200 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> Message-ID: <20160719081743.GK69003@hibernate.org> On Mon 2016-07-18 12:20, Scott Marlow wrote: > Thanks for the feedback. > > On 07/18/2016 09:24 AM, Emmanuel Bernard wrote: > > I'm lost. > > > > What is the expected code a developer will write ? > > > > If that' something along the lines of: > > > > jta.beginTx() // declaratively or imperatively > > neo4j.beginTx() > > ... > > neo4j.commit() > > jta.commit() //declaratively or imperatively > > They are not limited to writing the above code. In addition, the developer > can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like: > > jta.beginTx() // declaratively or imperatively > session = driver.session() // internally does session.beginTransaction() > ... > jta.commit() //declaratively or imperatively > > The calls to neo4j.beginTx()/commit() are ignored. > > The choice of ignoring those calls, is made against the alternative of > throwing an exception. The reason for ignoring the neo4j transactional > calls, is to be more compatible with existing ne04j code that may be using > the neo4j transactional code, with the goal that the JTA transaction > controls the underlying ne04j transaction. Neo4j transactional code also > runs the statements against the neo4j transaction class, instead of the > neo4j session class. You mean having existing code work with the new JTA transaction net? I don't think you can safely support that. What if the code does @Transactional public void doThings() { session = drive.session(); session.beginTransaction(); try { // do things catch (Exception e) { // swallow exception because we will fix things session.rollback(); session.beginTransaction(); // do something else session.commit(); } } Such an existing code won't work if JTA in involved and session.beginTrnasaction() / commit() are ignored. So only code written with the idea of the JTA net in mind will be safe. > > > > then I find it very user unfriendly to force the code to call both Tx > > APIs. It should be one or the other. > > Do you really want to rewrite your neo4j code to avoid the neo4j tx APIs > when enlisted into a JTA transaction? Or should the neo4j tx API calls be > ignored when enlisted into a JTA transaction (as we are doing now)? See my above example of already existing code. For new code that you want to run both in SE and Wildfly, that's an interesting question but how would you do it in practice? A try catch but rethrowing the exception in case JTA is involved and needs to be notified of the tx rollback? I'm interested to see concrete code because if doable, it will have lots of constraints and be limited to very specific patterns of code I think. But again, let's show each other code. Emmanuel From emmanuel at hibernate.org Tue Jul 19 04:22:30 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 19 Jul 2016 10:22:30 +0200 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <88875f0b-71a5-b56a-4b36-eb5ec58a3246@redhat.com> References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <88875f0b-71a5-b56a-4b36-eb5ec58a3246@redhat.com> Message-ID: <20160719082230.GL69003@hibernate.org> On Mon 2016-07-18 13:53, Scott Marlow wrote: > > > > The choice of ignoring those calls, is made against the alternative of > > throwing an exception. The reason for ignoring the neo4j transactional > > calls, is to be more compatible with existing ne04j code that may be > > using the neo4j transactional code, with the goal that the JTA > > transaction controls the underlying ne04j transaction. Neo4j > > transactional code also runs the statements against the neo4j > > transaction class, instead of the neo4j session class. > > > > In a JTA transaction, instead of ignoring calls to > org.neo4j.driver.v1.Transaction.failure(), we could call setRollbackOnly() > on the JTA transaction. So, the existing neo4j code can influence a JTA > rollback. IMO, this would improve our compatibility with existing neo4j. Yes that is an improvement but I don't think it would help in the example I showed in my previous email. The big question is do we want to offer something that works sometimes, or do we want to offer something that does not work but is explicit about it? From smarlow at redhat.com Tue Jul 19 10:49:28 2016 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 19 Jul 2016 10:49:28 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <20160719081743.GK69003@hibernate.org> References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> Message-ID: <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> On 07/19/2016 04:17 AM, Emmanuel Bernard wrote: > On Mon 2016-07-18 12:20, Scott Marlow wrote: >> Thanks for the feedback. >> >> On 07/18/2016 09:24 AM, Emmanuel Bernard wrote: >>> I'm lost. >>> >>> What is the expected code a developer will write ? >>> >>> If that' something along the lines of: >>> >>> jta.beginTx() // declaratively or imperatively >>> neo4j.beginTx() >>> ... >>> neo4j.commit() >>> jta.commit() //declaratively or imperatively >> >> They are not limited to writing the above code. In addition, the developer >> can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like: >> >> jta.beginTx() // declaratively or imperatively >> session = driver.session() // internally does session.beginTransaction() >> ... >> jta.commit() //declaratively or imperatively >> >> The calls to neo4j.beginTx()/commit() are ignored. >> >> The choice of ignoring those calls, is made against the alternative of >> throwing an exception. The reason for ignoring the neo4j transactional >> calls, is to be more compatible with existing ne04j code that may be using >> the neo4j transactional code, with the goal that the JTA transaction >> controls the underlying ne04j transaction. Neo4j transactional code also >> runs the statements against the neo4j transaction class, instead of the >> neo4j session class. > > You mean having existing code work with the new JTA transaction net? > I don't think you can safely support that. What if the code does > > @Transactional > public void doThings() { > session = drive.session(); > session.beginTransaction(); // should be: Transaction transaction = session.beginTransaction(); > try { > // do things > catch (Exception e) { > // swallow exception because we will fix things > session.rollback(); // should be: transaction.failure(); > session.beginTransaction(); transaction = session.beginTransaction(); > // do something else > session.commit(); > } > } > > Such an existing code won't work if JTA in involved and > session.beginTrnasaction() / commit() are ignored. With the current prototype, the above existing code won't work as originally intended (with regard to what the original developer had in mind) with JTA enlistment. > > So only code written with the idea of the JTA net in mind will be safe. Clearly, any existing neo4j code that expects to fail the current neo4j transaction, then start a new neo4j transaction to fix things, will not work in the JTA net. As the fixing of things in the JTA net, needs to occur before marking the JTA transaction for rollback only *or* by fixing things after the JTA transaction rolls back. Are there any other holes that come to mind, with regard to existing neo4j transaction code that won't work as original intended in the JTA net? > >>> >>> then I find it very user unfriendly to force the code to call both Tx >>> APIs. It should be one or the other. >> >> Do you really want to rewrite your neo4j code to avoid the neo4j tx APIs >> when enlisted into a JTA transaction? Or should the neo4j tx API calls be >> ignored when enlisted into a JTA transaction (as we are doing now)? > > See my above example of already existing code. > > For new code that you want to run both in SE and Wildfly, that's an > interesting question but how would you do it in practice? A try catch > but rethrowing the exception in case JTA is involved and needs to be > notified of the tx rollback? The developer could rewrite their "workaround tx failure" code to avoid further calls to the neo4j tx api, but this is kind of bad as they only should do this when the neo4j transaction is enlisted into the JTA transaction, but not when enlistment is disabled. Some neo4j connection profiles will be configured to allow JTA enlistment (transaction=1pc) and some will be configured to not allow JTA enlistment (transaction=none), so we can expect common application code will likely be reused for both JTA + non-JTA. Seems to me that SE is always the same as the WildFly neo4j connection profile with "transaction=none", so we have the same problem with SE + WildFly, trying to run the same user code that is expected to work with JTA enlistment (neo4j connection profile has "transaction=1pc"). I don't know of any CDI magic that helps, as if we add support for inject of a javax.transaction.TransactionScoped neo4j session, that works the same as a session obtained from Driver.session(). > I'm interested to see concrete code because if doable, it will have lots > of constraints and be limited to very specific patterns of code I think. > But again, let's show each other code. That should help us explore the compatibility with existing code idea and pick which approach to use (e.g. whether explicit neo4j transaction use in a JTA enlisted transaction should throw an exception or ignore the explicit transaction use as we are doing now in the prototype). Should we also post on https://groups.google.com/forum/#!forum/neo4j to ask for input on JTA enlistment? > > Emmanuel > From tcrawley at redhat.com Tue Jul 19 13:29:36 2016 From: tcrawley at redhat.com (Toby Crawley) Date: Tue, 19 Jul 2016 13:29:36 -0400 Subject: [wildfly-dev] Pretty-printing XML validation errors Message-ID: I've done some work to pretty-print XML validation errors that occur when parsing (standalone|domain|host).xml, and wanted to get some feedback on what I have so far to see if: 1) there is interest in seeing this completed 2) the current approach is the best way to integrate with WildFly 3) this same approach could be used to pretty-print issues with other xml parsed by WildFly (web.xml, jboss-deployment-structure.xml, etc) # Background Inspired by error reporting in the Elm language[1] and improvements in configuration feedback for Clojure tooling[2], I looked at what it would take to provide better feedback when parsing XML configuration. My goals were: * Give users clear feedback that can be used to correct the configuration error without the user having to context-switch to documentation, and, in most cases, enable the user to quickly identify and understand the issue before looking away from the validation output, by: * Showing (instead of telling) where in the XML the error occurred * Providing richer feedback than the native validation error provides (detect potential misspellings, provide alternate locations, etc) * Showing documentation for the element/attribute where possible (pulled from the XSD) * Use what we already produce (XSDs), without having to create additional context-specific schema. I've partially implemented a library (vdx)[3] that, given a validation error, the source document, and the relevant schemas, generates and prints a friendly error message. I've also made minimal changes to WildFly to report validation errors to vdx (see below). # Examples Below is some examples of the current startup output from WildFly when a validation error occurs: ## Detecting a misspelled attribute 13:18:03,798 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final 13:18:03,949 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final 13:18:04,010 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.2.0.CR5-SNAPSHOT "Kenny" starting 13:18:04,751 ERROR [org.jboss.as.controller] (Controller Boot Thread) ====================== Validation Error in standalone.xml ====================== 28: 29: 30: ^ 'modue' isn't an allowed attribute for the 'extension' element 31: 32: 33: Did you mean 'module'? ================================================================================ 13:18:04,753 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:175) at org.jboss.as.server.ServerService.boot(ServerService.java:357) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) at java.lang.Thread.run(Thread.java:745) 13:18:04,754 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. 13:18:04,762 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Core 2.2.0.CR5-SNAPSHOT "Kenny" stopped in 4ms ## Detecting a misplaced attribute ... 14:32:23,842 ERROR [org.jboss.as.controller] (Controller Boot Thread) ====================== Validation Error in standalone.xml ====================== 89: 90: ^ 'category' isn't an allowed attribute for the 'periodic-rotating-file-handler' element 92: 93: 94: 'category' is allowed on elements: subsystem > logger, subsystem > logging-profiles > logging-profile > logger Did you intend to put it on one of those elements? ================================================================================ ... ## Detecting a misplaced element ... 10:54:27,359 ERROR [org.jboss.as.controller] (Controller Boot Thread) ====================== Validation Error in standalone.xml ====================== 81: 82: 83: ^ 'extension' isn't an allowed element here 84: 85: 86: 'extension' is allowed in elements: domain > extensions, domain > host-excludes > host-exclude > excluded-extensions, host > extensions, host > servers > server > extensions, server > extensions Did you intend to put it in one of those elements? ================================================================================ ... # Changes to WildFly To support this, I've made some small changes changes to wildfly-core[4], but anticipate more before this is complete. The current changes are: * Modifications to ParseUtils to wrap the XMLStreamExceptions with an exception that can convey more context to vdx * Modifications to XmlConfigurationPersistor to: * catch the wrapped exception * see if ${jboss.home.dir}/docs/schema/ is available. If so, pretty-print the error. If not, throw the wrapped exception (which is the behavior before my changes). # Current issues * Only the first validation issue is reported, but this is unavoidable, since the subsystem parsers throw on the first error encountered * This uses xmlschema-walker from Apache XmlSchema[5], which has a couple of bugs that will need to be fixed and released (or forked) * Only errors reported by throwing Exceptions returned by ParseUtils are pretty-printed. Exceptions that come from within STAX reader aren't yet handled (for example, a misplaced element in the logging parser causes reader.handleAny() to be called[6], which triggers an unwrapped exception) * vdx itself is far from complete[7] - that work is pending the outcome of this discussion # Next steps As I said above, the first question to answer is: is this an interesting feature that you would like to see completed? If so, I'm willing to continue working on this, and would be happy to discuss here or on JIRA/HipChat as appropriate. [1]: http://elm-lang.org/blog/compilers-as-assistants [2]: http://rigsomelight.com/2016/05/17/good-configuration-feedback-is-essential.html [3]: https://github.com/projectodd/vdx [4]: https://github.com/tobias/wildfly-core/commit/b4d03897a6ea1b8c786d983da3b66eab0b3f36b8 [5]: https://ws.apache.org/xmlschema/ [6]: https://github.com/wildfly/wildfly-core/blob/2.x/logging/src/main/java/org/jboss/as/logging/LoggingSubsystemParser_3_0.java#L188 [7]: https://github.com/projectodd/vdx/issues From smarlow at redhat.com Tue Jul 19 14:36:00 2016 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 19 Jul 2016 14:36:00 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> Message-ID: On 07/19/2016 10:49 AM, Scott Marlow wrote: > > > On 07/19/2016 04:17 AM, Emmanuel Bernard wrote: >> On Mon 2016-07-18 12:20, Scott Marlow wrote: >>> Thanks for the feedback. >>> >>> On 07/18/2016 09:24 AM, Emmanuel Bernard wrote: >>>> I'm lost. >>>> >>>> What is the expected code a developer will write ? >>>> >>>> If that' something along the lines of: >>>> >>>> jta.beginTx() // declaratively or imperatively >>>> neo4j.beginTx() >>>> ... >>>> neo4j.commit() >>>> jta.commit() //declaratively or imperatively >>> >>> They are not limited to writing the above code. In addition, the developer >>> can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like: >>> >>> jta.beginTx() // declaratively or imperatively >>> session = driver.session() // internally does session.beginTransaction() >>> ... >>> jta.commit() //declaratively or imperatively >>> >>> The calls to neo4j.beginTx()/commit() are ignored. >>> >>> The choice of ignoring those calls, is made against the alternative of >>> throwing an exception. The reason for ignoring the neo4j transactional >>> calls, is to be more compatible with existing ne04j code that may be using >>> the neo4j transactional code, with the goal that the JTA transaction >>> controls the underlying ne04j transaction. Neo4j transactional code also >>> runs the statements against the neo4j transaction class, instead of the >>> neo4j session class. >> >> You mean having existing code work with the new JTA transaction net? >> I don't think you can safely support that. What if the code does >> >> @Transactional >> public void doThings() { >> session = drive.session(); >> session.beginTransaction(); > // should be: > Transaction transaction = session.beginTransaction(); >> try { >> // do things >> catch (Exception e) { >> // swallow exception because we will fix things >> session.rollback(); > // should be: > transaction.failure(); >> session.beginTransaction(); > transaction = session.beginTransaction(); >> // do something else >> session.commit(); >> } >> } >> >> Such an existing code won't work if JTA in involved and >> session.beginTrnasaction() / commit() are ignored. > > With the current prototype, the above existing code won't work as > originally intended (with regard to what the original developer had in > mind) with JTA enlistment. > >> >> So only code written with the idea of the JTA net in mind will be safe. > > Clearly, any existing neo4j code that expects to fail the current neo4j > transaction, then start a new neo4j transaction to fix things, will not > work in the JTA net. As the fixing of things in the JTA net, needs to > occur before marking the JTA transaction for rollback only *or* by > fixing things after the JTA transaction rolls back. > > Are there any other holes that come to mind, with regard to existing > neo4j transaction code that won't work as original intended in the JTA net? > >> >>>> >>>> then I find it very user unfriendly to force the code to call both Tx >>>> APIs. It should be one or the other. >>> >>> Do you really want to rewrite your neo4j code to avoid the neo4j tx APIs >>> when enlisted into a JTA transaction? Or should the neo4j tx API calls be >>> ignored when enlisted into a JTA transaction (as we are doing now)? >> >> See my above example of already existing code. >> >> For new code that you want to run both in SE and Wildfly, that's an >> interesting question but how would you do it in practice? A try catch >> but rethrowing the exception in case JTA is involved and needs to be >> notified of the tx rollback? > > The developer could rewrite their "workaround tx failure" code to avoid > further calls to the neo4j tx api, but this is kind of bad as they only > should do this when the neo4j transaction is enlisted into the JTA > transaction, but not when enlistment is disabled. Some neo4j connection > profiles will be configured to allow JTA enlistment (transaction=1pc) > and some will be configured to not allow JTA enlistment > (transaction=none), so we can expect common application code will likely > be reused for both JTA + non-JTA. Seems to me that SE is always the > same as the WildFly neo4j connection profile with "transaction=none", so > we have the same problem with SE + WildFly, trying to run the same user > code that is expected to work with JTA enlistment (neo4j connection > profile has "transaction=1pc"). > > I don't know of any CDI magic that helps, as if we add support for > inject of a javax.transaction.TransactionScoped neo4j session, that > works the same as a session obtained from Driver.session(). > >> I'm interested to see concrete code because if doable, it will have lots >> of constraints and be limited to very specific patterns of code I think. >> But again, let's show each other code. I found some examples in the Neo4j Java driver unit tests. I started a gist [1] that lists a few of the test cases that I thought were interesting for this discussion about "compatibility of existing Neo4j tx handling code in the JTA net". In actual applications, the use cases will not be so simple. Instead, we will see many different patterns mixed over several lines of application library code, however, each unit case noted is presenting a different example that would probably not run as is, when enlisted in a JTA transaction. This doesn't mean it is bad to enlist Neo4j transactions into a JTA transaction, it just means that it is bad assume that a Neo4j tx works the same when enlisted in a JTA transaction. I think that a challenge here for us, is to deduce what our rules should be when enlisting Neo4j transactions into a JTA transaction, with regard to what the application can expect and shouldn't expect. Scott [1] https://gist.github.com/scottmarlow/2779d21653e8466d85e38c1d62d4bb1e > > That should help us explore the compatibility with existing code idea > and pick which approach to use (e.g. whether explicit neo4j transaction > use in a JTA enlisted transaction should throw an exception or ignore > the explicit transaction use as we are doing now in the prototype). > > Should we also post on https://groups.google.com/forum/#!forum/neo4j to > ask for input on JTA enlistment? > >> >> Emmanuel >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Tue Jul 19 15:15:41 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 19 Jul 2016 14:15:41 -0500 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: Message-ID: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Thanks for this! The only big concern I have about this is that we?ll get this behavior for some failures but not all. And I don?t want to go down the path of trying to force every parser to work in a manner such that we consistently get this. Personally I think it?s ok to have this for only some failures. Others may disagree though and start filing bug reports, leading to demands that we fix said ?bugs?, leading to a shift of resource away from other tasks. My instinct is it?s worth it though. I?m curious what others think. I think the path you?ve followed is a good way to get a lot of benefit without being overly intrusive. A medium sized concern is this has to be robust. It can?t be producing misleading messages, as that?s worse than simply pointing to the line/col of where the mistake was. A minor concern is how big the added dependencies are. (I don?t know.) We want to keep WildFly Core small in footprint. Re: "Only the first validation issue is reported, but this is unavoidable, since the subsystem parsers throw on the first error encountered? ? I?m not bothered by that at all. We?re booting a server, not validating a document. If people are producing documents riddled with errors there are other tools to use to help with that. > On Jul 19, 2016, at 12:29 PM, Toby Crawley wrote: > > I've done some work to pretty-print XML validation errors that occur > when parsing (standalone|domain|host).xml, and wanted to get some > feedback on what I have so far to see if: > > 1) there is interest in seeing this completed > 2) the current approach is the best way to integrate with WildFly > 3) this same approach could be used to pretty-print issues with other > xml parsed by WildFly (web.xml, jboss-deployment-structure.xml, > etc) > > > # Background > > Inspired by error reporting in the Elm language[1] and improvements in > configuration feedback for Clojure tooling[2], I looked at what it > would take to provide better feedback when parsing XML configuration. > > My goals were: > > * Give users clear feedback that can be used to correct the > configuration error without the user having to context-switch to > documentation, and, in most cases, enable the user to quickly > identify and understand the issue before looking away from the > validation output, by: > > * Showing (instead of telling) where in the XML the error occurred > > * Providing richer feedback than the native validation error > provides (detect potential misspellings, provide alternate > locations, etc) > > * Showing documentation for the element/attribute where possible > (pulled from the XSD) > > * Use what we already produce (XSDs), without having to create > additional context-specific schema. > > I've partially implemented a library (vdx)[3] that, given a validation > error, the source document, and the relevant schemas, generates and > prints a friendly error message. I've also made minimal changes to > WildFly to report validation errors to vdx (see below). > > > # Examples > > Below is some examples of the current startup output from WildFly when > a validation error occurs: > > > ## Detecting a misspelled attribute > > 13:18:03,798 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final > 13:18:03,949 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 13:18:04,010 INFO [org.jboss.as] (MSC service thread 1-6) > WFLYSRV0049: WildFly Core 2.2.0.CR5-SNAPSHOT "Kenny" starting > 13:18:04,751 ERROR [org.jboss.as.controller] (Controller Boot Thread) > > ====================== Validation Error in standalone.xml ====================== > > 28: > 29: > 30: > > ^ 'modue' isn't an allowed attribute for the > 'extension' element > > 31: > 32: > 33: > > Did you mean 'module'? > > ================================================================================ > > > 13:18:04,753 ERROR [org.jboss.as.server] (Controller Boot Thread) > WFLYSRV0055: Caught exception during boot: > org.jboss.as.controller.persistence.ConfigurationPersistenceException: > WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:175) > at org.jboss.as.server.ServerService.boot(ServerService.java:357) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) > at java.lang.Thread.run(Thread.java:745) > > 13:18:04,754 FATAL [org.jboss.as.server] (Controller Boot Thread) > WFLYSRV0056: Server boot has failed in an unrecoverable manner; > exiting. See previous messages for details. > 13:18:04,762 INFO [org.jboss.as] (MSC service thread 1-3) > WFLYSRV0050: WildFly Core 2.2.0.CR5-SNAPSHOT "Kenny" stopped in 4ms > > > ## Detecting a misplaced attribute > > ... > 14:32:23,842 ERROR [org.jboss.as.controller] (Controller Boot Thread) > > ====================== Validation Error in standalone.xml ====================== > > 89: > 90: 91: category="WARN"> > > ^ 'category' isn't an > allowed attribute for the 'periodic-rotating-file-handler' element > > 92: > 93: > 94: > > 'category' is allowed on elements: subsystem > logger, subsystem > > logging-profiles > logging-profile > logger > Did you intend to put it on one of those elements? > > ================================================================================ > > ... > > > ## Detecting a misplaced element > > ... > > 10:54:27,359 ERROR [org.jboss.as.controller] (Controller Boot Thread) > > ====================== Validation Error in standalone.xml ====================== > > 81: > 82: > 83: > > ^ 'extension' isn't an allowed element here > > 84: > 85: > 86: > > 'extension' is allowed in elements: domain > extensions, domain > > host-excludes > host-exclude > excluded-extensions, host > extensions, > host > servers > server > extensions, server > extensions > Did you intend to put it in one of those elements? > > ================================================================================ > > ... > > > # Changes to WildFly > > To support this, I've made some small changes changes to > wildfly-core[4], but anticipate more before this is complete. > > The current changes are: > > * Modifications to ParseUtils to wrap the XMLStreamExceptions with > an exception that can convey more context to vdx > * Modifications to XmlConfigurationPersistor to: > * catch the wrapped exception > * see if ${jboss.home.dir}/docs/schema/ is available. If so, > pretty-print the error. If not, throw the wrapped exception > (which is the behavior before my changes). > > > # Current issues > > * Only the first validation issue is reported, but this is > unavoidable, since the subsystem parsers throw on the first error > encountered > * This uses xmlschema-walker from Apache XmlSchema[5], which has a > couple of bugs that will need to be fixed and released (or forked) > * Only errors reported by throwing Exceptions returned by ParseUtils > are pretty-printed. Exceptions that come from within STAX reader > aren't yet handled (for example, a misplaced element in the logging > parser causes reader.handleAny() to be called[6], which triggers an > unwrapped exception) > * vdx itself is far from complete[7] - that work is pending the > outcome of this discussion > > > # Next steps > > As I said above, the first question to answer is: is this an > interesting feature that you would like to see completed? If so, I'm > willing to continue working on this, and would be happy to discuss > here or on JIRA/HipChat as appropriate. > > [1]: http://elm-lang.org/blog/compilers-as-assistants > [2]: http://rigsomelight.com/2016/05/17/good-configuration-feedback-is-essential.html > [3]: https://github.com/projectodd/vdx > [4]: https://github.com/tobias/wildfly-core/commit/b4d03897a6ea1b8c786d983da3b66eab0b3f36b8 > [5]: https://ws.apache.org/xmlschema/ > [6]: https://github.com/wildfly/wildfly-core/blob/2.x/logging/src/main/java/org/jboss/as/logging/LoggingSubsystemParser_3_0.java#L188 > [7]: https://github.com/projectodd/vdx/issues > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160719/844437f5/attachment-0001.html From tcrawley at redhat.com Tue Jul 19 15:38:35 2016 From: tcrawley at redhat.com (Toby Crawley) Date: Tue, 19 Jul 2016 15:38:35 -0400 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Message-ID: On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry wrote: > The only big concern I have about this is that we?ll get this behavior for > some failures but not all. And I don?t want to go down the path of trying to > force every parser to work in a manner such that we consistently get this. > I haven't looked at it too deeply, but it may be straightforward to alter staxmapper to allow providing an exception generator that would allow catching more of the cases that the parsers miss. > Personally I think it?s ok to have this for only some failures. Others may > disagree though and start filing bug reports, leading to demands that we fix > said ?bugs?, leading to a shift of resource away from other tasks. > > My instinct is it?s worth it though. I?m curious what others think. > Adding more to the WildFly team's plate is a concern of mine as well. I'm willing to do the work to finish this feature, and to help out with any reported issues related to it in the future, but there would still be some increase in the team's workload from it. > I think the path you?ve followed is a good way to get a lot of benefit > without being overly intrusive. > > A medium sized concern is this has to be robust. It can?t be producing > misleading messages, as that?s worse than simply pointing to the line/col of > where the mistake was. > Agreed - there needs to be some confidence level that if the tool can't meet for an error, it falls back to just pointing to the line/col, printing the original message. I fact, that may be good enough for the failures that bubble out of staxmapper as well. > A minor concern is how big the added dependencies are. (I don?t know.) We > want to keep WildFly Core small in footprint. > Right now, the only dependencies vdx (31k) has are commons-lang (which is already a module in WildFly, but not core-feature-pack), xmlschema-walker (100k), and xmlschema-core (168k). For the rest of the work, I don't currently see needing any more dependencies. > Re: "Only the first validation issue is reported, but this is unavoidable, > since the subsystem parsers throw on the first error encountered? ? I?m not > bothered by that at all. We?re booting a server, not validating a document. > If people are producing documents riddled with errors there are other tools > to use to help with that. Makes sense, thanks. From hrupp at redhat.com Tue Jul 19 15:55:03 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 19 Jul 2016 21:55:03 +0200 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: Message-ID: This is awesome. I was hacking on some subsystem the other day and all I got was something like "error at char 3162", where I would have already been happy to know at least the line in standalone.xml. But this is soo much better :) From brian.stansberry at redhat.com Tue Jul 19 16:07:53 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 19 Jul 2016 15:07:53 -0500 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Message-ID: Comments in-line, except for something I just thought of. All exception and log messages produced will likely need to follow WildFly?s/EAP's i18n standards. Message prefixed with a code, text produced in a way in an i18n manner with a reasonable way to get localized text into the software. > On Jul 19, 2016, at 2:38 PM, Toby Crawley wrote: > > On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry > wrote: >> The only big concern I have about this is that we?ll get this behavior for >> some failures but not all. And I don?t want to go down the path of trying to >> force every parser to work in a manner such that we consistently get this. >> > > I haven't looked at it too deeply, but it may be straightforward to > alter staxmapper to allow providing an exception generator that would > allow catching more of the cases that the parsers miss. > I?m not sure how big of a problem staxmapper-thrown exceptions are. (I haven?t really thought.) What I was thinking more about when I wrote my previous post was parsers not using ParseUtils, or sometimes not using it. Also, a lot of XmlStreamException cases are generated from implementations of org.jboss.as.controller.AttributeDefinition, e.g. https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140 Parsers are encouraged to invoke methods on AttributeDefinition to validate attribute values. Perhaps though those are better left alone, as the validators are meant to produce useful exception messages. >> Personally I think it?s ok to have this for only some failures. Others may >> disagree though and start filing bug reports, leading to demands that we fix >> said ?bugs?, leading to a shift of resource away from other tasks. >> >> My instinct is it?s worth it though. I?m curious what others think. >> > > Adding more to the WildFly team's plate is a concern of mine as well. > I'm willing to do the work to finish this feature, and to help out > with any reported issues related to it in the future, but there would > still be some increase in the team's workload from it. > >> I think the path you?ve followed is a good way to get a lot of benefit >> without being overly intrusive. >> >> A medium sized concern is this has to be robust. It can?t be producing >> misleading messages, as that?s worse than simply pointing to the line/col of >> where the mistake was. >> > > Agreed - there needs to be some confidence level that if the tool > can't meet for an error, it falls back to just pointing to the > line/col, printing the original message. I fact, that may be good > enough for the failures that bubble out of staxmapper as well. > >> A minor concern is how big the added dependencies are. (I don?t know.) We >> want to keep WildFly Core small in footprint. >> > > Right now, the only dependencies vdx (31k) has are commons-lang (which > is already a module in WildFly, but not core-feature-pack), > xmlschema-walker (100k), and xmlschema-core (168k). For the rest of > the work, I don't currently see needing any more dependencies. Thanks. So about 583K including 284K for commons-lang. The current wildly-core-dist-3.0.0.Alpha3.zip is about 16.9MB, so this is fairly substantial. > >> Re: "Only the first validation issue is reported, but this is unavoidable, >> since the subsystem parsers throw on the first error encountered? ? I?m not >> bothered by that at all. We?re booting a server, not validating a document. >> If people are producing documents riddled with errors there are other tools >> to use to help with that. > > Makes sense, thanks. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160719/beefce2e/attachment.html From tcrawley at redhat.com Tue Jul 19 19:28:44 2016 From: tcrawley at redhat.com (Toby Crawley) Date: Tue, 19 Jul 2016 19:28:44 -0400 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Message-ID: On Tue, Jul 19, 2016 at 4:07 PM, Brian Stansberry wrote: > Comments in-line, except for something I just thought of. > > All exception and log messages produced will likely need to follow > WildFly?s/EAP's i18n standards. Message prefixed with a code, text produced > in a way in an i18n manner with a reasonable way to get localized text into > the software. Ah, good point. It shouldn't be difficult to add localized text to the output, the biggest cost there would be the time to translate the messages, but I'm not familiar with how i18n is done in our projects. For the message code, we could print the original exception message at the bottom or top of the validation block. That would then use the same code as we provide now, and would provide the same message we use now with every error. Would that satisfy the message code requirement? >> >> On Jul 19, 2016, at 2:38 PM, Toby Crawley wrote: >> >>> On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry >>> wrote: >>> >>> The only big concern I have about this is that we?ll get this behavior for >>> some failures but not all. And I don?t want to go down the path of trying to >>> force every parser to work in a manner such that we consistently get this. >>> >> >> I haven't looked at it too deeply, but it may be straightforward to >> alter staxmapper to allow providing an exception generator that would >> allow catching more of the cases that the parsers miss. >> > > I?m not sure how big of a problem staxmapper-thrown exceptions are. (I > haven?t really thought.) That's just the first place I saw errors from outside of ParseUtils, but I haven't yet started playing with attribute values. > > What I was thinking more about when I wrote my previous post was parsers not > using ParseUtils, or sometimes not using it. > > Also, a lot of XmlStreamException cases are generated from implementations > of org.jboss.as.controller.AttributeDefinition, e.g. > > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140 > > Parsers are encouraged to invoke methods on AttributeDefinition to validate > attribute values. Perhaps though those are better left alone, as the > validators are meant to produce useful exception messages. > If we let these fall back to just pointing out the error location with the original message, this may be ok (assuming by "the alidators are meant to produce useful exception messages" you mean the messages produced by the AttributeDefinitions). >>> A minor concern is how big the added dependencies are. (I don?t know.) We >>> want to keep WildFly Core small in footprint. >>> >> >> Right now, the only dependencies vdx (31k) has are commons-lang (which >> is already a module in WildFly, but not core-feature-pack), >> xmlschema-walker (100k), and xmlschema-core (168k). For the rest of >> the work, I don't currently see needing any more dependencies. >> > > Thanks. So about 583K including 284K for commons-lang. The current > wildly-core-dist-3.0.0.Alpha3.zip is about 16.9MB, so this is fairly > substantial. > I'm only using commons-lang for a Levenshtein distance implementation - that could certainly be pulled in, and we could drop the 284k for commons-lang. It certainly would be nice to keep core under 17MB though. - Toby From martin.kamp.jensen at schneider-electric.com Wed Jul 20 02:39:12 2016 From: martin.kamp.jensen at schneider-electric.com (martin.kamp.jensen at schneider-electric.com) Date: Wed, 20 Jul 2016 08:39:12 +0200 Subject: [wildfly-dev] WildFly 10.1 snapshots repository Message-ID: Hi, To prepare for WildFly 10.1, I would like to try out 10.1.0.Final-SNAPSHOT to see if that can replace 10.0.0.Final without too much trouble. However, I can only find a snapshot from April (e.g., http://repository.jboss.org/nexus/content/groups/public/org/wildfly/wildfly-parent/10.1.0.Final-SNAPSHOT/wildfly-parent-10.1.0.Final-20160412.045239-1.pom ). Is an up-to-date snapshots repository available? Thanks, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160720/1342726b/attachment-0001.html From kabir.khan at jboss.com Wed Jul 20 04:20:19 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 20 Jul 2016 10:20:19 +0200 Subject: [wildfly-dev] WildFly 10.1 snapshots repository In-Reply-To: References: Message-ID: <9A5617D4-85F3-47E0-A5B4-E619FC86F9C4@jboss.com> Your best bet is to build it from the master branch of https://github.com/wildfly/wildfly. Some information can be found at https://developer.jboss.org/wiki/HackingonWildFly. > On 20 Jul 2016, at 08:39, martin.kamp.jensen at schneider-electric.com wrote: > > Hi, > > To prepare for WildFly 10.1, I would like to try out 10.1.0.Final-SNAPSHOT to see if that can replace 10.0.0.Final without too much trouble. However, I can only find a snapshot from April (e.g., http://repository.jboss.org/nexus/content/groups/public/org/wildfly/wildfly-parent/10.1.0.Final-SNAPSHOT/wildfly-parent-10.1.0.Final-20160412.045239-1.pom). Is an up-to-date snapshots repository available? > > Thanks, > Martin > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From martin.kamp.jensen at schneider-electric.com Wed Jul 20 04:57:23 2016 From: martin.kamp.jensen at schneider-electric.com (martin.kamp.jensen at schneider-electric.com) Date: Wed, 20 Jul 2016 10:57:23 +0200 Subject: [wildfly-dev] WildFly 10.1 snapshots repository In-Reply-To: <9A5617D4-85F3-47E0-A5B4-E619FC86F9C4@jboss.com> References: <9A5617D4-85F3-47E0-A5B4-E619FC86F9C4@jboss.com> Message-ID: Kabir Khan wrote on 07/20/2016 10:20:19: > From: Kabir Khan > To: Martin Kamp Jensen/DK/Schneider at Europe > Cc: wildfly-dev at lists.jboss.org > Date: 07/20/2016 10:20 > Subject: Re: [wildfly-dev] WildFly 10.1 snapshots repository > > Your best bet is to build it from the master branch of https:// > github.com/wildfly/wildfly. I was hoping to avoid that but I may end up doing it unless there will be an official CR release of 10.1 before Final? > > Some information can be found at https://developer.jboss.org/wiki/ > HackingonWildFly. > > On 20 Jul 2016, at 08:39, martin.kamp.jensen at schneider-electric.com wrote: > > > > Hi, > > > > To prepare for WildFly 10.1, I would like to try out 10.1.0.Final- > SNAPSHOT to see if that can replace 10.0.0.Final without too much > trouble. However, I can only find a snapshot from April (e.g., > http://repository.jboss.org/nexus/content/groups/public/org/wildfly/ > wildfly-parent/10.1.0.Final-SNAPSHOT/wildfly-parent-10.1. > 0.Final-20160412.045239-1.pom). Is an up-to-date snapshots > repository available? > > > > Thanks, > > Martin > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160720/f7a39cb5/attachment.html From gtrikler at redhat.com Wed Jul 20 06:02:14 2016 From: gtrikler at redhat.com (Gytis Trikleris) Date: Wed, 20 Jul 2016 11:02:14 +0100 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> Message-ID: <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> Scott, I think that this wouldn?t be a common case, but it is still possible that user could inject drivers from two different profiles and invoke them in the same transaction. In this case two Neo4jXAResourceImpl instances would be enlisted to the transaction and that is not a recommended use case because atomicity cannot be guaranteed. There is a bit more info about it in section 3.2.1.1. of http://narayana.io/docs/product/index.html . Gytis > On 19 Jul 2016, at 19:36, Scott Marlow wrote: > > > > On 07/19/2016 10:49 AM, Scott Marlow wrote: >> >> >> On 07/19/2016 04:17 AM, Emmanuel Bernard wrote: >>> On Mon 2016-07-18 12:20, Scott Marlow wrote: >>>> Thanks for the feedback. >>>> >>>> On 07/18/2016 09:24 AM, Emmanuel Bernard wrote: >>>>> I'm lost. >>>>> >>>>> What is the expected code a developer will write ? >>>>> >>>>> If that' something along the lines of: >>>>> >>>>> jta.beginTx() // declaratively or imperatively >>>>> neo4j.beginTx() >>>>> ... >>>>> neo4j.commit() >>>>> jta.commit() //declaratively or imperatively >>>> >>>> They are not limited to writing the above code. In addition, the developer >>>> can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like: >>>> >>>> jta.beginTx() // declaratively or imperatively >>>> session = driver.session() // internally does session.beginTransaction() >>>> ... >>>> jta.commit() //declaratively or imperatively >>>> >>>> The calls to neo4j.beginTx()/commit() are ignored. >>>> >>>> The choice of ignoring those calls, is made against the alternative of >>>> throwing an exception. The reason for ignoring the neo4j transactional >>>> calls, is to be more compatible with existing ne04j code that may be using >>>> the neo4j transactional code, with the goal that the JTA transaction >>>> controls the underlying ne04j transaction. Neo4j transactional code also >>>> runs the statements against the neo4j transaction class, instead of the >>>> neo4j session class. >>> >>> You mean having existing code work with the new JTA transaction net? >>> I don't think you can safely support that. What if the code does >>> >>> @Transactional >>> public void doThings() { >>> session = drive.session(); >>> session.beginTransaction(); >> // should be: >> Transaction transaction = session.beginTransaction(); >>> try { >>> // do things >>> catch (Exception e) { >>> // swallow exception because we will fix things >>> session.rollback(); >> // should be: >> transaction.failure(); >>> session.beginTransaction(); >> transaction = session.beginTransaction(); >>> // do something else >>> session.commit(); >>> } >>> } >>> >>> Such an existing code won't work if JTA in involved and >>> session.beginTrnasaction() / commit() are ignored. >> >> With the current prototype, the above existing code won't work as >> originally intended (with regard to what the original developer had in >> mind) with JTA enlistment. >> >>> >>> So only code written with the idea of the JTA net in mind will be safe. >> >> Clearly, any existing neo4j code that expects to fail the current neo4j >> transaction, then start a new neo4j transaction to fix things, will not >> work in the JTA net. As the fixing of things in the JTA net, needs to >> occur before marking the JTA transaction for rollback only *or* by >> fixing things after the JTA transaction rolls back. >> >> Are there any other holes that come to mind, with regard to existing >> neo4j transaction code that won't work as original intended in the JTA net? >> >>> >>>>> >>>>> then I find it very user unfriendly to force the code to call both Tx >>>>> APIs. It should be one or the other. >>>> >>>> Do you really want to rewrite your neo4j code to avoid the neo4j tx APIs >>>> when enlisted into a JTA transaction? Or should the neo4j tx API calls be >>>> ignored when enlisted into a JTA transaction (as we are doing now)? >>> >>> See my above example of already existing code. >>> >>> For new code that you want to run both in SE and Wildfly, that's an >>> interesting question but how would you do it in practice? A try catch >>> but rethrowing the exception in case JTA is involved and needs to be >>> notified of the tx rollback? >> >> The developer could rewrite their "workaround tx failure" code to avoid >> further calls to the neo4j tx api, but this is kind of bad as they only >> should do this when the neo4j transaction is enlisted into the JTA >> transaction, but not when enlistment is disabled. Some neo4j connection >> profiles will be configured to allow JTA enlistment (transaction=1pc) >> and some will be configured to not allow JTA enlistment >> (transaction=none), so we can expect common application code will likely >> be reused for both JTA + non-JTA. Seems to me that SE is always the >> same as the WildFly neo4j connection profile with "transaction=none", so >> we have the same problem with SE + WildFly, trying to run the same user >> code that is expected to work with JTA enlistment (neo4j connection >> profile has "transaction=1pc"). >> >> I don't know of any CDI magic that helps, as if we add support for >> inject of a javax.transaction.TransactionScoped neo4j session, that >> works the same as a session obtained from Driver.session(). >> >>> I'm interested to see concrete code because if doable, it will have lots >>> of constraints and be limited to very specific patterns of code I think. >>> But again, let's show each other code. > > I found some examples in the Neo4j Java driver unit tests. I started a > gist [1] that lists a few of the test cases that I thought were > interesting for this discussion about "compatibility of existing Neo4j > tx handling code in the JTA net". > > In actual applications, the use cases will not be so simple. Instead, > we will see many different patterns mixed over several lines of > application library code, however, each unit case noted is presenting a > different example that would probably not run as is, when enlisted in a > JTA transaction. > > This doesn't mean it is bad to enlist Neo4j transactions into a JTA > transaction, it just means that it is bad assume that a Neo4j tx works > the same when enlisted in a JTA transaction. > > I think that a challenge here for us, is to deduce what our rules should > be when enlisting Neo4j transactions into a JTA transaction, with regard > to what the application can expect and shouldn't expect. > > Scott > > [1] https://gist.github.com/scottmarlow/2779d21653e8466d85e38c1d62d4bb1e > >> >> That should help us explore the compatibility with existing code idea >> and pick which approach to use (e.g. whether explicit neo4j transaction >> use in a JTA enlisted transaction should throw an exception or ignore >> the explicit transaction use as we are doing now in the prototype). >> >> Should we also post on https://groups.google.com/forum/#!forum/neo4j to >> ask for input on JTA enlistment? >> >>> >>> Emmanuel >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160720/db0e3266/attachment-0001.html From jesper.pedersen at redhat.com Wed Jul 20 08:53:23 2016 From: jesper.pedersen at redhat.com (Jesper Pedersen) Date: Wed, 20 Jul 2016 08:53:23 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> Message-ID: Hi, On 07/20/2016 06:02 AM, Gytis Trikleris wrote: > I think that this wouldn?t be a common case, but it is still possible that user could inject drivers from two different profiles and invoke them in the same transaction. In this case two Neo4jXAResourceImpl instances would be enlisted to the transaction and that is not a recommended use case because atomicity cannot be guaranteed. There is a bit more info about it in section 3.2.1.1. of http://narayana.io/docs/product/index.html . > This is precisely the same as the discussion. For (transaction="none"), users will need to manage the transactional resource of the NoSQL store themselves, e.g. how apps are coded today using session.beginTransaction() and so on. As the store isn't enlisted in the JTA transaction you can inject as many as you want. However, the ACID properties of the store is tied to the application code, and not the out-come of the JTA transaction. This is the same as doing Connection.setAutoCommit(false) and Connection.commit() in JDBC. Yes, there are apps that need this, but fewer each day. For (transaction="1pc"), the transactional resource of the NoSQL store is enlisted in the JTA transaction by the container, e.g. any application code using session.beginTransaction() and so on are basically no-ops. Now, the ACID properties of the store is tied to the out-come of the JTA transaction. This means that you can remove all code regarding transaction handling from your application and let the JTA transaction handle it (there is a question if tx.failure() should trigger setRollbackOnly(), but that is a separate matter). Like DataSource you only get to inject 1 instance, otherwise it is and 2pc. Yes, it is a different way of doing NoSQL apps, since the transactional scope is tied to JTA, but it also provides a much simpler way to do business logic flow. So, this will take some time for people to get used to, but people saw the benefit of not handling transactional integration of JDBC themselves (Go JCA !). The transactional properties will be different in each NoSQL store, f.ex. in Neo4J tx.success() / tx.failure() doesn't do anything before tx.close() is called. So having transaction="1pc" (and "2pc") is a way to unify transactional integration across different NoSQL stores. Best regards, Jesper From tomaz.cerar at gmail.com Wed Jul 20 09:38:51 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 20 Jul 2016 15:38:51 +0200 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Message-ID: Most of my concerns about this ware already raised by Brian (l18n, extra size of distro, inconsistencies between subsystems, ...) Also on top of this, having something like that would glorify configuration of server via XML, which is something we are trying to discourage in favor of CLI / mgmt api. Another problem is also that it relies on XSD which are not always 100% correct, which should be fixed (but that is another problem) There are also ideas about implementing non xml backend for storage of our configuration. type of storage for the backend shouldn't really matter as users should be interacting via API / CLI not by manually modifying the file. -- tomaz On Wed, Jul 20, 2016 at 1:28 AM, Toby Crawley wrote: > On Tue, Jul 19, 2016 at 4:07 PM, Brian Stansberry > wrote: > > Comments in-line, except for something I just thought of. > > > > All exception and log messages produced will likely need to follow > > WildFly?s/EAP's i18n standards. Message prefixed with a code, text > produced > > in a way in an i18n manner with a reasonable way to get localized text > into > > the software. > > Ah, good point. It shouldn't be difficult to add localized text to the > output, the biggest cost there would be the time to translate the > messages, but I'm not familiar with how i18n is done in our projects. > For the message code, we could print the original exception message at > the bottom or top of the validation block. That would then use the > same code as we provide now, and would provide the same message we use > now with every error. Would that satisfy the message code requirement? > > >> > >> On Jul 19, 2016, at 2:38 PM, Toby Crawley wrote: > >> > >>> On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry > >>> wrote: > >>> > >>> The only big concern I have about this is that we?ll get this behavior > for > >>> some failures but not all. And I don?t want to go down the path of > trying to > >>> force every parser to work in a manner such that we consistently get > this. > >>> > >> > >> I haven't looked at it too deeply, but it may be straightforward to > >> alter staxmapper to allow providing an exception generator that would > >> allow catching more of the cases that the parsers miss. > >> > > > > I?m not sure how big of a problem staxmapper-thrown exceptions are. (I > > haven?t really thought.) > > That's just the first place I saw errors from outside of ParseUtils, > but I haven't yet started playing with attribute values. > > > > > What I was thinking more about when I wrote my previous post was parsers > not > > using ParseUtils, or sometimes not using it. > > > > Also, a lot of XmlStreamException cases are generated from > implementations > > of org.jboss.as.controller.AttributeDefinition, e.g. > > > > > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140 > > > > Parsers are encouraged to invoke methods on AttributeDefinition to > validate > > attribute values. Perhaps though those are better left alone, as the > > validators are meant to produce useful exception messages. > > > > If we let these fall back to just pointing out the error location with > the original message, this may be ok (assuming by "the alidators are > meant to produce useful exception messages" you mean the messages > produced by the AttributeDefinitions). > > > > >>> A minor concern is how big the added dependencies are. (I don?t know.) > We > >>> want to keep WildFly Core small in footprint. > >>> > >> > >> Right now, the only dependencies vdx (31k) has are commons-lang (which > >> is already a module in WildFly, but not core-feature-pack), > >> xmlschema-walker (100k), and xmlschema-core (168k). For the rest of > >> the work, I don't currently see needing any more dependencies. > >> > > > > Thanks. So about 583K including 284K for commons-lang. The current > > wildly-core-dist-3.0.0.Alpha3.zip is about 16.9MB, so this is fairly > > substantial. > > > > I'm only using commons-lang for a Levenshtein distance implementation > - that could certainly be pulled in, and we could drop the 284k for > commons-lang. It certainly would be nice to keep core under 17MB > though. > > - Toby > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160720/2cba7c2d/attachment.html From smarlow at redhat.com Wed Jul 20 09:59:52 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 20 Jul 2016 09:59:52 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> Message-ID: <9e8d5dce-256e-1e30-aad7-0cccb663a2f9@redhat.com> On 07/20/2016 06:02 AM, Gytis Trikleris wrote: > Scott, > > I think that this wouldn?t be a common case, but it is still possible > that user could inject drivers from two different profiles and invoke > them in the same transaction. In this case two Neo4jXAResourceImpl > instances would be enlisted to the transaction and that is not a > recommended use case because atomicity cannot be guaranteed. There is a > bit more info about it in section 3.2.1.1. > of http://narayana.io/docs/product/index.html. I'm trying to understand how the description in 3.2.1.1 applies to Neo4jXAResourceImpl (implements org.jboss.tm.LastResource and not com.arjuna.ats.jta.resources.LastResourceCommitOptimisation). By default, will WildFly allow more than one org.jboss.tm.LastResource to be enlisted into the JTA transaction at a time? When you say above that its possible for two Neo4jXAResourceImpl's to be injected, would that only be if com.arjuna.ats.jta.allowMultipleLastResources is changed to true? Thanks for pointing this case out! Scott > > Gytis > >> On 19 Jul 2016, at 19:36, Scott Marlow > > wrote: >> >> >> >> On 07/19/2016 10:49 AM, Scott Marlow wrote: >>> >>> >>> On 07/19/2016 04:17 AM, Emmanuel Bernard wrote: >>>> On Mon 2016-07-18 12:20, Scott Marlow wrote: >>>>> Thanks for the feedback. >>>>> >>>>> On 07/18/2016 09:24 AM, Emmanuel Bernard wrote: >>>>>> I'm lost. >>>>>> >>>>>> What is the expected code a developer will write ? >>>>>> >>>>>> If that' something along the lines of: >>>>>> >>>>>> jta.beginTx() // declaratively or imperatively >>>>>> neo4j.beginTx() >>>>>> ... >>>>>> neo4j.commit() >>>>>> jta.commit() //declaratively or imperatively >>>>> >>>>> They are not limited to writing the above code. In addition, the >>>>> developer >>>>> can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like: >>>>> >>>>> jta.beginTx() // declaratively or imperatively >>>>> session = driver.session() // internally does >>>>> session.beginTransaction() >>>>> ... >>>>> jta.commit() //declaratively or imperatively >>>>> >>>>> The calls to neo4j.beginTx()/commit() are ignored. >>>>> >>>>> The choice of ignoring those calls, is made against the alternative of >>>>> throwing an exception. The reason for ignoring the neo4j transactional >>>>> calls, is to be more compatible with existing ne04j code that may >>>>> be using >>>>> the neo4j transactional code, with the goal that the JTA transaction >>>>> controls the underlying ne04j transaction. Neo4j transactional >>>>> code also >>>>> runs the statements against the neo4j transaction class, instead of the >>>>> neo4j session class. >>>> >>>> You mean having existing code work with the new JTA transaction net? >>>> I don't think you can safely support that. What if the code does >>>> >>>> @Transactional >>>> public void doThings() { >>>> session = drive.session(); >>>> session.beginTransaction(); >>> // should be: >>> Transaction transaction = session.beginTransaction(); >>>> try { >>>> // do things >>>> catch (Exception e) { >>>> // swallow exception because we will fix things >>>> session.rollback(); >>> // should be: >>> transaction.failure(); >>>> session.beginTransaction(); >>> transaction = session.beginTransaction(); >>>> // do something else >>>> session.commit(); >>>> } >>>> } >>>> >>>> Such an existing code won't work if JTA in involved and >>>> session.beginTrnasaction() / commit() are ignored. >>> >>> With the current prototype, the above existing code won't work as >>> originally intended (with regard to what the original developer had in >>> mind) with JTA enlistment. >>> >>>> >>>> So only code written with the idea of the JTA net in mind will be safe. >>> >>> Clearly, any existing neo4j code that expects to fail the current neo4j >>> transaction, then start a new neo4j transaction to fix things, will not >>> work in the JTA net. As the fixing of things in the JTA net, needs to >>> occur before marking the JTA transaction for rollback only *or* by >>> fixing things after the JTA transaction rolls back. >>> >>> Are there any other holes that come to mind, with regard to existing >>> neo4j transaction code that won't work as original intended in the >>> JTA net? >>> >>>> >>>>>> >>>>>> then I find it very user unfriendly to force the code to call both Tx >>>>>> APIs. It should be one or the other. >>>>> >>>>> Do you really want to rewrite your neo4j code to avoid the neo4j tx >>>>> APIs >>>>> when enlisted into a JTA transaction? Or should the neo4j tx API >>>>> calls be >>>>> ignored when enlisted into a JTA transaction (as we are doing now)? >>>> >>>> See my above example of already existing code. >>>> >>>> For new code that you want to run both in SE and Wildfly, that's an >>>> interesting question but how would you do it in practice? A try catch >>>> but rethrowing the exception in case JTA is involved and needs to be >>>> notified of the tx rollback? >>> >>> The developer could rewrite their "workaround tx failure" code to avoid >>> further calls to the neo4j tx api, but this is kind of bad as they only >>> should do this when the neo4j transaction is enlisted into the JTA >>> transaction, but not when enlistment is disabled. Some neo4j connection >>> profiles will be configured to allow JTA enlistment (transaction=1pc) >>> and some will be configured to not allow JTA enlistment >>> (transaction=none), so we can expect common application code will likely >>> be reused for both JTA + non-JTA. Seems to me that SE is always the >>> same as the WildFly neo4j connection profile with "transaction=none", so >>> we have the same problem with SE + WildFly, trying to run the same user >>> code that is expected to work with JTA enlistment (neo4j connection >>> profile has "transaction=1pc"). >>> >>> I don't know of any CDI magic that helps, as if we add support for >>> inject of a javax.transaction.TransactionScoped neo4j session, that >>> works the same as a session obtained from Driver.session(). >>> >>>> I'm interested to see concrete code because if doable, it will have lots >>>> of constraints and be limited to very specific patterns of code I think. >>>> But again, let's show each other code. >> >> I found some examples in the Neo4j Java driver unit tests. I started a >> gist [1] that lists a few of the test cases that I thought were >> interesting for this discussion about "compatibility of existing Neo4j >> tx handling code in the JTA net". >> >> In actual applications, the use cases will not be so simple. Instead, >> we will see many different patterns mixed over several lines of >> application library code, however, each unit case noted is presenting a >> different example that would probably not run as is, when enlisted in a >> JTA transaction. >> >> This doesn't mean it is bad to enlist Neo4j transactions into a JTA >> transaction, it just means that it is bad assume that a Neo4j tx works >> the same when enlisted in a JTA transaction. >> >> I think that a challenge here for us, is to deduce what our rules should >> be when enlisting Neo4j transactions into a JTA transaction, with regard >> to what the application can expect and shouldn't expect. >> >> Scott >> >> [1] https://gist.github.com/scottmarlow/2779d21653e8466d85e38c1d62d4bb1e >> >>> >>> That should help us explore the compatibility with existing code idea >>> and pick which approach to use (e.g. whether explicit neo4j transaction >>> use in a JTA enlisted transaction should throw an exception or ignore >>> the explicit transaction use as we are doing now in the prototype). >>> >>> Should we also post on https://groups.google.com/forum/#!forum/neo4j >>> to >>> ask for input on JTA enlistment? >>> >>>> >>>> Emmanuel >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From akostadi at redhat.com Wed Jul 20 09:59:59 2016 From: akostadi at redhat.com (Aleksandar Kostadinov) Date: Wed, 20 Jul 2016 16:59:59 +0300 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Message-ID: <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> Toma? Cerar wrote on 07/20/16 16:38: > Most of my concerns about this ware already raised by Brian (l18n, extra > size of distro, inconsistencies between subsystems, ...) > > Also on top of this, having something like that would glorify > configuration of server via XML, > which is something we are trying to discourage in favor of CLI / mgmt api. Excuse my ignorance if this is already taken care of. But last time I looked, using whatever management API was not very nice for container runtime. i.e. configuration changed through API was not persisted. I am wondering if this is already fixed somehow or is at least somebody considering it as an important use case (I think it should). From gtrikler at redhat.com Wed Jul 20 10:50:09 2016 From: gtrikler at redhat.com (Gytis Trikleris) Date: Wed, 20 Jul 2016 15:50:09 +0100 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <9e8d5dce-256e-1e30-aad7-0cccb663a2f9@redhat.com> References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> <9e8d5dce-256e-1e30-aad7-0cccb663a2f9@redhat.com> Message-ID: <664E837B-E6A3-4E84-89A7-EDD96664B32E@redhat.com> The specific marker interface for it is overridable. See https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/JTAEnvironmentBeanService.java#L58 where it is set to org.jboss.tm.LastResource. No, by default it will not add the second resource but it can be allowed by changing the config. However, it will still print the warning. Gytis > On 20 Jul 2016, at 14:59, Scott Marlow wrote: > > > > On 07/20/2016 06:02 AM, Gytis Trikleris wrote: >> Scott, >> >> I think that this wouldn?t be a common case, but it is still possible >> that user could inject drivers from two different profiles and invoke >> them in the same transaction. > In this case two Neo4jXAResourceImpl >> instances would be enlisted to the transaction and that is not a >> recommended use case because atomicity cannot be guaranteed. There is a >> bit more info about it in section 3.2.1.1. >> of http://narayana.io/docs/product/index.html. > > I'm trying to understand how the description in 3.2.1.1 applies to Neo4jXAResourceImpl (implements org.jboss.tm.LastResource and not com.arjuna.ats.jta.resources.LastResourceCommitOptimisation). > > > By default, will WildFly allow more than one org.jboss.tm.LastResource to be enlisted into the JTA transaction at a time? When you say above that its possible for two Neo4jXAResourceImpl's to be injected, would that only be if com.arjuna.ats.jta.allowMultipleLastResources is changed to true? > > Thanks for pointing this case out! > > Scott > >> >> Gytis >> >>> On 19 Jul 2016, at 19:36, Scott Marlow >> > wrote: >>> >>> >>> >>> On 07/19/2016 10:49 AM, Scott Marlow wrote: >>>> >>>> >>>> On 07/19/2016 04:17 AM, Emmanuel Bernard wrote: >>>>> On Mon 2016-07-18 12:20, Scott Marlow wrote: >>>>>> Thanks for the feedback. >>>>>> >>>>>> On 07/18/2016 09:24 AM, Emmanuel Bernard wrote: >>>>>>> I'm lost. >>>>>>> >>>>>>> What is the expected code a developer will write ? >>>>>>> >>>>>>> If that' something along the lines of: >>>>>>> >>>>>>> jta.beginTx() // declaratively or imperatively >>>>>>> neo4j.beginTx() >>>>>>> ... >>>>>>> neo4j.commit() >>>>>>> jta.commit() //declaratively or imperatively >>>>>> >>>>>> They are not limited to writing the above code. In addition, the >>>>>> developer >>>>>> can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like: >>>>>> >>>>>> jta.beginTx() // declaratively or imperatively >>>>>> session = driver.session() // internally does >>>>>> session.beginTransaction() >>>>>> ... >>>>>> jta.commit() //declaratively or imperatively >>>>>> >>>>>> The calls to neo4j.beginTx()/commit() are ignored. >>>>>> >>>>>> The choice of ignoring those calls, is made against the alternative of >>>>>> throwing an exception. The reason for ignoring the neo4j transactional >>>>>> calls, is to be more compatible with existing ne04j code that may >>>>>> be using >>>>>> the neo4j transactional code, with the goal that the JTA transaction >>>>>> controls the underlying ne04j transaction. Neo4j transactional >>>>>> code also >>>>>> runs the statements against the neo4j transaction class, instead of the >>>>>> neo4j session class. >>>>> >>>>> You mean having existing code work with the new JTA transaction net? >>>>> I don't think you can safely support that. What if the code does >>>>> >>>>> @Transactional >>>>> public void doThings() { >>>>> session = drive.session(); >>>>> session.beginTransaction(); >>>> // should be: >>>> Transaction transaction = session.beginTransaction(); >>>>> try { >>>>> // do things >>>>> catch (Exception e) { >>>>> // swallow exception because we will fix things >>>>> session.rollback(); >>>> // should be: >>>> transaction.failure(); >>>>> session.beginTransaction(); >>>> transaction = session.beginTransaction(); >>>>> // do something else >>>>> session.commit(); >>>>> } >>>>> } >>>>> >>>>> Such an existing code won't work if JTA in involved and >>>>> session.beginTrnasaction() / commit() are ignored. >>>> >>>> With the current prototype, the above existing code won't work as >>>> originally intended (with regard to what the original developer had in >>>> mind) with JTA enlistment. >>>> >>>>> >>>>> So only code written with the idea of the JTA net in mind will be safe. >>>> >>>> Clearly, any existing neo4j code that expects to fail the current neo4j >>>> transaction, then start a new neo4j transaction to fix things, will not >>>> work in the JTA net. As the fixing of things in the JTA net, needs to >>>> occur before marking the JTA transaction for rollback only *or* by >>>> fixing things after the JTA transaction rolls back. >>>> >>>> Are there any other holes that come to mind, with regard to existing >>>> neo4j transaction code that won't work as original intended in the >>>> JTA net? >>>> >>>>> >>>>>>> >>>>>>> then I find it very user unfriendly to force the code to call both Tx >>>>>>> APIs. It should be one or the other. >>>>>> >>>>>> Do you really want to rewrite your neo4j code to avoid the neo4j tx >>>>>> APIs >>>>>> when enlisted into a JTA transaction? Or should the neo4j tx API >>>>>> calls be >>>>>> ignored when enlisted into a JTA transaction (as we are doing now)? >>>>> >>>>> See my above example of already existing code. >>>>> >>>>> For new code that you want to run both in SE and Wildfly, that's an >>>>> interesting question but how would you do it in practice? A try catch >>>>> but rethrowing the exception in case JTA is involved and needs to be >>>>> notified of the tx rollback? >>>> >>>> The developer could rewrite their "workaround tx failure" code to avoid >>>> further calls to the neo4j tx api, but this is kind of bad as they only >>>> should do this when the neo4j transaction is enlisted into the JTA >>>> transaction, but not when enlistment is disabled. Some neo4j connection >>>> profiles will be configured to allow JTA enlistment (transaction=1pc) >>>> and some will be configured to not allow JTA enlistment >>>> (transaction=none), so we can expect common application code will likely >>>> be reused for both JTA + non-JTA. Seems to me that SE is always the >>>> same as the WildFly neo4j connection profile with "transaction=none", so >>>> we have the same problem with SE + WildFly, trying to run the same user >>>> code that is expected to work with JTA enlistment (neo4j connection >>>> profile has "transaction=1pc"). >>>> >>>> I don't know of any CDI magic that helps, as if we add support for >>>> inject of a javax.transaction.TransactionScoped neo4j session, that >>>> works the same as a session obtained from Driver.session(). >>>> >>>>> I'm interested to see concrete code because if doable, it will have lots >>>>> of constraints and be limited to very specific patterns of code I think. >>>>> But again, let's show each other code. >>> >>> I found some examples in the Neo4j Java driver unit tests. I started a >>> gist [1] that lists a few of the test cases that I thought were >>> interesting for this discussion about "compatibility of existing Neo4j >>> tx handling code in the JTA net". >>> >>> In actual applications, the use cases will not be so simple. Instead, >>> we will see many different patterns mixed over several lines of >>> application library code, however, each unit case noted is presenting a >>> different example that would probably not run as is, when enlisted in a >>> JTA transaction. >>> >>> This doesn't mean it is bad to enlist Neo4j transactions into a JTA >>> transaction, it just means that it is bad assume that a Neo4j tx works >>> the same when enlisted in a JTA transaction. >>> >>> I think that a challenge here for us, is to deduce what our rules should >>> be when enlisting Neo4j transactions into a JTA transaction, with regard >>> to what the application can expect and shouldn't expect. >>> >>> Scott >>> >>> [1] https://gist.github.com/scottmarlow/2779d21653e8466d85e38c1d62d4bb1e >>> >>>> >>>> That should help us explore the compatibility with existing code idea >>>> and pick which approach to use (e.g. whether explicit neo4j transaction >>>> use in a JTA enlisted transaction should throw an exception or ignore >>>> the explicit transaction use as we are doing now in the prototype). >>>> >>>> Should we also post on https://groups.google.com/forum/#!forum/neo4j >>>> to >>>> ask for input on JTA enlistment? >>>> >>>>> >>>>> Emmanuel >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> From jose.e.chavez at gmail.com Wed Jul 20 10:56:35 2016 From: jose.e.chavez at gmail.com (Jose Chavez) Date: Wed, 20 Jul 2016 09:56:35 -0500 Subject: [wildfly-dev] Wildfly 10 BOM In-Reply-To: References: Message-ID: When doing a mvn archetype:generate, I can see archetypes for Wildfly 8.2.0. Is there a plan to have the Wildfly 10 BOMs in Maven Central? What is the recommended way to setup a maven project targeting EJB/CDI/Web? Thanks, Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160720/e0b5b67e/attachment.html From smarlow at redhat.com Wed Jul 20 11:51:39 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 20 Jul 2016 11:51:39 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: References: <158caaad-e6c5-0ddd-e94b-f7f7c7cf5a35@redhat.com> <465efda0-b598-0d57-cf40-d5d52ba48323@redhat.com> <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> Message-ID: <0745c0ee-b867-9b0f-7bb3-07573efe6e71@redhat.com> On 07/20/2016 08:53 AM, Jesper Pedersen wrote: > Hi, > > On 07/20/2016 06:02 AM, Gytis Trikleris wrote: >> I think that this wouldn?t be a common case, but it is still possible >> that user could inject drivers from two different profiles and invoke >> them in the same transaction. In this case two Neo4jXAResourceImpl >> instances would be enlisted to the transaction and that is not a >> recommended use case because atomicity cannot be guaranteed. There is >> a bit more info about it in section 3.2.1.1. of >> http://narayana.io/docs/product/index.html >> . >> > > This is precisely the same as the > discussion. > > For (transaction="none"), users will need to > manage the transactional resource of the NoSQL store themselves, e.g. > how apps are coded today using session.beginTransaction() and so on. Not exactly, the application can also use compensation with the connection profile set to transaction=none. So, choices for Neo4j are really, use compensating transactions with JTA or 1pc with JTA or none. For the BASE NoSQL databases, the only option is to use compensating transactions with JTA or none. NoSQL connection profiles are not data-source. > > As the store isn't enlisted in the JTA transaction you can inject as > many as you want. However, the ACID properties of the store is tied to > the application code, and not the out-come of the JTA transaction. > > This is the same as doing Connection.setAutoCommit(false) and > Connection.commit() in JDBC. Yes, there are apps that need this, but > fewer each day. > > For (transaction="1pc"), the transactional > resource of the NoSQL store is enlisted in the JTA transaction by the > container, e.g. any application code using session.beginTransaction() > and so on are basically no-ops. > > Now, the ACID properties of the store is tied to the out-come of the JTA > transaction. This means that you can remove all code regarding > transaction handling from your application and let the JTA transaction > handle it (there is a question if tx.failure() should trigger > setRollbackOnly(), but that is a separate matter). Like DataSource you > only get to inject 1 instance, otherwise it is and 2pc. > > Yes, it is a different way of doing NoSQL apps, since the transactional > scope is tied to JTA, but it also provides a much simpler way to do > business logic flow. So, this will take some time for people to get used > to, but people saw the benefit of not handling transactional integration > of JDBC themselves (Go JCA !). > > The transactional properties will be different in each NoSQL store, > f.ex. in Neo4J tx.success() / tx.failure() doesn't do anything before > tx.close() is called. So having transaction="1pc" (and "2pc") is a way > to unify transactional integration across different NoSQL stores. We are taking a closer look at different Neo4j examples, to better understand the pros/cons of allowing applications to call tx.success/tx.failure in the JTA transaction. I think that the advantage of enlisting Neo4j into a JTA transaction is that it makes it easier for the application developer to coordinate updating multiple resources within the same transaction. > > Best regards, > Jesper > From brian.stansberry at redhat.com Wed Jul 20 13:18:03 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 20 Jul 2016 12:18:03 -0500 Subject: [wildfly-dev] WildFly 10.1 snapshots repository In-Reply-To: References: <9A5617D4-85F3-47E0-A5B4-E619FC86F9C4@jboss.com> Message-ID: There will be a 10.1.0.CR1 release before Final. > On Jul 20, 2016, at 3:57 AM, martin.kamp.jensen at schneider-electric.com wrote: > > Kabir Khan wrote on 07/20/2016 10:20:19: > > > From: Kabir Khan > > To: Martin Kamp Jensen/DK/Schneider at Europe > > Cc: wildfly-dev at lists.jboss.org > > Date: 07/20/2016 10:20 > > Subject: Re: [wildfly-dev] WildFly 10.1 snapshots repository > > > > Your best bet is to build it from the master branch of https:// > > github.com/wildfly/wildfly. > > I was hoping to avoid that but I may end up doing it unless there will be an official CR release of 10.1 before Final? > > > > > Some information can be found at https://developer.jboss.org/wiki/ > > HackingonWildFly. > > > On 20 Jul 2016, at 08:39, martin.kamp.jensen at schneider-electric.com wrote: > > > > > > Hi, > > > > > > To prepare for WildFly 10.1, I would like to try out 10.1.0.Final- > > SNAPSHOT to see if that can replace 10.0.0.Final without too much > > trouble. However, I can only find a snapshot from April (e.g., > > http://repository.jboss.org/nexus/content/groups/public/org/wildfly/ > > wildfly-parent/10.1.0.Final-SNAPSHOT/wildfly-parent-10.1. > > 0.Final-20160412.045239-1.pom). Is an up-to-date snapshots > > repository available? > > > > > > Thanks, > > > Martin > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > ______________________________________________________________________ > > This email has been scanned by the Symantec Email Security.cloud service. > > ______________________________________________________________________ > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160720/9274fced/attachment-0001.html From brian.stansberry at redhat.com Wed Jul 20 13:23:11 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 20 Jul 2016 12:23:11 -0500 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> Message-ID: > On Jul 20, 2016, at 8:59 AM, Aleksandar Kostadinov wrote: > > Toma? Cerar wrote on 07/20/16 16:38: >> Most of my concerns about this ware already raised by Brian (l18n, extra >> size of distro, inconsistencies between subsystems, ...) >> >> Also on top of this, having something like that would glorify >> configuration of server via XML, >> which is something we are trying to discourage in favor of CLI / mgmt api. > > Excuse my ignorance if this is already taken care of. But last time I > looked, using whatever management API was not very nice for container > runtime. i.e. configuration changed through API was not persisted. > I am wondering if this is already fixed somehow or is at least somebody > considering it as an important use case (I think it should). Persisting server configuration changes made via the supported management APIs back to the config file has been done in AS 7.0 and later. Its a fundamental requirement. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160720/9697832d/attachment.html From akostadi at redhat.com Wed Jul 20 18:49:12 2016 From: akostadi at redhat.com (Aleksandar Kostadinov) Date: Thu, 21 Jul 2016 01:49:12 +0300 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> Message-ID: <3635d158-5695-c134-e0d0-63dcfc1a9542@redhat.com> Brian Stansberry wrote on 07/20/16 20:23: > >> On Jul 20, 2016, at 8:59 AM, Aleksandar Kostadinov >> > wrote: >> >> Toma? Cerar wrote on 07/20/16 16:38: >>> Most of my concerns about this ware already raised by Brian (l18n, extra >>> size of distro, inconsistencies between subsystems, ...) >>> >>> Also on top of this, having something like that would glorify >>> configuration of server via XML, >>> which is something we are trying to discourage in favor of CLI / >>> mgmt api. >> >> Excuse my ignorance if this is already taken care of. But last time I >> looked, using whatever management API was not very nice for container >> runtime. i.e. configuration changed through API was not persisted. >> I am wondering if this is already fixed somehow or is at least somebody >> considering it as an important use case (I think it should). > > Persisting server configuration changes made via the supported > management APIs back to the config file has been done in AS 7.0 and > later. Its a fundamental requirement. I should have explained better. The config is saved on container. But container being stateless loses changes on restart. At least for OpenShift v2 that has been an issue. Shame on me I didn't look at OpenShift v3 integration. I'm not sure how it is handled there. Perhaps I should have done my homework before hijacking the thread. Sorry about that. Hopefully I can check wildfly on v3 next week. From emmanuel at hibernate.org Thu Jul 21 04:13:56 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 21 Jul 2016 10:13:56 +0200 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <0745c0ee-b867-9b0f-7bb3-07573efe6e71@redhat.com> References: <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> <0745c0ee-b867-9b0f-7bb3-07573efe6e71@redhat.com> Message-ID: <20160721081356.GN2145@hibernate.org> On Wed 2016-07-20 11:51, Scott Marlow wrote: > > > The transactional properties will be different in each NoSQL store, > > f.ex. in Neo4J tx.success() / tx.failure() doesn't do anything before > > tx.close() is called. So having transaction="1pc" (and "2pc") is a way > > to unify transactional integration across different NoSQL stores. > > We are taking a closer look at different Neo4j examples, to better > understand the pros/cons of allowing applications to call > tx.success/tx.failure in the JTA transaction. > > I think that the advantage of enlisting Neo4j into a JTA transaction is > that it makes it easier for the application developer to coordinate > updating multiple resources within the same transaction. That's not my preferred advantage to be honest. My favorite is that people can use the @Transactional programming model of EJB/CDI like they do for RDBMSes. That's a huge win. What we are questioning here, is transparently ignoring explicit "native" tx API calls when the JTA binding is in effect. It looked nice on paper but has serious corner cases. So simpler might be better here. Emmanuel From smarlow at redhat.com Thu Jul 21 10:22:48 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 21 Jul 2016 10:22:48 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <20160721081356.GN2145@hibernate.org> References: <6d570f13-9914-f6f8-9823-5d600dc58a8e@redhat.com> <20160718132400.GH69003@hibernate.org> <6c1ab09e-d8bf-2158-a5f4-770e2d0bb490@redhat.com> <20160719081743.GK69003@hibernate.org> <6bcee7c4-899c-7d8e-8c7a-d13526675fcb@redhat.com> <3343FF82-1A93-4F8A-9C72-0E99D4A972A5@redhat.com> <0745c0ee-b867-9b0f-7bb3-07573efe6e71@redhat.com> <20160721081356.GN2145@hibernate.org> Message-ID: <48b92b78-4682-6e42-83eb-79b7067744ce@redhat.com> On 07/21/2016 04:13 AM, Emmanuel Bernard wrote: > On Wed 2016-07-20 11:51, Scott Marlow wrote: > > >>> The transactional properties will be different in each NoSQL store, >>> f.ex. in Neo4J tx.success() / tx.failure() doesn't do anything before >>> tx.close() is called. So having transaction="1pc" (and "2pc") is a way >>> to unify transactional integration across different NoSQL stores. >> >> We are taking a closer look at different Neo4j examples, to better >> understand the pros/cons of allowing applications to call >> tx.success/tx.failure in the JTA transaction. >> >> I think that the advantage of enlisting Neo4j into a JTA transaction is >> that it makes it easier for the application developer to coordinate >> updating multiple resources within the same transaction. > > That's not my preferred advantage to be honest. > My favorite is that people can use the @Transactional programming model > of EJB/CDI like they do for RDBMSes. That's a huge win. Excellent that we are arguing over our preferred advantage, I like yours also, as well as mine! :-) > > What we are questioning here, is transparently ignoring explicit > "native" tx API calls when the JTA binding is in effect. It looked nice > on paper but has serious corner cases. So simpler might be better here. After reviewing some of the example code in the Neo4j Java driver unit tests [1], I'm leaning towards agreeing that throwing a RuntimeException is the better (strict) approach now. If we are wrong, it is easy for us to later add an option, to enable (lenient) proxying of the various "native" tx API calls when the JTA binding is in effect. We can revisit this once there is user demand for the various "native" tx API calls. Scott [1] https://gist.github.com/scottmarlow/2779d21653e8466d85e38c1d62d4bb1e From tcrawley at redhat.com Thu Jul 21 14:02:07 2016 From: tcrawley at redhat.com (Toby Crawley) Date: Thu, 21 Jul 2016 14:02:07 -0400 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Message-ID: On Wed, Jul 20, 2016 at 9:38 AM, Toma? Cerar wrote: > Also on top of this, having something like that would glorify configuration > of server via XML, > which is something we are trying to discourage in favor of CLI / mgmt api. I suspect I'm not the typical WildFly user, but I never use the CLI/API to configure or deploy. I much prefer to edit configuration by hand, and don't like requiring the server to be up to configure it. And Aleksandar has raised the issue about immutable deployments - if you use the CLI for every config change, you have to spin up the server before or as part of your build process in order to generate a configuration file to put into your container. But all that is orthogonal to the pretty-printing discussion. With regards to glorifying editing the XML - I disagree. If a user already prefers editing the XML over using the CLI, this makes things more pleasant for them. If this makes editing the XML more appealing than using the CLI to people that would normally prefer the CLI, then that would imply there is room for improvement in the feedback that that CLI gives. > Another problem is also that it relies on XSD which are not always 100% > correct, which should be fixed (but that is another problem) > I agree, if the schemas aren't correct, we should fix that. > There are also ideas about implementing non xml backend for storage of our > configuration. > type of storage for the backend shouldn't really matter as users should be > interacting via API / CLI not by manually modifying the file. If another backend is being considered, I hope it too will be user-editable. And if it is, a similar feedback tool could be applied to it. From jason.greene at redhat.com Thu Jul 21 14:29:22 2016 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 21 Jul 2016 13:29:22 -0500 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: <3635d158-5695-c134-e0d0-63dcfc1a9542@redhat.com> References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> <3635d158-5695-c134-e0d0-63dcfc1a9542@redhat.com> Message-ID: <796F6AD7-6597-48BC-BAC6-74CF08B48FA5@redhat.com> > On Jul 20, 2016, at 5:49 PM, Aleksandar Kostadinov wrote: > > Brian Stansberry wrote on 07/20/16 20:23: >> >>> On Jul 20, 2016, at 8:59 AM, Aleksandar Kostadinov >>> > wrote: >>> >>> Toma? Cerar wrote on 07/20/16 16:38: >>>> Most of my concerns about this ware already raised by Brian (l18n, extra >>>> size of distro, inconsistencies between subsystems, ...) >>>> >>>> Also on top of this, having something like that would glorify >>>> configuration of server via XML, >>>> which is something we are trying to discourage in favor of CLI / >>>> mgmt api. >>> >>> Excuse my ignorance if this is already taken care of. But last time I >>> looked, using whatever management API was not very nice for container >>> runtime. i.e. configuration changed through API was not persisted. >>> I am wondering if this is already fixed somehow or is at least somebody >>> considering it as an important use case (I think it should). >> >> Persisting server configuration changes made via the supported >> management APIs back to the config file has been done in AS 7.0 and >> later. Its a fundamental requirement. > > I should have explained better. The config is saved on container. But > container being stateless loses changes on restart. At least for > OpenShift v2 that has been an issue. > > Shame on me I didn't look at OpenShift v3 integration. I'm not sure how > it is handled there. Perhaps I should have done my homework before > hijacking the thread. Sorry about that. Hopefully I can check wildfly on > v3 next week. Currently, in the case of OS/docker you would typically stage your config in advance, so you would use the CLI to author the config which is then included in your image. Note that since 10 we have offline CLI, which allows you to use management ops without a running server. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Thu Jul 21 14:34:18 2016 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 21 Jul 2016 13:34:18 -0500 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Message-ID: <234BD520-1A40-4B64-9182-533224DEC384@redhat.com> > On Jul 21, 2016, at 1:02 PM, Toby Crawley wrote: > >> >> Another problem is also that it relies on XSD which are not always 100% >> correct, which should be fixed (but that is another problem) >> > > I agree, if the schemas aren't correct, we should fix that. This is a bit of tangent, but the problem is that system properties would require us to have very complex schemas that would make it difficult for authorship tools to aid the user. We essentially end up with unions for everything with a union on an expression syntax pattern which allows almost anything. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Thu Jul 21 15:55:16 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 21 Jul 2016 14:55:16 -0500 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: <3635d158-5695-c134-e0d0-63dcfc1a9542@redhat.com> References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> <3635d158-5695-c134-e0d0-63dcfc1a9542@redhat.com> Message-ID: > On Jul 20, 2016, at 5:49 PM, Aleksandar Kostadinov wrote: > > Brian Stansberry wrote on 07/20/16 20:23: >> >>> On Jul 20, 2016, at 8:59 AM, Aleksandar Kostadinov >>> > wrote: >>> >>> Toma? Cerar wrote on 07/20/16 16:38: >>>> Most of my concerns about this ware already raised by Brian (l18n, extra >>>> size of distro, inconsistencies between subsystems, ...) >>>> >>>> Also on top of this, having something like that would glorify >>>> configuration of server via XML, >>>> which is something we are trying to discourage in favor of CLI / >>>> mgmt api. >>> >>> Excuse my ignorance if this is already taken care of. But last time I >>> looked, using whatever management API was not very nice for container >>> runtime. i.e. configuration changed through API was not persisted. >>> I am wondering if this is already fixed somehow or is at least somebody >>> considering it as an important use case (I think it should). >> >> Persisting server configuration changes made via the supported >> management APIs back to the config file has been done in AS 7.0 and >> later. Its a fundamental requirement. > > I should have explained better. The config is saved on container. But container being stateless loses changes on restart. At least for OpenShift v2 that has been an issue. > Thanks; I figured I was missing something. :) > Shame on me I didn't look at OpenShift v3 integration. I'm not sure how it is handled there. Perhaps I should have done my homework before hijacking the thread. Sorry about that. Hopefully I can check wildfly on v3 next week. Jason has already replied with what I was going to say about ways to prepare the config other than editing xml. I?ll just follow up a bit on what he said by mentioning that I presented at a meeting of the folks who prepare middleware images for use on OpenShift and showed them the offline CLI, which they were interested in since it eases scripting of configuration. I don?t know how much it?s been adapted since then though. I recognize that end users are going to want to edit xml, and that?s fine, people can use techniques that best fit their preferences. I think it?s mistaken though for *tools* to be based on manipulating our xml configs. We work hard to ensure long term compatibility in our management APIs, but we have no such guarantees about our xml formats. We encourage normal users to prefer our management APIs over xml for the same reason, but an individual having to check the xsd again if our format changes is a smaller problem than a tool having to be rewritten. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160721/99518e79/attachment.html From tomaz.cerar at gmail.com Thu Jul 21 18:45:11 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 22 Jul 2016 00:45:11 +0200 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> Message-ID: On Thu, Jul 21, 2016 at 8:02 PM, Toby Crawley wrote: > if you use the CLI for every config change, you have to spin up the > server before or as part of your build process in order to generate a > configuration file to put into your container. > Well that is not really needed anymore, we do have embeded server in CLI. so you can just have CLI script that starts with embed-server (or embed-host-controller for domain) and than all the cli commands you need. than all you need is ./jboss-cli.sh --file path-to-config.cli This will start embedded server in admin mode so you can configure it without fully starting it. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160722/b7f45c18/attachment.html From rory.odonnell at oracle.com Fri Jul 22 05:18:28 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 22 Jul 2016 10:18:28 +0100 Subject: [wildfly-dev] Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net Message-ID: <731edf84-8139-ae3f-2c0e-722c4f0d4af7@oracle.com> Hi Jason/Tomaz, Early Access b128 for JDK 9 is available on java.net, summary of changes are listed here . Early Access b127 (#5304) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here Early Access b03 for JDK 8u112 is available on java.net, summary of changes are listed here Alan Bateman posted new EA builds contain initial implementation of current proposals , more info [0] The jigsaw/jake forest has been updated with an initial implementation of the proposals that Mark brought to the jpms-spec-experts mailing list last week. For those that don't build from source then the EA build/downloads [1] has also been refreshed. Rgds,Rory [0] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008467.html [1] https://jdk9.java.net/jigsaw/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160722/531ff6dc/attachment.html From akostadi at redhat.com Sat Jul 23 15:34:46 2016 From: akostadi at redhat.com (Aleksandar Kostadinov) Date: Sat, 23 Jul 2016 22:34:46 +0300 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> <3635d158-5695-c134-e0d0-63dcfc1a9542@redhat.com> Message-ID: <6fd20be2-0967-e0f2-9742-492772c7ed8d@redhat.com> Brian Stansberry wrote on 07/21/16 22:55: > >> On Jul 20, 2016, at 5:49 PM, Aleksandar Kostadinov >> > wrote: >> >> Brian Stansberry wrote on 07/20/16 20:23: >>> >>>> On Jul 20, 2016, at 8:59 AM, Aleksandar Kostadinov >>>> >>>> > wrote: >>>> >>>> Toma? Cerar wrote on 07/20/16 16:38: >>>>> Most of my concerns about this ware already raised by Brian (l18n, >>>>> extra >>>>> size of distro, inconsistencies between subsystems, ...) >>>>> >>>>> Also on top of this, having something like that would glorify >>>>> configuration of server via XML, >>>>> which is something we are trying to discourage in favor of CLI / >>>>> mgmt api. >>>> >>>> Excuse my ignorance if this is already taken care of. But last time I >>>> looked, using whatever management API was not very nice for container >>>> runtime. i.e. configuration changed through API was not persisted. >>>> I am wondering if this is already fixed somehow or is at least somebody >>>> considering it as an important use case (I think it should). >>> >>> Persisting server configuration changes made via the supported >>> management APIs back to the config file has been done in AS 7.0 and >>> later. Its a fundamental requirement. >> >> I should have explained better. The config is saved on container. But >> container being stateless loses changes on restart. At least for >> OpenShift v2 that has been an issue. >> > > Thanks; I figured I was missing something. :) > >> Shame on me I didn't look at OpenShift v3 integration. I'm not sure >> how it is handled there. Perhaps I should have done my homework before >> hijacking the thread. Sorry about that. Hopefully I can check wildfly >> on v3 next week. > > Jason has already replied with what I was going to say about ways to > prepare the config other than editing xml. I?ll just follow up a bit on > what he said by mentioning that I presented at a meeting of the folks > who prepare middleware images for use on OpenShift and showed them the > offline CLI, which they were interested in since it eases scripting of > configuration. I don?t know how much it?s been adapted since then though. > > I recognize that end users are going to want to edit xml, and that?s > fine, people can use techniques that best fit their preferences. I think > it?s mistaken though for *tools* to be based on manipulating our xml > configs. We work hard to ensure long term compatibility in our > management APIs, but we have no such guarantees about our xml formats. > We encourage normal users to prefer our management APIs over xml for the > same reason, but an individual having to check the xsd again if our > format changes is a smaller problem than a tool having to be rewritten. Offline cli is a nice improvement. The OpenShift Wildfly image might be configured to read cli commands from a file in the app repo to apply configuration before launching server. This would not give the ability to reconfigure cluster using management console though. Maybe that's not important for container use cases. I don't know. Just would be nice somebody to figure out what an *ultimate* Wildfly UX in OpenShift means so that core dev team can implement necessary features to get there. Just retrofitting to the cloud has less chances to attract (I'm not saying we do that). From mmusgrov at redhat.com Mon Jul 25 05:28:13 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Mon, 25 Jul 2016 10:28:13 +0100 Subject: [wildfly-dev] Has anyone experienced surefire issues when using java.sql and JDK-9? Message-ID: When I run any surefire test (with reuseForks=false) that uses java.sql classes on jdk-9 it fails with: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project maven-surefire-plugin-example: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException -> [Help 1] If I run it with reuseForks=true it works fine. Has anyone seen this error yet? I thought I would check with this list before submitting a request to the surefire team. A trivial reproducer is attached. > tree src ??? pom.xml ??? src ??? main ? ??? java ? ??? J9Example.java ??? test ??? java ??? J9Test.java > mvn clean test -DreuseForks=false [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project maven-surefire-plugin-example: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException -> [Help 1] Mike -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/a0951a2d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: j9test.tar Type: application/x-tar Size: 10240 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/a0951a2d/attachment.tar From mmusgrov at redhat.com Mon Jul 25 05:45:34 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Mon, 25 Jul 2016 10:45:34 +0100 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: On Wed, Jul 6, 2016 at 9:37 AM, Wolf Fink wrote: > Also I expect EJB chains working, I mean the following sequences > - remote->EJB (@NotSupported @Supports - no Tx started) -> internal EJB > (no matter whether called via Local/Remote interface) with @ReqNew or > @Required > - remote->EJB (any Tx started @Supports @Required @RequiresNew @Mandatory) > -> internal EJB (no matter whether called via Local/Remote interface) > @RequiresNew > > I'm not sure about this use-case with a client (no matter whether it is a > standalone app or another server) > - client starts a Tx > - client call EJB1 in Tx which return > - -> start Graceful shutdown > Stuart, how does the EJB subsystem know that there is an outstanding transaction (the EJB call may have enlisted a resource during the call)? Is it our (ie the txn subsystem) responsibility to detect that there is an outstanding transaction and delay the shutdown until it completes or until the shutdown grace period elapses? --> end Graceful shutdown Mike - client call EJB2 in the same Tx > - maybe EJB2 is annotated with @RequiresNew and need to suspend Tx1 and > start a new one to succeed > > My expectation and hope is that such scenario is possible to continue and > finish successfully. > > Wolf > > > > > On Wed, Jul 6, 2016 at 1:00 AM, Stuart Douglas > wrote: > >> Local transaction creation has to be allowed during graceful shutdown. >> e.g. if a web request is in the process of running and it attempts to start >> a transaction this must be allowed (the core requirement of graceful >> shutdown is that requests that have already been accepted continue to run >> as normal). >> >> The only case when transactions should be disallowed are remote >> transactions, such as remote EJB and CORBA, which I think should already be >> dealt with at the respective endpoints (in terms of disallowing new >> transaction creation). I think the main thing that needs consideration here >> is what to do with EJB requests that would otherwise be rejected that are >> part of an existing remote transaction. We probably need some way of >> identifying these requests and allowing them to proceed. >> >> Stuart >> >> >> >> On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris >> wrote: >> >>> Hello, >>> >>> I?m in the process of writing an analysis document for >>> https://issues.jboss.org/browse/EAP7-459 and need your input. >>> Specifically I?m looking for the list of subsystems which might need to >>> create new transactions during the graceful shutdown. Normally new >>> transactions would not be allowed then, but this might stop other >>> subsystems to shutdown properly. If such subsystems exist we?ll need to >>> think of the way how to filter out their requests (e.g. providing SPI for >>> them). >>> >>> Thanks, >>> Gytis >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/cbd54197/attachment-0001.html From mmusgrov at redhat.com Mon Jul 25 06:18:34 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Mon, 25 Jul 2016 11:18:34 +0100 Subject: [wildfly-dev] Has anyone experienced surefire issues when using java.sql and JDK-9? In-Reply-To: References: Message-ID: I should have mentioned that this problem was introduced in jdk build 9-ea+122 (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when they addressed: d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module and I am currently testing with jdk build 9-ea+128 Mike On Mon, Jul 25, 2016 at 10:28 AM, Michael Musgrove wrote: > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on jdk-9 it fails with: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) > on project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: > java.sql.SQLException -> [Help 1] > > If I run it with reuseForks=true it works fine. > > Has anyone seen this error yet? > > I thought I would check with this list before submitting a request to the > surefire team. A trivial reproducer is attached. > > > tree src > > ??? pom.xml > ??? src > ??? main > ? ??? java > ? ??? J9Example.java > ??? test > ??? java > ??? J9Test.java > > > mvn clean test -DreuseForks=false > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) > on project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: > java.sql.SQLException -> [Help 1] > > Mike > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/1dcd1bb5/attachment.html From stuart.w.douglas at gmail.com Mon Jul 25 06:36:59 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 25 Jul 2016 20:36:59 +1000 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: The transaction subsystem is going to have to handle that (with some help from the EJB subsystem). Stuart On Mon, Jul 25, 2016 at 7:45 PM, Michael Musgrove wrote: > > > On Wed, Jul 6, 2016 at 9:37 AM, Wolf Fink wrote: > >> Also I expect EJB chains working, I mean the following sequences >> - remote->EJB (@NotSupported @Supports - no Tx started) -> internal EJB >> (no matter whether called via Local/Remote interface) with @ReqNew or >> @Required >> - remote->EJB (any Tx started @Supports @Required @RequiresNew >> @Mandatory) -> internal EJB (no matter whether called via Local/Remote >> interface) @RequiresNew >> >> I'm not sure about this use-case with a client (no matter whether it is a >> standalone app or another server) >> - client starts a Tx >> - client call EJB1 in Tx which return >> > - -> start Graceful shutdown >> > > Stuart, how does the EJB subsystem know that there is an outstanding > transaction (the EJB call may have enlisted a resource during the call)? Is > it our (ie the txn subsystem) responsibility to detect that there is an > outstanding transaction and delay the shutdown until it completes or until > the shutdown grace period elapses? > > --> end Graceful shutdown > > Mike > > - client call EJB2 in the same Tx >> - maybe EJB2 is annotated with @RequiresNew and need to suspend Tx1 and >> start a new one to succeed >> >> My expectation and hope is that such scenario is possible to continue and >> finish successfully. >> >> Wolf >> >> >> >> >> On Wed, Jul 6, 2016 at 1:00 AM, Stuart Douglas < >> stuart.w.douglas at gmail.com> wrote: >> >>> Local transaction creation has to be allowed during graceful shutdown. >>> e.g. if a web request is in the process of running and it attempts to start >>> a transaction this must be allowed (the core requirement of graceful >>> shutdown is that requests that have already been accepted continue to run >>> as normal). >>> >>> The only case when transactions should be disallowed are remote >>> transactions, such as remote EJB and CORBA, which I think should already be >>> dealt with at the respective endpoints (in terms of disallowing new >>> transaction creation). I think the main thing that needs consideration here >>> is what to do with EJB requests that would otherwise be rejected that are >>> part of an existing remote transaction. We probably need some way of >>> identifying these requests and allowing them to proceed. >>> >>> Stuart >>> >>> >>> >>> On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris >>> wrote: >>> >>>> Hello, >>>> >>>> I?m in the process of writing an analysis document for >>>> https://issues.jboss.org/browse/EAP7-459 and need your input. >>>> Specifically I?m looking for the list of subsystems which might need to >>>> create new transactions during the graceful shutdown. Normally new >>>> transactions would not be allowed then, but this might stop other >>>> subsystems to shutdown properly. If such subsystems exist we?ll need to >>>> think of the way how to filter out their requests (e.g. providing SPI for >>>> them). >>>> >>>> Thanks, >>>> Gytis >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/d6b435ad/attachment.html From mmusgrov at redhat.com Mon Jul 25 06:52:17 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Mon, 25 Jul 2016 11:52:17 +0100 Subject: [wildfly-dev] Transactions requirement during the graceful shutdown In-Reply-To: References: Message-ID: OK thank you for all your input on this task and I think we have enough to go on in order to proceed with JTA/JTS. But let's keep this thread open for the XTS support for the feature (we did have an earlier private email thread with subject "?XTS impact on suspend/resume? which was inconclusive). Mike On Mon, Jul 25, 2016 at 11:36 AM, Stuart Douglas wrote: > The transaction subsystem is going to have to handle that (with some help > from the EJB subsystem). > > Stuart > > > On Mon, Jul 25, 2016 at 7:45 PM, Michael Musgrove > wrote: > >> >> >> On Wed, Jul 6, 2016 at 9:37 AM, Wolf Fink wrote: >> >>> Also I expect EJB chains working, I mean the following sequences >>> - remote->EJB (@NotSupported @Supports - no Tx started) -> internal EJB >>> (no matter whether called via Local/Remote interface) with @ReqNew or >>> @Required >>> - remote->EJB (any Tx started @Supports @Required @RequiresNew >>> @Mandatory) -> internal EJB (no matter whether called via Local/Remote >>> interface) @RequiresNew >>> >>> I'm not sure about this use-case with a client (no matter whether it is >>> a standalone app or another server) >>> - client starts a Tx >>> - client call EJB1 in Tx which return >>> >> - -> start Graceful shutdown >>> >> >> Stuart, how does the EJB subsystem know that there is an outstanding >> transaction (the EJB call may have enlisted a resource during the call)? Is >> it our (ie the txn subsystem) responsibility to detect that there is an >> outstanding transaction and delay the shutdown until it completes or until >> the shutdown grace period elapses? >> >> --> end Graceful shutdown >> >> Mike >> >> - client call EJB2 in the same Tx >>> - maybe EJB2 is annotated with @RequiresNew and need to suspend Tx1 >>> and start a new one to succeed >>> >>> My expectation and hope is that such scenario is possible to continue >>> and finish successfully. >>> >>> Wolf >>> >>> >>> >>> >>> On Wed, Jul 6, 2016 at 1:00 AM, Stuart Douglas < >>> stuart.w.douglas at gmail.com> wrote: >>> >>>> Local transaction creation has to be allowed during graceful shutdown. >>>> e.g. if a web request is in the process of running and it attempts to start >>>> a transaction this must be allowed (the core requirement of graceful >>>> shutdown is that requests that have already been accepted continue to run >>>> as normal). >>>> >>>> The only case when transactions should be disallowed are remote >>>> transactions, such as remote EJB and CORBA, which I think should already be >>>> dealt with at the respective endpoints (in terms of disallowing new >>>> transaction creation). I think the main thing that needs consideration here >>>> is what to do with EJB requests that would otherwise be rejected that are >>>> part of an existing remote transaction. We probably need some way of >>>> identifying these requests and allowing them to proceed. >>>> >>>> Stuart >>>> >>>> >>>> >>>> On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I?m in the process of writing an analysis document for >>>>> https://issues.jboss.org/browse/EAP7-459 and need your input. >>>>> Specifically I?m looking for the list of subsystems which might need to >>>>> create new transactions during the graceful shutdown. Normally new >>>>> transactions would not be allowed then, but this might stop other >>>>> subsystems to shutdown properly. If such subsystems exist we?ll need to >>>>> think of the way how to filter out their requests (e.g. providing SPI for >>>>> them). >>>>> >>>>> Thanks, >>>>> Gytis >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> >> -- >> Michael Musgrove >> Transactions Team >> e: mmusgrov at redhat.com >> t: +44 191 243 0870 >> >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson >> (US), Charles Peters (US) >> >> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael >> O'Neill(Ireland) >> > > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/a8c9b7cf/attachment-0001.html From brian.stansberry at redhat.com Mon Jul 25 12:37:20 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Jul 2016 11:37:20 -0500 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: Message-ID: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> So what are we going to do about this? We?ve now reached the point where we need to start generating documentation for WildFly 11. And we?re beginning to require devs, at least those working for Red Hat, to write some sort of community doc as part of getting RFEs resolved. So docs infrastructure issue are beginning to impact our ability to get code changes in. My 2 cents: an asciidoctor and git based approach sounds good, but unless we have resources available to make it happen quickly basically starting from today, we need to devise a strategy based on continuing to use confluence. The biggest problem I saw in James? original post was "Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.? If that?s an inherent problem in cloning docs it?s hard to deal with. Having a living document isn?t so hard; you just write as if it?s a living doc and say things like ?Since WildFly 10? etc. But if you can?t snapshot the living doc for a release without creating a lot of bad links, that?s a problem. > On May 12, 2016, at 10:32 PM, James Perkins wrote: > > I've been reading the WildFly documentation [1] quite a bit lately and noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. Sometimes documentation is just plain out of date referencing behavior that has possibly been removed or replaced by something better. > > This has happened because we keep copying the documentation over each time we have a new version. Overall this makes sense as a lot of it doesn't need to be changed. However it leaves reading the documentation confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in the text with a link for AS72 isn't very user friendly as I'm sure we can all agree. > > There's a few different ways we could go with this. > > Approach 1: > One, probably the easiest, is to use a single confluence project. We'd need to remove the version numbers from the text, which I think we should do anyway. Instead of referencing WildFly 10 we just reference it as WildFly. > > An issue I can think of with this approach is some how annotating or referencing that parts of the documentation only work with ${version}. For example new features would have to be noted they only work with ${version}+. > > > Approach 2: > Essentially he same as approach 1 only do allow different Confluence projects for the different Java EE target version. So WIldFly 8, 9 and 10 would all be documented under something like WFLYEE7. > > Approach 3 > Switch to using something like asciidoc which can use variables and generate links to the correct content. While this approach is probably takes the most work up front, it seems like like it would be easier to maintain between releases. > > Any other suggestions are welcome. > > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/980f0f48/attachment.html From jperkins at redhat.com Mon Jul 25 13:10:21 2016 From: jperkins at redhat.com (James Perkins) Date: Mon, 25 Jul 2016 10:10:21 -0700 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> Message-ID: Thanks for bringing this back up Brian. I was just about to do the same :) The only idea I'm personally opposed to is the "fork for every release" Though thinking of it as a live doc where we snapshot it for a release is not a bad idea. We could just have a WFLY project that we snapshot for every release. We just need to be careful about using versioning when writing the docs, unless it's a "Since WIldFly whatever" type of thing. We just want to avoid the "In WildFly x". With regards to the linking problem, I'm not sure if we (myself included) are just linking incorrectly between documents or it's just a limitation of Confluence. It looks like most links are done like [WFLY8:Implicit module dependencies for deployments]. I noticed some don't have the "WFLY${version}" prefix so maybe that's the way to go. When you use the linking function in confluence it adds the doc reference to the link which could be part of the problem. There are also docs that just point to old information. Like the main page references Java EE 6 getting started [1]. The Some pages are just dead too [2]. In some places, I tried to fix the ones I found in the WFLY10 docs, it just references the wrong version of WildFly. A lot of XML references too which likely point to older namespaces, maybe not a huge deal though. Overall they're not bad. They just need a little TLC. I do think too there is probably some bigger chunks we can get rid of like a lot of the quickstart section since we have it all on GitHub. Also subsystem references could be replaced with WildScribe. Anyway, I'm up for anything that allows the documentation to be consistent, easy to write and easy to use. The main attraction for me to asciidoc is being able to use git for versioning as well as being able to use variables. I don't however know how well asciidoc deals with multiple documents and combining them together. Regardless of the direction I'm willing to put some time into fixing/updating it. I just think before we invest any time we make a firm decision on the direction we want to go. [1]: https://docs.jboss.org/author/display/WFLY10/Documentation#Documentation-DeveloperGuides [2]: https://docs.jboss.org/author/display/WFLY10/Development+Guidelines+and+Recommended+Practices On Mon, Jul 25, 2016 at 9:37 AM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > So what are we going to do about this? > > We?ve now reached the point where we need to start generating > documentation for WildFly 11. And we?re beginning to require devs, at least > those working for Red Hat, to write some sort of community doc as part of > getting RFEs resolved. So docs infrastructure issue are beginning to impact > our ability to get code changes in. > > My 2 cents: an asciidoctor and git based approach sounds good, but unless > we have resources available to make it happen quickly basically starting > from today, we need to devise a strategy based on continuing to use > confluence. > > The biggest problem I saw in James? original post was "Links take you to > old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.? If > that?s an inherent problem in cloning docs it?s hard to deal with. Having a > living document isn?t so hard; you just write as if it?s a living doc and > say things like ?Since WildFly 10? etc. But if you can?t snapshot the > living doc for a release without creating a lot of bad links, that?s a > problem. > > On May 12, 2016, at 10:32 PM, James Perkins wrote: > > I've been reading the WildFly documentation [1] quite a bit lately and > noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly > 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you > to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. > Sometimes documentation is just plain out of date referencing behavior that > has possibly been removed or replaced by something better. > > This has happened because we keep copying the documentation over each time > we have a new version. Overall this makes sense as a lot of it doesn't need > to be changed. However it leaves reading the documentation confusing. > Reading documentation for WildFly 10 and seeing WildFly 8 in the text with > a link for AS72 isn't very user friendly as I'm sure we can all agree. > > There's a few different ways we could go with this. > > Approach 1: > One, probably the easiest, is to use a single confluence project. We'd > need to remove the version numbers from the text, which I think we should > do anyway. Instead of referencing WildFly 10 we just reference it as > WildFly. > > An issue I can think of with this approach is some how annotating or > referencing that parts of the documentation only work with ${version}. For > example new features would have to be noted they only work with ${version}+. > > > Approach 2: > Essentially he same as approach 1 only do allow different Confluence > projects for the different Java EE target version. So WIldFly 8, 9 and 10 > would all be documented under something like WFLYEE7. > > Approach 3 > Switch to using something like asciidoc which can use variables and > generate links to the correct content. While this approach is probably > takes the most work up front, it seems like like it would be easier to > maintain between releases. > > Any other suggestions are welcome. > > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/81d0be90/attachment-0001.html From jperkins at redhat.com Mon Jul 25 13:40:12 2016 From: jperkins at redhat.com (James Perkins) Date: Mon, 25 Jul 2016 10:40:12 -0700 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> Message-ID: Just one more follow as Tomaz mentioned to me, another option would be https://www.gitbook.com/. Both WildFly Swarm [1] and JBeret [2] use it. [1]: https://wildfly-swarm.gitbooks.io/wildfly-swarm-users-guide/content/ [2]: https://jberet.gitbooks.io/jberet-user-guide/content/ On Mon, Jul 25, 2016 at 10:10 AM, James Perkins wrote: > Thanks for bringing this back up Brian. I was just about to do the same :) > > The only idea I'm personally opposed to is the "fork for every release" > Though thinking of it as a live doc where we snapshot it for a release is > not a bad idea. We could just have a WFLY project that we snapshot for > every release. We just need to be careful about using versioning when > writing the docs, unless it's a "Since WIldFly whatever" type of thing. We > just want to avoid the "In WildFly x". > > With regards to the linking problem, I'm not sure if we (myself included) > are just linking incorrectly between documents or it's just a limitation of > Confluence. It looks like most links are done like [WFLY8:Implicit module > dependencies for deployments]. I noticed some don't have the > "WFLY${version}" prefix so maybe that's the way to go. When you use the > linking function in confluence it adds the doc reference to the link which > could be part of the problem. > > There are also docs that just point to old information. Like the main page > references Java EE 6 getting started [1]. The Some pages are just dead too > [2]. In some places, I tried to fix the ones I found in the WFLY10 docs, it > just references the wrong version of WildFly. A lot of XML references too > which likely point to older namespaces, maybe not a huge deal though. > > Overall they're not bad. They just need a little TLC. I do think too there > is probably some bigger chunks we can get rid of like a lot of the > quickstart section since we have it all on GitHub. Also subsystem > references could be replaced with WildScribe. > > Anyway, I'm up for anything that allows the documentation to be > consistent, easy to write and easy to use. The main attraction for me to > asciidoc is being able to use git for versioning as well as being able to > use variables. I don't however know how well asciidoc deals with multiple > documents and combining them together. > > Regardless of the direction I'm willing to put some time into > fixing/updating it. I just think before we invest any time we make a firm > decision on the direction we want to go. > > > [1]: > https://docs.jboss.org/author/display/WFLY10/Documentation#Documentation-DeveloperGuides > [2]: > https://docs.jboss.org/author/display/WFLY10/Development+Guidelines+and+Recommended+Practices > > On Mon, Jul 25, 2016 at 9:37 AM, Brian Stansberry < > brian.stansberry at redhat.com> wrote: > >> So what are we going to do about this? >> >> We?ve now reached the point where we need to start generating >> documentation for WildFly 11. And we?re beginning to require devs, at least >> those working for Red Hat, to write some sort of community doc as part of >> getting RFEs resolved. So docs infrastructure issue are beginning to impact >> our ability to get code changes in. >> >> My 2 cents: an asciidoctor and git based approach sounds good, but unless >> we have resources available to make it happen quickly basically starting >> from today, we need to devise a strategy based on continuing to use >> confluence. >> >> The biggest problem I saw in James? original post was "Links take you to >> old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.? If >> that?s an inherent problem in cloning docs it?s hard to deal with. Having a >> living document isn?t so hard; you just write as if it?s a living doc and >> say things like ?Since WildFly 10? etc. But if you can?t snapshot the >> living doc for a release without creating a lot of bad links, that?s a >> problem. >> >> On May 12, 2016, at 10:32 PM, James Perkins wrote: >> >> I've been reading the WildFly documentation [1] quite a bit lately and >> noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly >> 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you >> to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. >> Sometimes documentation is just plain out of date referencing behavior that >> has possibly been removed or replaced by something better. >> >> This has happened because we keep copying the documentation over each >> time we have a new version. Overall this makes sense as a lot of it doesn't >> need to be changed. However it leaves reading the documentation confusing. >> Reading documentation for WildFly 10 and seeing WildFly 8 in the text with >> a link for AS72 isn't very user friendly as I'm sure we can all agree. >> >> There's a few different ways we could go with this. >> >> Approach 1: >> One, probably the easiest, is to use a single confluence project. We'd >> need to remove the version numbers from the text, which I think we should >> do anyway. Instead of referencing WildFly 10 we just reference it as >> WildFly. >> >> An issue I can think of with this approach is some how annotating or >> referencing that parts of the documentation only work with ${version}. For >> example new features would have to be noted they only work with ${version}+. >> >> >> Approach 2: >> Essentially he same as approach 1 only do allow different Confluence >> projects for the different Java EE target version. So WIldFly 8, 9 and 10 >> would all be documented under something like WFLYEE7. >> >> Approach 3 >> Switch to using something like asciidoc which can use variables and >> generate links to the correct content. While this approach is probably >> takes the most work up front, it seems like like it would be easier to >> maintain between releases. >> >> Any other suggestions are welcome. >> >> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation >> >> -- >> James R. Perkins >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> JBoss by Red Hat >> >> >> >> > > > -- > James R. Perkins > JBoss by Red Hat > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/3c831d03/attachment.html From ehugonne at redhat.com Mon Jul 25 13:57:30 2016 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 25 Jul 2016 19:57:30 +0200 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> Message-ID: Hi, Should we have a maintenance branch for the current stable version documentation (maybe on gitbook) and a living documentation (using github rendering) or just the living doc ? On 25/07/2016 19:40, James Perkins wrote: > Just one more follow as Tomaz mentioned to me, another option would be https://www.gitbook.com/. Both WildFly Swarm [1] and JBeret [2] use it. > > [1]: https://wildfly-swarm.gitbooks.io/wildfly-swarm-users-guide/content/ > [2]: https://jberet.gitbooks.io/jberet-user-guide/content/ > > On Mon, Jul 25, 2016 at 10:10 AM, James Perkins > wrote: > > Thanks for bringing this back up Brian. I was just about to do the same :) > > The only idea I'm personally opposed to is the "fork for every release" Though thinking of it as a live doc where we snapshot it for a > release is not a bad idea. We could just have a WFLY project that we snapshot for every release. We just need to be careful about using > versioning when writing the docs, unless it's a "Since WIldFly whatever" type of thing. We just want to avoid the "In WildFly x". > > With regards to the linking problem, I'm not sure if we (myself included) are just linking incorrectly between documents or it's just a > limitation of Confluence. It looks like most links are done like [WFLY8:Implicit module dependencies for deployments]. I noticed some > don't have the "WFLY${version}" prefix so maybe that's the way to go. When you use the linking function in confluence it adds the doc > reference to the link which could be part of the problem. > > There are also docs that just point to old information. Like the main page references Java EE 6 getting started [1]. The Some pages are > just dead too [2]. In some places, I tried to fix the ones I found in the WFLY10 docs, it just references the wrong version of WildFly. > A lot of XML references too which likely point to older namespaces, maybe not a huge deal though. > > Overall they're not bad. They just need a little TLC. I do think too there is probably some bigger chunks we can get rid of like a lot > of the quickstart section since we have it all on GitHub. Also subsystem references could be replaced with WildScribe. > > Anyway, I'm up for anything that allows the documentation to be consistent, easy to write and easy to use. The main attraction for me to > asciidoc is being able to use git for versioning as well as being able to use variables. I don't however know how well asciidoc deals > with multiple documents and combining them together. > > Regardless of the direction I'm willing to put some time into fixing/updating it. I just think before we invest any time we make a firm > decision on the direction we want to go. > > > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation#Documentation-DeveloperGuides > [2]: https://docs.jboss.org/author/display/WFLY10/Development+Guidelines+and+Recommended+Practices > > On Mon, Jul 25, 2016 at 9:37 AM, Brian Stansberry > wrote: > > So what are we going to do about this? > > We?ve now reached the point where we need to start generating documentation for WildFly 11. And we?re beginning to require devs, at > least those working for Red Hat, to write some sort of community doc as part of getting RFEs resolved. So docs infrastructure issue > are beginning to impact our ability to get code changes in. > > My 2 cents: an asciidoctor and git based approach sounds good, but unless we have resources available to make it happen quickly > basically starting from today, we need to devise a strategy based on continuing to use confluence. > > The biggest problem I saw in James? original post was "Links take you to old documentation, e.g. a WFLY10 doc takes you to a page > for WFLY8.? If that?s an inherent problem in cloning docs it?s hard to deal with. Having a living document isn?t so hard; you just > write as if it?s a living doc and say things like ?Since WildFly 10? etc. But if you can?t snapshot the living doc for a release > without creating a lot of bad links, that?s a problem. > >> On May 12, 2016, at 10:32 PM, James Perkins > wrote: >> >> I've been reading the WildFly documentation [1] quite a bit lately and noticing a lot of issues. Sometimes it references WildFly 8 >> in the WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you to old documentation, e.g. a WFLY10 doc >> takes you to a page for WFLY8. Sometimes documentation is just plain out of date referencing behavior that has possibly been >> removed or replaced by something better. >> >> This has happened because we keep copying the documentation over each time we have a new version. Overall this makes sense as a >> lot of it doesn't need to be changed. However it leaves reading the documentation confusing. Reading documentation for WildFly 10 >> and seeing WildFly 8 in the text with a link for AS72 isn't very user friendly as I'm sure we can all agree. >> >> There's a few different ways we could go with this. >> >> Approach 1: >> One, probably the easiest, is to use a single confluence project. We'd need to remove the version numbers from the text, which I >> think we should do anyway. Instead of referencing WildFly 10 we just reference it as WildFly. >> >> An issue I can think of with this approach is some how annotating or referencing that parts of the documentation only work with >> ${version}. For example new features would have to be noted they only work with ${version}+. >> >> >> Approach 2: >> Essentially he same as approach 1 only do allow different Confluence projects for the different Java EE target version. So WIldFly >> 8, 9 and 10 would all be documented under something like WFLYEE7. >> >> Approach 3 >> Switch to using something like asciidoc which can use variables and generate links to the correct content. While this approach is >> probably takes the most work up front, it seems like like it would be easier to maintain between releases. >> >> Any other suggestions are welcome. >> >> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation >> >> -- >> James R. Perkins >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > > > > -- > James R. Perkins > JBoss by Red Hat > > > > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/39ce395d/attachment-0001.bin From bmcwhirt at redhat.com Mon Jul 25 14:46:10 2016 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Mon, 25 Jul 2016 14:46:10 -0400 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> Message-ID: I?ve been quite pleased with GitBook. I?ve not worked with git branches with it, but it does work with commits (and occasionally with tags, but sometimes I?ve failed to make them work). Basically, every commit produces a new published site, and you can ref any sha1 (or tag, sometimes). So we keep the repository HEAD as ?living? on-going document. At each release, we tag and then reference that SHA1 for that release?s version of the docs. See http://wildfly-swarm.io/documentation/ We use AsciiDoc but you can use Markdown also and make that choice on a per-chapter basis. Additionally, there is a 100% local toolchain, so you can work locally with your favorite editor and see the build in real-time. Plus, there?s a ?native? editor, which is basically a local version of the online editor, based upon Chrome. I don?t love it, especially since they took away my vi keybindings. It also supports plugins, which we haven?t really explored yet, but they?re just node.js packages from npm. I also talked Stian/Bill into GitBook for Keycloak. Another benefit: it doesn?t take 45 seconds to load a page you find via Google because it?s based on a jboss.org-hosted Confluence. -Bob On Mon, Jul 25, 2016 at 1:40 PM, James Perkins wrote: > Just one more follow as Tomaz mentioned to me, another option would be > https://www.gitbook.com/. Both WildFly Swarm [1] and JBeret [2] use it. > > [1]: https://wildfly-swarm.gitbooks.io/wildfly-swarm-users-guide/content/ > [2]: https://jberet.gitbooks.io/jberet-user-guide/content/ > > On Mon, Jul 25, 2016 at 10:10 AM, James Perkins > wrote: > >> Thanks for bringing this back up Brian. I was just about to do the same :) >> >> The only idea I'm personally opposed to is the "fork for every release" >> Though thinking of it as a live doc where we snapshot it for a release is >> not a bad idea. We could just have a WFLY project that we snapshot for >> every release. We just need to be careful about using versioning when >> writing the docs, unless it's a "Since WIldFly whatever" type of thing. We >> just want to avoid the "In WildFly x". >> >> With regards to the linking problem, I'm not sure if we (myself included) >> are just linking incorrectly between documents or it's just a limitation of >> Confluence. It looks like most links are done like [WFLY8:Implicit module >> dependencies for deployments]. I noticed some don't have the >> "WFLY${version}" prefix so maybe that's the way to go. When you use the >> linking function in confluence it adds the doc reference to the link which >> could be part of the problem. >> >> There are also docs that just point to old information. Like the main >> page references Java EE 6 getting started [1]. The Some pages are just >> dead too [2]. In some places, I tried to fix the ones I found in the WFLY10 >> docs, it just references the wrong version of WildFly. A lot of XML >> references too which likely point to older namespaces, maybe not a huge >> deal though. >> >> Overall they're not bad. They just need a little TLC. I do think too >> there is probably some bigger chunks we can get rid of like a lot of the >> quickstart section since we have it all on GitHub. Also subsystem >> references could be replaced with WildScribe. >> >> Anyway, I'm up for anything that allows the documentation to be >> consistent, easy to write and easy to use. The main attraction for me to >> asciidoc is being able to use git for versioning as well as being able to >> use variables. I don't however know how well asciidoc deals with multiple >> documents and combining them together. >> >> Regardless of the direction I'm willing to put some time into >> fixing/updating it. I just think before we invest any time we make a firm >> decision on the direction we want to go. >> >> >> [1]: >> https://docs.jboss.org/author/display/WFLY10/Documentation#Documentation-DeveloperGuides >> [2]: >> https://docs.jboss.org/author/display/WFLY10/Development+Guidelines+and+Recommended+Practices >> >> On Mon, Jul 25, 2016 at 9:37 AM, Brian Stansberry < >> brian.stansberry at redhat.com> wrote: >> >>> So what are we going to do about this? >>> >>> We?ve now reached the point where we need to start generating >>> documentation for WildFly 11. And we?re beginning to require devs, at least >>> those working for Red Hat, to write some sort of community doc as part of >>> getting RFEs resolved. So docs infrastructure issue are beginning to impact >>> our ability to get code changes in. >>> >>> My 2 cents: an asciidoctor and git based approach sounds good, but >>> unless we have resources available to make it happen quickly basically >>> starting from today, we need to devise a strategy based on continuing to >>> use confluence. >>> >>> The biggest problem I saw in James? original post was "Links take you to >>> old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.? If >>> that?s an inherent problem in cloning docs it?s hard to deal with. Having a >>> living document isn?t so hard; you just write as if it?s a living doc and >>> say things like ?Since WildFly 10? etc. But if you can?t snapshot the >>> living doc for a release without creating a lot of bad links, that?s a >>> problem. >>> >>> On May 12, 2016, at 10:32 PM, James Perkins wrote: >>> >>> I've been reading the WildFly documentation [1] quite a bit lately and >>> noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly >>> 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you >>> to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. >>> Sometimes documentation is just plain out of date referencing behavior that >>> has possibly been removed or replaced by something better. >>> >>> This has happened because we keep copying the documentation over each >>> time we have a new version. Overall this makes sense as a lot of it doesn't >>> need to be changed. However it leaves reading the documentation confusing. >>> Reading documentation for WildFly 10 and seeing WildFly 8 in the text with >>> a link for AS72 isn't very user friendly as I'm sure we can all agree. >>> >>> There's a few different ways we could go with this. >>> >>> Approach 1: >>> One, probably the easiest, is to use a single confluence project. We'd >>> need to remove the version numbers from the text, which I think we should >>> do anyway. Instead of referencing WildFly 10 we just reference it as >>> WildFly. >>> >>> An issue I can think of with this approach is some how annotating or >>> referencing that parts of the documentation only work with ${version}. For >>> example new features would have to be noted they only work with ${version}+. >>> >>> >>> Approach 2: >>> Essentially he same as approach 1 only do allow different Confluence >>> projects for the different Java EE target version. So WIldFly 8, 9 and 10 >>> would all be documented under something like WFLYEE7. >>> >>> Approach 3 >>> Switch to using something like asciidoc which can use variables and >>> generate links to the correct content. While this approach is probably >>> takes the most work up front, it seems like like it would be easier to >>> maintain between releases. >>> >>> Any other suggestions are welcome. >>> >>> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation >>> >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> -- >>> Brian Stansberry >>> Manager, Senior Principal Software Engineer >>> JBoss by Red Hat >>> >>> >>> >>> >> >> >> -- >> James R. Perkins >> JBoss by Red Hat >> > > > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/27c63e12/attachment.html From jperkins at redhat.com Mon Jul 25 14:46:18 2016 From: jperkins at redhat.com (James Perkins) Date: Mon, 25 Jul 2016 11:46:18 -0700 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> Message-ID: On Mon, Jul 25, 2016 at 10:57 AM, Emmanuel Hugonnet wrote: > Hi, > Should we have a maintenance branch for the current stable version > documentation (maybe on gitbook) and a living documentation (using github > rendering) or just the living doc ? > > > I think it kind of depends on the framework we choose. If we stick with Confluence I think we could just have a WFLY document id and then once we release we make a copy of that version. The downside is if you do find a mistake you might have to change it in a few different spots. Regardless of the framework it could be a bit tricky for micro-releases if master has already changed when making a snapshot. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/a30aab8c/attachment.html From brian.stansberry at redhat.com Mon Jul 25 16:52:37 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Jul 2016 15:52:37 -0500 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> Message-ID: <074DCD1F-ABF0-4FB1-9924-29041A406FBA@redhat.com> Who is hosting the gitbook stuff? Lazy question I suspect, but I promise I poked around a bit first and it wasn?t completely obvious. :) > On Jul 25, 2016, at 1:46 PM, Bob McWhirter wrote: > > I?ve been quite pleased with GitBook. > > I?ve not worked with git branches with it, but it does work with commits (and occasionally with tags, but sometimes I?ve failed to make them work). > > Basically, every commit produces a new published site, and you can ref any sha1 (or tag, sometimes). > > So we keep the repository HEAD as ?living? on-going document. > > At each release, we tag and then reference that SHA1 for that release?s version of the docs. > > See > > http://wildfly-swarm.io/documentation/ > > We use AsciiDoc but you can use Markdown also and make that choice on a per-chapter basis. > > Additionally, there is a 100% local toolchain, so you can work locally with your favorite editor and see the build in real-time. > > Plus, there?s a ?native? editor, which is basically a local version of the online editor, based upon Chrome. I don?t love it, especially since they took away my vi keybindings. > > It also supports plugins, which we haven?t really explored yet, but they?re just node.js packages from npm. > > I also talked Stian/Bill into GitBook for Keycloak. > > Another benefit: it doesn?t take 45 seconds to load a page you find via Google because it?s based on a jboss.org-hosted Confluence. > > -Bob > > > On Mon, Jul 25, 2016 at 1:40 PM, James Perkins > wrote: > Just one more follow as Tomaz mentioned to me, another option would be https://www.gitbook.com/ . Both WildFly Swarm [1] and JBeret [2] use it. > > [1]: https://wildfly-swarm.gitbooks.io/wildfly-swarm-users-guide/content/ > [2]: https://jberet.gitbooks.io/jberet-user-guide/content/ > > On Mon, Jul 25, 2016 at 10:10 AM, James Perkins > wrote: > Thanks for bringing this back up Brian. I was just about to do the same :) > > The only idea I'm personally opposed to is the "fork for every release" Though thinking of it as a live doc where we snapshot it for a release is not a bad idea. We could just have a WFLY project that we snapshot for every release. We just need to be careful about using versioning when writing the docs, unless it's a "Since WIldFly whatever" type of thing. We just want to avoid the "In WildFly x". > > With regards to the linking problem, I'm not sure if we (myself included) are just linking incorrectly between documents or it's just a limitation of Confluence. It looks like most links are done like [WFLY8:Implicit module dependencies for deployments]. I noticed some don't have the "WFLY${version}" prefix so maybe that's the way to go. When you use the linking function in confluence it adds the doc reference to the link which could be part of the problem. > > There are also docs that just point to old information. Like the main page references Java EE 6 getting started [1]. The Some pages are just dead too [2]. In some places, I tried to fix the ones I found in the WFLY10 docs, it just references the wrong version of WildFly. A lot of XML references too which likely point to older namespaces, maybe not a huge deal though. > > Overall they're not bad. They just need a little TLC. I do think too there is probably some bigger chunks we can get rid of like a lot of the quickstart section since we have it all on GitHub. Also subsystem references could be replaced with WildScribe. > > Anyway, I'm up for anything that allows the documentation to be consistent, easy to write and easy to use. The main attraction for me to asciidoc is being able to use git for versioning as well as being able to use variables. I don't however know how well asciidoc deals with multiple documents and combining them together. > > Regardless of the direction I'm willing to put some time into fixing/updating it. I just think before we invest any time we make a firm decision on the direction we want to go. > > > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation#Documentation-DeveloperGuides > [2]: https://docs.jboss.org/author/display/WFLY10/Development+Guidelines+and+Recommended+Practices > > On Mon, Jul 25, 2016 at 9:37 AM, Brian Stansberry > wrote: > So what are we going to do about this? > > We?ve now reached the point where we need to start generating documentation for WildFly 11. And we?re beginning to require devs, at least those working for Red Hat, to write some sort of community doc as part of getting RFEs resolved. So docs infrastructure issue are beginning to impact our ability to get code changes in. > > My 2 cents: an asciidoctor and git based approach sounds good, but unless we have resources available to make it happen quickly basically starting from today, we need to devise a strategy based on continuing to use confluence. > > The biggest problem I saw in James? original post was "Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.? If that?s an inherent problem in cloning docs it?s hard to deal with. Having a living document isn?t so hard; you just write as if it?s a living doc and say things like ?Since WildFly 10? etc. But if you can?t snapshot the living doc for a release without creating a lot of bad links, that?s a problem. > >> On May 12, 2016, at 10:32 PM, James Perkins > wrote: >> >> I've been reading the WildFly documentation [1] quite a bit lately and noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. Sometimes documentation is just plain out of date referencing behavior that has possibly been removed or replaced by something better. >> >> This has happened because we keep copying the documentation over each time we have a new version. Overall this makes sense as a lot of it doesn't need to be changed. However it leaves reading the documentation confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in the text with a link for AS72 isn't very user friendly as I'm sure we can all agree. >> >> There's a few different ways we could go with this. >> >> Approach 1: >> One, probably the easiest, is to use a single confluence project. We'd need to remove the version numbers from the text, which I think we should do anyway. Instead of referencing WildFly 10 we just reference it as WildFly. >> >> An issue I can think of with this approach is some how annotating or referencing that parts of the documentation only work with ${version}. For example new features would have to be noted they only work with ${version}+. >> >> >> Approach 2: >> Essentially he same as approach 1 only do allow different Confluence projects for the different Java EE target version. So WIldFly 8, 9 and 10 would all be documented under something like WFLYEE7. >> >> Approach 3 >> Switch to using something like asciidoc which can use variables and generate links to the correct content. While this approach is probably takes the most work up front, it seems like like it would be easier to maintain between releases. >> >> Any other suggestions are welcome. >> >> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation >> >> -- >> James R. Perkins >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > > > > -- > James R. Perkins > JBoss by Red Hat > > > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/dbdb6066/attachment-0001.html From tomaz.cerar at gmail.com Mon Jul 25 17:32:24 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 25 Jul 2016 23:32:24 +0200 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: <074DCD1F-ABF0-4FB1-9924-29041A406FBA@redhat.com> References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> <074DCD1F-ABF0-4FB1-9924-29041A406FBA@redhat.com> Message-ID: On Mon, Jul 25, 2016 at 10:52 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > Who is hosting the gitbook stuff? whois and friends say it is ec2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/a1b838f3/attachment.html From brian.stansberry at redhat.com Mon Jul 25 17:56:24 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Jul 2016 16:56:24 -0500 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> <074DCD1F-ABF0-4FB1-9924-29041A406FBA@redhat.com> Message-ID: <3E885F26-A86B-42BE-B427-344035DE3BCD@redhat.com> Thanks. That?s an implementation choice of whoever is providing this service though. It seems it?s a company named Friend Code, Inc. > On Jul 25, 2016, at 4:32 PM, Toma? Cerar wrote: > > > On Mon, Jul 25, 2016 at 10:52 PM, Brian Stansberry > wrote: > Who is hosting the gitbook stuff? > > > whois and friends say it is ec2 -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/9454e7a1/attachment.html From hbraun at redhat.com Tue Jul 26 01:54:30 2016 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 26 Jul 2016 07:54:30 +0200 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: <3E885F26-A86B-42BE-B427-344035DE3BCD@redhat.com> References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> <074DCD1F-ABF0-4FB1-9924-29041A406FBA@redhat.com> <3E885F26-A86B-42BE-B427-344035DE3BCD@redhat.com> Message-ID: <6B401EB0-48A0-4114-AC92-A7500F43CC40@redhat.com> Don't know the company behind gitbook, or how they host their site. But you can also take the gitbooks npm and run it on your own. It's also a nice way to edit/view docs locally. But for the majority of cases you can simply edit the file right on github, which is really convinient. I've spend quiet some time with this for swarm, so if you need any help with this contact me offline. Regards, Heiko > Am 25.07.2016 um 23:56 n Brian Stansberry : > > Thanks. That?s an implementation choice of whoever is providing this service though. > > It seems it?s a company named Friend Code, Inc. > >> On Jul 25, 2016, at 4:32 PM, Toma? Cerar wrote: >> >> >>> On Mon, Jul 25, 2016 at 10:52 PM, Brian Stansberry wrote: >>> Who is hosting the gitbook stuff? >> >> >> whois and friends say it is ec2 > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160726/6e5eed3a/attachment.html From ropalka at redhat.com Tue Jul 26 18:51:12 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 27 Jul 2016 00:51:12 +0200 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> Message-ID: <3985018c-8eaf-e146-254d-d4fd884baa6a@redhat.com> Just FYI there's documentation framework decision going on on Linux Kernel these days: http://lwn.net/Articles/692704/ There are pros and cons being evaluated of different doc. generation frameworks. Rio On 07/25/2016 08:46 PM, James Perkins wrote: > > > On Mon, Jul 25, 2016 at 10:57 AM, Emmanuel Hugonnet > > wrote: > > Hi, > Should we have a maintenance branch for the current stable version > documentation (maybe on gitbook) and a living documentation (using > github > rendering) or just the living doc ? > > > > I think it kind of depends on the framework we choose. If we stick > with Confluence I think we could just have a WFLY document id and then > once we release we make a copy of that version. The downside is if you > do find a mistake you might have to change it in a few different spots. > > Regardless of the framework it could be a bit tricky for > micro-releases if master has already changed when making a snapshot. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Richard Opalka Principal Software Engineer Red Hat JBoss Middleware Mobile: +420 731 186 942 E-mail: ropalka at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160727/2c58b9fa/attachment.html From mkouba at redhat.com Wed Jul 27 03:26:13 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 27 Jul 2016 09:26:13 +0200 Subject: [wildfly-dev] How to work with an optional module dependency Message-ID: Hi all, the Weld/CDI team is working on SWARM-568 [1] - to slim the module dependencies of the Weld subsystem. We will need to modify Weld subsystem so that some dependencies (EJB, JPA, etc.) are optional. And this brings additional complexity in the code. I wonder whether there are any tips/recommendations/guidelines/examples/etc how to work with an optional module dependency? More specifically, what is the best approach to detect a module availability? In Java SE one would usually take the ClassLoader and try to load some specific class... Also what is the safe and reliable way of "handling" the code which depends on an optional module. It seems a JVM impl may choose to link everything up front. So I think the only way is to create a separate class containing all the logic and call this class via reflection. Thanks a lot, Martin [1] https://issues.jboss.org/browse/SWARM-568 -- Martin Kouba Software Engineer Red Hat, Czech Republic From hbraun at redhat.com Wed Jul 27 03:42:08 2016 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 27 Jul 2016 09:42:08 +0200 Subject: [wildfly-dev] How to work with an optional module dependency In-Reply-To: References: Message-ID: <515A26D4-CCE0-4CA5-805D-47FF3EA3E632@redhat.com> Maybe using the ServiceLoader? https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html This should work fine with JBoss Modules as well. /Heiko > On 27 Jul 2016, at 09:26, Martin Kouba wrote: > > Hi all, > > the Weld/CDI team is working on SWARM-568 [1] - to slim the module > dependencies of the Weld subsystem. We will need to modify Weld > subsystem so that some dependencies (EJB, JPA, etc.) are optional. And > this brings additional complexity in the code. > > I wonder whether there are any > tips/recommendations/guidelines/examples/etc how to work with an > optional module dependency? > > More specifically, what is the best approach to detect a module > availability? In Java SE one would usually take the ClassLoader and try > to load some specific class... > > Also what is the safe and reliable way of "handling" the code which > depends on an optional module. It seems a JVM impl may choose to link > everything up front. So I think the only way is to create a separate > class containing all the logic and call this class via reflection. > > Thanks a lot, > > Martin > > [1] > https://issues.jboss.org/browse/SWARM-568 > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160727/a0597fc5/attachment.html From akostadi at redhat.com Wed Jul 27 13:17:37 2016 From: akostadi at redhat.com (Aleksandar Kostadinov) Date: Wed, 27 Jul 2016 20:17:37 +0300 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: <891EF4C5-86A4-49E6-9A8F-A7D5EC476BA1@redhat.com> References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> <3635d158-5695-c134-e0d0-63dcfc1a9542@redhat.com> <891EF4C5-86A4-49E6-9A8F-A7D5EC476BA1@redhat.com> Message-ID: <9e31b91f-4bfb-dc34-4aa7-c0e83d9c8867@redhat.com> Heiko W.Rupp wrote on 07/27/16 14:57: > On 21 Jul 2016, at 0:49, Aleksandar Kostadinov wrote: >> >> I should have explained better. The config is saved on container. But >> container being stateless loses changes on restart. At least for > > Yeah, that is a bit of an issue. One needs to mount the whole config > dir to an external volume(*) and then on container creation populate it > with a default configuration. > Or externalize the changes of the standard config and apply it each > time at container start (docker run, not docker start). OpenShift does support persistent volumes. Thinking about auto-scale I'm not sure that would help a lot though. I'm wondering whether domain mode can help - having domain node(s) with persistent storage configuration for management. Then the worker nodes would read config from domain. I suspect though most people would not want to waste resources for non-worker nodes and would expect to have things working OOB in some simple manner. Perhaps wildfly may support committing configuration changes in whatever format to some external system (git, file server, whatever), then read it from there. e.g. if wildfly can commit any and all configuration changes to git, an OpenShift deployment config can trigger redeploy based on the noticed changes automatically (or user can trigger manually). btw it would help if Wildfly records only changes from defaults (not all configuration files). In this way migrating between versions and changing defaults might work much smoother. From brian.stansberry at redhat.com Wed Jul 27 13:30:23 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 27 Jul 2016 12:30:23 -0500 Subject: [wildfly-dev] Pretty-printing XML validation errors In-Reply-To: <9e31b91f-4bfb-dc34-4aa7-c0e83d9c8867@redhat.com> References: <175112BC-84C9-4A61-802F-A5978729D96F@redhat.com> <37c14893-21bd-4e5f-27d5-ee28968d5c31@redhat.com> <3635d158-5695-c134-e0d0-63dcfc1a9542@redhat.com> <891EF4C5-86A4-49E6-9A8F-A7D5EC476BA1@redhat.com> <9e31b91f-4bfb-dc34-4aa7-c0e83d9c8867@redhat.com> Message-ID: <1DFCC102-DBE5-4983-9E52-D8FC2AE997A7@redhat.com> There?s lots of discussion around this general topic at https://issues.jboss.org/browse/WFCORE-433 . > On Jul 27, 2016, at 12:17 PM, Aleksandar Kostadinov wrote: > > Heiko W.Rupp wrote on 07/27/16 14:57: >> On 21 Jul 2016, at 0:49, Aleksandar Kostadinov wrote: >>> >>> I should have explained better. The config is saved on container. But >>> container being stateless loses changes on restart. At least for >> >> Yeah, that is a bit of an issue. One needs to mount the whole config >> dir to an external volume(*) and then on container creation populate it >> with a default configuration. >> Or externalize the changes of the standard config and apply it each >> time at container start (docker run, not docker start). > > OpenShift does support persistent volumes. Thinking about auto-scale I'm not sure that would help a lot though. > > I'm wondering whether domain mode can help - having domain node(s) with persistent storage configuration for management. Then the worker nodes would read config from domain. > > I suspect though most people would not want to waste resources for non-worker nodes and would expect to have things working OOB in some simple manner. Perhaps wildfly may support committing configuration changes in whatever format to some external system (git, file server, whatever), then read it from there. > e.g. if wildfly can commit any and all configuration changes to git, an OpenShift deployment config can trigger redeploy based on the noticed changes automatically (or user can trigger manually). > > btw it would help if Wildfly records only changes from defaults (not all configuration files). In this way migrating between versions and changing defaults might work much smoother. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160727/516e9110/attachment.html From jperkins at redhat.com Thu Jul 28 17:46:23 2016 From: jperkins at redhat.com (James Perkins) Date: Thu, 28 Jul 2016 14:46:23 -0700 Subject: [wildfly-dev] Open Logging Discussion Message-ID: I haven't put much thought into a solution for this, but I want to put it out there to start a discussion. There is a new feature request [1] to provide access logs for EJB's. We currently have at least 3 different places to configure different types of logging. 1. The logging subsystem 2. Management access logging 3. Web access logging All 3 of these reside under different resources and have different configuration options. Which is really understandable since they are all quite different in what they are trying to do. However since we may be adding a forth now I'm thinking we should start to consider some other options for these. Possibly some kind of centralized location to configure logging in or something that all log messages pass through to ensure they're routed correctly (yes I realize this is essentially a log manager). As it is now we do have the ability to download logs from a server. Audit logs, web access logs, process controller logs and host controller logs can not be downloaded or viewed from the log viewer on the web console. I again assume user would like access to all log files or some way to view all log messages. I'm mainly bringing this up because I'm guessing for things like WildFly Swarm and OpenShift log files aren't all that useful as the user has no access to them. Pushing log messages to some kind of log aggregation server in these cases is often useful in these situations. At a minimum I do think we need to provide a way to download or view all log files. In managed domains this is probably useful as well as environments like docker. Anyway I'm just looking to plant a seed at this point and see what others think. [1]: https://issues.jboss.org/browse/WFLY-6892 -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160728/b8695051/attachment.html From hpehl at redhat.com Fri Jul 29 05:11:20 2016 From: hpehl at redhat.com (Harald Pehl) Date: Fri, 29 Jul 2016 11:11:20 +0200 Subject: [wildfly-dev] Open Logging Discussion In-Reply-To: References: Message-ID: <78515E33-D65E-4650-93A4-46A13BB68477@redhat.com> > On 28 Jul 2016, at 23:46, James Perkins wrote: > > I haven't put much thought into a solution for this, but I want to put it out there to start a discussion. > > There is a new feature request [1] to provide access logs for EJB's. We currently have at least 3 different places to configure different types of logging. > The logging subsystem > Management access logging > Web access logging > All 3 of these reside under different resources and have different configuration options. Which is really understandable since they are all quite different in what they are trying to do. > > However since we may be adding a forth now I'm thinking we should start to consider some other options for these. Possibly some kind of centralized location to configure logging in or something that all log messages pass through to ensure they're routed correctly (yes I realize this is essentially a log manager). > > As it is now we do have the ability to download logs from a server. Audit logs, web access logs, process controller logs and host controller logs can not be downloaded or viewed from the log viewer on the web console. I again assume user would like access to all log files or some way to view all log messages. +1 for providing access to other log files. > > I'm mainly bringing this up because I'm guessing for things like WildFly Swarm and OpenShift log files aren't all that useful as the user has no access to them. Pushing log messages to some kind of log aggregation server in these cases is often useful in these situations. > > At a minimum I do think we need to provide a way to download or view all log files. In managed domains this is probably useful as well as environments like docker. > > Anyway I'm just looking to plant a seed at this point and see what others think. > > [1]: https://issues.jboss.org/browse/WFLY-6892 > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/f2117159/attachment-0001.html From ceharris414 at me.com Fri Jul 29 09:42:18 2016 From: ceharris414 at me.com (Carl Harris) Date: Fri, 29 Jul 2016 09:42:18 -0400 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> Message-ID: <9172A062-BF26-499D-80B8-A9734532340C@me.com> On Jul 25, 2016, at 1:40 PM, James Perkins wrote: Anyway, I'm up for anything that allows the documentation to be consistent, easy to write and easy to use. The main attraction for me to asciidoc is being able to use git for versioning as well as being able to use variables. I don't however know how well asciidoc deals with multiple documents and combining them together. This has probably already been mentioned somewhere in this thread, but a related advantage to an asciidoc (or similar) approach using git, is that you can more easily take documentation contributions in the form of pull requests. I often find myself wanting to suggest a revision, especially after figuring out how to do something that wasn't clearly explained, but apart from adding comments to the page (which are difficult to put in context), there is no good way to suggest revisions in Confluence. carl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/0222bb68/attachment.html From mikesir at vt.edu Fri Jul 29 12:59:51 2016 From: mikesir at vt.edu (Michael Irwin) Date: Fri, 29 Jul 2016 12:59:51 -0400 Subject: [wildfly-dev] Specifying order of new JGroups Protocol Message-ID: I'm adding a JGroup stack protocol using this command: /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add() But, the new protocol is added to the end of the list of protocols. And, since protocol order matters, how do I add the protocol to the front of the list? And, I'd prefer to do it without tweaking the XML directly. Any pointers? -- Michael Irwin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/f595085e/attachment.html From jperkins at redhat.com Fri Jul 29 13:16:08 2016 From: jperkins at redhat.com (James Perkins) Date: Fri, 29 Jul 2016 10:16:08 -0700 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: <9172A062-BF26-499D-80B8-A9734532340C@me.com> References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> <9172A062-BF26-499D-80B8-A9734532340C@me.com> Message-ID: On Fri, Jul 29, 2016 at 6:42 AM, Carl Harris wrote: > > On Jul 25, 2016, at 1:40 PM, James Perkins wrote: > > Anyway, I'm up for anything that allows the documentation to be >> consistent, easy to write and easy to use. The main attraction for me to >> asciidoc is being able to use git for versioning as well as being able to >> use variables. I don't however know how well asciidoc deals with multiple >> documents and combining them together. >> > > This has probably already been mentioned somewhere in this thread, but a > related advantage to an asciidoc (or similar) approach using git, is that > you can more easily take documentation contributions in the form of pull > requests. I often find myself wanting to suggest a revision, especially > after figuring out how to do something that wasn't clearly explained, but > apart from adding comments to the page (which are difficult to put in > context), there is no good way to suggest revisions in Confluence. > > This is something I didn't consider. Thank you for pointing it out. Out of curiosity is there a reason you don't want to just update the document itself? > carl > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/3084f1b4/attachment.html From ceharris414 at me.com Fri Jul 29 13:55:00 2016 From: ceharris414 at me.com (Carl Harris) Date: Fri, 29 Jul 2016 13:55:00 -0400 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: <6B2939DF-BFB2-45EB-A0F2-D9FD18688C48@redhat.com> <9172A062-BF26-499D-80B8-A9734532340C@me.com> Message-ID: <74B37E28-2110-4449-870E-19DC0D9ACA9F@me.com> > On Jul 29, 2016, at 1:16 PM, James Perkins wrote: > > On Fri, Jul 29, 2016 at 6:42 AM, Carl Harris > wrote: > This has probably already been mentioned somewhere in this thread, but a related advantage to an asciidoc (or similar) approach using git, is that you can more easily take documentation contributions in the form of pull requests. > This is something I didn't consider. Thank you for pointing it out. Out of curiosity is there a reason you don't want to just update the document itself? Apart from the issue of needing permission to do so, as I contributor I would feel more confident about suggesting a revision through a pull request, as opposed to committing a revision. Someone more familiar with the documentation would be able to ensure that conventions are appropriately followed, that the revision doesn't change the semantics in a way that is incorrect or inappropriate, etc. Basically, all the same benefits of any code review, but applied to documentation. Having used a couple of open source products with freely editable documentation wikis, I'd say that even a minimal process of reviewing and merging changes is more likely to result in a consistent and useful document than simply allowing community edits. Again, just my 2 cents. carl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/58bd9c0e/attachment.html From jason.greene at redhat.com Fri Jul 29 15:54:35 2016 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 29 Jul 2016 14:54:35 -0500 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: Message-ID: I think we should stick with what we have, which works well enough, and just have a live / always up to date doc. Everyone is pretty busy at the moment, so to switch to any new option, the starting point would be a volunteer willing to own all of the porting and reformatting work on all of our existing content. > On May 12, 2016, at 10:32 PM, James Perkins wrote: > > I've been reading the WildFly documentation [1] quite a bit lately and noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. Sometimes documentation is just plain out of date referencing behavior that has possibly been removed or replaced by something better. > > This has happened because we keep copying the documentation over each time we have a new version. Overall this makes sense as a lot of it doesn't need to be changed. However it leaves reading the documentation confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in the text with a link for AS72 isn't very user friendly as I'm sure we can all agree. > > There's a few different ways we could go with this. > > Approach 1: > One, probably the easiest, is to use a single confluence project. We'd need to remove the version numbers from the text, which I think we should do anyway. Instead of referencing WildFly 10 we just reference it as WildFly. > > An issue I can think of with this approach is some how annotating or referencing that parts of the documentation only work with ${version}. For example new features would have to be noted they only work with ${version}+. > > > Approach 2: > Essentially he same as approach 1 only do allow different Confluence projects for the different Java EE target version. So WIldFly 8, 9 and 10 would all be documented under something like WFLYEE7. > > Approach 3 > Switch to using something like asciidoc which can use variables and generate links to the correct content. While this approach is probably takes the most work up front, it seems like like it would be easier to maintain between releases. > > Any other suggestions are welcome. > > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/e83aa452/attachment-0001.html From jason.greene at redhat.com Fri Jul 29 16:12:33 2016 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 29 Jul 2016 15:12:33 -0500 Subject: [wildfly-dev] 10.1.0.CR1 is available! Try it out! Message-ID: Some of you may have noticed that 10.1.0.CR1 was released yesterday: http://wildfly.org/downloads/ Please give it a try and report any major issues. Provided nothing critical comes up, we will release Final next week. Major new features include: - Out of the box HTTP/2 support - TLS cert auto-generation - Load-balancing profile is now in our default domain.xml config - Support for clustering node discovery on Azure (jgroups AZURE_PING) Overall there are 308 issues resolved in this release: https://issues.jboss.org/secure/ReleaseNote.jspa?version=12329499&styleName=Html&projectId=12313721 Thanks again! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Fri Jul 29 17:23:31 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 29 Jul 2016 16:23:31 -0500 Subject: [wildfly-dev] One Doc to Rule Them All In-Reply-To: References: Message-ID: Practical tip: tl;dr; Don?t include the Confluence space prefix in the markup for cross document links. Long version: An issue with using a "live / always up to date doc? is I expect we?ll want to snapshot it when we do releases, at least for majors. The way confluence creates links between pages can work against that though. But this can be mitigated with careful work. Say I want to create a link in the ?Admin Guide? page to the ?RBAC? page. The little ?link? icon at the top left of the editor helps me do that. The problem is it creates markup like this: [WFLY:RBAC] That link will be a problem when we create a snapshot of the docs for WildFly 11 since in the snapshot it will still say ?WFLY? and the effective URL wll be https://docs.jboss.org/author/display/WFLY/ RBAC and not the WFLY11 snapshot URL: https://docs.jboss.org/author/display/WFLY11/ RBAC Anyone following the link will get directed to the then current docs, which may have inaccurate information for WildFly 11. (Right now our docs have the opposite problem that James mentioned on this thread; the WFLY10 docs are a copy of WFLY9 which was a copy of WFLY8 and when those copies were created a bunch of links pointing to [WFLY9:xxx} or even earlier were created.) Avoiding this problem just takes a bit of care though. If you use the link button, edit the resulting link test to remove the ?WFLY:" space prefix, resulting in [RBAC] With that syntax the link becomes relative to the current document?s space, and when that space is copied the copies will also have relative links. > On Jul 29, 2016, at 2:54 PM, Jason Greene wrote: > > I think we should stick with what we have, which works well enough, and just have a live / always up to date doc. > > Everyone is pretty busy at the moment, so to switch to any new option, the starting point would be a volunteer willing to own all of the porting and reformatting work on all of our existing content. > > >> On May 12, 2016, at 10:32 PM, James Perkins > wrote: >> >> I've been reading the WildFly documentation [1] quite a bit lately and noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. Sometimes documentation is just plain out of date referencing behavior that has possibly been removed or replaced by something better. >> >> This has happened because we keep copying the documentation over each time we have a new version. Overall this makes sense as a lot of it doesn't need to be changed. However it leaves reading the documentation confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in the text with a link for AS72 isn't very user friendly as I'm sure we can all agree. >> >> There's a few different ways we could go with this. >> >> Approach 1: >> One, probably the easiest, is to use a single confluence project. We'd need to remove the version numbers from the text, which I think we should do anyway. Instead of referencing WildFly 10 we just reference it as WildFly. >> >> An issue I can think of with this approach is some how annotating or referencing that parts of the documentation only work with ${version}. For example new features would have to be noted they only work with ${version}+. >> >> >> Approach 2: >> Essentially he same as approach 1 only do allow different Confluence projects for the different Java EE target version. So WIldFly 8, 9 and 10 would all be documented under something like WFLYEE7. >> >> Approach 3 >> Switch to using something like asciidoc which can use variables and generate links to the correct content. While this approach is probably takes the most work up front, it seems like like it would be easier to maintain between releases. >> >> Any other suggestions are welcome. >> >> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation >> >> -- >> James R. Perkins >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/fd9992ab/attachment.html From rachmato at redhat.com Fri Jul 29 17:30:20 2016 From: rachmato at redhat.com (Richard Achmatowicz) Date: Fri, 29 Jul 2016 17:30:20 -0400 Subject: [wildfly-dev] Specifying order of new JGroups Protocol In-Reply-To: References: Message-ID: <90014423-6f6e-73cc-a65a-7dbafdf55700@redhat.com> Hi Michael There is no operation for inserting a protocol layer at a specific position in the stack. You will have to remove the original stack definition and recreate it with a series of commands. This can be placed into a CLI batch and executed as a script if you need to do it often. Here is an example: contents of the CLI script (the following commands in a text file called, say, setstack.cli): -------------------------------------------------------------------------------------- connect batch /subsystem=jgroups/stack=tcp:remove() /subsystem=jgroups/stack=tcp:add() /subsystem=jgroups/stack=tcp/transport=TCP:add(socket-binding="jgroups-tcp") /subsystem=jgroups/stack=tcp/protocol=MPING:add(socket-binding="jgroups-mping") /subsystem=jgroups/stack=tcp/protocol=MERGE3:add() /subsystem=jgroups/stack=tcp/protocol=FDSOCK:add(socket-binding="jgroups-tcp-fd") /subsystem=jgroups/stack=tcp/protocol=FD:add() /subsystem=jgroups/stack=tcp/protocol=VERIFY_SUSPECT:add() /subsystem=jgroups/stack=tcp/protocol=pbcast.NAKACK2:add() /subsystem=jgroups/stack=tcp/protocol=UNICAST3:add() /subsystem=jgroups/stack=tcp/protocol=pbcast.STABLE:add() /subsystem=jgroups/stack=tcp/protocol=pbcast.GMS:add() /subsystem=jgroups/stack=tcp/protocol=MFC:add() /subsystem=jgroups/stack=tcp/protocol=FRAG2:add() run-batch -------------------------------------------------------------------------------------- execute the CLI script: ./jboss-cli.sh --file=setstack.cli Richard On 29/07/16 12:59 PM, Michael Irwin wrote: > I'm adding a JGroup stack protocol using this command: > > /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add() > > But, the new protocol is added to the end of the list of protocols. > And, since protocol order matters, how do I add the protocol to the > front of the list? And, I'd prefer to do it without tweaking the XML > directly. Any pointers? > > -- > Michael Irwin > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/39dc3f64/attachment.html From brian.stansberry at redhat.com Fri Jul 29 17:40:04 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 29 Jul 2016 16:40:04 -0500 Subject: [wildfly-dev] Specifying order of new JGroups Protocol In-Reply-To: <90014423-6f6e-73cc-a65a-7dbafdf55700@redhat.com> References: <90014423-6f6e-73cc-a65a-7dbafdf55700@redhat.com> Message-ID: There was an ?add-index? param that was added in 10[1] and perhaps only became functional in the just released 10.1.0.CR1 due to [2]. [1] https://issues.jboss.org/browse/WFLY-4723 [2] https://issues.jboss.org/browse/WFLY-6782 > On Jul 29, 2016, at 4:30 PM, Richard Achmatowicz wrote: > > Hi Michael > > There is no operation for inserting a protocol layer at a specific position in the stack. > You will have to remove the original stack definition and recreate it with a series of commands. > This can be placed into a CLI batch and executed as a script if you need to do it often. > Here is an example: > > contents of the CLI script (the following commands in a text file called, say, setstack.cli): > -------------------------------------------------------------------------------------- > connect > batch > /subsystem=jgroups/stack=tcp:remove() > > /subsystem=jgroups/stack=tcp:add() > /subsystem=jgroups/stack=tcp/transport=TCP:add(socket-binding="jgroups-tcp") > /subsystem=jgroups/stack=tcp/protocol=MPING:add(socket-binding="jgroups-mping") > /subsystem=jgroups/stack=tcp/protocol=MERGE3:add() > /subsystem=jgroups/stack=tcp/protocol=FDSOCK:add(socket-binding="jgroups-tcp-fd") > /subsystem=jgroups/stack=tcp/protocol=FD:add() > /subsystem=jgroups/stack=tcp/protocol=VERIFY_SUSPECT:add() > /subsystem=jgroups/stack=tcp/protocol=pbcast.NAKACK2:add() > /subsystem=jgroups/stack=tcp/protocol=UNICAST3:add() > /subsystem=jgroups/stack=tcp/protocol=pbcast.STABLE:add() > /subsystem=jgroups/stack=tcp/protocol=pbcast.GMS:add() > /subsystem=jgroups/stack=tcp/protocol=MFC:add() > /subsystem=jgroups/stack=tcp/protocol=FRAG2:add() > run-batch > -------------------------------------------------------------------------------------- > > execute the CLI script: > ./jboss-cli.sh --file=setstack.cli > > Richard > On 29/07/16 12:59 PM, Michael Irwin wrote: >> I'm adding a JGroup stack protocol using this command: >> >> /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add() >> >> But, the new protocol is added to the end of the list of protocols. And, since protocol order matters, how do I add the protocol to the front of the list? And, I'd prefer to do it without tweaking the XML directly. Any pointers? >> >> -- >> Michael Irwin >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160729/18bc79f2/attachment-0001.html From hcamp at muerte.net Sat Jul 30 18:14:38 2016 From: hcamp at muerte.net (Harold Campbell) Date: Sat, 30 Jul 2016 17:14:38 -0500 Subject: [wildfly-dev] 10.1.0.CR1 is available! Try it out! In-Reply-To: References: Message-ID: <1469916878.28969.13.camel@muerte.net> On Fri, 2016-07-29 at 15:12 -0500, Jason Greene wrote: > Some of you may have noticed that 10.1.0.CR1 was released yesterday: > http://wildfly.org/downloads/ > > Please give it a try and report any major issues. Provided nothing > critical comes up, we will release Final next week. > This is a showstopper for me. https://issues.jboss.org/browse/WFLY-6898 -- Harold Campbell I hold it, that a little rebellion, now and then, is a good thing... -- Thomas Jefferson