From brian.stansberry at redhat.com Fri May 1 12:23:48 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 01 May 2015 11:23:48 -0500 Subject: [wildfly-dev] WildFly Core 1.0.0.CR1 is released Message-ID: <5543A894.8040909@redhat.com> I've released the 1.0.0.CR1 version of WildFly Core and submitted a pull request to move WildFly Full to it. I've also created a 1.x branch of WildFly Core in github. From this point forward, the 'master' branch is for work on WildFly Core 2.0, while 1.x should be used for patches needed to get 1.0.0 to Final. PRs for fixes to 1.x should also have a matching PR for master so we have no regressions. I plan to do a 1.0.0.CR2 release next Friday, if there are any necessary changes to 1.0.0. Our target for 1.0.0.Final is May 15. Enjoy, and thanks everyone for all the hard work! -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Fri May 1 16:38:53 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 1 May 2015 15:38:53 -0500 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! Message-ID: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> Hello Everyone, I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. For more details, check out the release notes: https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes As always, you can download it here: http://wildfly.org/downloads/ -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From arun.gupta at gmail.com Fri May 1 17:48:16 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 1 May 2015 14:48:16 -0700 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> Message-ID: That's an awesome way to start the weekend, congrats! BTW, I tried to create a Docker image using the description at: https://github.com/arun-gupta/docker-images/blob/master/wildfly/Dockerfile Running this image gives the error: 21:38:40,361 INFO [org.hornetq.jms.server] (ServerService Thread Pool -- 65) HQ121005: Invalid "host" value "0.0.0.0" detected for "http-connector" 9.0.0 Beta2 gave a similar error. This image can also be tried as: docker run -it -p 8080:8080 arungupta/wildfly:9cr1 Any idea? Arun On Fri, May 1, 2015 at 1:38 PM, Jason Greene wrote: > Hello Everyone, > > I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. > > For more details, check out the release notes: > https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes > > As always, you can download it here: > http://wildfly.org/downloads/ > > -- > 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 -- http://blog.arungupta.me http://twitter.com/arungupta From dandread at redhat.com Sat May 2 16:04:19 2015 From: dandread at redhat.com (Dimitris Andreadis) Date: Sat, 02 May 2015 22:04:19 +0200 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> Message-ID: <55452DC3.7020500@redhat.com> BTW, the servlet-only distro is missing from the CR downloads: http://wildfly.org/downloads/ On 01/05/2015 22:38, Jason Greene wrote: > Hello Everyone, > > I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. > > For more details, check out the release notes: > https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes > > As always, you can download it here: > http://wildfly.org/downloads/ > > -- > 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 > From eduardo.santanadasilva at gmail.com Sat May 2 18:23:42 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Sat, 2 May 2015 19:23:42 -0300 Subject: [wildfly-dev] WFLY-4200 WAR MDB cannot obtain superclass on module classpath Message-ID: I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module classpath This is what I posted about it: "I believe that the problem is because AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the parse phase: Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS Since the dependencies will be resolved at Phase.DEPENDENCIES, your build will not work. Regarding WFLY, my suggestion is not throw the EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass) only bring up some flag that the required interfaces were not yet resolved, some attachment could be useful, just to retain the super class name. When the dependencies were solved, the class will be present on the class index and the test against the annotation should be performed again. Since that work will be done twice, to verify the required interfaces, this requires some experts advice." Thanks, -- __________________________ Eduardo Sant'Ana da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150502/0650125a/attachment.html From jason.greene at redhat.com Sun May 3 17:53:16 2015 From: jason.greene at redhat.com (Jason Greene) Date: Sun, 3 May 2015 17:53:16 -0400 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <55452DC3.7020500@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <55452DC3.7020500@redhat.com> Message-ID: <5265A18E-33C3-43C7-A4B3-A80AF4D73C54@redhat.com> Thanks for catching that. I corrected the issue and regenerated the site. > On May 2, 2015, at 4:04 PM, Dimitris Andreadis wrote: > > BTW, the servlet-only distro is missing from the CR downloads: > > http://wildfly.org/downloads/ > > On 01/05/2015 22:38, Jason Greene wrote: >> Hello Everyone, >> >> I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. >> >> For more details, check out the release notes: >> https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes >> >> As always, you can download it here: >> http://wildfly.org/downloads/ >> >> -- >> 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 >> > _______________________________________________ > 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 lfryc at redhat.com Mon May 4 05:28:22 2015 From: lfryc at redhat.com (Lukas Fryc) Date: Mon, 4 May 2015 11:28:22 +0200 Subject: [wildfly-dev] Embedded Arquillian Container In-Reply-To: <5542326F.6040602@redhat.com> References: <5542326F.6040602@redhat.com> Message-ID: An only embedded container's advantage over managed container is a simpler test debugging - no special setup required. I'm fine with dropping it, just in case it wasn't intentional decision to remove embedded container, we can re-introduce it. ~ Lukas On Thu, Apr 30, 2015 at 3:47 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > Hi Lukas, > > On 4/29/15 9:58 AM, Lukas Fryc wrote: > > Hey guys, > > > > just wondering if wildfly-arquillian-container-embedded was discontinued > > with split of 9.x: > > > > https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96 > > > > It was, yes, as wildfly-arquillian shouldn't depend on WildFly Full (to > avoid a circular dependency) and WildFly Core didn't have an embedding > module. > > > > When working on a re-enablement, I found out that even though arq > > adapter now depends on wildfly-core/embedded, particularly > > on EmbeddedServerFactory, this class has its counterpart in > > wildfly/embedded as well. > > > > I added the wildfly-core/embedded module in order to support the Offline > CLI.[1] At this point I consider it to be an internal module, not > public API. I expect that will soften over time, but for WildFly Core > 1.0 / WildFly Full 9.0 at least, that's what it is. > > [1] http://wildfly.org/news/2015/03/13/Offline-CLI/ > > > Question is, should be embedded arquillian container still available for > > 9.x? > > > > Jason Greene would need to rule on that, but I know we were ok with > dropping it before. Is there much use of it? > > > If yes, I can continue and provide a PR, just I will need a bit of > > guidance with what EmbeddedServerFactory it should actually use (if that > > matters). > > > > What API would it need from wildfly-core/embedded? Is the > StandaloneServer API there adequate? > > > > > Cheers, > > > > ~ Lukas > > > > -- > > Lukas Fryc > > AeroGear Core Developer > > Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > 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/20150504/d1b95050/attachment.html From jharting at redhat.com Mon May 4 06:25:51 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 04 May 2015 12:25:51 +0200 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> Message-ID: <5547492F.30504@redhat.com> Congrats on the release! It seems that Jandex upgrade to 2.0 has not been done yet. Is my understanding correct that it has been postponed till WF10? On 05/01/2015 10:38 PM, Jason Greene wrote: > Hello Everyone, > > I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. > > For more details, check out the release notes: > https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes > > As always, you can download it here: > http://wildfly.org/downloads/ > > -- > 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 From tomaz.cerar at gmail.com Mon May 4 06:30:06 2015 From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=) Date: Mon, 4 May 2015 12:30:06 +0200 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <5547492F.30504@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <5547492F.30504@redhat.com> Message-ID: <55474a2f.654bb40a.1e24.563a@mx.google.com> Yes! With 10 we are moving to java 8 which will also bring in/allow us to move to jandex 2 Tomaz Sent from my Phone -----Original Message----- From: "Jozef Hartinger" Sent: ?4.?5.?2015 12:26 To: "Jason Greene" ; "WildFly Dev" Subject: Re: [wildfly-dev] WildFly 9.0.0.CR1 is released! Congrats on the release! It seems that Jandex upgrade to 2.0 has not been done yet. Is my understanding correct that it has been postponed till WF10? On 05/01/2015 10:38 PM, Jason Greene wrote: > Hello Everyone, > > I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. > > For more details, check out the release notes: > https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes > > As always, you can download it here: > http://wildfly.org/downloads/ > > -- > 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 _______________________________________________ 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/20150504/36bcec25/attachment.html From anselm.hou at aroundhub.com Mon May 4 07:32:06 2015 From: anselm.hou at aroundhub.com (Anselm Hou) Date: Mon, 4 May 2015 19:32:06 +0800 Subject: [wildfly-dev] Starting Infinispan as Eager Mode Message-ID: Dear all experts, I'm trying to migrate my current Wildfly 8.1.0 Final to WildFly 9.0.0.CR1. While doing so I wish to configure the infinispan's hibernate cache to configure as start as EAGER, but when I try it via the Admin Console, it throws an error message and said it can not start as EAGER... Any help will be high appreciated. Thank you in advance. Anselm Following is my request & response that captured from console: Request { "operation" => "composite", "address" => [], "steps" => [{ "address" => [ ("profile" => "full"), ("subsystem" => "infinispan"), ("cache-container" => "hibernate") ], "operation" => "write-attribute", "name" => "start", "value" => "EAGER" }] } Response Internal Server Error { "outcome" => "failed", "failure-description" => {"domain-failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0248: Invalid value EAGER for start; legal values are [LAZY]"}}}, "rolled-back" => true } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150504/dc4f82b3/attachment.html From cody.lerum at gmail.com Mon May 4 07:35:15 2015 From: cody.lerum at gmail.com (Cody Lerum) Date: Mon, 4 May 2015 05:35:15 -0600 Subject: [wildfly-dev] Embedded Arquillian Container In-Reply-To: References: <5542326F.6040602@redhat.com> Message-ID: Is there a good example published somewhere for users who want to use a managed container within a CI like Travis? This is becoming an increasingly pretty popular configuration, and the easier for the users to get started and update from release to release the better. -C On May 4, 2015 3:28 AM, "Lukas Fryc" wrote: > An only embedded container's advantage over managed container is a simpler > test debugging - no special setup required. > > I'm fine with dropping it, just in case it wasn't intentional decision to > remove embedded container, we can re-introduce it. > > ~ Lukas > > On Thu, Apr 30, 2015 at 3:47 PM, Brian Stansberry < > brian.stansberry at redhat.com> wrote: > >> Hi Lukas, >> >> On 4/29/15 9:58 AM, Lukas Fryc wrote: >> > Hey guys, >> > >> > just wondering if wildfly-arquillian-container-embedded was discontinued >> > with split of 9.x: >> > >> > https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96 >> > >> >> It was, yes, as wildfly-arquillian shouldn't depend on WildFly Full (to >> avoid a circular dependency) and WildFly Core didn't have an embedding >> module. >> > >> > When working on a re-enablement, I found out that even though arq >> > adapter now depends on wildfly-core/embedded, particularly >> > on EmbeddedServerFactory, this class has its counterpart in >> > wildfly/embedded as well. >> > >> >> I added the wildfly-core/embedded module in order to support the Offline >> CLI.[1] At this point I consider it to be an internal module, not >> public API. I expect that will soften over time, but for WildFly Core >> 1.0 / WildFly Full 9.0 at least, that's what it is. >> >> [1] http://wildfly.org/news/2015/03/13/Offline-CLI/ >> >> > Question is, should be embedded arquillian container still available for >> > 9.x? >> > >> >> Jason Greene would need to rule on that, but I know we were ok with >> dropping it before. Is there much use of it? >> >> > If yes, I can continue and provide a PR, just I will need a bit of >> > guidance with what EmbeddedServerFactory it should actually use (if that >> > matters). >> > >> >> What API would it need from wildfly-core/embedded? Is the >> StandaloneServer API there adequate? >> >> > >> > Cheers, >> > >> > ~ Lukas >> > >> > -- >> > Lukas Fryc >> > AeroGear Core Developer >> > Red Hat >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> >> >> -- >> Brian Stansberry >> 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 >> > > > _______________________________________________ > 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/20150504/9dd83817/attachment-0001.html From lthon at redhat.com Mon May 4 07:51:18 2015 From: lthon at redhat.com (Ladislav Thon) Date: Mon, 04 May 2015 13:51:18 +0200 Subject: [wildfly-dev] Starting Infinispan as Eager Mode In-Reply-To: References: Message-ID: <55475D36.6060405@redhat.com> Hi, > I wish to configure the infinispan's hibernate > cache to configure as start as EAGER AFAIK, this is no longer possible, Infinispan caches are now always started lazily. I don't know the details, so hopefully clustering developers will chime in. LT > Following is my request & response that captured from console: > > Request > { > "operation" => "composite", > "address" => [], > "steps" => [{ > "address" => [ > ("profile" => "full"), > ("subsystem" => "infinispan"), > ("cache-container" => "hibernate") > ], > "operation" => "write-attribute", > "name" => "start", > "value" => "EAGER" > }] > } > > Response > > Internal Server Error > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => > {"WFLYCTL0062: Composite operation failed and was rolled back. Steps > that failed:" => {"Operation step-1" => "WFLYCTL0248: Invalid value > EAGER for start; legal values are [LAZY]"}}}, > "rolled-back" => true > } > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From lfryc at redhat.com Mon May 4 07:58:36 2015 From: lfryc at redhat.com (Lukas Fryc) Date: Mon, 4 May 2015 13:58:36 +0200 Subject: [wildfly-dev] Embedded Arquillian Container In-Reply-To: References: <5542326F.6040602@redhat.com> Message-ID: Hey Cody, I know Aslak and Alex Soto work on a "proxy container" that will allow you to seamlessly switch between EAP/JBossAS/WildFly: https://github.com/lordofthejars/arquillian-container-proxy That impl should auto-download configured container and run in managed mode. Btw the name is not set in stone yet.. :-) On Mon, May 4, 2015 at 1:35 PM, Cody Lerum wrote: > Is there a good example published somewhere for users who want to use a > managed container within a CI like Travis? > > This is becoming an increasingly pretty popular configuration, and the > easier for the users to get started and update from release to release the > better. > > -C > On May 4, 2015 3:28 AM, "Lukas Fryc" wrote: > >> An only embedded container's advantage over managed container is a >> simpler test debugging - no special setup required. >> >> I'm fine with dropping it, just in case it wasn't intentional decision to >> remove embedded container, we can re-introduce it. >> >> ~ Lukas >> >> On Thu, Apr 30, 2015 at 3:47 PM, Brian Stansberry < >> brian.stansberry at redhat.com> wrote: >> >>> Hi Lukas, >>> >>> On 4/29/15 9:58 AM, Lukas Fryc wrote: >>> > Hey guys, >>> > >>> > just wondering if wildfly-arquillian-container-embedded was >>> discontinued >>> > with split of 9.x: >>> > >>> > https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96 >>> > >>> >>> It was, yes, as wildfly-arquillian shouldn't depend on WildFly Full (to >>> avoid a circular dependency) and WildFly Core didn't have an embedding >>> module. >>> > >>> > When working on a re-enablement, I found out that even though arq >>> > adapter now depends on wildfly-core/embedded, particularly >>> > on EmbeddedServerFactory, this class has its counterpart in >>> > wildfly/embedded as well. >>> > >>> >>> I added the wildfly-core/embedded module in order to support the Offline >>> CLI.[1] At this point I consider it to be an internal module, not >>> public API. I expect that will soften over time, but for WildFly Core >>> 1.0 / WildFly Full 9.0 at least, that's what it is. >>> >>> [1] http://wildfly.org/news/2015/03/13/Offline-CLI/ >>> >>> > Question is, should be embedded arquillian container still available >>> for >>> > 9.x? >>> > >>> >>> Jason Greene would need to rule on that, but I know we were ok with >>> dropping it before. Is there much use of it? >>> >>> > If yes, I can continue and provide a PR, just I will need a bit of >>> > guidance with what EmbeddedServerFactory it should actually use (if >>> that >>> > matters). >>> > >>> >>> What API would it need from wildfly-core/embedded? Is the >>> StandaloneServer API there adequate? >>> >>> > >>> > Cheers, >>> > >>> > ~ Lukas >>> > >>> > -- >>> > Lukas Fryc >>> > AeroGear Core Developer >>> > Red Hat >>> > >>> > >>> > _______________________________________________ >>> > wildfly-dev mailing list >>> > wildfly-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > >>> >>> >>> -- >>> Brian Stansberry >>> 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 >>> >> >> >> _______________________________________________ >> 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/20150504/f31e3480/attachment.html From tomaz.cerar at gmail.com Mon May 4 08:34:01 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 4 May 2015 14:34:01 +0200 Subject: [wildfly-dev] Embedded Arquillian Container In-Reply-To: References: <5542326F.6040602@redhat.com> Message-ID: Guys, I've sent PR https://github.com/wildfly/wildfly-arquillian/pull/18 that adds back embedded arquillian container which uses wildfly-core embedded api. -- tomaz On Mon, May 4, 2015 at 1:35 PM, Cody Lerum wrote: > Is there a good example published somewhere for users who want to use a > managed container within a CI like Travis? > > This is becoming an increasingly pretty popular configuration, and the > easier for the users to get started and update from release to release the > better. > > -C > On May 4, 2015 3:28 AM, "Lukas Fryc" wrote: > >> An only embedded container's advantage over managed container is a >> simpler test debugging - no special setup required. >> >> I'm fine with dropping it, just in case it wasn't intentional decision to >> remove embedded container, we can re-introduce it. >> >> ~ Lukas >> >> On Thu, Apr 30, 2015 at 3:47 PM, Brian Stansberry < >> brian.stansberry at redhat.com> wrote: >> >>> Hi Lukas, >>> >>> On 4/29/15 9:58 AM, Lukas Fryc wrote: >>> > Hey guys, >>> > >>> > just wondering if wildfly-arquillian-container-embedded was >>> discontinued >>> > with split of 9.x: >>> > >>> > https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96 >>> > >>> >>> It was, yes, as wildfly-arquillian shouldn't depend on WildFly Full (to >>> avoid a circular dependency) and WildFly Core didn't have an embedding >>> module. >>> > >>> > When working on a re-enablement, I found out that even though arq >>> > adapter now depends on wildfly-core/embedded, particularly >>> > on EmbeddedServerFactory, this class has its counterpart in >>> > wildfly/embedded as well. >>> > >>> >>> I added the wildfly-core/embedded module in order to support the Offline >>> CLI.[1] At this point I consider it to be an internal module, not >>> public API. I expect that will soften over time, but for WildFly Core >>> 1.0 / WildFly Full 9.0 at least, that's what it is. >>> >>> [1] http://wildfly.org/news/2015/03/13/Offline-CLI/ >>> >>> > Question is, should be embedded arquillian container still available >>> for >>> > 9.x? >>> > >>> >>> Jason Greene would need to rule on that, but I know we were ok with >>> dropping it before. Is there much use of it? >>> >>> > If yes, I can continue and provide a PR, just I will need a bit of >>> > guidance with what EmbeddedServerFactory it should actually use (if >>> that >>> > matters). >>> > >>> >>> What API would it need from wildfly-core/embedded? Is the >>> StandaloneServer API there adequate? >>> >>> > >>> > Cheers, >>> > >>> > ~ Lukas >>> > >>> > -- >>> > Lukas Fryc >>> > AeroGear Core Developer >>> > Red Hat >>> > >>> > >>> > _______________________________________________ >>> > wildfly-dev mailing list >>> > wildfly-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > >>> >>> >>> -- >>> Brian Stansberry >>> 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 >>> >> >> >> _______________________________________________ >> 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/20150504/11d1932c/attachment.html From jason.greene at redhat.com Mon May 4 10:07:10 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Mon, 4 May 2015 10:07:10 -0400 (EDT) Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <5547492F.30504@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <5547492F.30504@redhat.com> Message-ID: <15EBE06E-005A-4D27-84FE-050A2BAC4E5C@redhat.com> Yes that's correct. We need to make some deployer changes to prevent holding on to indexes. Sent from my iPhone > On May 4, 2015, at 6:25 AM, Jozef Hartinger wrote: > > Congrats on the release! > > It seems that Jandex upgrade to 2.0 has not been done yet. Is my understanding correct that it has been postponed till WF10? > >> On 05/01/2015 10:38 PM, Jason Greene wrote: >> Hello Everyone, >> >> I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. >> >> For more details, check out the release notes: >> https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes >> >> As always, you can download it here: >> http://wildfly.org/downloads/ >> >> -- >> 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 > From cody.lerum at gmail.com Mon May 4 10:11:51 2015 From: cody.lerum at gmail.com (Cody Lerum) Date: Mon, 4 May 2015 08:11:51 -0600 Subject: [wildfly-dev] Embedded Arquillian Container In-Reply-To: References: <5542326F.6040602@redhat.com> Message-ID: Very interesting. This could greatly simplify users maven builds for CI. -C On Mon, May 4, 2015 at 5:58 AM, Lukas Fryc wrote: > Hey Cody, > > I know Aslak and Alex Soto work on a "proxy container" that will allow you > to seamlessly switch between EAP/JBossAS/WildFly: > > https://github.com/lordofthejars/arquillian-container-proxy > > That impl should auto-download configured container and run in managed mode. > > Btw the name is not set in stone yet.. :-) > > On Mon, May 4, 2015 at 1:35 PM, Cody Lerum wrote: >> >> Is there a good example published somewhere for users who want to use a >> managed container within a CI like Travis? >> >> This is becoming an increasingly pretty popular configuration, and the >> easier for the users to get started and update from release to release the >> better. >> >> -C >> >> On May 4, 2015 3:28 AM, "Lukas Fryc" wrote: >>> >>> An only embedded container's advantage over managed container is a >>> simpler test debugging - no special setup required. >>> >>> I'm fine with dropping it, just in case it wasn't intentional decision to >>> remove embedded container, we can re-introduce it. >>> >>> ~ Lukas >>> >>> On Thu, Apr 30, 2015 at 3:47 PM, Brian Stansberry >>> wrote: >>>> >>>> Hi Lukas, >>>> >>>> On 4/29/15 9:58 AM, Lukas Fryc wrote: >>>> > Hey guys, >>>> > >>>> > just wondering if wildfly-arquillian-container-embedded was >>>> > discontinued >>>> > with split of 9.x: >>>> > >>>> > https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96 >>>> > >>>> >>>> It was, yes, as wildfly-arquillian shouldn't depend on WildFly Full (to >>>> avoid a circular dependency) and WildFly Core didn't have an embedding >>>> module. >>>> > >>>> > When working on a re-enablement, I found out that even though arq >>>> > adapter now depends on wildfly-core/embedded, particularly >>>> > on EmbeddedServerFactory, this class has its counterpart in >>>> > wildfly/embedded as well. >>>> > >>>> >>>> I added the wildfly-core/embedded module in order to support the Offline >>>> CLI.[1] At this point I consider it to be an internal module, not >>>> public API. I expect that will soften over time, but for WildFly Core >>>> 1.0 / WildFly Full 9.0 at least, that's what it is. >>>> >>>> [1] http://wildfly.org/news/2015/03/13/Offline-CLI/ >>>> >>>> > Question is, should be embedded arquillian container still available >>>> > for >>>> > 9.x? >>>> > >>>> >>>> Jason Greene would need to rule on that, but I know we were ok with >>>> dropping it before. Is there much use of it? >>>> >>>> > If yes, I can continue and provide a PR, just I will need a bit of >>>> > guidance with what EmbeddedServerFactory it should actually use (if >>>> > that >>>> > matters). >>>> > >>>> >>>> What API would it need from wildfly-core/embedded? Is the >>>> StandaloneServer API there adequate? >>>> >>>> > >>>> > Cheers, >>>> > >>>> > ~ Lukas >>>> > >>>> > -- >>>> > Lukas Fryc >>>> > AeroGear Core Developer >>>> > Red Hat >>>> > >>>> > >>>> > _______________________________________________ >>>> > wildfly-dev mailing list >>>> > wildfly-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> > >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From jmesnil at redhat.com Mon May 4 10:28:26 2015 From: jmesnil at redhat.com (Jeff Mesnil) Date: Mon, 4 May 2015 16:28:26 +0200 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> Message-ID: <650C9391-96AD-4721-B4AF-EA0B758DFA85@redhat.com> > Running this image gives the error: > > 21:38:40,361 INFO [org.hornetq.jms.server] (ServerService Thread Pool > -- 65) HQ121005: Invalid "host" value "0.0.0.0" detected for > "http-connector" > > 9.0.0 Beta2 gave a similar error. > > This image can also be tried as: > > docker run -it -p 8080:8080 arungupta/wildfly:9cr1 > > Any idea? You bind all sockets to the 0.0.0.0 address when you start WildFly When HornetQ starts, it looks like it is checking whether this address is valid for clients to connect to the server. You need to either pass a ?valid? address (that clients can connect to) using -b or you need to tweak the http-connector resource and instead of using the http socket-binding to specify port=8080 and host=. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From arun.gupta at gmail.com Mon May 4 12:38:16 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Mon, 4 May 2015 09:38:16 -0700 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <650C9391-96AD-4721-B4AF-EA0B758DFA85@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <650C9391-96AD-4721-B4AF-EA0B758DFA85@redhat.com> Message-ID: Jeff, >> >> docker run -it -p 8080:8080 arungupta/wildfly:9cr1 >> >> Any idea? The complete error message is: 15:53:03,915 INFO [org.hornetq.jms.server] (ServerService Thread Pool -- 65) HQ121005: Invalid "host" value "0.0.0.0" detected for "http-connector" connector. Switching to "2f9ad0bb1373". If this new address is incorrect please manually configure the connector to use the proper one. > > You bind all sockets to the 0.0.0.0 address when you start WildFly > When HornetQ starts, it looks like it is checking whether this address is valid for clients to connect to the server. > > You need to either pass a ?valid? address (that clients can connect to) using -b or you need to tweak the http-connector resource and instead of using the http socket-binding to specify port=8080 and host=. > Running the following command inside the container: /opt/jboss/wildfly/bin/standalone.sh -c standalone-full.xml -b 192.168.99.100 gives the following error: 16:00:58,663 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) 16:00:58,683 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.1.Final 16:00:58,693 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.1.Final 16:00:58,697 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: WFLYSRV0082: failed to resolve interface public at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91) [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.4.Final.jar:1.2.4.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] And then all other modules fail with the following error: 16:00:59,499 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("core-service" => "management"), ("management-interface" => "http-interface") ]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { "Services that were unable to start:" => [ "jboss.serverManagement.controller.management.http", "jboss.serverManagement.controller.management.http.shutdown" ], "Services that may be the cause:" => [ "jboss.http-upgrade-registry.default", "jboss.remoting.remotingConnectorInfoService.http-remoting-connector" ] }} Docker container address may not be known until the actual start, certainly not when the image is built. The IP address cannot be baked into the Dockerfile as it may not be available during the build time. This error message showed up for WildFly 8.2 as well but http//:8080 was accessible. Not in this case. What changed? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From sanne at hibernate.org Mon May 4 13:53:37 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 4 May 2015 18:53:37 +0100 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <15EBE06E-005A-4D27-84FE-050A2BAC4E5C@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <5547492F.30504@redhat.com> <15EBE06E-005A-4D27-84FE-050A2BAC4E5C@redhat.com> Message-ID: Is it possible for our other projects (like Hibernate) to start using Jandex2 sooner rather than later, w/o banning our users from WildFly 9? We're in an innovation paradox ;-) Thanks, Sanne On 4 May 2015 at 15:07, Jason T. Greene wrote: > Yes that's correct. We need to make some deployer changes to prevent holding on to indexes. > > Sent from my iPhone > >> On May 4, 2015, at 6:25 AM, Jozef Hartinger wrote: >> >> Congrats on the release! >> >> It seems that Jandex upgrade to 2.0 has not been done yet. Is my understanding correct that it has been postponed till WF10? >> >>> On 05/01/2015 10:38 PM, Jason Greene wrote: >>> Hello Everyone, >>> >>> I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. >>> >>> For more details, check out the release notes: >>> https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes >>> >>> As always, you can download it here: >>> http://wildfly.org/downloads/ >>> >>> -- >>> 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 >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From fjuma at redhat.com Mon May 4 16:10:17 2015 From: fjuma at redhat.com (Farah Juma) Date: Mon, 4 May 2015 16:10:17 -0400 (EDT) Subject: [wildfly-dev] WildFly 9.0.0.CR1 is now on OpenShift In-Reply-To: <1684210081.7986280.1430770124826.JavaMail.zimbra@redhat.com> Message-ID: <146949091.7986773.1430770217829.JavaMail.zimbra@redhat.com> See https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-9 for details on how to get started or update an existing application. Enjoy! From jmesnil at redhat.com Tue May 5 04:21:16 2015 From: jmesnil at redhat.com (Jeff Mesnil) Date: Tue, 5 May 2015 10:21:16 +0200 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <650C9391-96AD-4721-B4AF-EA0B758DFA85@redhat.com> Message-ID: <39185635-F80F-45F9-8A18-A864442A0612@redhat.com> Could you try something please? Update the standalone-full.xml by adding an outbound-socket-binding in the standard-sockets group: and reference this socket-binding (http-messaging) from the messaging?s http-connector: With that changes, the host setting for the messaging?s HTTP connector is not tied to the socket bound for the server to accept connections. You can then start the server with ./standalone.sh -c standalone-full.xml -b 0.0.0.0 -Djboss.messaging.http.host= The server will run fine and JMS clients would be able to connect to the servers through the address. I assume you can somehow pass an env variable to the Dockerfile so that the IP address can be specified only when Docker actually run the container? If you confirm it works, that?s a configuration we can have by default to simplify running WildFly in a container. jeff > On 04 May 2015, at 18:38, Arun Gupta wrote: > > Jeff, > >>> >>> docker run -it -p 8080:8080 arungupta/wildfly:9cr1 >>> >>> Any idea? > > The complete error message is: > > 15:53:03,915 INFO [org.hornetq.jms.server] (ServerService Thread Pool > -- 65) HQ121005: Invalid "host" value "0.0.0.0" detected for > "http-connector" connector. Switching to "2f9ad0bb1373". If this new > address is incorrect please manually configure the connector to use > the proper one. > > >> >> You bind all sockets to the 0.0.0.0 address when you start WildFly >> When HornetQ starts, it looks like it is checking whether this address is valid for clients to connect to the server. >> >> You need to either pass a ?valid? address (that clients can connect to) using -b or you need to tweak the http-connector resource and instead of using the http socket-binding to specify port=8080 and host=. >> > > Running the following command inside the container: > > /opt/jboss/wildfly/bin/standalone.sh -c standalone-full.xml -b 192.168.99.100 > > gives the following error: > > 16:00:58,663 INFO [org.jboss.as.server] (Controller Boot Thread) > WFLYSRV0039: Creating http management service using socket-binding > (management-http) > 16:00:58,683 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.1.Final > 16:00:58,693 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO > Implementation Version 3.3.1.Final > 16:00:58,697 ERROR [org.jboss.msc.service.fail] (MSC service thread > 1-5) MSC000001: Failed to start service jboss.network.public: > org.jboss.msc.service.StartException in service jboss.network.public: > WFLYSRV0082: failed to resolve interface public > at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91) > [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [jboss-msc-1.2.4.Final.jar:1.2.4.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > > And then all other modules fail with the following error: > > 16:00:59,499 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - > address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: {"WFLYCTL0288: One or more services were > unable to start due to one or more indirect dependencies not being > available." => { > "Services that were unable to start:" => [ > "jboss.serverManagement.controller.management.http", > "jboss.serverManagement.controller.management.http.shutdown" > ], > "Services that may be the cause:" => [ > "jboss.http-upgrade-registry.default", > "jboss.remoting.remotingConnectorInfoService.http-remoting-connector" > ] > }} > > Docker container address may not be known until the actual start, > certainly not when the image is built. The IP address cannot be baked > into the Dockerfile as it may not be available during the build time. > > This error message showed up for WildFly 8.2 as well but > http//:8080 was accessible. Not in this case. > > What changed? > > Arun > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From smarlow at redhat.com Tue May 5 11:54:38 2015 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 05 May 2015 11:54:38 -0400 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <5547492F.30504@redhat.com> <15EBE06E-005A-4D27-84FE-050A2BAC4E5C@redhat.com> Message-ID: <5548E7BE.1070301@redhat.com> Best to talk with Jason but I heard that the Jandex indexes will soon be larger (as part of the Java 8 changes). As a result of the size changes, Jandex indexes should only be accessed during the WildFly deployment phases. I'm not sure how Hibernate would use Jandex2 without creating its own instances of the indexes, which would be expensive memory wise. There is also the Hibernate 5.0 release, that we want to integrate with WildFly. I think that is where we might tightly couple Hibernate ORM with Jandex, by passing a composite index into Hibernate. The Jandex reference will need to be cleared by the end of deployment. Would that help? On 05/04/2015 01:53 PM, Sanne Grinovero wrote: > Is it possible for our other projects (like Hibernate) to start using > Jandex2 sooner rather than later, w/o banning our users from WildFly > 9? > > We're in an innovation paradox ;-) > > Thanks, > Sanne > > > On 4 May 2015 at 15:07, Jason T. Greene wrote: >> Yes that's correct. We need to make some deployer changes to prevent holding on to indexes. >> >> Sent from my iPhone >> >>> On May 4, 2015, at 6:25 AM, Jozef Hartinger wrote: >>> >>> Congrats on the release! >>> >>> It seems that Jandex upgrade to 2.0 has not been done yet. Is my understanding correct that it has been postponed till WF10? >>> >>>> On 05/01/2015 10:38 PM, Jason Greene wrote: >>>> Hello Everyone, >>>> >>>> I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution. >>>> >>>> For more details, check out the release notes: >>>> https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes >>>> >>>> As always, you can download it here: >>>> http://wildfly.org/downloads/ >>>> >>>> -- >>>> 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 >>> >> >> _______________________________________________ >> 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 steve at hibernate.org Tue May 5 12:47:58 2015 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 5 May 2015 11:47:58 -0500 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <5548E7BE.1070301@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <5547492F.30504@redhat.com> <15EBE06E-005A-4D27-84FE-050A2BAC4E5C@redhat.com> <5548E7BE.1070301@redhat.com> Message-ID: FWIW, those hooks in Hibernate 5 already exist, based on Jandex 1, of course :) We are not currently using Jandex. That was work happening under the metamodel redesign, which we had to push to 6.0. When we do start using Jandex, the plan is to use the provided Jandex as a base. But the problem always has been that Hibernate needs to augment that information from orm.xml. Also we do have to manage cases outside of WildFly, so we'd have to build the Index manually. Also, I want to look at the building of an index as a build-time step, storing some representation of that index into the artifact. We can then locate that representation at runtime and load it via resource lookup, depending on what that saves/gains us perf wise (tbd). Again this along with the passed Jandex index serve as the base index. We at least still need to do that augmentation as Jandex does not handle that at all. What is "end of deployment"? Is that the end of phase-2 in our 2-phase JPA bootstrap design? If so, that should be fine. On Tue, May 5, 2015 at 10:54 AM, Scott Marlow wrote: > Best to talk with Jason but I heard that the Jandex indexes will soon be > larger (as part of the Java 8 changes). As a result of the size > changes, Jandex indexes should only be accessed during the WildFly > deployment phases. > > I'm not sure how Hibernate would use Jandex2 without creating its own > instances of the indexes, which would be expensive memory wise. > > There is also the Hibernate 5.0 release, that we want to integrate with > WildFly. I think that is where we might tightly couple Hibernate ORM > with Jandex, by passing a composite index into Hibernate. The Jandex > reference will need to be cleared by the end of deployment. Would that > help? > > On 05/04/2015 01:53 PM, Sanne Grinovero wrote: > > Is it possible for our other projects (like Hibernate) to start using > > Jandex2 sooner rather than later, w/o banning our users from WildFly > > 9? > > > > We're in an innovation paradox ;-) > > > > Thanks, > > Sanne > > > > > > On 4 May 2015 at 15:07, Jason T. Greene wrote: > >> Yes that's correct. We need to make some deployer changes to prevent > holding on to indexes. > >> > >> Sent from my iPhone > >> > >>> On May 4, 2015, at 6:25 AM, Jozef Hartinger > wrote: > >>> > >>> Congrats on the release! > >>> > >>> It seems that Jandex upgrade to 2.0 has not been done yet. Is my > understanding correct that it has been postponed till WF10? > >>> > >>>> On 05/01/2015 10:38 PM, Jason Greene wrote: > >>>> Hello Everyone, > >>>> > >>>> I am happy to announce the first candidate release of WildFly 9! > WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new > capabilities, including intelligent load balancing, HTTP/2 support, a new > offline CLI mode, graceful single node shutdown, and a new Servlet-only > distribution. > >>>> > >>>> For more details, check out the release notes: > >>>> https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes > >>>> > >>>> As always, you can download it here: > >>>> http://wildfly.org/downloads/ > >>>> > >>>> -- > >>>> 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 > >>> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150505/b5df8d89/attachment-0001.html From smarlow at redhat.com Tue May 5 13:55:20 2015 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 05 May 2015 13:55:20 -0400 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <5547492F.30504@redhat.com> <15EBE06E-005A-4D27-84FE-050A2BAC4E5C@redhat.com> <5548E7BE.1070301@redhat.com> Message-ID: <55490408.2090009@redhat.com> > What is "end of deployment"? Is that the end of phase-2 in our 2-phase > JPA bootstrap design? If so, that should be fine. Yes, the end of phase-2 in our 2-phase JPA bootstrap design should occur before (WildFly) deployment is complete. From brian.stansberry at redhat.com Tue May 5 16:55:48 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 May 2015 15:55:48 -0500 Subject: [wildfly-dev] 9.x branch created; master is for WildFly 10 Message-ID: <55492E54.30602@redhat.com> I've created a 9.x branch in the WildFly repo on github.[1] From this point forward, work on the 'master' branch will be targeted toward the WildFly 10 release. If you have a change that needs to go into WildFly 9 (i.e. for 9.0.0.CR2), you will need to submit two pull requests: one against the 9.x branch, and one against master. The latter ensures your fix doesn't get dropped in WildFly 10. If you create a PR against 9.x, be careful in the github UI when you submit it. Even if your local branch was based on 9.x, github doesn't recognize that and by default will create the PR against master. You need to use the pulldown to select 9.x. For WildFly Core I created a 1.x branch last Friday, and master now targets 2.0, which will be the core version using in WildFly 10. Our intent is to produce a WildFly 10.0.0.Alpha1 on or around May 19, with another alpha following every two weeks. These are meant to be time-boxed releases, produced according to schedule with whatever is ready included. Best regards, -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat [1] https://github.com/wildfly/wildfly/tree/9.x From jperkins at redhat.com Tue May 5 17:37:16 2015 From: jperkins at redhat.com (James R. Perkins) Date: Tue, 05 May 2015 14:37:16 -0700 Subject: [wildfly-dev] WildFly Core Moving to Java 8 Message-ID: <5549380C.2010107@redhat.com> Assuming the master-ignore jobs pass I'll be moving WildFly Core to require Java 8. Note that you'll likely see more compile warnings. We'll work on cleaning those up as we go but if you feel the desire to help out please keep commits small and concise. This is your 4 (maybe more like 30) minute notice. -- James R. Perkins JBoss by Red Hat From arjan.tijms at gmail.com Tue May 5 19:21:15 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 6 May 2015 01:21:15 +0200 Subject: [wildfly-dev] Calling attention to two security bugs in WildFly Message-ID: Hi, A while back I reported https://issues.jboss.org/browse/SECURITY-746 and https://issues.jboss.org/browse/SECURITY-876 746 has been open for a long time, while 876 is relatively new. Both concern propagation of the authenticated identity from Servlet to EJB, something which unfortunately has seen bugs in some form of the other for several years now. Would really be great if this can be fixed. I provided a possible workaround for 876, and a reproducer test for both issues. If needed I can help more. Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150506/004da4ec/attachment.html From jperkins at redhat.com Tue May 5 19:45:35 2015 From: jperkins at redhat.com (James R. Perkins) Date: Tue, 05 May 2015 16:45:35 -0700 Subject: [wildfly-dev] WildFly Core Moving to Java 8 In-Reply-To: <5549380C.2010107@redhat.com> References: <5549380C.2010107@redhat.com> Message-ID: <5549561F.50509@redhat.com> The time has come. Java 8 is now required on WildFly Core master. On 05/05/2015 02:37 PM, James R. Perkins wrote: > Assuming the master-ignore jobs pass I'll be moving WildFly Core to > require Java 8. Note that you'll likely see more compile warnings. > We'll work on cleaning those up as we go but if you feel the desire to > help out please keep commits small and concise. > > This is your 4 (maybe more like 30) minute notice. > -- James R. Perkins JBoss by Red Hat From lfryc at redhat.com Wed May 6 03:06:48 2015 From: lfryc at redhat.com (Lukas Fryc) Date: Wed, 6 May 2015 09:06:48 +0200 Subject: [wildfly-dev] Embedded Arquillian Container In-Reply-To: References: <5542326F.6040602@redhat.com> Message-ID: The embedded container works great with your PR! Personally I'd say: ship it! :-) Can someone review and merge? On Mon, May 4, 2015 at 2:34 PM, Toma? Cerar wrote: > Guys, > > I've sent PR https://github.com/wildfly/wildfly-arquillian/pull/18 that > adds back embedded arquillian container > which uses wildfly-core embedded api. > > -- > tomaz > > On Mon, May 4, 2015 at 1:35 PM, Cody Lerum wrote: > >> Is there a good example published somewhere for users who want to use a >> managed container within a CI like Travis? >> >> This is becoming an increasingly pretty popular configuration, and the >> easier for the users to get started and update from release to release the >> better. >> >> -C >> On May 4, 2015 3:28 AM, "Lukas Fryc" wrote: >> >>> An only embedded container's advantage over managed container is a >>> simpler test debugging - no special setup required. >>> >>> I'm fine with dropping it, just in case it wasn't intentional decision >>> to remove embedded container, we can re-introduce it. >>> >>> ~ Lukas >>> >>> On Thu, Apr 30, 2015 at 3:47 PM, Brian Stansberry < >>> brian.stansberry at redhat.com> wrote: >>> >>>> Hi Lukas, >>>> >>>> On 4/29/15 9:58 AM, Lukas Fryc wrote: >>>> > Hey guys, >>>> > >>>> > just wondering if wildfly-arquillian-container-embedded was >>>> discontinued >>>> > with split of 9.x: >>>> > >>>> > https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96 >>>> > >>>> >>>> It was, yes, as wildfly-arquillian shouldn't depend on WildFly Full (to >>>> avoid a circular dependency) and WildFly Core didn't have an embedding >>>> module. >>>> > >>>> > When working on a re-enablement, I found out that even though arq >>>> > adapter now depends on wildfly-core/embedded, particularly >>>> > on EmbeddedServerFactory, this class has its counterpart in >>>> > wildfly/embedded as well. >>>> > >>>> >>>> I added the wildfly-core/embedded module in order to support the Offline >>>> CLI.[1] At this point I consider it to be an internal module, not >>>> public API. I expect that will soften over time, but for WildFly Core >>>> 1.0 / WildFly Full 9.0 at least, that's what it is. >>>> >>>> [1] http://wildfly.org/news/2015/03/13/Offline-CLI/ >>>> >>>> > Question is, should be embedded arquillian container still available >>>> for >>>> > 9.x? >>>> > >>>> >>>> Jason Greene would need to rule on that, but I know we were ok with >>>> dropping it before. Is there much use of it? >>>> >>>> > If yes, I can continue and provide a PR, just I will need a bit of >>>> > guidance with what EmbeddedServerFactory it should actually use (if >>>> that >>>> > matters). >>>> > >>>> >>>> What API would it need from wildfly-core/embedded? Is the >>>> StandaloneServer API there adequate? >>>> >>>> > >>>> > Cheers, >>>> > >>>> > ~ Lukas >>>> > >>>> > -- >>>> > Lukas Fryc >>>> > AeroGear Core Developer >>>> > Red Hat >>>> > >>>> > >>>> > _______________________________________________ >>>> > wildfly-dev mailing list >>>> > wildfly-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> > >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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/20150506/adb81332/attachment.html From myfear at web.de Wed May 6 06:17:43 2015 From: myfear at web.de (Markus Eisele) Date: Wed, 6 May 2015 12:17:43 +0200 Subject: [wildfly-dev] Swarm "Could not find or load main class" Message-ID: Hi, I've been playing around with swarm today and here is the source: https://github.com/myfear/WildFlySwarmDemo Very simple project. JAX-RS and nothing else. mvn package produces the jar. Execution results in: java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar Error: Could not find or load main class org.wildfly.swarm.bootstrap.Main Any help appreciated! Thanks, M ____________ @myfear http://blog.eisele.net From ken at kenfinnigan.me Wed May 6 06:40:20 2015 From: ken at kenfinnigan.me (Ken Finnigan) Date: Wed, 6 May 2015 06:40:20 -0400 Subject: [wildfly-dev] Swarm "Could not find or load main class" In-Reply-To: References: Message-ID: Hi Markus, That's weird, as I was able to clone your repo, build it, and run it without any problems. Is your fat jar around 30.1Mb in size? Does org.wildfly.swarm.bootstrap.Main exist in that jar? Thanks Ken On Wed, May 6, 2015 at 6:17 AM, Markus Eisele wrote: > Hi, > > I've been playing around with swarm today and here is the source: > https://github.com/myfear/WildFlySwarmDemo > > Very simple project. JAX-RS and nothing else. > > mvn package produces the jar. Execution results in: > > java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar > Error: Could not find or load main class org.wildfly.swarm.bootstrap.Main > > Any help appreciated! > > Thanks, > M > > ____________ > @myfear > http://blog.eisele.net > _______________________________________________ > 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/20150506/d9a60be2/attachment-0001.html From myfear at web.de Wed May 6 06:52:25 2015 From: myfear at web.de (Markus Eisele) Date: Wed, 6 May 2015 12:52:25 +0200 Subject: [wildfly-dev] Swarm "Could not find or load main class" In-Reply-To: References: Message-ID: It is around 30 Meg and does contain the class. Indeed. I have a pretty straight forward JDK setup and tried to run with both 1.7.0_65 and 1.8.0_20. Only difference is that I run on Windows? Is the maven version an issue? I'm running 3.3.3? Anything I can do to provide more debug information? Cheers, Markus On May 6, 2015 12:40 PM, "Ken Finnigan" wrote: > Hi Markus, > > That's weird, as I was able to clone your repo, build it, and run it > without any problems. > > Is your fat jar around 30.1Mb in size? Does > org.wildfly.swarm.bootstrap.Main exist in that jar? > > Thanks > Ken > > > On Wed, May 6, 2015 at 6:17 AM, Markus Eisele wrote: > >> Hi, >> >> I've been playing around with swarm today and here is the source: >> https://github.com/myfear/WildFlySwarmDemo >> >> Very simple project. JAX-RS and nothing else. >> >> mvn package produces the jar. Execution results in: >> >> java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar >> Error: Could not find or load main class org.wildfly.swarm.bootstrap.Main >> >> Any help appreciated! >> >> Thanks, >> M >> >> ____________ >> @myfear >> http://blog.eisele.net >> _______________________________________________ >> 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/20150506/dabdb337/attachment.html From jai.forums2013 at gmail.com Wed May 6 08:08:14 2015 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 06 May 2015 17:38:14 +0530 Subject: [wildfly-dev] Swarm "Could not find or load main class" In-Reply-To: References: Message-ID: <554A042E.7080603@gmail.com> A quick debugging option is to try: java -verbose:class -jar swarm-sample-1.0-SNAPSHOT-swarm.jar That will dump out some information of where the classes are being loaded from. It might give a hint on what's going on. You might want to redirect the output to a file since with that -verbose:class option, the output can potentially be huge. -Jaikiran On Wednesday 06 May 2015 04:22 PM, Markus Eisele wrote: > > It is around 30 Meg and does contain the class. Indeed. > I have a pretty straight forward JDK setup and tried to run with both > 1.7.0_65 and 1.8.0_20. > Only difference is that I run on Windows? > Is the maven version an issue? I'm running 3.3.3? > > > Anything I can do to provide more debug information? > > Cheers, > > Markus > > > On May 6, 2015 12:40 PM, "Ken Finnigan" > wrote: > > Hi Markus, > > That's weird, as I was able to clone your repo, build it, and run > it without any problems. > > Is your fat jar around 30.1Mb in size? Does > org.wildfly.swarm.bootstrap.Main exist in that jar? > > Thanks > Ken > > > On Wed, May 6, 2015 at 6:17 AM, Markus Eisele > wrote: > > Hi, > > I've been playing around with swarm today and here is the source: > https://github.com/myfear/WildFlySwarmDemo > > Very simple project. JAX-RS and nothing else. > > mvn package produces the jar. Execution results in: > > java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar > Error: Could not find or load main class > org.wildfly.swarm.bootstrap.Main > > Any help appreciated! > > Thanks, > M > > ____________ > @myfear > http://blog.eisele.net > _______________________________________________ > 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/20150506/9123761a/attachment.html From myfear at web.de Wed May 6 08:45:25 2015 From: myfear at web.de (Markus Eisele) Date: Wed, 6 May 2015 14:45:25 +0200 Subject: [wildfly-dev] Swarm "Could not find or load main class" In-Reply-To: References: <554A042E.7080603@gmail.com> Message-ID: Hi, The output doesn't contain a single org.jboss class being loaded. Also it does not contain the jar itself. So, technically speaking this can't work. But why? The command isn't exactly complicated. Any further ideas? Thanks, Markus > On May 6, 2015 2:12 PM, "Jaikiran Pai" wrote: >> >> A quick debugging option is to try: >> >> java -verbose:class -jar swarm-sample-1.0-SNAPSHOT-swarm.jar >> >> That will dump out some information of where the classes are being loaded from. It might give a hint on what's going on. You might want to redirect the output to a file since with that -verbose:class option, the output can potentially be huge. >> >> -Jaikiran >> On Wednesday 06 May 2015 04:22 PM, Markus Eisele wrote: >>> >>> It is around 30 Meg and does contain the class. Indeed. >>> I have a pretty straight forward JDK setup and tried to run with both 1.7.0_65 and 1.8.0_20. >>> Only difference is that I run on Windows? >>> Is the maven version an issue? I'm running 3.3.3? >>> >>> >>> Anything I can do to provide more debug information? >>> >>> Cheers, >>> >>> Markus >>> >>> >>> On May 6, 2015 12:40 PM, "Ken Finnigan" wrote: >>>> >>>> Hi Markus, >>>> >>>> That's weird, as I was able to clone your repo, build it, and run it without any problems. >>>> >>>> Is your fat jar around 30.1Mb in size? Does org.wildfly.swarm.bootstrap.Main exist in that jar? >>>> >>>> Thanks >>>> Ken >>>> >>>> >>>> On Wed, May 6, 2015 at 6:17 AM, Markus Eisele wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've been playing around with swarm today and here is the source: >>>>> https://github.com/myfear/WildFlySwarmDemo >>>>> >>>>> Very simple project. JAX-RS and nothing else. >>>>> >>>>> mvn package produces the jar. Execution results in: >>>>> >>>>> java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar >>>>> Error: Could not find or load main class org.wildfly.swarm.bootstrap.Main >>>>> >>>>> Any help appreciated! >>>>> >>>>> Thanks, >>>>> M >>>>> >>>>> ____________ >>>>> @myfear >>>>> http://blog.eisele.net >>>>> _______________________________________________ >>>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150506/cf2a67d1/attachment.html From ken at kenfinnigan.me Wed May 6 08:51:32 2015 From: ken at kenfinnigan.me (Ken Finnigan) Date: Wed, 6 May 2015 08:51:32 -0400 Subject: [wildfly-dev] Swarm "Could not find or load main class" In-Reply-To: References: <554A042E.7080603@gmail.com> Message-ID: Can you upload the generated jar somewhere? Then I could take a closer look Thanks Ken On Wed, May 6, 2015 at 8:45 AM, Markus Eisele wrote: > Hi, > > The output doesn't contain a single org.jboss class being loaded. Also it > does not contain the jar itself. > So, technically speaking this can't work. But why? The command isn't > exactly complicated. > > Any further ideas? > Thanks, > Markus > > > On May 6, 2015 2:12 PM, "Jaikiran Pai" wrote: > >> > >> A quick debugging option is to try: > >> > >> java -verbose:class -jar swarm-sample-1.0-SNAPSHOT-swarm.jar > >> > >> That will dump out some information of where the classes are being > loaded from. It might give a hint on what's going on. You might want to > redirect the output to a file since with that -verbose:class option, the > output can potentially be huge. > >> > >> -Jaikiran > >> On Wednesday 06 May 2015 04:22 PM, Markus Eisele wrote: > >>> > >>> It is around 30 Meg and does contain the class. Indeed. > >>> I have a pretty straight forward JDK setup and tried to run with both > 1.7.0_65 and 1.8.0_20. > >>> Only difference is that I run on Windows? > >>> Is the maven version an issue? I'm running 3.3.3? > >>> > >>> > >>> Anything I can do to provide more debug information? > >>> > >>> Cheers, > >>> > >>> Markus > >>> > >>> > >>> On May 6, 2015 12:40 PM, "Ken Finnigan" wrote: > >>>> > >>>> Hi Markus, > >>>> > >>>> That's weird, as I was able to clone your repo, build it, and run it > without any problems. > >>>> > >>>> Is your fat jar around 30.1Mb in size? Does > org.wildfly.swarm.bootstrap.Main exist in that jar? > >>>> > >>>> Thanks > >>>> Ken > >>>> > >>>> > >>>> On Wed, May 6, 2015 at 6:17 AM, Markus Eisele wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I've been playing around with swarm today and here is the source: > >>>>> https://github.com/myfear/WildFlySwarmDemo > >>>>> > >>>>> Very simple project. JAX-RS and nothing else. > >>>>> > >>>>> mvn package produces the jar. Execution results in: > >>>>> > >>>>> java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar > >>>>> Error: Could not find or load main class > org.wildfly.swarm.bootstrap.Main > >>>>> > >>>>> Any help appreciated! > >>>>> > >>>>> Thanks, > >>>>> M > >>>>> > >>>>> ____________ > >>>>> @myfear > >>>>> http://blog.eisele.net > >>>>> _______________________________________________ > >>>>> 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 > > _______________________________________________ > 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/20150506/1174e33b/attachment-0001.html From myfear at web.de Wed May 6 09:22:11 2015 From: myfear at web.de (Markus Eisele) Date: Wed, 6 May 2015 15:22:11 +0200 Subject: [wildfly-dev] Swarm "Could not find or load main class" In-Reply-To: References: <554A042E.7080603@gmail.com> Message-ID: Here it is: https://www.dropbox.com/s/9n57o55gqvt0u21/swarm-sample-1.0-SNAPSHOT-swarm.jar?dl=0 Thanks for looking into it! Cheers, Markus On 6 May 2015 at 14:51, Ken Finnigan wrote: > Can you upload the generated jar somewhere? > > Then I could take a closer look > > Thanks > Ken > > On Wed, May 6, 2015 at 8:45 AM, Markus Eisele wrote: >> >> Hi, >> >> The output doesn't contain a single org.jboss class being loaded. Also it >> does not contain the jar itself. >> So, technically speaking this can't work. But why? The command isn't >> exactly complicated. >> >> Any further ideas? >> Thanks, >> Markus >> >> > On May 6, 2015 2:12 PM, "Jaikiran Pai" wrote: >> >> >> >> A quick debugging option is to try: >> >> >> >> java -verbose:class -jar swarm-sample-1.0-SNAPSHOT-swarm.jar >> >> >> >> That will dump out some information of where the classes are being >> >> loaded from. It might give a hint on what's going on. You might want to >> >> redirect the output to a file since with that -verbose:class option, the >> >> output can potentially be huge. >> >> >> >> -Jaikiran >> >> On Wednesday 06 May 2015 04:22 PM, Markus Eisele wrote: >> >>> >> >>> It is around 30 Meg and does contain the class. Indeed. >> >>> I have a pretty straight forward JDK setup and tried to run with both >> >>> 1.7.0_65 and 1.8.0_20. >> >>> Only difference is that I run on Windows? >> >>> Is the maven version an issue? I'm running 3.3.3? >> >>> >> >>> >> >>> Anything I can do to provide more debug information? >> >>> >> >>> Cheers, >> >>> >> >>> Markus >> >>> >> >>> >> >>> On May 6, 2015 12:40 PM, "Ken Finnigan" wrote: >> >>>> >> >>>> Hi Markus, >> >>>> >> >>>> That's weird, as I was able to clone your repo, build it, and run it >> >>>> without any problems. >> >>>> >> >>>> Is your fat jar around 30.1Mb in size? Does >> >>>> org.wildfly.swarm.bootstrap.Main exist in that jar? >> >>>> >> >>>> Thanks >> >>>> Ken >> >>>> >> >>>> >> >>>> On Wed, May 6, 2015 at 6:17 AM, Markus Eisele wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> I've been playing around with swarm today and here is the source: >> >>>>> https://github.com/myfear/WildFlySwarmDemo >> >>>>> >> >>>>> Very simple project. JAX-RS and nothing else. >> >>>>> >> >>>>> mvn package produces the jar. Execution results in: >> >>>>> >> >>>>> java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar >> >>>>> Error: Could not find or load main class >> >>>>> org.wildfly.swarm.bootstrap.Main >> >>>>> >> >>>>> Any help appreciated! >> >>>>> >> >>>>> Thanks, >> >>>>> M >> >>>>> >> >>>>> ____________ >> >>>>> @myfear >> >>>>> http://blog.eisele.net >> >>>>> _______________________________________________ >> >>>>> 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 >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From bmcwhirt at redhat.com Wed May 6 09:24:05 2015 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Wed, 6 May 2015 09:24:05 -0400 Subject: [wildfly-dev] Swarm "Could not find or load main class" In-Reply-To: References: <554A042E.7080603@gmail.com> Message-ID: <02C601B2-235E-419B-BA0D-6EED23183F9E@redhat.com> Plugin seems to be constructing the jar with backwards slashes? org\jboss\modules\Util.class -Bob > On May 6, 2015, at 9:22 AM, Markus Eisele wrote: > > Here it is: > > https://www.dropbox.com/s/9n57o55gqvt0u21/swarm-sample-1.0-SNAPSHOT-swarm.jar?dl=0 > > Thanks for looking into it! > > Cheers, > Markus > > On 6 May 2015 at 14:51, Ken Finnigan wrote: >> Can you upload the generated jar somewhere? >> >> Then I could take a closer look >> >> Thanks >> Ken >> >> On Wed, May 6, 2015 at 8:45 AM, Markus Eisele wrote: >>> >>> Hi, >>> >>> The output doesn't contain a single org.jboss class being loaded. Also it >>> does not contain the jar itself. >>> So, technically speaking this can't work. But why? The command isn't >>> exactly complicated. >>> >>> Any further ideas? >>> Thanks, >>> Markus >>> >>>> On May 6, 2015 2:12 PM, "Jaikiran Pai" wrote: >>>>> >>>>> A quick debugging option is to try: >>>>> >>>>> java -verbose:class -jar swarm-sample-1.0-SNAPSHOT-swarm.jar >>>>> >>>>> That will dump out some information of where the classes are being >>>>> loaded from. It might give a hint on what's going on. You might want to >>>>> redirect the output to a file since with that -verbose:class option, the >>>>> output can potentially be huge. >>>>> >>>>> -Jaikiran >>>>> On Wednesday 06 May 2015 04:22 PM, Markus Eisele wrote: >>>>>> >>>>>> It is around 30 Meg and does contain the class. Indeed. >>>>>> I have a pretty straight forward JDK setup and tried to run with both >>>>>> 1.7.0_65 and 1.8.0_20. >>>>>> Only difference is that I run on Windows? >>>>>> Is the maven version an issue? I'm running 3.3.3? >>>>>> >>>>>> >>>>>> Anything I can do to provide more debug information? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Markus >>>>>> >>>>>> >>>>>> On May 6, 2015 12:40 PM, "Ken Finnigan" wrote: >>>>>>> >>>>>>> Hi Markus, >>>>>>> >>>>>>> That's weird, as I was able to clone your repo, build it, and run it >>>>>>> without any problems. >>>>>>> >>>>>>> Is your fat jar around 30.1Mb in size? Does >>>>>>> org.wildfly.swarm.bootstrap.Main exist in that jar? >>>>>>> >>>>>>> Thanks >>>>>>> Ken >>>>>>> >>>>>>> >>>>>>> On Wed, May 6, 2015 at 6:17 AM, Markus Eisele wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've been playing around with swarm today and here is the source: >>>>>>>> https://github.com/myfear/WildFlySwarmDemo >>>>>>>> >>>>>>>> Very simple project. JAX-RS and nothing else. >>>>>>>> >>>>>>>> mvn package produces the jar. Execution results in: >>>>>>>> >>>>>>>> java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar >>>>>>>> Error: Could not find or load main class >>>>>>>> org.wildfly.swarm.bootstrap.Main >>>>>>>> >>>>>>>> Any help appreciated! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> M >>>>>>>> >>>>>>>> ____________ >>>>>>>> @myfear >>>>>>>> http://blog.eisele.net >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 ken at kenfinnigan.me Wed May 6 11:29:32 2015 From: ken at kenfinnigan.me (Ken Finnigan) Date: Wed, 6 May 2015 11:29:32 -0400 Subject: [wildfly-dev] Swarm "Could not find or load main class" In-Reply-To: <02C601B2-235E-419B-BA0D-6EED23183F9E@redhat.com> References: <554A042E.7080603@gmail.com> <02C601B2-235E-419B-BA0D-6EED23183F9E@redhat.com> Message-ID: Markus, There are some issues with WildFly Swarm on Windows at the moment. I'm currently working my way through resolving them. Ken On Wed, May 6, 2015 at 9:24 AM, Bob McWhirter wrote: > Plugin seems to be constructing the jar with backwards slashes? > > org\jboss\modules\Util.class > > -Bob > > > > On May 6, 2015, at 9:22 AM, Markus Eisele wrote: > > > > Here it is: > > > > > https://www.dropbox.com/s/9n57o55gqvt0u21/swarm-sample-1.0-SNAPSHOT-swarm.jar?dl=0 > > > > Thanks for looking into it! > > > > Cheers, > > Markus > > > > On 6 May 2015 at 14:51, Ken Finnigan wrote: > >> Can you upload the generated jar somewhere? > >> > >> Then I could take a closer look > >> > >> Thanks > >> Ken > >> > >> On Wed, May 6, 2015 at 8:45 AM, Markus Eisele wrote: > >>> > >>> Hi, > >>> > >>> The output doesn't contain a single org.jboss class being loaded. Also > it > >>> does not contain the jar itself. > >>> So, technically speaking this can't work. But why? The command isn't > >>> exactly complicated. > >>> > >>> Any further ideas? > >>> Thanks, > >>> Markus > >>> > >>>> On May 6, 2015 2:12 PM, "Jaikiran Pai" > wrote: > >>>>> > >>>>> A quick debugging option is to try: > >>>>> > >>>>> java -verbose:class -jar swarm-sample-1.0-SNAPSHOT-swarm.jar > >>>>> > >>>>> That will dump out some information of where the classes are being > >>>>> loaded from. It might give a hint on what's going on. You might want > to > >>>>> redirect the output to a file since with that -verbose:class option, > the > >>>>> output can potentially be huge. > >>>>> > >>>>> -Jaikiran > >>>>> On Wednesday 06 May 2015 04:22 PM, Markus Eisele wrote: > >>>>>> > >>>>>> It is around 30 Meg and does contain the class. Indeed. > >>>>>> I have a pretty straight forward JDK setup and tried to run with > both > >>>>>> 1.7.0_65 and 1.8.0_20. > >>>>>> Only difference is that I run on Windows? > >>>>>> Is the maven version an issue? I'm running 3.3.3? > >>>>>> > >>>>>> > >>>>>> Anything I can do to provide more debug information? > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Markus > >>>>>> > >>>>>> > >>>>>> On May 6, 2015 12:40 PM, "Ken Finnigan" wrote: > >>>>>>> > >>>>>>> Hi Markus, > >>>>>>> > >>>>>>> That's weird, as I was able to clone your repo, build it, and run > it > >>>>>>> without any problems. > >>>>>>> > >>>>>>> Is your fat jar around 30.1Mb in size? Does > >>>>>>> org.wildfly.swarm.bootstrap.Main exist in that jar? > >>>>>>> > >>>>>>> Thanks > >>>>>>> Ken > >>>>>>> > >>>>>>> > >>>>>>> On Wed, May 6, 2015 at 6:17 AM, Markus Eisele > wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I've been playing around with swarm today and here is the source: > >>>>>>>> https://github.com/myfear/WildFlySwarmDemo > >>>>>>>> > >>>>>>>> Very simple project. JAX-RS and nothing else. > >>>>>>>> > >>>>>>>> mvn package produces the jar. Execution results in: > >>>>>>>> > >>>>>>>> java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar > >>>>>>>> Error: Could not find or load main class > >>>>>>>> org.wildfly.swarm.bootstrap.Main > >>>>>>>> > >>>>>>>> Any help appreciated! > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> M > >>>>>>>> > >>>>>>>> ____________ > >>>>>>>> @myfear > >>>>>>>> http://blog.eisele.net > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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/20150506/41ad13fd/attachment.html From brian.stansberry at redhat.com Wed May 6 12:10:43 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 06 May 2015 11:10:43 -0500 Subject: [wildfly-dev] Embedded Arquillian Container In-Reply-To: References: <5542326F.6040602@redhat.com> Message-ID: <554A3D03.3040302@redhat.com> On 5/6/15 2:06 AM, Lukas Fryc wrote: > The embedded container works great with your PR! > > Personally I'd say: ship it! :-) > > Can someone review and merge? > I'll need to get https://issues.jboss.org/browse/WFCORE-677 into WildFly Core 1.0.0.CR2. And once that's there, Tomaz (or someone), please add a commit getting rid of the "bundlePath" property from https://github.com/wildfly/wildfly-arquillian/blob/master/container-embedded/src/main/java/org/jboss/as/arquillian/container/embedded/EmbeddedContainerConfiguration.java Thanks. > On Mon, May 4, 2015 at 2:34 PM, Toma? Cerar > wrote: > > Guys, > > I've sent PR https://github.com/wildfly/wildfly-arquillian/pull/18 > that adds back embedded arquillian container > which uses wildfly-core embedded api. > > -- > tomaz > > On Mon, May 4, 2015 at 1:35 PM, Cody Lerum > wrote: > > Is there a good example published somewhere for users who want > to use a managed container within a CI like Travis? > > This is becoming an increasingly pretty popular configuration, > and the easier for the users to get started and update from > release to release the better. > > -C > > On May 4, 2015 3:28 AM, "Lukas Fryc" > wrote: > > An only embedded container's advantage over managed > container is a simpler test debugging - no special setup > required. > > I'm fine with dropping it, just in case it wasn't > intentional decision to remove embedded container, we can > re-introduce it. > > ~ Lukas > > On Thu, Apr 30, 2015 at 3:47 PM, Brian Stansberry > > wrote: > > Hi Lukas, > > On 4/29/15 9:58 AM, Lukas Fryc wrote: > > Hey guys, > > > > just wondering if wildfly-arquillian-container-embedded was discontinued > > with split of 9.x: > > > >https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96 > > > > It was, yes, as wildfly-arquillian shouldn't depend on > WildFly Full (to > avoid a circular dependency) and WildFly Core didn't > have an embedding > module. > > > > When working on a re-enablement, I found out that even though arq > > adapter now depends on wildfly-core/embedded, particularly > > on EmbeddedServerFactory, this class has its counterpart in > > wildfly/embedded as well. > > > > I added the wildfly-core/embedded module in order to > support the Offline > CLI.[1] At this point I consider it to be an internal > module, not > public API. I expect that will soften over time, but for > WildFly Core > 1.0 / WildFly Full 9.0 at least, that's what it is. > > [1] http://wildfly.org/news/2015/03/13/Offline-CLI/ > > > Question is, should be embedded arquillian container still available for > > 9.x? > > > > Jason Greene would need to rule on that, but I know we > were ok with > dropping it before. Is there much use of it? > > > If yes, I can continue and provide a PR, just I will need a bit of > > guidance with what EmbeddedServerFactory it should actually use (if that > > matters). > > > > What API would it need from wildfly-core/embedded? Is the > StandaloneServer API there adequate? > > > > > Cheers, > > > > ~ Lukas > > > > -- > > Lukas Fryc > > AeroGear Core Developer > > Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > 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 > > > > _______________________________________________ > 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Thu May 7 06:16:33 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 07 May 2015 11:16:33 +0100 Subject: [wildfly-dev] Bring back jboss-admin.sh Message-ID: <554B3B81.8010005@jboss.com> Before it was called jboss-cli,sh the script was called jboss-admin.sh IMO the latter was always a more obvious name for users to call but as it was only a CLI the name was changed. Then we added a GUI mode. I would think we could then add more to it: - - Give our admin tool the ability to start jconsole. - Add the user maintenance and SSL maintenance features to it. - Give it the ability to start your web browser for the admin console? For the latter I wonder if we could benefit from the tool having a connection to the server, maybe make use of KeyCloak to obtain an SSO token that is included in the URL to start the browser and we could possibly achieve a form of local auth for web. Not sure what other thoughts are but these are just a couple of points on my mind. Regards, Darran Lofthouse. From ewertz at redhat.com Thu May 7 09:41:21 2015 From: ewertz at redhat.com (Edward Wertz) Date: Thu, 7 May 2015 09:41:21 -0400 (EDT) Subject: [wildfly-dev] Bring back jboss-admin.sh In-Reply-To: <554B3B81.8010005@jboss.com> References: <554B3B81.8010005@jboss.com> Message-ID: <33357071.71.1431006077270.JavaMail.joe@localhost.localdomain> Hey Darran, I'm currently working on an upgrade of the AESH console used by the CLI. Mostly to get a more familiarity with the code base, but also to fix some lingering issues and make it easier to create new commands. After that, and possibly some refactoring, I was going to start trying to gather some information about how people use the interface, either CLI or GUI, and what else they'd like it to be able to do. I hadn't given further development too much thought yet though. Folding in the other script's functionality, like add-user at minimum since it's in wildfly-core, does seem like an obvious place to start when you mention it. If something is going to be called 'the' CLI, after all, it should probably be the only necessary interface. I was already working on getting AESH to handle nested commands. Something simple for the upgrade, but it might be able to expand into something able to act as an entry point for the other script functionality as well. I'm not sure about how to handle scripts outside of core. But, I suppose that's a bridge to cross after add-user works. I'll keep this in mind. I might have been trying to think of large enhancements, but the small annoyance of needing to use 2 or 3 different scripts instead of one can easily be just as bad as any missing functionality. It's already there, just badly organized, which is almost worse than it not existing in the first place. -- Joe ----- Original Message ----- > From: "Darran Lofthouse" > To: wildfly-dev at lists.jboss.org > Sent: Thursday, May 7, 2015 6:16:33 PM > Subject: [wildfly-dev] Bring back jboss-admin.sh > > Before it was called jboss-cli,sh the script was called > jboss-admin.sh > IMO the latter was always a more obvious name for users to call but > as > it was only a CLI the name was changed. Then we added a GUI mode. > > I would think we could then add more to it: - > - Give our admin tool the ability to start jconsole. > - Add the user maintenance and SSL maintenance features to it. > - Give it the ability to start your web browser for the admin > console? > > For the latter I wonder if we could benefit from the tool having a > connection to the server, maybe make use of KeyCloak to obtain an SSO > token that is included in the URL to start the browser and we could > possibly achieve a form of local auth for web. > > Not sure what other thoughts are but these are just a couple of > points > on my mind. > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From belaran at redhat.com Thu May 7 10:02:14 2015 From: belaran at redhat.com (Romain PELISSE) Date: Thu, 7 May 2015 16:02:14 +0200 Subject: [wildfly-dev] Bring back jboss-admin.sh In-Reply-To: <33357071.71.1431006077270.JavaMail.joe@localhost.localdomain> References: <554B3B81.8010005@jboss.com> <33357071.71.1431006077270.JavaMail.joe@localhost.localdomain> Message-ID: <20150507140214.GJ14236@august.redhat.com> I don't know if such approach is feasible for JBoss, but for PMD, I had the same issues. Every time we added a new "main" (ie a tool) we had yet another scripts. As all of those scripts more/less did the same thing, I end up having one, single bash script called "run.sh"[1] that required, as a first param the name of the "main class" to run. I wonder if we could have something like that: ./bin/run.sh 'add-user' ./bin/run.h 'jconsole' ./bin/run.sh 'jboss-admin' (and so on...) This would work only if all those "admin utilities" more/less required the same classpath. (or at least survives sharing classpath with other admin utilities). [1] https://github.com/pmd/pmd/blob/master/pmd-dist/src/main/scripts/run.sh On Thu, May 07, 2015 at 09:41:21AM -0400, Edward Wertz wrote: > Hey Darran, > > I'm currently working on an upgrade of the AESH console used by the CLI. Mostly to get a more familiarity with the code base, but also to fix some lingering issues and make it easier to create new commands. After that, and possibly some refactoring, I was going to start trying to gather some information about how people use the interface, either CLI or GUI, and what else they'd like it to be able to do. I hadn't given further development too much thought yet though. > > Folding in the other script's functionality, like add-user at minimum since it's in wildfly-core, does seem like an obvious place to start when you mention it. If something is going to be called 'the' CLI, after all, it should probably be the only necessary interface. I was already working on getting AESH to handle nested commands. Something simple for the upgrade, but it might be able to expand into something able to act as an entry point for the other script functionality as well. > > I'm not sure about how to handle scripts outside of core. But, I suppose that's a bridge to cross after add-user works. > > I'll keep this in mind. I might have been trying to think of large enhancements, but the small annoyance of needing to use 2 or 3 different scripts instead of one can easily be just as bad as any missing functionality. It's already there, just badly organized, which is almost worse than it not existing in the first place. > > -- Joe > > > > > ----- Original Message ----- > > From: "Darran Lofthouse" > > To: wildfly-dev at lists.jboss.org > > Sent: Thursday, May 7, 2015 6:16:33 PM > > Subject: [wildfly-dev] Bring back jboss-admin.sh > > > > Before it was called jboss-cli,sh the script was called > > jboss-admin.sh > > IMO the latter was always a more obvious name for users to call but > > as > > it was only a CLI the name was changed. Then we added a GUI mode. > > > > I would think we could then add more to it: - > > - Give our admin tool the ability to start jconsole. > > - Add the user maintenance and SSL maintenance features to it. > > - Give it the ability to start your web browser for the admin > > console? > > > > For the latter I wonder if we could benefit from the tool having a > > connection to the server, maybe make use of KeyCloak to obtain an SSO > > token that is included in the URL to start the browser and we could > > possibly achieve a form of local auth for web. > > > > Not sure what other thoughts are but these are just a couple of > > points > > on my mind. > > > > Regards, > > Darran Lofthouse. > > _______________________________________________ > > 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 -- Best Regards, http://developerblog.redhat.com/author/rpelisse/ Romain PELISSE Software Engineer Red Hat GmbH Zieher Business Centers, Am Treptower Park 75, 12435 Berlin Germany Cell (DE): +49 (0) 172-7442628 Cell (FR): +33 (0) 669304455 Delivering value year after year Red Hat ranks # 1 in value among software vendors http://www.redhat.com/promo/vendor/ Freedom...Courage...Commitment...Accountability Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters From sguilhen at redhat.com Thu May 7 15:55:54 2015 From: sguilhen at redhat.com (Stefan Guilhen) Date: Thu, 07 May 2015 16:55:54 -0300 Subject: [wildfly-dev] Calling attention to two security bugs in WildFly In-Reply-To: References: Message-ID: <554BC34A.6010100@redhat.com> I'll move these issues over to WildFly as they have nothing to do with PicketBox. I'm currently looking into 876 (logout not clearing the context) and it should be fixed for WF9. Regarding SECURITY-746, historically the EJB container has always setup a new security context when a call is made to a protected EJB. There is no mechanism in place to skip any authentication and just trust the incoming context. The Elytron project will tackle the security context propagation issues that we have today, so anything we code for WF9 in that sense will be just a temporary band aid. Its also worth saying that this issue affects mainly apps that use JASPIC for authentication - most of the time applications use regular JAAS based security domains so usually the same domain and login modules are involved in both Web and EJB authentication. When using JASPIC, the EJB app might need a different domain configuration to handle its authentication, which is an annoyance. Anil tried getting around that in the past by setting the so called "login-module-stack" in the JASPIC configuration, so that both Web and EJB layers would end up doing the regular JAAS based login and thus you wouldn't need a different domain configuration. However, a JASPIC module is not required to go through JAAS, so I can see why that can be a problem. That being said, one possible solution would be to reuse the incoming context if it already contains an authenticated subject and if the security domain of the incoming context matches the one configured in the EJB app. This would probably need a flag like "trust-incoming-security-context" in the EJB subsystem because it will change how the server handles authentication in EJB container and how existing apps are protected. The default value would be false to preserve current behavior but one could change it to true in order to reuse the context that was established in the Web layer. Of course, if the EJB app defines a different security domain then we create a new context and enforce authentication against this domain instead of trusting an incoming security context. It is not the best solution but might be ok as a workaround until Elytron gets properly integrated. On 05/05/2015 08:21 PM, arjan tijms wrote: > Hi, > > A while back I reported https://issues.jboss.org/browse/SECURITY-746 > and https://issues.jboss.org/browse/SECURITY-876 > > 746 has been open for a long time, while 876 is relatively new. > > Both concern propagation of the authenticated identity from Servlet to > EJB, something which unfortunately has seen bugs in some form of the > other for several years now. > > Would really be great if this can be fixed. I provided a possible > workaround for 876, and a reproducer test for both issues. If needed I > can help more. > > Kind regards, > Arjan Tijms > > > _______________________________________________ > 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/20150507/311a9c54/attachment.html From arjan.tijms at gmail.com Thu May 7 16:59:06 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 7 May 2015 22:59:06 +0200 Subject: [wildfly-dev] Calling attention to two security bugs in WildFly In-Reply-To: <554BC34A.6010100@redhat.com> References: <554BC34A.6010100@redhat.com> Message-ID: Hi, On Thu, May 7, 2015 at 9:55 PM, Stefan Guilhen wrote: > I'll move these issues over to WildFly as they have nothing to do with > PicketBox. I'm currently looking into 876 (logout not clearing the context) > and it should be fixed for WF9. > 876 indeed seemed wrong in PicketBox, I'm not sure what I was thinking back then. As I think the problem wasn't even JASPIC specific, I filed a new issue in Undertow which Stuart then moved to WildFly, where it's now at: https://issues.jboss.org/browse/WFLY-4602 I think it finally has found the right place ;) > Regarding SECURITY-746, historically the EJB container has always setup a > new security context when a call is made to a protected EJB. There is no > mechanism in place to skip any authentication and just trust the incoming > context. > Yes I know, although it's maybe extra confusing that when the EJB is not protected (doesn't use the implicit interceptor for @RolesAllowed), but does use the security machinery manually (via the ejb context), then the authenticated identity that was established in the web layer is available to the EJB bean. > Its also worth saying that this issue affects mainly apps that use JASPIC > for authentication - most of the time applications use regular JAAS based > security domains so usually the same domain and login modules are involved > in both Web and EJB authentication. > Indeed, in those cases the web layer has an authentication mechanism defined (e.g. Servlet's FORM) that always delegates to what we call an "identity store" in the security EG (which is roughly a JAAS login module). EJB doesn't have the authentication mechanism concept, and only uses the "identity store". Effectively the problem is still there though, as you have to make sure as a developer that the web and ejb layers use the same domain/module, plus you don't really want to re-authenticate for every call to every secured EJB all the time. JBoss works around this problem by using an authentication cache. So effectively you could perhaps say that with the proprietary JAAS based domains the identity does propagate, via the cache. I think it rarely happens that the JAAS module is indeed called following a call from a Servlet to an EJB as it almost always hits the cache (before JASPIC I used the JBoss specific JAAS modules for a long time). > When using JASPIC, the EJB app might need a different domain configuration > to handle its authentication, which is an annoyance. Anil tried getting > around that in the past by setting the so called "login-module-stack" in > the JASPIC configuration, so that both Web and EJB layers would end up > doing the regular JAAS based login and thus you wouldn't need a different > domain configuration. However, a JASPIC module is not required to go > through JAAS, so I can see why that can be a problem. > This solution that Anil had back then is still something that's worth investigating today. A JASPIC module is indeed not required to delegate to an "identity store", but it would be great if there was a standard mechanism to configure that it should do that and a means for the container to see that this configuration is in place. There's the JASPIC bridge profile that somewhat says something about this, but I'm not sure that this would work here. Another thing to consider is that in modern Java EE programming EJB beans are often just local and very simple beans that are even put directly in the war. Mentally there is no "web layer" or "ejb layer" in the sense as there once was when remote EJBs and separate EJB modules where more the norm. > That being said, one possible solution would be to reuse the incoming > context if it already contains an authenticated subject and if the security > domain of the incoming context matches the one configured in the EJB app. > This would probably need a flag like "trust-incoming-security-context" in > the EJB subsystem because it will change how the server handles > authentication in EJB container and how existing apps are protected. The > default value would be false to preserve current behavior but one could > change it to true in order to reuse the context that was established in the > Web layer. Of course, if the EJB app defines a different security domain > then we create a new context and enforce authentication against this domain > instead of trusting an incoming security context. > > It is not the best solution but might be ok as a workaround until Elytron > gets properly integrated. > Well, it sounds like a very obvious and straightforward solution. Just wondering, but did you ever check how some other other servers do this? As far as I know almost all of them automatically propagate the context from a Servlet to an EJB bean (at least GlassFish, WebLogic and Geronimo do this for sure). Kind regards, Arjan Tijms > > > On 05/05/2015 08:21 PM, arjan tijms wrote: > > Hi, > > A while back I reported https://issues.jboss.org/browse/SECURITY-746 and > https://issues.jboss.org/browse/SECURITY-876 > > 746 has been open for a long time, while 876 is relatively new. > > Both concern propagation of the authenticated identity from Servlet to > EJB, something which unfortunately has seen bugs in some form of the other > for several years now. > > Would really be great if this can be fixed. I provided a possible > workaround for 876, and a reproducer test for both issues. If needed I can > help more. > > Kind regards, > Arjan Tijms > > > _______________________________________________ > wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://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/20150507/9a427df5/attachment-0001.html From jperkins at redhat.com Thu May 7 17:24:36 2015 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 07 May 2015 14:24:36 -0700 Subject: [wildfly-dev] WildFly Full Moving to Java 8 Message-ID: <554BD814.9080604@redhat.com> And now it's time for WildFly Full to move to Java 8. Sames rules/warnings about WildFly Core's move to Java 8. Please no just refactor PR's to things like lambdas, diamond operators, etc. If you're fixing compile warnings please keep commits small and concise. Likely one commit per maven module. Though we don't want to get into just refactoring because we can. -- James R. Perkins JBoss by Red Hat From jperkins at redhat.com Thu May 7 18:07:18 2015 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 07 May 2015 15:07:18 -0700 Subject: [wildfly-dev] WildFly Full Moving to Java 8 In-Reply-To: <554BD814.9080604@redhat.com> References: <554BD814.9080604@redhat.com> Message-ID: <554BE216.5070303@redhat.com> WildFly Full master is now on Java 8. On 05/07/2015 02:24 PM, James R. Perkins wrote: > And now it's time for WildFly Full to move to Java 8. Sames > rules/warnings about WildFly Core's move to Java 8. Please no just > refactor PR's to things like lambdas, diamond operators, etc. If > you're fixing compile warnings please keep commits small and concise. > Likely one commit per maven module. Though we don't want to get into > just refactoring because we can. > -- James R. Perkins JBoss by Red Hat From brian.stansberry at redhat.com Fri May 8 17:19:02 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 08 May 2015 16:19:02 -0500 Subject: [wildfly-dev] WildFly Core 1.0.0.CR2 is released Message-ID: <554D2846.7010305@redhat.com> This afternoon I released version 1.0.0.CR2 of WildFly Core. It has been integrated into the 9.x branch of full WildFly. Best regards, -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From frank.langelage at osnanet.de Sun May 10 15:34:16 2015 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sun, 10 May 2015 21:34:16 +0200 Subject: [wildfly-dev] WildFly Full 10.0.0.Alpha1-SNAPSHOT identifies itself as WildFly Full 9.0.0.CR2-SNAPSHOT Message-ID: <554FB2B8.3030508@osnanet.de> I updated my workspace today and did a new build using Java 8. But on startup of Wildfly it identifies itself still as WildFly Full 9.0.0.CR2-SNAPSHOT. 10.05. 21:26:15,923 INFO [org.jboss.as#done] WFLYSRV0025: WildFly Full 9.0.0.CR2-SNAPSHOT (WildFly Core 1.0.0.CR1) started in 9023ms - Started 518 of 722 services (265 services are lazy, passive or on-demand) It seems that feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/product/wildfly-full/dir/META-INF/MANIFEST.MF web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/product/wildfly-web/dir/META-INF/MANIFEST.MF need to be updated too. From arun.gupta at gmail.com Sun May 10 15:39:27 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Sun, 10 May 2015 12:39:27 -0700 Subject: [wildfly-dev] WildFly 9.0.0.CR1 is released! In-Reply-To: <39185635-F80F-45F9-8A18-A864442A0612@redhat.com> References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com> <650C9391-96AD-4721-B4AF-EA0B758DFA85@redhat.com> <39185635-F80F-45F9-8A18-A864442A0612@redhat.com> Message-ID: Took some time but finally got to it 38k above the ground :) This worked. But what changed from WildFly 8.2 that this configuration is required? Marek, any idea? Arun On Tue, May 5, 2015 at 1:21 AM, Jeff Mesnil wrote: > Could you try something please? > > Update the standalone-full.xml by adding an outbound-socket-binding in the standard-sockets group: > > > > > > and reference this socket-binding (http-messaging) from the messaging?s http-connector: > > > > > > With that changes, the host setting for the messaging?s HTTP connector is not tied to the socket bound for the server to accept connections. > > You can then start the server with ./standalone.sh -c standalone-full.xml -b 0.0.0.0 -Djboss.messaging.http.host= > > The server will run fine and JMS clients would be able to connect to the servers through the address. > > I assume you can somehow pass an env variable to the Dockerfile so that the IP address can be specified only when Docker actually run the container? > > If you confirm it works, that?s a configuration we can have by default to simplify running WildFly in a container. > > jeff > > >> On 04 May 2015, at 18:38, Arun Gupta wrote: >> >> Jeff, >> >>>> >>>> docker run -it -p 8080:8080 arungupta/wildfly:9cr1 >>>> >>>> Any idea? >> >> The complete error message is: >> >> 15:53:03,915 INFO [org.hornetq.jms.server] (ServerService Thread Pool >> -- 65) HQ121005: Invalid "host" value "0.0.0.0" detected for >> "http-connector" connector. Switching to "2f9ad0bb1373". If this new >> address is incorrect please manually configure the connector to use >> the proper one. >> >> >>> >>> You bind all sockets to the 0.0.0.0 address when you start WildFly >>> When HornetQ starts, it looks like it is checking whether this address is valid for clients to connect to the server. >>> >>> You need to either pass a ?valid? address (that clients can connect to) using -b or you need to tweak the http-connector resource and instead of using the http socket-binding to specify port=8080 and host=. >>> >> >> Running the following command inside the container: >> >> /opt/jboss/wildfly/bin/standalone.sh -c standalone-full.xml -b 192.168.99.100 >> >> gives the following error: >> >> 16:00:58,663 INFO [org.jboss.as.server] (Controller Boot Thread) >> WFLYSRV0039: Creating http management service using socket-binding >> (management-http) >> 16:00:58,683 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.1.Final >> 16:00:58,693 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO >> Implementation Version 3.3.1.Final >> 16:00:58,697 ERROR [org.jboss.msc.service.fail] (MSC service thread >> 1-5) MSC000001: Failed to start service jboss.network.public: >> org.jboss.msc.service.StartException in service jboss.network.public: >> WFLYSRV0082: failed to resolve interface public >> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91) >> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) >> [jboss-msc-1.2.4.Final.jar:1.2.4.Final] >> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) >> [jboss-msc-1.2.4.Final.jar:1.2.4.Final] >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_65] >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_65] >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] >> >> And then all other modules fail with the following error: >> >> 16:00:59,499 ERROR [org.jboss.as.controller.management-operation] >> (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - >> address: ([ >> ("core-service" => "management"), >> ("management-interface" => "http-interface") >> ]) - failure description: {"WFLYCTL0288: One or more services were >> unable to start due to one or more indirect dependencies not being >> available." => { >> "Services that were unable to start:" => [ >> "jboss.serverManagement.controller.management.http", >> "jboss.serverManagement.controller.management.http.shutdown" >> ], >> "Services that may be the cause:" => [ >> "jboss.http-upgrade-registry.default", >> "jboss.remoting.remotingConnectorInfoService.http-remoting-connector" >> ] >> }} >> >> Docker container address may not be known until the actual start, >> certainly not when the image is built. The IP address cannot be baked >> into the Dockerfile as it may not be available during the build time. >> >> This error message showed up for WildFly 8.2 as well but >> http//:8080 was accessible. Not in this case. >> >> What changed? >> >> Arun >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > -- http://blog.arungupta.me http://twitter.com/arungupta From eduardo.santanadasilva at gmail.com Sun May 10 15:50:44 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Sun, 10 May 2015 16:50:44 -0300 Subject: [wildfly-dev] WildFly Full 10.0.0.Alpha1-SNAPSHOT identifies itself as WildFly Full 9.0.0.CR2-SNAPSHOT In-Reply-To: <554FB2B8.3030508@osnanet.de> References: <554FB2B8.3030508@osnanet.de> Message-ID: I've created a PR for that: https://github.com/wildfly/wildfly/pull/7439 2015-05-10 16:34 GMT-03:00 Frank Langelage : > I updated my workspace today and did a new build using Java 8. > But on startup of Wildfly it identifies itself still as WildFly Full > 9.0.0.CR2-SNAPSHOT. > > 10.05. 21:26:15,923 INFO [org.jboss.as#done] WFLYSRV0025: WildFly Full > 9.0.0.CR2-SNAPSHOT (WildFly Core 1.0.0.CR1) started in 9023ms - Started > 518 of 722 services (265 services are lazy, passive or on-demand) > > It seems that > > feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/product/wildfly-full/dir/META-INF/MANIFEST.MF > > web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/product/wildfly-web/dir/META-INF/MANIFEST.MF > need to be updated too. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150510/b687521e/attachment.html From brian.stansberry at redhat.com Mon May 11 09:45:08 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 11 May 2015 08:45:08 -0500 Subject: [wildfly-dev] WildFly Full 10.0.0.Alpha1-SNAPSHOT identifies itself as WildFly Full 9.0.0.CR2-SNAPSHOT In-Reply-To: References: <554FB2B8.3030508@osnanet.de> Message-ID: <5550B264.6070004@redhat.com> I've merged that. Thanks, both of you! On 5/10/15 2:50 PM, Eduardo Sant?Ana da Silva wrote: > I've created a PR for that: > > https://github.com/wildfly/wildfly/pull/7439 > > 2015-05-10 16:34 GMT-03:00 Frank Langelage >: > > I updated my workspace today and did a new build using Java 8. > But on startup of Wildfly it identifies itself still as WildFly Full > 9.0.0.CR2-SNAPSHOT. > > 10.05. 21:26:15,923 INFO [org.jboss.as#done > ] WFLYSRV0025: WildFly Full > 9.0.0.CR2-SNAPSHOT (WildFly Core 1.0.0.CR1) started in 9023ms - Started > 518 of 722 services (265 services are lazy, passive or on-demand) > > It seems that > feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/product/wildfly-full/dir/META-INF/MANIFEST.MF > web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/product/wildfly-web/dir/META-INF/MANIFEST.MF > need to be updated too. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From manderse at redhat.com Tue May 12 05:00:42 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 12 May 2015 11:00:42 +0200 Subject: [wildfly-dev] WildFly Core Moving to Java 8 In-Reply-To: <5549561F.50509@redhat.com> References: <5549380C.2010107@redhat.com> <5549561F.50509@redhat.com> Message-ID: <60F221DF-53D4-4DFA-9264-C9569CAB037C@redhat.com> On 6 May 2015, at 1:45, James R. Perkins wrote: > The time has come. Java 8 is now required on WildFly Core master. Just a question - does this also imply than any client communicating with it via the management API using the client libraries needs to run Java 8 ? Just wondering what level of backwards compatibility we are looking at. /max From tomaz.cerar at gmail.com Tue May 12 05:26:41 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 12 May 2015 11:26:41 +0200 Subject: [wildfly-dev] WildFly Core Moving to Java 8 In-Reply-To: <60F221DF-53D4-4DFA-9264-C9569CAB037C@redhat.com> References: <5549380C.2010107@redhat.com> <5549561F.50509@redhat.com> <60F221DF-53D4-4DFA-9264-C9569CAB037C@redhat.com> Message-ID: Max, for now controller-client jar compatibility is still set to 1.6 but it would be wise to move that to 1.7 if you guys are fine with that. see: https://github.com/wildfly/wildfly-core/blob/master/controller-client/pom.xml#L44 javac supports setting target as current - 2, so we are now on border and might cause us problems in future for JDK9. If you guys are fine with this, can we move controller-client to 1.7? -- tomaz On Tue, May 12, 2015 at 11:00 AM, Max Rydahl Andersen wrote: > On 6 May 2015, at 1:45, James R. Perkins wrote: > > > The time has come. Java 8 is now required on WildFly Core master. > > Just a question - does this also imply than any client communicating > with it via the management API using the client libraries needs to run > Java 8 ? > > Just wondering what level of backwards compatibility we are looking at. > > /max > _______________________________________________ > 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/20150512/330119e4/attachment-0001.html From manderse at redhat.com Tue May 12 08:33:13 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 12 May 2015 14:33:13 +0200 Subject: [wildfly-dev] WildFly Core Moving to Java 8 In-Reply-To: References: <5549380C.2010107@redhat.com> <5549561F.50509@redhat.com> <60F221DF-53D4-4DFA-9264-C9569CAB037C@redhat.com> Message-ID: <5EF7B155-B66E-4DDE-951D-038A09F4D7AA@redhat.com> On 12 May 2015, at 11:26, Toma? Cerar wrote: > Max, > > for now controller-client jar compatibility is still set to 1.6 but it > would be wise to move that to 1.7 if you guys are fine with that. > see: > https://github.com/wildfly/wildfly-core/blob/master/controller-client/pom.xml#L44 > > javac supports setting target as current - 2, so we are now on border > and > might cause us problems in future for JDK9. > > If you guys are fine with this, can we move controller-client to 1.7? We (JBoss Tools/Developer Studio) currently targets Java 7 as minimal version thus we specifically fine with that. We might even also move to Java 8, but still interested in knowing the planned compatibility limits. /max > > > -- > tomaz > > > On Tue, May 12, 2015 at 11:00 AM, Max Rydahl Andersen > > wrote: > >> On 6 May 2015, at 1:45, James R. Perkins wrote: >> >>> The time has come. Java 8 is now required on WildFly Core master. >> >> Just a question - does this also imply than any client communicating >> with it via the management API using the client libraries needs to >> run >> Java 8 ? >> >> Just wondering what level of backwards compatibility we are looking >> at. >> >> /max >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> /max http://about.me/maxandersen From brian.stansberry at redhat.com Tue May 12 10:31:25 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 12 May 2015 09:31:25 -0500 Subject: [wildfly-dev] WildFly Core Moving to Java 8 In-Reply-To: <5EF7B155-B66E-4DDE-951D-038A09F4D7AA@redhat.com> References: <5549380C.2010107@redhat.com> <5549561F.50509@redhat.com> <60F221DF-53D4-4DFA-9264-C9569CAB037C@redhat.com> <5EF7B155-B66E-4DDE-951D-038A09F4D7AA@redhat.com> Message-ID: <55520EBD.7090109@redhat.com> There's no intent that this change affects the wire protocols or the message formats. If you experience issues, please raise a bug report. On 5/12/15 7:33 AM, Max Rydahl Andersen wrote: > On 12 May 2015, at 11:26, Toma? Cerar wrote: > >> Max, >> >> for now controller-client jar compatibility is still set to 1.6 but it >> would be wise to move that to 1.7 if you guys are fine with that. >> see: >> https://github.com/wildfly/wildfly-core/blob/master/controller-client/pom.xml#L44 >> >> javac supports setting target as current - 2, so we are now on border >> and >> might cause us problems in future for JDK9. >> >> If you guys are fine with this, can we move controller-client to 1.7? > > We (JBoss Tools/Developer Studio) currently targets Java 7 as minimal > version > thus we specifically fine with that. > > We might even also move to Java 8, but still interested in knowing the > planned > compatibility limits. > > /max > >> >> >> -- >> tomaz >> >> >> On Tue, May 12, 2015 at 11:00 AM, Max Rydahl Andersen >> >> wrote: >> >>> On 6 May 2015, at 1:45, James R. Perkins wrote: >>> >>>> The time has come. Java 8 is now required on WildFly Core master. >>> >>> Just a question - does this also imply than any client communicating >>> with it via the management API using the client libraries needs to >>> run >>> Java 8 ? >>> >>> Just wondering what level of backwards compatibility we are looking >>> at. >>> >>> /max >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > > > /max > http://about.me/maxandersen > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Wed May 13 05:53:29 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 13 May 2015 10:53:29 +0100 Subject: [wildfly-dev] Management Parser Versioning In-Reply-To: <553FA161.9080604@jboss.com> References: <553783E5.3010204@jboss.com> <5537944C.9090602@redhat.com> <55390D13.3020706@jboss.com> <553910A6.9060909@redhat.com> <553911C2.8010706@jboss.com> <553E604D.7040207@jboss.com> <553FA161.9080604@jboss.com> Message-ID: <55531F19.10309@jboss.com> These changes have now been merged. So for any engineer working on management schema changes for version 4.0.0 you can now just edit the classes with the _4 suffix and ignore previous versions - the previous versions are in their own forked versions. Some XML handling was not forked for 4 where changes have been minimal / non-existent if for any reason we do fine a reason to change those for 4 then we will need to fork them so we do not mix 1, 2, and 3 with 4. In the future this will make it a lot easier for us to delete versions 1, 2, and 3 in one go without having to unravel the various version checks to still support 4 and beyond. Regards, Darran Lofthouse. On 28/04/15 16:04, Darran Lofthouse wrote: > The following commit covers the WildFly side: - > > https://github.com/darranl/wildfly/commit/8fc073eb11b71904d6235381ad2d3903ce3241aa > > One problem with the current split is that as soon as you add a new > management schema to core the integration with wildfly is broken > immediately as some tests verify we write as version 3 when now we write > as version 4. > > I would suggest that as soon as we start development on WildFly 10 we > create a very fast tag or core with just a few changes, probably just: - > - Bump to Java 8 > - This schema version bump in this thread. > - Any other build tweaks needed for Java 8. > > WildFly can then use the new tag and have the same treatment. > > Regards, > Darran Lofthouse. > > > On 27/04/15 17:14, Darran Lofthouse wrote: >> The following commits are now the end result of the re-factoring to >> allow a fork on new major versions and also to add version 4.0 of the >> schema: - >> >> https://github.com/wildfly/wildfly-core/compare/f4a07f4e9b41dc59823fea1813f947c67965525a...58faefb1fa830d0193f862da9958b2541aea7dad >> >> The changes look extensive but TBH the bulk is just moving of existing >> code and some duplicate for the fork for 4. >> >> I have distinct commits to show the steps taken but the key points are: - >> >> # Split out the model specific parsing from CommonXml into smaller >> implementations, this was to allow CommonXml to remain the common base >> without still containing version specific parsing. >> >> # Rework of ManagementXml to be version based and rework the delegate, >> the big problem we had was we were looping back on ourselves with static >> calls which did not cleanly map to versioned implementations. >> >> # Moved existing StandalonXml, HostXml, DomainXml, ManagementXml into >> 'Legacy' parsers and used existing class to load these on-demand. >> >> # Forked the legacy parsers to create the version 4 parsers, removed all >> version handling so a clean start for 4. >> >> At this point there is still plenty of parsing code not forked for 4 but >> TBH those are all relatively stable and rarely change, StandaloneXml, >> HostXml, DomainXml, and ManagementXml on the other hand have changed for >> every major version so far. >> >> Regards, >> Darran Lofthouse. >> >> On 23/04/15 16:37, Darran Lofthouse wrote: >>> On 23/04/15 16:32, Brian Stansberry wrote: >>>> I don't think I've ever rejected or even questioned a PR because it made >>>> a parser tolerant in the way you describe, so I'm fine with being tolerant. >>> >>> +1 I think the first two rules are what we need to advertise we support, >>> after all that is why we have schemas. The third point is more about >>> the requirements being placed on the maintainer of the parser so if your >>> XML does not match the schema the best we say is "It may work, it may >>> not work and that can change without warning". >>> >>>> My only caveat is in no way do we have any commitment to be tolerant. If >>>> a change is implemented in such a way that the legacy schema parsing is >>>> tolerant, then it's tolerant for that change. Some other change may not >>>> be implemented that way and the parsing won't be tolerant. So we'll be >>>> inconsistent. >>>> >>>> I'm sure we're already inconsistent in this regard, so that doesn't >>>> worry me. The schema defines the rules. If you follow them, you know >>>> what you'll get. If you break them, maybe it will work anyway, maybe >>>> not. Our only guarantee if you break the rules is you'll either end up >>>> with a valid running configuration or we'll fail. >>>> >>>> On 4/23/15 10:17 AM, Darran Lofthouse wrote: >>>>> Thinking about future XML changes, once the parser is forked I think we >>>>> can also relax how we add new optional attributes and elements to the >>>>> schema. >>>>> >>>>> As I see it our main commitment is: - >>>>> >>>>> * XML that is valid according to the schema should parse without error. * >>>>> >>>>> I say 'should' as I believe in some cases documentation is relied upon >>>>> to describe valid combinations. >>>>> >>>>> * The XML we write must be valid according to the schema. * >>>>> >>>>> Don't see any justification for not following that one. >>>>> >>>>> * Parsers can be tolerant to XML that is technically invalid. * >>>>> >>>>> e.g. we are not big on enforcing sequence ordering. >>>>> >>>>> So lets say we have a release that contains a 4.0 version of the schema >>>>> I think if in version 4.1 of the schema we add an optional attribute or >>>>> element we can just add support for that attribute or element to the >>>>> existing parse method. >>>>> >>>>> Of course if the new attribute or element is required then we will need >>>>> to switch to something version specific to avoid rejecting previously >>>>> valid configuration. >>>>> >>>>> I know this is a long way off but I only raise this now as I realise >>>>> this has already happened where a new optional element has been added to >>>>> the schema. Technically if we were strict about it the code is wrong >>>>> but the scenarios where it is going to break for someone are quite >>>>> contrived and I think this fits with tolerant parsing and we will >>>>> automatically fix on the next write. >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> On 22/04/15 13:30, Brian Stansberry wrote: >>>>>> That's fine with me. >>>>>> >>>>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote: >>>>>>> Working with the parsers for the core config has become increasingly >>>>>>> cryptic, we are now at the point where we have three different major >>>>>>> versions which diverge and converge as we work on them. Most recent >>>>>>> changes have resulted in large sections of the config converging for 1.x >>>>>>> and 3.x leaving 2.x independent. >>>>>>> >>>>>>> So that I can add references to Elytron I am starting to add support for >>>>>>> version 4. >>>>>>> >>>>>>> One think that I have learned is that each major version tends to belong >>>>>>> to one branch of the codebase, all changes to that version happen on >>>>>>> that branch first: - >>>>>>> >>>>>>> 1.x - Maintained only for EAP >>>>>>> 2.x - WildFly 8.x branch >>>>>>> 3.x - WildFly Core master branch >>>>>>> >>>>>>> I would expect if further changes are made to core for WildFly 9 >>>>>>> releases we will end up with 1.x branch of core and and 4.x version of >>>>>>> the schema will be owned by the master branch. >>>>>>> >>>>>>> To make things less cryptic I am proposing that until we find a better >>>>>>> solution for all subsequent major schema versions we just fork the >>>>>>> parser and all related classes. >>>>>>> >>>>>>> This will simplify the code being modified for the upstream development. >>>>>>> >>>>>>> Forward porting parsing changes will also become a simple copy and paste. >>>>>>> >>>>>>> For the current cryptic approach I think almost every engineer (and I am >>>>>>> finding it really hard to think of exceptions) that has worked in-depth >>>>>>> in this area has introduced at least one bug and I don't think the test >>>>>>> coverage is high enough to protect against this. >>>>>>> >>>>>>> Regards, >>>>>>> Darran Lofthouse. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >> _______________________________________________ >> 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 manderse at redhat.com Wed May 13 06:30:48 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 13 May 2015 12:30:48 +0200 Subject: [wildfly-dev] WildFly Core Moving to Java 8 In-Reply-To: <55520EBD.7090109@redhat.com> References: <5549380C.2010107@redhat.com> <5549561F.50509@redhat.com> <60F221DF-53D4-4DFA-9264-C9569CAB037C@redhat.com> <5EF7B155-B66E-4DDE-951D-038A09F4D7AA@redhat.com> <55520EBD.7090109@redhat.com> Message-ID: On 12 May 2015, at 16:31, Brian Stansberry wrote: > There's no intent that this change affects the wire protocols or the > message formats. If you experience issues, please raise a bug report. Thanks - will do ;) /max > On 5/12/15 7:33 AM, Max Rydahl Andersen wrote: >> On 12 May 2015, at 11:26, Toma? Cerar wrote: >> >>> Max, >>> >>> for now controller-client jar compatibility is still set to 1.6 but >>> it >>> would be wise to move that to 1.7 if you guys are fine with that. >>> see: >>> https://github.com/wildfly/wildfly-core/blob/master/controller-client/pom.xml#L44 >>> >>> javac supports setting target as current - 2, so we are now on >>> border >>> and >>> might cause us problems in future for JDK9. >>> >>> If you guys are fine with this, can we move controller-client to >>> 1.7? >> >> We (JBoss Tools/Developer Studio) currently targets Java 7 as minimal >> version >> thus we specifically fine with that. >> >> We might even also move to Java 8, but still interested in knowing >> the >> planned >> compatibility limits. >> >> /max >> >>> >>> >>> -- >>> tomaz >>> >>> >>> On Tue, May 12, 2015 at 11:00 AM, Max Rydahl Andersen >>> >>> wrote: >>> >>>> On 6 May 2015, at 1:45, James R. Perkins wrote: >>>> >>>>> The time has come. Java 8 is now required on WildFly Core master. >>>> >>>> Just a question - does this also imply than any client >>>> communicating >>>> with it via the management API using the client libraries needs to >>>> run >>>> Java 8 ? >>>> >>>> Just wondering what level of backwards compatibility we are looking >>>> at. >>>> >>>> /max >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >> >> >> /max >> http://about.me/maxandersen >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Brian Stansberry > 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 /max http://about.me/maxandersen From smarlow at redhat.com Thu May 14 11:23:14 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 14 May 2015 11:23:14 -0400 Subject: [wildfly-dev] WildFly 10 documentation is now available, please correct your area... Message-ID: <5554BDE2.1080308@redhat.com> We cloned the WildFly 9 documentation into WildFly 10. Please go through and correct the references to WildFly 9 (or 8) in your area. In some cases, it might make sense to remove the version number to make this easier next time (if the context still makes sense). Thanks, Scott [1] https://docs.jboss.org/author/display/WFLY10 From brian.stansberry at redhat.com Thu May 14 12:48:35 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 14 May 2015 11:48:35 -0500 Subject: [wildfly-dev] WildFly 10 documentation is now available, please correct your area... In-Reply-To: <5554BDE2.1080308@redhat.com> References: <5554BDE2.1080308@redhat.com> Message-ID: <5554D1E3.9050707@redhat.com> +1 on getting rid of version numbers in the text where they aren't providing information beyond what can be gotten from the URL of the doc. The URL of the doc provides the default version number in a pretty clear way. On 5/14/15 10:23 AM, Scott Marlow wrote: > We cloned the WildFly 9 documentation into WildFly 10. Please go > through and correct the references to WildFly 9 (or 8) in your area. In > some cases, it might make sense to remove the version number to make > this easier next time (if the context still makes sense). > > Thanks, > Scott > > [1] https://docs.jboss.org/author/display/WFLY10 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Fri May 15 06:08:45 2015 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 15 May 2015 12:08:45 +0200 Subject: [wildfly-dev] datasource:installed-drivers-list() Message-ID: What?s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing? a) any driver: no matter wether it?s a module or deployment b) any driver installed as a module c) any driver resource declared under subsystem=datasources/jdbc-driver=* d) a combination of any of the above /Heiko From smaestri at redhat.com Fri May 15 08:23:45 2015 From: smaestri at redhat.com (Stefano Maestri) Date: Fri, 15 May 2015 14:23:45 +0200 Subject: [wildfly-dev] datasource:installed-drivers-list() In-Reply-To: References: Message-ID: <5555E551.2050306@redhat.com> Expected behavior is c) any driver resource declared under subsystem=datasources/jdbc-driver=* regards S. On 05/15/2015 12:08 PM, Heiko Braun wrote: > What?s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing? > > a) any driver: no matter wether it?s a module or deployment > b) any driver installed as a module > c) any driver resource declared under subsystem=datasources/jdbc-driver=* > d) a combination of any of the above > > > /Heiko > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From hbraun at redhat.com Fri May 15 08:56:49 2015 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 15 May 2015 14:56:49 +0200 Subject: [wildfly-dev] datasource:installed-drivers-list() In-Reply-To: <5555E551.2050306@redhat.com> References: <5555E551.2050306@redhat.com> Message-ID: <6CCD3F18-0364-478B-BACB-3E29CEC92D3C@redhat.com> Ok, thanks. This leads me to two further questions: a) why does it need a separate operation? The same can be achieved with read-children-resources. b) what happened to the mechanism to detect drivers that are installed as deployments? iirc this particular operation used to show them in the past. > Am 15.05.2015 um 14:23 schrieb Stefano Maestri : > > Expected behavior is > > > c) any driver resource declared under subsystem=datasources/jdbc-driver=* > > > > regards > S. > > > >> On 05/15/2015 12:08 PM, Heiko Braun wrote: >> What?s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing? >> >> a) any driver: no matter wether it?s a module or deployment >> b) any driver installed as a module >> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >> d) a combination of any of the above >> >> >> /Heiko >> >> >> _______________________________________________ >> 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 smaestri at redhat.com Fri May 15 08:59:15 2015 From: smaestri at redhat.com (Stefano Maestri) Date: Fri, 15 May 2015 14:59:15 +0200 Subject: [wildfly-dev] datasource:installed-drivers-list() In-Reply-To: <6CCD3F18-0364-478B-BACB-3E29CEC92D3C@redhat.com> References: <5555E551.2050306@redhat.com> <6CCD3F18-0364-478B-BACB-3E29CEC92D3C@redhat.com> Message-ID: <5555EDA3.9060006@redhat.com> Yup you are right, but in standalone is different and this operation give you also ones installed by deployments. In domain this is not possible since deployments are local to single hosts. regards S. On 05/15/2015 02:56 PM, Heiko Braun wrote: > Ok, thanks. > This leads me to two further questions: > > a) why does it need a separate operation? The same can be achieved with read-children-resources. > > b) what happened to the mechanism to detect drivers that are installed as deployments? iirc this particular operation used to show them in the past. > > > >> Am 15.05.2015 um 14:23 schrieb Stefano Maestri : >> >> Expected behavior is >> >> >> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >> >> >> >> regards >> S. >> >> >> >>> On 05/15/2015 12:08 PM, Heiko Braun wrote: >>> What?s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing? >>> >>> a) any driver: no matter wether it?s a module or deployment >>> b) any driver installed as a module >>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>> d) a combination of any of the above >>> >>> >>> /Heiko >>> >>> >>> _______________________________________________ >>> 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 smaestri at redhat.com Fri May 15 09:25:14 2015 From: smaestri at redhat.com (Stefano Maestri) Date: Fri, 15 May 2015 15:25:14 +0200 Subject: [wildfly-dev] datasource:installed-drivers-list() In-Reply-To: <5555EDA3.9060006@redhat.com> References: <5555E551.2050306@redhat.com> <6CCD3F18-0364-478B-BACB-3E29CEC92D3C@redhat.com> <5555EDA3.9060006@redhat.com> Message-ID: <5555F3BA.5050002@redhat.com> I've double checked when this is changed for domain. It's in https://issues.jboss.org/browse/WFLY-3634 https://issues.jboss.org/browse/HAL-483 since deployed driver doesn't refer to any profile at all. If you need something different or I misunderstood your request, lets discuss here or just open another issue. regards S. On 05/15/2015 02:59 PM, Stefano Maestri wrote: > Yup you are right, but in standalone is different and this operation > give you also ones installed by deployments. > In domain this is not possible since deployments are local to single hosts. > > regards > S. > > On 05/15/2015 02:56 PM, Heiko Braun wrote: >> Ok, thanks. >> This leads me to two further questions: >> >> a) why does it need a separate operation? The same can be achieved with read-children-resources. >> >> b) what happened to the mechanism to detect drivers that are installed as deployments? iirc this particular operation used to show them in the past. >> >> >> >>> Am 15.05.2015 um 14:23 schrieb Stefano Maestri : >>> >>> Expected behavior is >>> >>> >>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>> >>> >>> >>> regards >>> S. >>> >>> >>> >>>> On 05/15/2015 12:08 PM, Heiko Braun wrote: >>>> What?s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing? >>>> >>>> a) any driver: no matter wether it?s a module or deployment >>>> b) any driver installed as a module >>>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>>> d) a combination of any of the above >>>> >>>> >>>> /Heiko >>>> >>>> >>>> _______________________________________________ >>>> 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 From hbraun at redhat.com Fri May 15 12:52:54 2015 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 15 May 2015 18:52:54 +0200 Subject: [wildfly-dev] datasource:installed-drivers-list() In-Reply-To: <5555F3BA.5050002@redhat.com> References: <5555E551.2050306@redhat.com> <6CCD3F18-0364-478B-BACB-3E29CEC92D3C@redhat.com> <5555EDA3.9060006@redhat.com> <5555F3BA.5050002@redhat.com> Message-ID: I did refer to the server specific operation at /host=foo/server=bar/subsystem=ds:installed-drivers-list If I remember correctly is used to display drivers that come as regular deployments as well. Has this changed? > On 15 May 2015, at 15:25, Stefano Maestri wrote: > > I've double checked when this is changed for domain. > It's in > > https://issues.jboss.org/browse/WFLY-3634 > https://issues.jboss.org/browse/HAL-483 > > since deployed driver doesn't refer to any profile at all. > > If you need something different or I misunderstood your request, lets > discuss here or just open another issue. > > regards > S. > > On 05/15/2015 02:59 PM, Stefano Maestri wrote: >> Yup you are right, but in standalone is different and this operation >> give you also ones installed by deployments. >> In domain this is not possible since deployments are local to single hosts. >> >> regards >> S. >> >> On 05/15/2015 02:56 PM, Heiko Braun wrote: >>> Ok, thanks. >>> This leads me to two further questions: >>> >>> a) why does it need a separate operation? The same can be achieved with read-children-resources. >>> >>> b) what happened to the mechanism to detect drivers that are installed as deployments? iirc this particular operation used to show them in the past. >>> >>> >>> >>>> Am 15.05.2015 um 14:23 schrieb Stefano Maestri : >>>> >>>> Expected behavior is >>>> >>>> >>>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>>> >>>> >>>> >>>> regards >>>> S. >>>> >>>> >>>> >>>>> On 05/15/2015 12:08 PM, Heiko Braun wrote: >>>>> What?s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing? >>>>> >>>>> a) any driver: no matter wether it?s a module or deployment >>>>> b) any driver installed as a module >>>>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>>>> d) a combination of any of the above >>>>> >>>>> >>>>> /Heiko >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > From hbraun at redhat.com Fri May 15 12:55:53 2015 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 15 May 2015 18:55:53 +0200 Subject: [wildfly-dev] datasource:installed-drivers-list() In-Reply-To: <5555F3BA.5050002@redhat.com> References: <5555E551.2050306@redhat.com> <6CCD3F18-0364-478B-BACB-3E29CEC92D3C@redhat.com> <5555EDA3.9060006@redhat.com> <5555F3BA.5050002@redhat.com> Message-ID: Thanks for digging it up. We?ve got people complaining about this and I am trying to trace the decisions behind this. But now I remember WFLY-3634. So moving forward JDBC drivers as modules are the way to go in the domain? > On 15 May 2015, at 15:25, Stefano Maestri wrote: > > I've double checked when this is changed for domain. > It's in > > https://issues.jboss.org/browse/WFLY-3634 > https://issues.jboss.org/browse/HAL-483 > > since deployed driver doesn't refer to any profile at all. > > If you need something different or I misunderstood your request, lets > discuss here or just open another issue. > > regards > S. > > On 05/15/2015 02:59 PM, Stefano Maestri wrote: >> Yup you are right, but in standalone is different and this operation >> give you also ones installed by deployments. >> In domain this is not possible since deployments are local to single hosts. >> >> regards >> S. >> >> On 05/15/2015 02:56 PM, Heiko Braun wrote: >>> Ok, thanks. >>> This leads me to two further questions: >>> >>> a) why does it need a separate operation? The same can be achieved with read-children-resources. >>> >>> b) what happened to the mechanism to detect drivers that are installed as deployments? iirc this particular operation used to show them in the past. >>> >>> >>> >>>> Am 15.05.2015 um 14:23 schrieb Stefano Maestri : >>>> >>>> Expected behavior is >>>> >>>> >>>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>>> >>>> >>>> >>>> regards >>>> S. >>>> >>>> >>>> >>>>> On 05/15/2015 12:08 PM, Heiko Braun wrote: >>>>> What?s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing? >>>>> >>>>> a) any driver: no matter wether it?s a module or deployment >>>>> b) any driver installed as a module >>>>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>>>> d) a combination of any of the above >>>>> >>>>> >>>>> /Heiko >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > From hbraun at redhat.com Fri May 15 12:56:15 2015 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 15 May 2015 18:56:15 +0200 Subject: [wildfly-dev] datasource:installed-drivers-list() In-Reply-To: References: <5555E551.2050306@redhat.com> <6CCD3F18-0364-478B-BACB-3E29CEC92D3C@redhat.com> <5555EDA3.9060006@redhat.com> <5555F3BA.5050002@redhat.com> Message-ID: <67443D18-DF78-484C-9ABE-0ECD899D198B@redhat.com> No need to answer. WFLY-3634 explains it. > On 15 May 2015, at 18:52, Heiko Braun wrote: > > > I did refer to the server specific operation at /host=foo/server=bar/subsystem=ds:installed-drivers-list > > If I remember correctly is used to display drivers that come as regular deployments as well. Has this changed? > > >> On 15 May 2015, at 15:25, Stefano Maestri wrote: >> >> I've double checked when this is changed for domain. >> It's in >> >> https://issues.jboss.org/browse/WFLY-3634 >> https://issues.jboss.org/browse/HAL-483 >> >> since deployed driver doesn't refer to any profile at all. >> >> If you need something different or I misunderstood your request, lets >> discuss here or just open another issue. >> >> regards >> S. >> >> On 05/15/2015 02:59 PM, Stefano Maestri wrote: >>> Yup you are right, but in standalone is different and this operation >>> give you also ones installed by deployments. >>> In domain this is not possible since deployments are local to single hosts. >>> >>> regards >>> S. >>> >>> On 05/15/2015 02:56 PM, Heiko Braun wrote: >>>> Ok, thanks. >>>> This leads me to two further questions: >>>> >>>> a) why does it need a separate operation? The same can be achieved with read-children-resources. >>>> >>>> b) what happened to the mechanism to detect drivers that are installed as deployments? iirc this particular operation used to show them in the past. >>>> >>>> >>>> >>>>> Am 15.05.2015 um 14:23 schrieb Stefano Maestri : >>>>> >>>>> Expected behavior is >>>>> >>>>> >>>>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>>>> >>>>> >>>>> >>>>> regards >>>>> S. >>>>> >>>>> >>>>> >>>>>> On 05/15/2015 12:08 PM, Heiko Braun wrote: >>>>>> What?s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing? >>>>>> >>>>>> a) any driver: no matter wether it?s a module or deployment >>>>>> b) any driver installed as a module >>>>>> c) any driver resource declared under subsystem=datasources/jdbc-driver=* >>>>>> d) a combination of any of the above >>>>>> >>>>>> >>>>>> /Heiko >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Mon May 18 13:54:51 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 May 2015 12:54:51 -0500 Subject: [wildfly-dev] First Alphas of WildFly 10 and WildFly Core 2 have been released Message-ID: <555A276B.3030403@redhat.com> I've released WildFly 10.0.0.Alpha1 and WildFly Core 2.0.0.Alpha1 and Alpha2. They are available from the jboss.org maven repository.[1] The 10.0.0.Alpha1 release is the first in a series of alphas we intend to release roughly every two weeks. At this point we don't intend to include these alphas on the normal wildfly.org download page.[2] However the full distribution zip is available from the maven repo.[3] These releases differ from what's in the recent 9.0.0.CR1 release in four main ways: 1) Bug fixes and component updates that will go into 9.0.0.Final are included. 2) The build has been changed to require use of JDK 8. 3) Narayana (transactions) was upgraded from 5.0.4 to 5.1.1. 4) A number of miscellaneous changes related to getting the master branch ready for work on the next major release were made. To see the full list of resolved issues, see [4]. Best regards, -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat [1] https://repository.jboss.org/nexus/content/groups/public-jboss [2] http://wildfly.org/downloads/ [3] https://repository.jboss.org/nexus/content/groups/public-jboss/org/wildfly/wildfly-dist/10.0.0.Alpha1/wildfly-dist-10.0.0.Alpha1.zip [4] https://issues.jboss.org/browse/WFLY/fixforversion/12327159/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel From arun.gupta at gmail.com Mon May 18 14:04:55 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Mon, 18 May 2015 11:04:55 -0700 Subject: [wildfly-dev] First Alphas of WildFly 10 and WildFly Core 2 have been released In-Reply-To: <555A276B.3030403@redhat.com> References: <555A276B.3030403@redhat.com> Message-ID: Brian, On Mon, May 18, 2015 at 10:54 AM, Brian Stansberry wrote: > I've released WildFly 10.0.0.Alpha1 and WildFly Core 2.0.0.Alpha1 and > Alpha2. They are available from the jboss.org maven repository.[1] > > The 10.0.0.Alpha1 release is the first in a series of alphas we intend > to release roughly every two weeks. Will these be Alpha2, Alpha3, and so on? > > At this point we don't intend to include these alphas on the normal > wildfly.org download page.[2] However the full distribution zip is > available from the maven repo.[3] What's the rationale behind that? Arun > > These releases differ from what's in the recent 9.0.0.CR1 release in > four main ways: > > 1) Bug fixes and component updates that will go into 9.0.0.Final are > included. > > 2) The build has been changed to require use of JDK 8. > > 3) Narayana (transactions) was upgraded from 5.0.4 to 5.1.1. > > 4) A number of miscellaneous changes related to getting the master > branch ready for work on the next major release were made. > > To see the full list of resolved issues, see [4]. > > Best regards, > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > > > [1] https://repository.jboss.org/nexus/content/groups/public-jboss > [2] http://wildfly.org/downloads/ > [3] > https://repository.jboss.org/nexus/content/groups/public-jboss/org/wildfly/wildfly-dist/10.0.0.Alpha1/wildfly-dist-10.0.0.Alpha1.zip > [4] > https://issues.jboss.org/browse/WFLY/fixforversion/12327159/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- http://blog.arungupta.me http://twitter.com/arungupta From jperkins at redhat.com Mon May 18 14:44:00 2015 From: jperkins at redhat.com (James R. Perkins) Date: Mon, 18 May 2015 11:44:00 -0700 Subject: [wildfly-dev] First Alphas of WildFly 10 and WildFly Core 2 have been released In-Reply-To: References: <555A276B.3030403@redhat.com> Message-ID: <555A32F0.7020004@redhat.com> On 05/18/2015 11:04 AM, Arun Gupta wrote: > Brian, > > > On Mon, May 18, 2015 at 10:54 AM, Brian Stansberry > wrote: >> I've released WildFly 10.0.0.Alpha1 and WildFly Core 2.0.0.Alpha1 and >> Alpha2. They are available from the jboss.org maven repository.[1] >> >> The 10.0.0.Alpha1 release is the first in a series of alphas we intend >> to release roughly every two weeks. > Will these be Alpha2, Alpha3, and so on? > >> At this point we don't intend to include these alphas on the normal >> wildfly.org download page.[2] However the full distribution zip is >> available from the maven repo.[3] > What's the rationale behind that? I don't know the reason, but FWIW with the wildfly-maven-plugin you can override the version with -Dwildfly.version=10.0.0.Alpha1 or specifying the version in the configuration. > > Arun > >> These releases differ from what's in the recent 9.0.0.CR1 release in >> four main ways: >> >> 1) Bug fixes and component updates that will go into 9.0.0.Final are >> included. >> >> 2) The build has been changed to require use of JDK 8. >> >> 3) Narayana (transactions) was upgraded from 5.0.4 to 5.1.1. >> >> 4) A number of miscellaneous changes related to getting the master >> branch ready for work on the next major release were made. >> >> To see the full list of resolved issues, see [4]. >> >> Best regards, >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> >> >> [1] https://repository.jboss.org/nexus/content/groups/public-jboss >> [2] http://wildfly.org/downloads/ >> [3] >> https://repository.jboss.org/nexus/content/groups/public-jboss/org/wildfly/wildfly-dist/10.0.0.Alpha1/wildfly-dist-10.0.0.Alpha1.zip >> [4] >> https://issues.jboss.org/browse/WFLY/fixforversion/12327159/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >> _______________________________________________ >> 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 brian.stansberry at redhat.com Mon May 18 15:15:24 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 May 2015 14:15:24 -0500 Subject: [wildfly-dev] First Alphas of WildFly 10 and WildFly Core 2 have been released In-Reply-To: References: <555A276B.3030403@redhat.com> Message-ID: <555A3A4C.9010700@redhat.com> On 5/18/15 1:04 PM, Arun Gupta wrote: > Brian, > > > On Mon, May 18, 2015 at 10:54 AM, Brian Stansberry > wrote: >> I've released WildFly 10.0.0.Alpha1 and WildFly Core 2.0.0.Alpha1 and >> Alpha2. They are available from the jboss.org maven repository.[1] >> >> The 10.0.0.Alpha1 release is the first in a series of alphas we intend >> to release roughly every two weeks. > > Will these be Alpha2, Alpha3, and so on? > Yes, until we produce the Beta1, currently scheduled for early August. >> >> At this point we don't intend to include these alphas on the normal >> wildfly.org download page.[2] However the full distribution zip is >> available from the maven repo.[3] > > What's the rationale behind that? > They'll fill up the downloads page, and they require manual republishing every time. We'd like to tweak the page such that it automatically shows the latest alpha, but we've got too many higher priority tasks to focus on. > Arun > >> >> These releases differ from what's in the recent 9.0.0.CR1 release in >> four main ways: >> >> 1) Bug fixes and component updates that will go into 9.0.0.Final are >> included. >> >> 2) The build has been changed to require use of JDK 8. >> >> 3) Narayana (transactions) was upgraded from 5.0.4 to 5.1.1. >> >> 4) A number of miscellaneous changes related to getting the master >> branch ready for work on the next major release were made. >> >> To see the full list of resolved issues, see [4]. >> >> Best regards, >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> >> >> [1] https://repository.jboss.org/nexus/content/groups/public-jboss >> [2] http://wildfly.org/downloads/ >> [3] >> https://repository.jboss.org/nexus/content/groups/public-jboss/org/wildfly/wildfly-dist/10.0.0.Alpha1/wildfly-dist-10.0.0.Alpha1.zip >> [4] >> https://issues.jboss.org/browse/WFLY/fixforversion/12327159/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From arun.gupta at gmail.com Mon May 18 17:07:55 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Mon, 18 May 2015 14:07:55 -0700 Subject: [wildfly-dev] First Alphas of WildFly 10 and WildFly Core 2 have been released In-Reply-To: <555A3A4C.9010700@redhat.com> References: <555A276B.3030403@redhat.com> <555A3A4C.9010700@redhat.com> Message-ID: >> >> >> What's the rationale behind that? >> > > They'll fill up the downloads page, and they require manual republishing > every time. We'd like to tweak the page such that it automatically shows the > latest alpha, but we've got too many higher priority tasks to focus on. Agreed, sounds very reasonable approach :-) Arun > > >> Arun >> >>> >>> These releases differ from what's in the recent 9.0.0.CR1 release in >>> four main ways: >>> >>> 1) Bug fixes and component updates that will go into 9.0.0.Final are >>> included. >>> >>> 2) The build has been changed to require use of JDK 8. >>> >>> 3) Narayana (transactions) was upgraded from 5.0.4 to 5.1.1. >>> >>> 4) A number of miscellaneous changes related to getting the master >>> branch ready for work on the next major release were made. >>> >>> To see the full list of resolved issues, see [4]. >>> >>> Best regards, >>> >>> -- >>> Brian Stansberry >>> Senior Principal Software Engineer >>> JBoss by Red Hat >>> >>> >>> [1] https://repository.jboss.org/nexus/content/groups/public-jboss >>> [2] http://wildfly.org/downloads/ >>> [3] >>> >>> https://repository.jboss.org/nexus/content/groups/public-jboss/org/wildfly/wildfly-dist/10.0.0.Alpha1/wildfly-dist-10.0.0.Alpha1.zip >>> [4] >>> >>> https://issues.jboss.org/browse/WFLY/fixforversion/12327159/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat -- http://blog.arungupta.me http://twitter.com/arungupta From rory.odonnell at oracle.com Tue May 19 04:21:25 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 19 May 2015 09:21:25 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b64 and JDK 8u60 b15 are available on java.net Message-ID: <555AF285.6020502@oracle.com> Hi Jason/Tomaz, Early Access build for JDK 9 b64 is available on java.net, summary of changes are listed here The JDK 9 schedule of record is available on the JDK 9 Project page: http://openjdk.java.net/projects/jdk9 Early Access build for JDK 8u60 b15 is available on java.net, summary of changes are listed here. Note with 8077220 in 8u60 b12 , we are disabling the RC4 cipher suite by default. As we enter the later phases of development for JDK 8u60, please log any show stoppers as soon as possible. Rgds,Rory -- 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/20150519/eee505a7/attachment.html From sanne at hibernate.org Thu May 21 07:30:23 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 21 May 2015 12:30:23 +0100 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 Message-ID: Hi all, I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 to use a preview of Hibernate ORM version 5. It seems the JPA deployer isn't allowing me to run such experiments: # First experiment - providerModule set to custom module In my first attempt, I create a custom set of jboss modules which include the snapshot builds of ORM 5, add them to my standalone WF9 instance and set the persistence.xml property: jboss.as.jpa.providerModule = my-custom-module-name and then get: Caused by: java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.envers.boot.internal.EnversIntegrator not a subtype at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) [rt.jar:1.7.0_51] at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) at org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) ... 7 more Clearly it looks like I'm being served classes from the bundled Hibernate 4.x implementation - on top of those from the module I'm requesting. This isn't what the deployer should be doing, right? # Second experiment - use the "application provided" In this case I hope to hint the JPA deployer to not add the default implementor but look for a JPA implementation within my deployment, but still package my custom Hibernate build as a module. - use the same custom module containing Hibernate ORM 5 (a preview snapshot) - Add a "Dependency:" section to the manifest to import (and export) my custom module - set the "jboss.as.jpa.providerModule" property to value "application" This gets me: Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYJPA0027: Persistence provider module load error application (class org.hibernate.jpa.HibernatePersistenceProvider) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] ... 5 more Caused by: org.jboss.modules.ModuleNotFoundException: application:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) [jboss-modules.jar:1.4.3.Final] at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) ... 10 more Remarks: - it's attempting to load the "application:main" module?! that's not what I'd expect from reading [1] - the provider should be available to the deployment classpath, so I'm not sure why it's not finding the Provider? (I'm even exporting it, although I'm not sure if that was required). Any suggestions to get this running please? Also I wonder if some of these should warrant opening a JIRA, but I'm not sure how far I misunderstood the intentions of these JPA deployer properties. Thanks, Sanne [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties From fjuma at redhat.com Thu May 21 10:34:21 2015 From: fjuma at redhat.com (Farah Juma) Date: Thu, 21 May 2015 10:34:21 -0400 (EDT) Subject: [wildfly-dev] WildFly 10.0.0.Alpha1 is now on OpenShift In-Reply-To: <678355229.1664323.1432160240637.JavaMail.zimbra@redhat.com> Message-ID: <2037650570.1858799.1432218861199.JavaMail.zimbra@redhat.com> See https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-10 for details on how to get started. Enjoy! From smarlow at redhat.com Thu May 21 10:36:44 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 21 May 2015 10:36:44 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: Message-ID: <555DED7C.2070607@redhat.com> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on this soon for WildFly 10. On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > Hi all, > I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 > to use a preview of Hibernate ORM version 5. > > It seems the JPA deployer isn't allowing me to run such experiments: > > # First experiment - providerModule set to custom module > > In my first attempt, I create a custom set of jboss modules which > include the snapshot builds of ORM 5, add them to my standalone WF9 > instance and set the persistence.xml property: > jboss.as.jpa.providerModule = my-custom-module-name > > and then get: > > Caused by: java.util.ServiceConfigurationError: > org.hibernate.integrator.spi.Integrator: Provider > org.hibernate.envers.boot.internal.EnversIntegrator not a subtype > at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] > at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > [rt.jar:1.7.0_51] > at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] > at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > at org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > ... 7 more > > Clearly it looks like I'm being served classes from the bundled > Hibernate 4.x implementation - on top of those from the module I'm > requesting. This isn't what the deployer should be doing, right? > > # Second experiment - use the "application provided" > > In this case I hope to hint the JPA deployer to not add the default > implementor but look for a JPA implementation within my deployment, > but still package my custom Hibernate build as a module. > > - use the same custom module containing Hibernate ORM 5 (a preview snapshot) > - Add a "Dependency:" section to the manifest to import (and export) > my custom module > - set the "jboss.as.jpa.providerModule" property to value "application" > > This gets me: > > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: > WFLYJPA0027: Persistence provider module load error application (class > org.hibernate.jpa.HibernatePersistenceProvider) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > ... 5 more > Caused by: org.jboss.modules.ModuleNotFoundException: application:main > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > [jboss-modules.jar:1.4.3.Final] > at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > ... 10 more > > Remarks: > - it's attempting to load the "application:main" module?! that's not > what I'd expect from reading [1] This seems to be a bug. I hit it a few days ago when I packaged Hibernate ORM 4.1.x with an application (in a unit test) and forgot to set the persistence provider in persistence.xml. > - the provider should be available to the deployment classpath, so > I'm not sure why it's not finding the Provider? (I'm even exporting > it, although I'm not sure if that was required). Providers are always found through the javax.persistence.spi.PersistenceProviderResolver, not directly from the deployment classpath. > > Any suggestions to get this running please? > > Also I wonder if some of these should warrant opening a JIRA, but I'm > not sure how far I misunderstood the intentions of these JPA deployer > properties. Lets talk in a few days again on IRC. > > Thanks, > Sanne > > [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > From emmanuel at hibernate.org Thu May 21 14:11:01 2015 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 21 May 2015 20:11:01 +0200 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <555DED7C.2070607@redhat.com> References: <555DED7C.2070607@redhat.com> Message-ID: <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. It would help speed up the Hibernate 5 stream adoption and avoid a lot of duplicated work for 6+ months. > On 21 mai 2015, at 16:36, Scott Marlow wrote: > > Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on this soon > for WildFly 10. > >> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >> Hi all, >> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 >> to use a preview of Hibernate ORM version 5. >> >> It seems the JPA deployer isn't allowing me to run such experiments: >> >> # First experiment - providerModule set to custom module >> >> In my first attempt, I create a custom set of jboss modules which >> include the snapshot builds of ORM 5, add them to my standalone WF9 >> instance and set the persistence.xml property: >> jboss.as.jpa.providerModule = my-custom-module-name >> >> and then get: >> >> Caused by: java.util.ServiceConfigurationError: >> org.hibernate.integrator.spi.Integrator: Provider >> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] >> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] >> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >> [rt.jar:1.7.0_51] >> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] >> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >> at org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >> at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >> at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >> ... 7 more >> >> Clearly it looks like I'm being served classes from the bundled >> Hibernate 4.x implementation - on top of those from the module I'm >> requesting. This isn't what the deployer should be doing, right? >> >> # Second experiment - use the "application provided" >> >> In this case I hope to hint the JPA deployer to not add the default >> implementor but look for a JPA implementation within my deployment, >> but still package my custom Hibernate build as a module. >> >> - use the same custom module containing Hibernate ORM 5 (a preview snapshot) >> - Add a "Dependency:" section to the manifest to import (and export) >> my custom module >> - set the "jboss.as.jpa.providerModule" property to value "application" >> >> This gets me: >> >> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: >> WFLYJPA0027: Persistence provider module load error application (class >> org.hibernate.jpa.HibernatePersistenceProvider) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >> ... 5 more >> Caused by: org.jboss.modules.ModuleNotFoundException: application:main >> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >> [jboss-modules.jar:1.4.3.Final] >> at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >> ... 10 more >> >> Remarks: >> - it's attempting to load the "application:main" module?! that's not >> what I'd expect from reading [1] > > This seems to be a bug. I hit it a few days ago when I packaged > Hibernate ORM 4.1.x with an application (in a unit test) and forgot to > set the persistence provider in persistence.xml. > >> - the provider should be available to the deployment classpath, so >> I'm not sure why it's not finding the Provider? (I'm even exporting >> it, although I'm not sure if that was required). > > Providers are always found through the > javax.persistence.spi.PersistenceProviderResolver, not directly from the > deployment classpath. > >> >> Any suggestions to get this running please? >> >> Also I wonder if some of these should warrant opening a JIRA, but I'm >> not sure how far I misunderstood the intentions of these JPA deployer >> properties. > > Lets talk in a few days again on IRC. > >> >> Thanks, >> Sanne >> >> [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Thu May 21 15:01:24 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 21 May 2015 15:01:24 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> Message-ID: <555E2B84.6020600@redhat.com> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the integration code that we will look at merging into WildFly 10. Are you looking for a custom WildFly 9.x branch or actual changes in WildFly 9 (doesn't seem as likely to me but I don't control the schedule)? > > It would help speed up the Hibernate 5 stream adoption and avoid a lot of duplicated work for 6+ months. > >> On 21 mai 2015, at 16:36, Scott Marlow wrote: >> >> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on this soon >> for WildFly 10. >> >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>> Hi all, >>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 >>> to use a preview of Hibernate ORM version 5. >>> >>> It seems the JPA deployer isn't allowing me to run such experiments: >>> >>> # First experiment - providerModule set to custom module >>> >>> In my first attempt, I create a custom set of jboss modules which >>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>> instance and set the persistence.xml property: >>> jboss.as.jpa.providerModule = my-custom-module-name >>> >>> and then get: >>> >>> Caused by: java.util.ServiceConfigurationError: >>> org.hibernate.integrator.spi.Integrator: Provider >>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] >>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] >>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>> [rt.jar:1.7.0_51] >>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] >>> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>> at org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >>> at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >>> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >>> at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>> ... 7 more >>> >>> Clearly it looks like I'm being served classes from the bundled >>> Hibernate 4.x implementation - on top of those from the module I'm >>> requesting. This isn't what the deployer should be doing, right? >>> >>> # Second experiment - use the "application provided" >>> >>> In this case I hope to hint the JPA deployer to not add the default >>> implementor but look for a JPA implementation within my deployment, >>> but still package my custom Hibernate build as a module. >>> >>> - use the same custom module containing Hibernate ORM 5 (a preview snapshot) >>> - Add a "Dependency:" section to the manifest to import (and export) >>> my custom module >>> - set the "jboss.as.jpa.providerModule" property to value "application" >>> >>> This gets me: >>> >>> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>> WFLYJPA0027: Persistence provider module load error application (class >>> org.hibernate.jpa.HibernatePersistenceProvider) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>> ... 5 more >>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main >>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>> [jboss-modules.jar:1.4.3.Final] >>> at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>> ... 10 more >>> >>> Remarks: >>> - it's attempting to load the "application:main" module?! that's not >>> what I'd expect from reading [1] >> >> This seems to be a bug. I hit it a few days ago when I packaged >> Hibernate ORM 4.1.x with an application (in a unit test) and forgot to >> set the persistence provider in persistence.xml. >> >>> - the provider should be available to the deployment classpath, so >>> I'm not sure why it's not finding the Provider? (I'm even exporting >>> it, although I'm not sure if that was required). >> >> Providers are always found through the >> javax.persistence.spi.PersistenceProviderResolver, not directly from the >> deployment classpath. >> >>> >>> Any suggestions to get this running please? >>> >>> Also I wonder if some of these should warrant opening a JIRA, but I'm >>> not sure how far I misunderstood the intentions of these JPA deployer >>> properties. >> >> Lets talk in a few days again on IRC. >> >>> >>> Thanks, >>> Sanne >>> >>> [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Thu May 21 15:05:51 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 21 May 2015 21:05:51 +0200 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <555E2B84.6020600@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> Message-ID: Scott, if you do one last jipijapa release that adds "support" for hibernate5 hibernate guys could take that version and override it in wildfly 9 same way as they add new h5 modules. -- tomaz On Thu, May 21, 2015 at 9:01 PM, Scott Marlow wrote: > On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > > Scott, No way to make ORM 5 work in 9 at all? With the user setting the > additional slotted modules of course. > > https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the > integration code that we will look at merging into WildFly 10. Are you > looking for a custom WildFly 9.x branch or actual changes in WildFly 9 > (doesn't seem as likely to me but I don't control the schedule)? > > > > > It would help speed up the Hibernate 5 stream adoption and avoid a lot > of duplicated work for 6+ months. > > > >> On 21 mai 2015, at 16:36, Scott Marlow wrote: > >> > >> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on this soon > >> for WildFly 10. > >> > >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >>> Hi all, > >>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 > >>> to use a preview of Hibernate ORM version 5. > >>> > >>> It seems the JPA deployer isn't allowing me to run such experiments: > >>> > >>> # First experiment - providerModule set to custom module > >>> > >>> In my first attempt, I create a custom set of jboss modules which > >>> include the snapshot builds of ORM 5, add them to my standalone WF9 > >>> instance and set the persistence.xml property: > >>> jboss.as.jpa.providerModule = my-custom-module-name > >>> > >>> and then get: > >>> > >>> Caused by: java.util.ServiceConfigurationError: > >>> org.hibernate.integrator.spi.Integrator: Provider > >>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype > >>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > [rt.jar:1.7.0_51] > >>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) > [rt.jar:1.7.0_51] > >>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >>> [rt.jar:1.7.0_51] > >>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > [rt.jar:1.7.0_51] > >>> at > org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >>> at > org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > >>> at > org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >>> at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >>> at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > >>> at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > >>> at > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >>> at > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >>> at > org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > >>> at > org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >>> at > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >>> at > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >>> at > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >>> ... 7 more > >>> > >>> Clearly it looks like I'm being served classes from the bundled > >>> Hibernate 4.x implementation - on top of those from the module I'm > >>> requesting. This isn't what the deployer should be doing, right? > >>> > >>> # Second experiment - use the "application provided" > >>> > >>> In this case I hope to hint the JPA deployer to not add the default > >>> implementor but look for a JPA implementation within my deployment, > >>> but still package my custom Hibernate build as a module. > >>> > >>> - use the same custom module containing Hibernate ORM 5 (a preview > snapshot) > >>> - Add a "Dependency:" section to the manifest to import (and export) > >>> my custom module > >>> - set the "jboss.as.jpa.providerModule" property to value > "application" > >>> > >>> This gets me: > >>> > >>> Caused by: > org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >>> WFLYJPA0027: Persistence provider module load error application (class > >>> org.hibernate.jpa.HibernatePersistenceProvider) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >>> at > org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >>> at > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >>> ... 5 more > >>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main > >>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >>> [jboss-modules.jar:1.4.3.Final] > >>> at > org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >>> ... 10 more > >>> > >>> Remarks: > >>> - it's attempting to load the "application:main" module?! that's not > >>> what I'd expect from reading [1] > >> > >> This seems to be a bug. I hit it a few days ago when I packaged > >> Hibernate ORM 4.1.x with an application (in a unit test) and forgot to > >> set the persistence provider in persistence.xml. > >> > >>> - the provider should be available to the deployment classpath, so > >>> I'm not sure why it's not finding the Provider? (I'm even exporting > >>> it, although I'm not sure if that was required). > >> > >> Providers are always found through the > >> javax.persistence.spi.PersistenceProviderResolver, not directly from the > >> deployment classpath. > >> > >>> > >>> Any suggestions to get this running please? > >>> > >>> Also I wonder if some of these should warrant opening a JIRA, but I'm > >>> not sure how far I misunderstood the intentions of these JPA deployer > >>> properties. > >> > >> Lets talk in a few days again on IRC. > >> > >>> > >>> Thanks, > >>> Sanne > >>> > >>> [1] - > https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > >> _______________________________________________ > >> 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/20150521/1681190b/attachment-0001.html From smarlow at redhat.com Thu May 21 15:08:21 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 21 May 2015 15:08:21 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <555E2B84.6020600@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> Message-ID: <555E2D25.5080905@redhat.com> On 05/21/2015 03:01 PM, Scott Marlow wrote: > On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. > > https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the > integration code that we will look at merging into WildFly 10. Are you > looking for a custom WildFly 9.x branch or actual changes in WildFly 9 > (doesn't seem as likely to me but I don't control the schedule)? You could also try setting up custom slotted modules as well in your local WildFly 9 with jars from the above branch. > >> >> It would help speed up the Hibernate 5 stream adoption and avoid a lot of duplicated work for 6+ months. >> >>> On 21 mai 2015, at 16:36, Scott Marlow wrote: >>> >>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on this soon >>> for WildFly 10. >>> >>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>> Hi all, >>>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 >>>> to use a preview of Hibernate ORM version 5. >>>> >>>> It seems the JPA deployer isn't allowing me to run such experiments: >>>> >>>> # First experiment - providerModule set to custom module >>>> >>>> In my first attempt, I create a custom set of jboss modules which >>>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>>> instance and set the persistence.xml property: >>>> jboss.as.jpa.providerModule = my-custom-module-name >>>> >>>> and then get: >>>> >>>> Caused by: java.util.ServiceConfigurationError: >>>> org.hibernate.integrator.spi.Integrator: Provider >>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] >>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] >>>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>> [rt.jar:1.7.0_51] >>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] >>>> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>> at org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >>>> at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >>>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >>>> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >>>> at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>> ... 7 more >>>> >>>> Clearly it looks like I'm being served classes from the bundled >>>> Hibernate 4.x implementation - on top of those from the module I'm >>>> requesting. This isn't what the deployer should be doing, right? >>>> >>>> # Second experiment - use the "application provided" >>>> >>>> In this case I hope to hint the JPA deployer to not add the default >>>> implementor but look for a JPA implementation within my deployment, >>>> but still package my custom Hibernate build as a module. >>>> >>>> - use the same custom module containing Hibernate ORM 5 (a preview snapshot) >>>> - Add a "Dependency:" section to the manifest to import (and export) >>>> my custom module >>>> - set the "jboss.as.jpa.providerModule" property to value "application" >>>> >>>> This gets me: >>>> >>>> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>> WFLYJPA0027: Persistence provider module load error application (class >>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>> ... 5 more >>>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main >>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>> [jboss-modules.jar:1.4.3.Final] >>>> at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>> ... 10 more >>>> >>>> Remarks: >>>> - it's attempting to load the "application:main" module?! that's not >>>> what I'd expect from reading [1] >>> >>> This seems to be a bug. I hit it a few days ago when I packaged >>> Hibernate ORM 4.1.x with an application (in a unit test) and forgot to >>> set the persistence provider in persistence.xml. >>> >>>> - the provider should be available to the deployment classpath, so >>>> I'm not sure why it's not finding the Provider? (I'm even exporting >>>> it, although I'm not sure if that was required). >>> >>> Providers are always found through the >>> javax.persistence.spi.PersistenceProviderResolver, not directly from the >>> deployment classpath. >>> >>>> >>>> Any suggestions to get this running please? >>>> >>>> Also I wonder if some of these should warrant opening a JIRA, but I'm >>>> not sure how far I misunderstood the intentions of these JPA deployer >>>> properties. >>> >>> Lets talk in a few days again on IRC. >>> >>>> >>>> Thanks, >>>> Sanne >>>> >>>> [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >>> _______________________________________________ >>> 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 Thu May 21 15:10:11 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 21 May 2015 15:10:11 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> Message-ID: <555E2D93.3000700@redhat.com> On 05/21/2015 03:05 PM, Toma? Cerar wrote: > Scott, > > if you do one last jipijapa release that adds "support" for hibernate5 > hibernate guys could take that version and override it in wildfly 9 same > way as they add new h5 modules. I assume this will be an iterative process but sure, we could also push a release of the JIPI-31 branch. Lets keep talking about what is needed... > > -- > tomaz > > On Thu, May 21, 2015 at 9:01 PM, Scott Marlow > wrote: > > On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > > Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. > > https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the > integration code that we will look at merging into WildFly 10. Are you > looking for a custom WildFly 9.x branch or actual changes in WildFly 9 > (doesn't seem as likely to me but I don't control the schedule)? > > > > > It would help speed up the Hibernate 5 stream adoption and avoid > a lot of duplicated work for 6+ months. > > > >> On 21 mai 2015, at 16:36, Scott Marlow > wrote: > >> > >> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on > this soon > >> for WildFly 10. > >> > >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >>> Hi all, > >>> I'm attempting to deploy some integration tests on WildFly > 9.0.0.CR1 > >>> to use a preview of Hibernate ORM version 5. > >>> > >>> It seems the JPA deployer isn't allowing me to run such > experiments: > >>> > >>> # First experiment - providerModule set to custom module > >>> > >>> In my first attempt, I create a custom set of jboss modules which > >>> include the snapshot builds of ORM 5, add them to my standalone WF9 > >>> instance and set the persistence.xml property: > >>> jboss.as.jpa.providerModule = my-custom-module-name > >>> > >>> and then get: > >>> > >>> Caused by: java.util.ServiceConfigurationError: > >>> org.hibernate.integrator.spi.Integrator: Provider > >>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype > >>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > [rt.jar:1.7.0_51] > >>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) > [rt.jar:1.7.0_51] > >>> at > java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >>> [rt.jar:1.7.0_51] > >>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > [rt.jar:1.7.0_51] > >>> at > org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >>> at > org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > >>> at > org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >>> at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >>> at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > >>> at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > >>> at > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >>> at > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >>> at > org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > >>> at > org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >>> at > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >>> at > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >>> at > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >>> ... 7 more > >>> > >>> Clearly it looks like I'm being served classes from the bundled > >>> Hibernate 4.x implementation - on top of those from the module I'm > >>> requesting. This isn't what the deployer should be doing, right? > >>> > >>> # Second experiment - use the "application provided" > >>> > >>> In this case I hope to hint the JPA deployer to not add the > default > >>> implementor but look for a JPA implementation within my deployment, > >>> but still package my custom Hibernate build as a module. > >>> > >>> - use the same custom module containing Hibernate ORM 5 (a > preview snapshot) > >>> - Add a "Dependency:" section to the manifest to import (and > export) > >>> my custom module > >>> - set the "jboss.as.jpa.providerModule" property to value > "application" > >>> > >>> This gets me: > >>> > >>> Caused by: > org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >>> WFLYJPA0027: Persistence provider module load error application > (class > >>> org.hibernate.jpa.HibernatePersistenceProvider) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >>> at > org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >>> at > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >>> ... 5 more > >>> Caused by: org.jboss.modules.ModuleNotFoundException: > application:main > >>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >>> [jboss-modules.jar:1.4.3.Final] > >>> at > org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >>> at > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >>> ... 10 more > >>> > >>> Remarks: > >>> - it's attempting to load the "application:main" module?! > that's not > >>> what I'd expect from reading [1] > >> > >> This seems to be a bug. I hit it a few days ago when I packaged > >> Hibernate ORM 4.1.x with an application (in a unit test) and > forgot to > >> set the persistence provider in persistence.xml. > >> > >>> - the provider should be available to the deployment > classpath, so > >>> I'm not sure why it's not finding the Provider? (I'm even exporting > >>> it, although I'm not sure if that was required). > >> > >> Providers are always found through the > >> javax.persistence.spi.PersistenceProviderResolver, not directly > from the > >> deployment classpath. > >> > >>> > >>> Any suggestions to get this running please? > >>> > >>> Also I wonder if some of these should warrant opening a JIRA, > but I'm > >>> not sure how far I misunderstood the intentions of these JPA > deployer > >>> properties. > >> > >> Lets talk in a few days again on IRC. > >> > >>> > >>> Thanks, > >>> Sanne > >>> > >>> [1] - > https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > >> _______________________________________________ > >> 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 darran.lofthouse at jboss.com Fri May 22 06:31:07 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 22 May 2015 11:31:07 +0100 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions Message-ID: <555F056B.3040406@jboss.com> Following on from PR https://github.com/wildfly/wildfly-core/pull/757 and my final comment in the PR we need to have a discussion on how we coordinate capability and requirement definitions - especially where multiple components need a common definition. The first option is to do it all by convention and have no shared constants, the down side of this is we now need to document this and keep the document maintained. A document would also make it hard in the future to flag certain capabilities as deprecated if preferred alternatives are made available. The second option would be to just define the Strings somewhere and use Javadoc to specify if the capability is dynamic and it's service type. The third option is defining the string and RuntimeCapability instances in a central place so they can both be referenced as needed. Any other options? Where these live will be a second point to discuss but that is heavily driven based on what we will share in the first place. Regards, Darran Lofthouse. From brian.stansberry at redhat.com Fri May 22 08:57:06 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 22 May 2015 07:57:06 -0500 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <555F056B.3040406@jboss.com> References: <555F056B.3040406@jboss.com> Message-ID: <555F27A2.2000306@redhat.com> Thanks for raising this; it's a good set of questions. I'll be AFK for a week starting late today, so I'll start with point #2 even though that's backwards. It's just the one where I have a stronger opinion. The controller module should be about basic API for creating resources, attributes, handlers. Having other stuff like the actual ModelControllerImpl in there isn't pure, but I don't mind much. But then over time I and others have put some stuff in there basically just because both server and host-controller use it. We need to move away from that kind of thing, and not add more. As for your question 1, I don't feel strongly at all, just have some thoughts. To initially use a capability, people are going to have to look up data. We're not going to stick all of these in controller, so that means there's going to be a search, and these kinds of classes are going to be dispersed. Trying to maintain some fairly centralized document somewhere would actually make that initial search easier. Using constants like in your PR is helpful for later maintenance. If some constant is deprecated, referrers will see that in their IDE. They can easily click to read javadoc and learn if the requirement's dynamic and the service type. The biggest concern I have is avoiding premature classloading links. This is important in the case of optional requirements. If a requirement is optional, it's critical that the declaration of the requirement in the code doesn't force loading of classes from the required capability's module. Otherwise that module is no longer optional and its harder to create a slim distribution. On 5/22/15 5:31 AM, Darran Lofthouse wrote: > Following on from PR https://github.com/wildfly/wildfly-core/pull/757 > and my final comment in the PR we need to have a discussion on how we > coordinate capability and requirement definitions - especially where > multiple components need a common definition. > > The first option is to do it all by convention and have no shared > constants, the down side of this is we now need to document this and > keep the document maintained. A document would also make it hard in the > future to flag certain capabilities as deprecated if preferred > alternatives are made available. > > The second option would be to just define the Strings somewhere and use > Javadoc to specify if the capability is dynamic and it's service type. > > The third option is defining the string and RuntimeCapability instances > in a central place so they can both be referenced as needed. > > Any other options? > > Where these live will be a second point to discuss but that is heavily > driven based on what we will share in the first place. > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Fri May 22 09:50:01 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 22 May 2015 15:50:01 +0200 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <555F056B.3040406@jboss.com> References: <555F056B.3040406@jboss.com> Message-ID: On Fri, May 22, 2015 at 12:31 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > > The first option is to do it all by convention and have no shared > constants, the down side of this is we now need to document this and > keep the document maintained. A document would also make it hard in the > future to flag certain capabilities as deprecated if preferred > alternatives are made available. > > Well, deprecated can be done on two levels, one is compile time, the other runtime. and at runtime it is easy to add feedback that certain capability is deprecated. > The second option would be to just define the Strings somewhere and use > Javadoc to specify if the capability is dynamic and it's service type. > > That one sounds ok, but you still need central place with constants, even if just for compile. > The third option is defining the string and RuntimeCapability instances > in a central place so they can both be referenced as needed. I don't like this one at all, I know it was in initial design of capabilities and it was the single thing I disliked the most. so IMO, either #1 or #2 is fine, but lest avoid #3 if possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150522/ba871e5f/attachment-0001.html From darran.lofthouse at jboss.com Fri May 22 10:16:26 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 22 May 2015 15:16:26 +0100 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: References: <555F056B.3040406@jboss.com> Message-ID: <555F3A3A.2010600@jboss.com> On 22/05/15 14:50, Toma? Cerar wrote: > > On Fri, May 22, 2015 at 12:31 PM, Darran Lofthouse > > wrote: > > > The first option is to do it all by convention and have no shared > constants, the down side of this is we now need to document this and > keep the document maintained. A document would also make it hard in the > future to flag certain capabilities as deprecated if preferred > alternatives are made available. > > Well, deprecated can be done on two levels, one is compile time, the > other runtime. > and at runtime it is easy to add feedback that certain capability is > deprecated. I don't really see runtime deprecation is an option here - the problem here is unless the capability is defined in a central location there is no central point to flag it as deprecated - the capability is kind of our central coordination point. There is no single provider of the capability to be the definitive reference point to flag deprecation - hence the central definition in the PR. > The second option would be to just define the Strings somewhere and use > Javadoc to specify if the capability is dynamic and it's service type. > > That one sounds ok, but you still need central place with constants, > even if just for compile. > > The third option is defining the string and RuntimeCapability instances > in a central place so they can both be referenced as needed. I think a String only definition means that we only have an option to flag as deprecated at compile time - not runtime, but that may be fine. > I don't like this one at all, I know it was in initial design of > capabilities > and it was the single thing I disliked the most. > > so IMO, either #1 or #2 is fine, but lest avoid #3 if possible. > > From darran.lofthouse at jboss.com Fri May 22 10:21:26 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 22 May 2015 15:21:26 +0100 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <555F27A2.2000306@redhat.com> References: <555F056B.3040406@jboss.com> <555F27A2.2000306@redhat.com> Message-ID: <555F3B66.2070700@jboss.com> On 22/05/15 13:57, Brian Stansberry wrote: > Thanks for raising this; it's a good set of questions. > > I'll be AFK for a week starting late today, so I'll start with point #2 > even though that's backwards. It's just the one where I have a stronger > opinion. > > The controller module should be about basic API for creating resources, > attributes, handlers. Having other stuff like the actual > ModelControllerImpl in there isn't pure, but I don't mind much. But then > over time I and others have put some stuff in there basically just > because both server and host-controller use it. We need to move away > from that kind of thing, and not add more. I can move it to a different module but most likely I think that would be a new module, 'server' could have been a candidate but that depends on too many artifacts that will also need to reference these. > As for your question 1, I don't feel strongly at all, just have some > thoughts. To initially use a capability, people are going to have to > look up data. We're not going to stick all of these in controller, so > that means there's going to be a search, and these kinds of classes are > going to be dispersed. Trying to maintain some fairly centralized > document somewhere would actually make that initial search easier. At the moment with this PR all I am proposing is a central location for capabilities that we know will be widely used, in this case the server and subsystems etc. are going to have hard coded dependencies on Elytron APIs - what is not hard coded is how the implementations of those APIs are actually made available. The Elytron project could not contain these definitions as that has no dependencies on WildFly, the Elytron Subsystem can not contain this as that is an optional module. > Using constants like in your PR is helpful for later maintenance. If > some constant is deprecated, referrers will see that in their IDE. They > can easily click to read javadoc and learn if the requirement's dynamic > and the service type. > > The biggest concern I have is avoiding premature classloading links. > This is important in the case of optional requirements. If a requirement > is optional, it's critical that the declaration of the requirement in > the code doesn't force loading of classes from the required capability's > module. Otherwise that module is no longer optional and its harder to > create a slim distribution. In this case the only classes being referenced are classes from the Elytron module and that module is going to be mandatory within the server. Generally it sounds like 'controller' is a no-go so the format of any constants in code will probably dictate where this lives. If we are only talking Strings I may be able to add it to the 'wildfly-core-security-api' module although javadoc can not reference any capability related classes so that may not be preferable - of I can create a new module with a dependency on controller and everything else that uses Elytron capabilities can then depend on this new artifact / module. > On 5/22/15 5:31 AM, Darran Lofthouse wrote: >> Following on from PR https://github.com/wildfly/wildfly-core/pull/757 >> and my final comment in the PR we need to have a discussion on how we >> coordinate capability and requirement definitions - especially where >> multiple components need a common definition. >> >> The first option is to do it all by convention and have no shared >> constants, the down side of this is we now need to document this and >> keep the document maintained. A document would also make it hard in the >> future to flag certain capabilities as deprecated if preferred >> alternatives are made available. >> >> The second option would be to just define the Strings somewhere and use >> Javadoc to specify if the capability is dynamic and it's service type. >> >> The third option is defining the string and RuntimeCapability instances >> in a central place so they can both be referenced as needed. >> >> Any other options? >> >> Where these live will be a second point to discuss but that is heavily >> driven based on what we will share in the first place. >> >> Regards, >> Darran Lofthouse. >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From brian.stansberry at redhat.com Fri May 22 12:25:17 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 22 May 2015 11:25:17 -0500 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <555F3B66.2070700@jboss.com> References: <555F056B.3040406@jboss.com> <555F27A2.2000306@redhat.com> <555F3B66.2070700@jboss.com> Message-ID: <555F586D.7060706@redhat.com> On 5/22/15 9:21 AM, Darran Lofthouse wrote: > > > On 22/05/15 13:57, Brian Stansberry wrote: >> Thanks for raising this; it's a good set of questions. >> >> I'll be AFK for a week starting late today, so I'll start with point #2 >> even though that's backwards. It's just the one where I have a stronger >> opinion. >> >> The controller module should be about basic API for creating resources, >> attributes, handlers. Having other stuff like the actual >> ModelControllerImpl in there isn't pure, but I don't mind much. But then >> over time I and others have put some stuff in there basically just >> because both server and host-controller use it. We need to move away >> from that kind of thing, and not add more. > > I can move it to a different module but most likely I think that would > be a new module, 'server' could have been a candidate but that depends > on too many artifacts that will also need to reference these. > >> As for your question 1, I don't feel strongly at all, just have some >> thoughts. To initially use a capability, people are going to have to >> look up data. We're not going to stick all of these in controller, so >> that means there's going to be a search, and these kinds of classes are >> going to be dispersed. Trying to maintain some fairly centralized >> document somewhere would actually make that initial search easier. > > At the moment with this PR all I am proposing is a central location for > capabilities that we know will be widely used, in this case the server > and subsystems etc. are going to have hard coded dependencies on Elytron > APIs - what is not hard coded is how the implementations of those APIs > are actually made available. > Who is the consumer of these? A requirer only needs the String names, none of the "public static final RuntimeCapability" instances. The different providers of the capability can use the RuntimeCapability constants, but I think those should be separated somehow. They are really none of the business of the requirers. > The Elytron project could not contain these definitions as that has no > dependencies on WildFly, the Elytron Subsystem can not contain this as > that is an optional module. > >> Using constants like in your PR is helpful for later maintenance. If >> some constant is deprecated, referrers will see that in their IDE. They >> can easily click to read javadoc and learn if the requirement's dynamic >> and the service type. >> >> The biggest concern I have is avoiding premature classloading links. >> This is important in the case of optional requirements. If a requirement >> is optional, it's critical that the declaration of the requirement in >> the code doesn't force loading of classes from the required capability's >> module. Otherwise that module is no longer optional and its harder to >> create a slim distribution. > > In this case the only classes being referenced are classes from the > Elytron module and that module is going to be mandatory within the server. > Yep. This classloading thing is more of a general concern, not particularly relevant to this particular case. People tend to code things up by copying existing code though, so it's good to consider the general problem before establishing precedents. > Generally it sounds like 'controller' is a no-go so the format of any > constants in code will probably dictate where this lives. > > If we are only talking Strings I may be able to add it to the > 'wildfly-core-security-api' module although javadoc can not reference > any capability related classes so that may not be preferable - of I can > create a new module with a dependency on controller and everything else > that uses Elytron capabilities can then depend on this new artifact / > module. > >> On 5/22/15 5:31 AM, Darran Lofthouse wrote: >>> Following on from PR https://github.com/wildfly/wildfly-core/pull/757 >>> and my final comment in the PR we need to have a discussion on how we >>> coordinate capability and requirement definitions - especially where >>> multiple components need a common definition. >>> >>> The first option is to do it all by convention and have no shared >>> constants, the down side of this is we now need to document this and >>> keep the document maintained. A document would also make it hard in the >>> future to flag certain capabilities as deprecated if preferred >>> alternatives are made available. >>> >>> The second option would be to just define the Strings somewhere and use >>> Javadoc to specify if the capability is dynamic and it's service type. >>> >>> The third option is defining the string and RuntimeCapability instances >>> in a central place so they can both be referenced as needed. >>> >>> Any other options? >>> >>> Where these live will be a second point to discuss but that is heavily >>> driven based on what we will share in the first place. >>> >>> Regards, >>> Darran Lofthouse. >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Fri May 22 13:55:03 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 22 May 2015 18:55:03 +0100 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <555F586D.7060706@redhat.com> References: <555F056B.3040406@jboss.com> <555F27A2.2000306@redhat.com> <555F3B66.2070700@jboss.com> <555F586D.7060706@redhat.com> Message-ID: <555F6D77.10108@jboss.com> On 22/05/15 17:25, Brian Stansberry wrote: > On 5/22/15 9:21 AM, Darran Lofthouse wrote: >> >> >> On 22/05/15 13:57, Brian Stansberry wrote: >>> Thanks for raising this; it's a good set of questions. >>> >>> I'll be AFK for a week starting late today, so I'll start with point #2 >>> even though that's backwards. It's just the one where I have a stronger >>> opinion. >>> >>> The controller module should be about basic API for creating resources, >>> attributes, handlers. Having other stuff like the actual >>> ModelControllerImpl in there isn't pure, but I don't mind much. But then >>> over time I and others have put some stuff in there basically just >>> because both server and host-controller use it. We need to move away >>> from that kind of thing, and not add more. >> >> I can move it to a different module but most likely I think that would >> be a new module, 'server' could have been a candidate but that depends >> on too many artifacts that will also need to reference these. >> >>> As for your question 1, I don't feel strongly at all, just have some >>> thoughts. To initially use a capability, people are going to have to >>> look up data. We're not going to stick all of these in controller, so >>> that means there's going to be a search, and these kinds of classes are >>> going to be dispersed. Trying to maintain some fairly centralized >>> document somewhere would actually make that initial search easier. >> >> At the moment with this PR all I am proposing is a central location for >> capabilities that we know will be widely used, in this case the server >> and subsystems etc. are going to have hard coded dependencies on Elytron >> APIs - what is not hard coded is how the implementations of those APIs >> are actually made available. >> > > Who is the consumer of these? A requirer only needs the String names, > none of the "public static final RuntimeCapability" instances. The consumers will be: - - Various resources in core. - Subsystems in general. - Deployments. One possible problem I am seeing with only using a String on the consumer side is that there is no type associated even though the dependency injection for dynamic capabilities at least is going to depend on a mutually agreed type. > The different providers of the capability can use the RuntimeCapability > constants, but I think those should be separated somehow. They are > really none of the business of the requirers. The providers will be: - - The Elytron Subsystem (Optional) - Any other subsytem that wants to provide one or more of these capabilities. For separation we could have different classes, different modules or even some factory class to convert from the name to the RuntimeCapability instance. I think single new module with two classes may be the better compromise for now otherwise we risk two new modules - each with a single class. The main point being that WildFly Core is the single common dependency for everything >> The Elytron project could not contain these definitions as that has no >> dependencies on WildFly, the Elytron Subsystem can not contain this as >> that is an optional module. >> >>> Using constants like in your PR is helpful for later maintenance. If >>> some constant is deprecated, referrers will see that in their IDE. They >>> can easily click to read javadoc and learn if the requirement's dynamic >>> and the service type. >>> >>> The biggest concern I have is avoiding premature classloading links. >>> This is important in the case of optional requirements. If a requirement >>> is optional, it's critical that the declaration of the requirement in >>> the code doesn't force loading of classes from the required capability's >>> module. Otherwise that module is no longer optional and its harder to >>> create a slim distribution. >> >> In this case the only classes being referenced are classes from the >> Elytron module and that module is going to be mandatory within the >> server. >> > > Yep. This classloading thing is more of a general concern, not > particularly relevant to this particular case. People tend to code > things up by copying existing code though, so it's good to consider the > general problem before establishing precedents. > >> Generally it sounds like 'controller' is a no-go so the format of any >> constants in code will probably dictate where this lives. >> >> If we are only talking Strings I may be able to add it to the >> 'wildfly-core-security-api' module although javadoc can not reference >> any capability related classes so that may not be preferable - of I can >> create a new module with a dependency on controller and everything else >> that uses Elytron capabilities can then depend on this new artifact / >> module. >> >>> On 5/22/15 5:31 AM, Darran Lofthouse wrote: >>>> Following on from PR https://github.com/wildfly/wildfly-core/pull/757 >>>> and my final comment in the PR we need to have a discussion on how we >>>> coordinate capability and requirement definitions - especially where >>>> multiple components need a common definition. >>>> >>>> The first option is to do it all by convention and have no shared >>>> constants, the down side of this is we now need to document this and >>>> keep the document maintained. A document would also make it hard in >>>> the >>>> future to flag certain capabilities as deprecated if preferred >>>> alternatives are made available. >>>> >>>> The second option would be to just define the Strings somewhere and use >>>> Javadoc to specify if the capability is dynamic and it's service type. >>>> >>>> The third option is defining the string and RuntimeCapability instances >>>> in a central place so they can both be referenced as needed. >>>> >>>> Any other options? >>>> >>>> Where these live will be a second point to discuss but that is heavily >>>> driven based on what we will share in the first place. >>>> >>>> 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 Fri May 22 14:00:49 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 22 May 2015 13:00:49 -0500 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <555F6D77.10108@jboss.com> References: <555F056B.3040406@jboss.com> <555F27A2.2000306@redhat.com> <555F3B66.2070700@jboss.com> <555F586D.7060706@redhat.com> <555F6D77.10108@jboss.com> Message-ID: <555F6ED1.3030202@redhat.com> On 05/22/2015 12:55 PM, Darran Lofthouse wrote: > > > On 22/05/15 17:25, Brian Stansberry wrote: >> On 5/22/15 9:21 AM, Darran Lofthouse wrote: >>> >>> >>> On 22/05/15 13:57, Brian Stansberry wrote: >>>> Thanks for raising this; it's a good set of questions. >>>> >>>> I'll be AFK for a week starting late today, so I'll start with point #2 >>>> even though that's backwards. It's just the one where I have a stronger >>>> opinion. >>>> >>>> The controller module should be about basic API for creating resources, >>>> attributes, handlers. Having other stuff like the actual >>>> ModelControllerImpl in there isn't pure, but I don't mind much. But then >>>> over time I and others have put some stuff in there basically just >>>> because both server and host-controller use it. We need to move away >>>> from that kind of thing, and not add more. >>> >>> I can move it to a different module but most likely I think that would >>> be a new module, 'server' could have been a candidate but that depends >>> on too many artifacts that will also need to reference these. >>> >>>> As for your question 1, I don't feel strongly at all, just have some >>>> thoughts. To initially use a capability, people are going to have to >>>> look up data. We're not going to stick all of these in controller, so >>>> that means there's going to be a search, and these kinds of classes are >>>> going to be dispersed. Trying to maintain some fairly centralized >>>> document somewhere would actually make that initial search easier. >>> >>> At the moment with this PR all I am proposing is a central location for >>> capabilities that we know will be widely used, in this case the server >>> and subsystems etc. are going to have hard coded dependencies on Elytron >>> APIs - what is not hard coded is how the implementations of those APIs >>> are actually made available. >>> >> >> Who is the consumer of these? A requirer only needs the String names, >> none of the "public static final RuntimeCapability" instances. > > The consumers will be: - > - Various resources in core. > - Subsystems in general. > - Deployments. > > One possible problem I am seeing with only using a String on the > consumer side is that there is no type associated even though the > dependency injection for dynamic capabilities at least is going to > depend on a mutually agreed type. I don't think that really makes a huge difference in this case. There will be a fairly small number of consumers, and type safety in this case is not going to be critical. And really I don't anticipate that type safety would catch any bugs that wouldn't be caught in any event by the simpler string-based system at the same time. >> The different providers of the capability can use the RuntimeCapability >> constants, but I think those should be separated somehow. They are >> really none of the business of the requirers. > > The providers will be: - > - The Elytron Subsystem (Optional) > - Any other subsytem that wants to provide one or more of these > capabilities. > > For separation we could have different classes, different modules or > even some factory class to convert from the name to the > RuntimeCapability instance. Too complex - I think we need to think minimally here. Keep the mechanism as simple as possible. > I think single new module with two classes may be the better compromise > for now otherwise we risk two new modules - each with a single class. > > The main point being that WildFly Core is the single common dependency > for everything For the moment. Not forever though. >>> The Elytron project could not contain these definitions as that has no >>> dependencies on WildFly, the Elytron Subsystem can not contain this as >>> that is an optional module. >>> >>>> Using constants like in your PR is helpful for later maintenance. If >>>> some constant is deprecated, referrers will see that in their IDE. They >>>> can easily click to read javadoc and learn if the requirement's dynamic >>>> and the service type. >>>> >>>> The biggest concern I have is avoiding premature classloading links. >>>> This is important in the case of optional requirements. If a requirement >>>> is optional, it's critical that the declaration of the requirement in >>>> the code doesn't force loading of classes from the required capability's >>>> module. Otherwise that module is no longer optional and its harder to >>>> create a slim distribution. >>> >>> In this case the only classes being referenced are classes from the >>> Elytron module and that module is going to be mandatory within the >>> server. >>> >> >> Yep. This classloading thing is more of a general concern, not >> particularly relevant to this particular case. People tend to code >> things up by copying existing code though, so it's good to consider the >> general problem before establishing precedents. >> >>> Generally it sounds like 'controller' is a no-go so the format of any >>> constants in code will probably dictate where this lives. >>> >>> If we are only talking Strings I may be able to add it to the >>> 'wildfly-core-security-api' module although javadoc can not reference >>> any capability related classes so that may not be preferable - of I can >>> create a new module with a dependency on controller and everything else >>> that uses Elytron capabilities can then depend on this new artifact / >>> module. >>> >>>> On 5/22/15 5:31 AM, Darran Lofthouse wrote: >>>>> Following on from PR https://github.com/wildfly/wildfly-core/pull/757 >>>>> and my final comment in the PR we need to have a discussion on how we >>>>> coordinate capability and requirement definitions - especially where >>>>> multiple components need a common definition. >>>>> >>>>> The first option is to do it all by convention and have no shared >>>>> constants, the down side of this is we now need to document this and >>>>> keep the document maintained. A document would also make it hard in >>>>> the >>>>> future to flag certain capabilities as deprecated if preferred >>>>> alternatives are made available. >>>>> >>>>> The second option would be to just define the Strings somewhere and use >>>>> Javadoc to specify if the capability is dynamic and it's service type. >>>>> >>>>> The third option is defining the string and RuntimeCapability instances >>>>> in a central place so they can both be referenced as needed. >>>>> >>>>> Any other options? >>>>> >>>>> Where these live will be a second point to discuss but that is heavily >>>>> driven based on what we will share in the first place. >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> _______________________________________________ >>>>> 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 > -- - DML From darran.lofthouse at jboss.com Fri May 22 14:06:26 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 22 May 2015 19:06:26 +0100 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <555F6ED1.3030202@redhat.com> References: <555F056B.3040406@jboss.com> <555F27A2.2000306@redhat.com> <555F3B66.2070700@jboss.com> <555F586D.7060706@redhat.com> <555F6D77.10108@jboss.com> <555F6ED1.3030202@redhat.com> Message-ID: <555F7022.4060201@jboss.com> On 22/05/15 19:00, David M. Lloyd wrote: > On 05/22/2015 12:55 PM, Darran Lofthouse wrote: >> >> >> On 22/05/15 17:25, Brian Stansberry wrote: >>> On 5/22/15 9:21 AM, Darran Lofthouse wrote: >>>> >>>> >>>> On 22/05/15 13:57, Brian Stansberry wrote: >>>>> Thanks for raising this; it's a good set of questions. >>>>> >>>>> I'll be AFK for a week starting late today, so I'll start with point #2 >>>>> even though that's backwards. It's just the one where I have a stronger >>>>> opinion. >>>>> >>>>> The controller module should be about basic API for creating resources, >>>>> attributes, handlers. Having other stuff like the actual >>>>> ModelControllerImpl in there isn't pure, but I don't mind much. But then >>>>> over time I and others have put some stuff in there basically just >>>>> because both server and host-controller use it. We need to move away >>>>> from that kind of thing, and not add more. >>>> >>>> I can move it to a different module but most likely I think that would >>>> be a new module, 'server' could have been a candidate but that depends >>>> on too many artifacts that will also need to reference these. >>>> >>>>> As for your question 1, I don't feel strongly at all, just have some >>>>> thoughts. To initially use a capability, people are going to have to >>>>> look up data. We're not going to stick all of these in controller, so >>>>> that means there's going to be a search, and these kinds of classes are >>>>> going to be dispersed. Trying to maintain some fairly centralized >>>>> document somewhere would actually make that initial search easier. >>>> >>>> At the moment with this PR all I am proposing is a central location for >>>> capabilities that we know will be widely used, in this case the server >>>> and subsystems etc. are going to have hard coded dependencies on Elytron >>>> APIs - what is not hard coded is how the implementations of those APIs >>>> are actually made available. >>>> >>> >>> Who is the consumer of these? A requirer only needs the String names, >>> none of the "public static final RuntimeCapability" instances. >> >> The consumers will be: - >> - Various resources in core. >> - Subsystems in general. >> - Deployments. >> >> One possible problem I am seeing with only using a String on the >> consumer side is that there is no type associated even though the >> dependency injection for dynamic capabilities at least is going to >> depend on a mutually agreed type. > > I don't think that really makes a huge difference in this case. There > will be a fairly small number of consumers, and type safety in this case > is not going to be critical. And really I don't anticipate that type > safety would catch any bugs that wouldn't be caught in any event by the > simpler string-based system at the same time. > >>> The different providers of the capability can use the RuntimeCapability >>> constants, but I think those should be separated somehow. They are >>> really none of the business of the requirers. >> >> The providers will be: - >> - The Elytron Subsystem (Optional) >> - Any other subsytem that wants to provide one or more of these >> capabilities. >> >> For separation we could have different classes, different modules or >> even some factory class to convert from the name to the >> RuntimeCapability instance. > > Too complex - I think we need to think minimally here. Keep the > mechanism as simple as possible. Which part was too complex? The Factory? IMO I think go for one new module, 2 classes in this module, 1 class for the String constants and 1 class for the statically defined RuntimeCapability definitions. >> I think single new module with two classes may be the better compromise >> for now otherwise we risk two new modules - each with a single class. >> >> The main point being that WildFly Core is the single common dependency >> for everything > > For the moment. Not forever though. In what way? Everything is depending on 'controller' as that is where the notion of capabilities are defined - are we saying the core of core can be split out even further? >>>> The Elytron project could not contain these definitions as that has no >>>> dependencies on WildFly, the Elytron Subsystem can not contain this as >>>> that is an optional module. >>>> >>>>> Using constants like in your PR is helpful for later maintenance. If >>>>> some constant is deprecated, referrers will see that in their IDE. They >>>>> can easily click to read javadoc and learn if the requirement's dynamic >>>>> and the service type. >>>>> >>>>> The biggest concern I have is avoiding premature classloading links. >>>>> This is important in the case of optional requirements. If a requirement >>>>> is optional, it's critical that the declaration of the requirement in >>>>> the code doesn't force loading of classes from the required capability's >>>>> module. Otherwise that module is no longer optional and its harder to >>>>> create a slim distribution. >>>> >>>> In this case the only classes being referenced are classes from the >>>> Elytron module and that module is going to be mandatory within the >>>> server. >>>> >>> >>> Yep. This classloading thing is more of a general concern, not >>> particularly relevant to this particular case. People tend to code >>> things up by copying existing code though, so it's good to consider the >>> general problem before establishing precedents. >>> >>>> Generally it sounds like 'controller' is a no-go so the format of any >>>> constants in code will probably dictate where this lives. >>>> >>>> If we are only talking Strings I may be able to add it to the >>>> 'wildfly-core-security-api' module although javadoc can not reference >>>> any capability related classes so that may not be preferable - of I can >>>> create a new module with a dependency on controller and everything else >>>> that uses Elytron capabilities can then depend on this new artifact / >>>> module. >>>> >>>>> On 5/22/15 5:31 AM, Darran Lofthouse wrote: >>>>>> Following on from PR https://github.com/wildfly/wildfly-core/pull/757 >>>>>> and my final comment in the PR we need to have a discussion on how we >>>>>> coordinate capability and requirement definitions - especially where >>>>>> multiple components need a common definition. >>>>>> >>>>>> The first option is to do it all by convention and have no shared >>>>>> constants, the down side of this is we now need to document this and >>>>>> keep the document maintained. A document would also make it hard in >>>>>> the >>>>>> future to flag certain capabilities as deprecated if preferred >>>>>> alternatives are made available. >>>>>> >>>>>> The second option would be to just define the Strings somewhere and use >>>>>> Javadoc to specify if the capability is dynamic and it's service type. >>>>>> >>>>>> The third option is defining the string and RuntimeCapability instances >>>>>> in a central place so they can both be referenced as needed. >>>>>> >>>>>> Any other options? >>>>>> >>>>>> Where these live will be a second point to discuss but that is heavily >>>>>> driven based on what we will share in the first place. >>>>>> >>>>>> Regards, >>>>>> Darran Lofthouse. >>>>>> _______________________________________________ >>>>>> 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 brian.stansberry at redhat.com Fri May 22 16:25:55 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 22 May 2015 15:25:55 -0500 Subject: [wildfly-dev] WildFly Core 1.0.0.CR5 released Message-ID: <555F90D3.3030906@redhat.com> It's Friday so it's time for another WildFly Core weekly release. This time it's 1.0.0.CR5, which has been integrated into the 9.x branch of WildFly for use in the 9.0.0.Final release. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Sat May 23 13:24:05 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Sat, 23 May 2015 12:24:05 -0500 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <555F7022.4060201@jboss.com> References: <555F056B.3040406@jboss.com> <555F27A2.2000306@redhat.com> <555F3B66.2070700@jboss.com> <555F586D.7060706@redhat.com> <555F6D77.10108@jboss.com> <555F6ED1.3030202@redhat.com> <555F7022.4060201@jboss.com> Message-ID: <5560B7B5.7060203@redhat.com> On 05/22/2015 01:06 PM, Darran Lofthouse wrote: > > > On 22/05/15 19:00, David M. Lloyd wrote: >> On 05/22/2015 12:55 PM, Darran Lofthouse wrote: >>> >>> >>> On 22/05/15 17:25, Brian Stansberry wrote: >>>> On 5/22/15 9:21 AM, Darran Lofthouse wrote: >>>>> >>>>> >>>>> On 22/05/15 13:57, Brian Stansberry wrote: >>>>>> Thanks for raising this; it's a good set of questions. >>>>>> >>>>>> I'll be AFK for a week starting late today, so I'll start with point #2 >>>>>> even though that's backwards. It's just the one where I have a stronger >>>>>> opinion. >>>>>> >>>>>> The controller module should be about basic API for creating resources, >>>>>> attributes, handlers. Having other stuff like the actual >>>>>> ModelControllerImpl in there isn't pure, but I don't mind much. But then >>>>>> over time I and others have put some stuff in there basically just >>>>>> because both server and host-controller use it. We need to move away >>>>>> from that kind of thing, and not add more. >>>>> >>>>> I can move it to a different module but most likely I think that would >>>>> be a new module, 'server' could have been a candidate but that depends >>>>> on too many artifacts that will also need to reference these. >>>>> >>>>>> As for your question 1, I don't feel strongly at all, just have some >>>>>> thoughts. To initially use a capability, people are going to have to >>>>>> look up data. We're not going to stick all of these in controller, so >>>>>> that means there's going to be a search, and these kinds of classes are >>>>>> going to be dispersed. Trying to maintain some fairly centralized >>>>>> document somewhere would actually make that initial search easier. >>>>> >>>>> At the moment with this PR all I am proposing is a central location for >>>>> capabilities that we know will be widely used, in this case the server >>>>> and subsystems etc. are going to have hard coded dependencies on Elytron >>>>> APIs - what is not hard coded is how the implementations of those APIs >>>>> are actually made available. >>>>> >>>> >>>> Who is the consumer of these? A requirer only needs the String names, >>>> none of the "public static final RuntimeCapability" instances. >>> >>> The consumers will be: - >>> - Various resources in core. >>> - Subsystems in general. >>> - Deployments. >>> >>> One possible problem I am seeing with only using a String on the >>> consumer side is that there is no type associated even though the >>> dependency injection for dynamic capabilities at least is going to >>> depend on a mutually agreed type. >> >> I don't think that really makes a huge difference in this case. There >> will be a fairly small number of consumers, and type safety in this case >> is not going to be critical. And really I don't anticipate that type >> safety would catch any bugs that wouldn't be caught in any event by the >> simpler string-based system at the same time. >> >>>> The different providers of the capability can use the RuntimeCapability >>>> constants, but I think those should be separated somehow. They are >>>> really none of the business of the requirers. >>> >>> The providers will be: - >>> - The Elytron Subsystem (Optional) >>> - Any other subsytem that wants to provide one or more of these >>> capabilities. >>> >>> For separation we could have different classes, different modules or >>> even some factory class to convert from the name to the >>> RuntimeCapability instance. >> >> Too complex - I think we need to think minimally here. Keep the >> mechanism as simple as possible. > > Which part was too complex? The Factory? > > IMO I think go for one new module, 2 classes in this module, 1 class for > the String constants and 1 class for the statically defined > RuntimeCapability definitions. Having a module for every capability, which is what this implies, is too complex. We should have zero modules with zero classes and every consumer can have their own copy of the one string that they need. Many providers won't even need special classes, so setting this precedent doesn't really make any sense. >>> I think single new module with two classes may be the better compromise >>> for now otherwise we risk two new modules - each with a single class. ^^^ This right here is the warning sign. If we're creating four-class modules, let alone two- or one-class modules, we've made a wrong turn. More modules per anything is a massive and unnecessary increase in complexity and maintenance burden. >>> The main point being that WildFly Core is the single common dependency >>> for everything >> >> For the moment. Not forever though. > > In what way? Everything is depending on 'controller' as that is where > the notion of capabilities are defined - are we saying the core of core > can be split out even further? The core of core may not even continue to exist in its current form beyond WildFly 10 or 11 once we implement the new management code. >>>>> The Elytron project could not contain these definitions as that has no >>>>> dependencies on WildFly, the Elytron Subsystem can not contain this as >>>>> that is an optional module. >>>>> >>>>>> Using constants like in your PR is helpful for later maintenance. If >>>>>> some constant is deprecated, referrers will see that in their IDE. They >>>>>> can easily click to read javadoc and learn if the requirement's dynamic >>>>>> and the service type. >>>>>> >>>>>> The biggest concern I have is avoiding premature classloading links. >>>>>> This is important in the case of optional requirements. If a requirement >>>>>> is optional, it's critical that the declaration of the requirement in >>>>>> the code doesn't force loading of classes from the required capability's >>>>>> module. Otherwise that module is no longer optional and its harder to >>>>>> create a slim distribution. >>>>> >>>>> In this case the only classes being referenced are classes from the >>>>> Elytron module and that module is going to be mandatory within the >>>>> server. >>>>> >>>> >>>> Yep. This classloading thing is more of a general concern, not >>>> particularly relevant to this particular case. People tend to code >>>> things up by copying existing code though, so it's good to consider the >>>> general problem before establishing precedents. >>>> >>>>> Generally it sounds like 'controller' is a no-go so the format of any >>>>> constants in code will probably dictate where this lives. >>>>> >>>>> If we are only talking Strings I may be able to add it to the >>>>> 'wildfly-core-security-api' module although javadoc can not reference >>>>> any capability related classes so that may not be preferable - of I can >>>>> create a new module with a dependency on controller and everything else >>>>> that uses Elytron capabilities can then depend on this new artifact / >>>>> module. >>>>> >>>>>> On 5/22/15 5:31 AM, Darran Lofthouse wrote: >>>>>>> Following on from PR https://github.com/wildfly/wildfly-core/pull/757 >>>>>>> and my final comment in the PR we need to have a discussion on how we >>>>>>> coordinate capability and requirement definitions - especially where >>>>>>> multiple components need a common definition. >>>>>>> >>>>>>> The first option is to do it all by convention and have no shared >>>>>>> constants, the down side of this is we now need to document this and >>>>>>> keep the document maintained. A document would also make it hard in >>>>>>> the >>>>>>> future to flag certain capabilities as deprecated if preferred >>>>>>> alternatives are made available. >>>>>>> >>>>>>> The second option would be to just define the Strings somewhere and use >>>>>>> Javadoc to specify if the capability is dynamic and it's service type. >>>>>>> >>>>>>> The third option is defining the string and RuntimeCapability instances >>>>>>> in a central place so they can both be referenced as needed. >>>>>>> >>>>>>> Any other options? >>>>>>> >>>>>>> Where these live will be a second point to discuss but that is heavily >>>>>>> driven based on what we will share in the first place. >>>>>>> >>>>>>> Regards, >>>>>>> Darran Lofthouse. >>>>>>> _______________________________________________ >>>>>>> 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 > -- - DML From darran.lofthouse at jboss.com Tue May 26 06:26:48 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 26 May 2015 11:26:48 +0100 Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions In-Reply-To: <5560B7B5.7060203@redhat.com> References: <555F056B.3040406@jboss.com> <555F27A2.2000306@redhat.com> <555F3B66.2070700@jboss.com> <555F586D.7060706@redhat.com> <555F6D77.10108@jboss.com> <555F6ED1.3030202@redhat.com> <555F7022.4060201@jboss.com> <5560B7B5.7060203@redhat.com> Message-ID: <55644A68.6090301@jboss.com> Ok so David's view is essentially my option one - we do this entirely by convention / documentation and have no shared constants. Everyone happy with this? Or any strong arguments towards having constants? Regards, Darran Lofthouse. On 23/05/15 18:24, David M. Lloyd wrote: > On 05/22/2015 01:06 PM, Darran Lofthouse wrote: >> >> >> On 22/05/15 19:00, David M. Lloyd wrote: >>> On 05/22/2015 12:55 PM, Darran Lofthouse wrote: >>>> >>>> >>>> On 22/05/15 17:25, Brian Stansberry wrote: >>>>> On 5/22/15 9:21 AM, Darran Lofthouse wrote: >>>>>> >>>>>> >>>>>> On 22/05/15 13:57, Brian Stansberry wrote: >>>>>>> Thanks for raising this; it's a good set of questions. >>>>>>> >>>>>>> I'll be AFK for a week starting late today, so I'll start with point #2 >>>>>>> even though that's backwards. It's just the one where I have a stronger >>>>>>> opinion. >>>>>>> >>>>>>> The controller module should be about basic API for creating resources, >>>>>>> attributes, handlers. Having other stuff like the actual >>>>>>> ModelControllerImpl in there isn't pure, but I don't mind much. But then >>>>>>> over time I and others have put some stuff in there basically just >>>>>>> because both server and host-controller use it. We need to move away >>>>>>> from that kind of thing, and not add more. >>>>>> >>>>>> I can move it to a different module but most likely I think that would >>>>>> be a new module, 'server' could have been a candidate but that depends >>>>>> on too many artifacts that will also need to reference these. >>>>>> >>>>>>> As for your question 1, I don't feel strongly at all, just have some >>>>>>> thoughts. To initially use a capability, people are going to have to >>>>>>> look up data. We're not going to stick all of these in controller, so >>>>>>> that means there's going to be a search, and these kinds of classes are >>>>>>> going to be dispersed. Trying to maintain some fairly centralized >>>>>>> document somewhere would actually make that initial search easier. >>>>>> >>>>>> At the moment with this PR all I am proposing is a central location for >>>>>> capabilities that we know will be widely used, in this case the server >>>>>> and subsystems etc. are going to have hard coded dependencies on Elytron >>>>>> APIs - what is not hard coded is how the implementations of those APIs >>>>>> are actually made available. >>>>>> >>>>> >>>>> Who is the consumer of these? A requirer only needs the String names, >>>>> none of the "public static final RuntimeCapability" instances. >>>> >>>> The consumers will be: - >>>> - Various resources in core. >>>> - Subsystems in general. >>>> - Deployments. >>>> >>>> One possible problem I am seeing with only using a String on the >>>> consumer side is that there is no type associated even though the >>>> dependency injection for dynamic capabilities at least is going to >>>> depend on a mutually agreed type. >>> >>> I don't think that really makes a huge difference in this case. There >>> will be a fairly small number of consumers, and type safety in this case >>> is not going to be critical. And really I don't anticipate that type >>> safety would catch any bugs that wouldn't be caught in any event by the >>> simpler string-based system at the same time. >>> >>>>> The different providers of the capability can use the RuntimeCapability >>>>> constants, but I think those should be separated somehow. They are >>>>> really none of the business of the requirers. >>>> >>>> The providers will be: - >>>> - The Elytron Subsystem (Optional) >>>> - Any other subsytem that wants to provide one or more of these >>>> capabilities. >>>> >>>> For separation we could have different classes, different modules or >>>> even some factory class to convert from the name to the >>>> RuntimeCapability instance. >>> >>> Too complex - I think we need to think minimally here. Keep the >>> mechanism as simple as possible. >> >> Which part was too complex? The Factory? >> >> IMO I think go for one new module, 2 classes in this module, 1 class for >> the String constants and 1 class for the statically defined >> RuntimeCapability definitions. > > Having a module for every capability, which is what this implies, is too > complex. We should have zero modules with zero classes and every > consumer can have their own copy of the one string that they need. Many > providers won't even need special classes, so setting this precedent > doesn't really make any sense. > >>>> I think single new module with two classes may be the better compromise >>>> for now otherwise we risk two new modules - each with a single class. > > ^^^ This right here is the warning sign. If we're creating four-class > modules, let alone two- or one-class modules, we've made a wrong turn. > More modules per anything is a massive and unnecessary increase in > complexity and maintenance burden. > >>>> The main point being that WildFly Core is the single common dependency >>>> for everything >>> >>> For the moment. Not forever though. >> >> In what way? Everything is depending on 'controller' as that is where >> the notion of capabilities are defined - are we saying the core of core >> can be split out even further? > > The core of core may not even continue to exist in its current form > beyond WildFly 10 or 11 once we implement the new management code. > >>>>>> The Elytron project could not contain these definitions as that has no >>>>>> dependencies on WildFly, the Elytron Subsystem can not contain this as >>>>>> that is an optional module. >>>>>> >>>>>>> Using constants like in your PR is helpful for later maintenance. If >>>>>>> some constant is deprecated, referrers will see that in their IDE. They >>>>>>> can easily click to read javadoc and learn if the requirement's dynamic >>>>>>> and the service type. >>>>>>> >>>>>>> The biggest concern I have is avoiding premature classloading links. >>>>>>> This is important in the case of optional requirements. If a requirement >>>>>>> is optional, it's critical that the declaration of the requirement in >>>>>>> the code doesn't force loading of classes from the required capability's >>>>>>> module. Otherwise that module is no longer optional and its harder to >>>>>>> create a slim distribution. >>>>>> >>>>>> In this case the only classes being referenced are classes from the >>>>>> Elytron module and that module is going to be mandatory within the >>>>>> server. >>>>>> >>>>> >>>>> Yep. This classloading thing is more of a general concern, not >>>>> particularly relevant to this particular case. People tend to code >>>>> things up by copying existing code though, so it's good to consider the >>>>> general problem before establishing precedents. >>>>> >>>>>> Generally it sounds like 'controller' is a no-go so the format of any >>>>>> constants in code will probably dictate where this lives. >>>>>> >>>>>> If we are only talking Strings I may be able to add it to the >>>>>> 'wildfly-core-security-api' module although javadoc can not reference >>>>>> any capability related classes so that may not be preferable - of I can >>>>>> create a new module with a dependency on controller and everything else >>>>>> that uses Elytron capabilities can then depend on this new artifact / >>>>>> module. >>>>>> >>>>>>> On 5/22/15 5:31 AM, Darran Lofthouse wrote: >>>>>>>> Following on from PR https://github.com/wildfly/wildfly-core/pull/757 >>>>>>>> and my final comment in the PR we need to have a discussion on how we >>>>>>>> coordinate capability and requirement definitions - especially where >>>>>>>> multiple components need a common definition. >>>>>>>> >>>>>>>> The first option is to do it all by convention and have no shared >>>>>>>> constants, the down side of this is we now need to document this and >>>>>>>> keep the document maintained. A document would also make it hard in >>>>>>>> the >>>>>>>> future to flag certain capabilities as deprecated if preferred >>>>>>>> alternatives are made available. >>>>>>>> >>>>>>>> The second option would be to just define the Strings somewhere and use >>>>>>>> Javadoc to specify if the capability is dynamic and it's service type. >>>>>>>> >>>>>>>> The third option is defining the string and RuntimeCapability instances >>>>>>>> in a central place so they can both be referenced as needed. >>>>>>>> >>>>>>>> Any other options? >>>>>>>> >>>>>>>> Where these live will be a second point to discuss but that is heavily >>>>>>>> driven based on what we will share in the first place. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Darran Lofthouse. >>>>>>>> _______________________________________________ >>>>>>>> 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 >> > From ssilvert at redhat.com Tue May 26 16:51:40 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 26 May 2015 16:51:40 -0400 Subject: [wildfly-dev] Reading Mgt Model from a Servlet Message-ID: <5564DCDC.4070405@redhat.com> 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 From jason.greene at redhat.com Tue May 26 17:51:18 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 26 May 2015 16:51:18 -0500 Subject: [wildfly-dev] Reading Mgt Model from a Servlet In-Reply-To: <5564DCDC.4070405@redhat.com> References: <5564DCDC.4070405@redhat.com> Message-ID: 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 ssilvert at redhat.com Tue May 26 18:17:57 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 26 May 2015 18:17:57 -0400 Subject: [wildfly-dev] Reading Mgt Model from a Servlet In-Reply-To: References: <5564DCDC.4070405@redhat.com> Message-ID: <5564F115.3010900@redhat.com> 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 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. >> 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 jlivings at redhat.com Tue May 26 18:44:31 2015 From: jlivings at redhat.com (James Livingston) Date: Wed, 27 May 2015 08:44:31 +1000 Subject: [wildfly-dev] Reading Mgt Model from a Servlet In-Reply-To: References: <5564DCDC.4070405@redhat.com> Message-ID: <1432680271.26385.11.camel@redhat.com> On Tue, 2015-05-26 at 16:51 -0500, Jason Greene wrote: > 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 It is more than just the initialisation path you need to be worried about. I'm not sure what the exact rule is, but it wouldn't surprise me if it is "never block on a management op from any code the container has called". For example using a management op from a servlet service method (e.g. doPost) is dangerous because there may be an op in progress that is waiting for all servlet processing to finish before it does it's work. -- James "Doc" Livingston JBoss Support Engineering Group From junior.jairo1 at gmail.com Wed May 27 13:54:38 2015 From: junior.jairo1 at gmail.com (Jairo Junior) Date: Wed, 27 May 2015 17:54:38 +0000 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands Message-ID: I've been working on a Puppet Module for Wildfly [1] that uses his HTTP Management API to perform operations (manage resources/deploys and execute commands), but my command execution code is a little bit limited cause I have to transform from CLI syntax to JSON. e.g.: :shutdown(restart=true) becomes {"operation" : "shutdown", "restart" : "true" } Is there any specific reason to not support plain CLI commands through HTTP API? I looked at the code and it didn't see hard to implement this... [1] https://github.com/biemond/biemond-wildfly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150527/417225af/attachment.html From hbraun at redhat.com Thu May 28 04:56:33 2015 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 28 May 2015 10:56:33 +0200 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: Message-ID: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> You can already use DMR over HTTP. It requires a different content-type ('application/dmr-encoded') and uses a base64 encoded representation of the payload ('ModelNode.toBase64String()'). You can describe an operation through the DMR API and then simply do HTTP POST to ?/management? endpoint. make sure to use 'application/dmr-encoded? for both 'Content-Type' and ?Accept? headers. The response can be parse using 'ModelNode.fromBase64()'. Hope this helps, Heiko > On 27 May 2015, at 19:54, Jairo Junior wrote: > > I've been working on a Puppet Module for Wildfly [1] that uses his HTTP Management API to perform operations (manage resources/deploys and execute commands), but my command execution code is a little bit limited cause I have to transform from CLI syntax to JSON. e.g.: > > :shutdown(restart=true) > > becomes > > {"operation" : "shutdown", "restart" : "true" } > > Is there any specific reason to not support plain CLI commands through HTTP API? I looked at the code and it didn't see hard to implement this... > > [1] https://github.com/biemond/biemond-wildfly > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From hbraun at redhat.com Thu May 28 04:58:50 2015 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 28 May 2015 10:58:50 +0200 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> Message-ID: The DMR library can be found here: https://github.com/jbossas/jboss-dmr > On 28 May 2015, at 10:56, Heiko Braun wrote: > > > You can already use DMR over HTTP. It requires a different content-type ('application/dmr-encoded') and uses a base64 encoded representation of the payload ('ModelNode.toBase64String()'). > > You can describe an operation through the DMR API and then simply do HTTP POST to ?/management? endpoint. make sure to use 'application/dmr-encoded? for both 'Content-Type' and ?Accept? headers. > > The response can be parse using 'ModelNode.fromBase64()'. > > Hope this helps, > Heiko > > > >> On 27 May 2015, at 19:54, Jairo Junior wrote: >> >> I've been working on a Puppet Module for Wildfly [1] that uses his HTTP Management API to perform operations (manage resources/deploys and execute commands), but my command execution code is a little bit limited cause I have to transform from CLI syntax to JSON. e.g.: >> >> :shutdown(restart=true) >> >> becomes >> >> {"operation" : "shutdown", "restart" : "true" } >> >> Is there any specific reason to not support plain CLI commands through HTTP API? I looked at the code and it didn't see hard to implement this... >> >> [1] https://github.com/biemond/biemond-wildfly >> >> _______________________________________________ >> 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/20150528/7a6a9330/attachment.html From sanne at hibernate.org Thu May 28 06:30:37 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 May 2015 11:30:37 +0100 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <555E2D93.3000700@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> Message-ID: Could someone explain please, why it's hard to have a deployer just use a different JPA implementor which the user might want to provide? I'm pretty sure I know how to start a JPA context in plain JavaSE, and don't need to know which implementor version I'm going to use, other than for sake of configuration. The WildFly documentation mentions this property "jboss.as.jpa.providerModule", which sounds great on paper and it would be a nice usability improvement if it would also actually work as it suggests. There's plenty of evidence on StackOverflow that the current limitations are unexpected. For example, Spring moved to Hibernate 5 and people won't be able to use your stable line of the application server with Spring; I'd hope we could implement a plan to prevent this from happening at the next upgrade cycles. Thanks, Sanne On 21 May 2015 at 20:10, Scott Marlow wrote: > > > On 05/21/2015 03:05 PM, Toma? Cerar wrote: >> Scott, >> >> if you do one last jipijapa release that adds "support" for hibernate5 >> hibernate guys could take that version and override it in wildfly 9 same >> way as they add new h5 modules. > > I assume this will be an iterative process but sure, we could also push > a release of the JIPI-31 branch. Lets keep talking about what is needed... > >> >> -- >> tomaz >> >> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow > > wrote: >> >> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >> > Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >> >> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >> integration code that we will look at merging into WildFly 10. Are you >> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >> (doesn't seem as likely to me but I don't control the schedule)? >> >> > >> > It would help speed up the Hibernate 5 stream adoption and avoid >> a lot of duplicated work for 6+ months. >> > >> >> On 21 mai 2015, at 16:36, Scott Marlow > > wrote: >> >> >> >> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >> this soon >> >> for WildFly 10. >> >> >> >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >> >>> Hi all, >> >>> I'm attempting to deploy some integration tests on WildFly >> 9.0.0.CR1 >> >>> to use a preview of Hibernate ORM version 5. >> >>> >> >>> It seems the JPA deployer isn't allowing me to run such >> experiments: >> >>> >> >>> # First experiment - providerModule set to custom module >> >>> >> >>> In my first attempt, I create a custom set of jboss modules which >> >>> include the snapshot builds of ORM 5, add them to my standalone WF9 >> >>> instance and set the persistence.xml property: >> >>> jboss.as.jpa.providerModule = my-custom-module-name >> >>> >> >>> and then get: >> >>> >> >>> Caused by: java.util.ServiceConfigurationError: >> >>> org.hibernate.integrator.spi.Integrator: Provider >> >>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >> >>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >> [rt.jar:1.7.0_51] >> >>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >> [rt.jar:1.7.0_51] >> >>> at >> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >> >>> [rt.jar:1.7.0_51] >> >>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >> [rt.jar:1.7.0_51] >> >>> at >> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >> >>> at >> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >> >>> at >> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >> >>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >> >>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >> >>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >> >>> at >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >> >>> at >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >> >>> at >> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >> >>> at >> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >> >>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >> >>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >> >>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >> >>> ... 7 more >> >>> >> >>> Clearly it looks like I'm being served classes from the bundled >> >>> Hibernate 4.x implementation - on top of those from the module I'm >> >>> requesting. This isn't what the deployer should be doing, right? >> >>> >> >>> # Second experiment - use the "application provided" >> >>> >> >>> In this case I hope to hint the JPA deployer to not add the >> default >> >>> implementor but look for a JPA implementation within my deployment, >> >>> but still package my custom Hibernate build as a module. >> >>> >> >>> - use the same custom module containing Hibernate ORM 5 (a >> preview snapshot) >> >>> - Add a "Dependency:" section to the manifest to import (and >> export) >> >>> my custom module >> >>> - set the "jboss.as.jpa.providerModule" property to value >> "application" >> >>> >> >>> This gets me: >> >>> >> >>> Caused by: >> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >> >>> WFLYJPA0027: Persistence provider module load error application >> (class >> >>> org.hibernate.jpa.HibernatePersistenceProvider) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >> >>> at >> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >> >>> at >> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >> >>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >> >>> ... 5 more >> >>> Caused by: org.jboss.modules.ModuleNotFoundException: >> application:main >> >>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >> >>> [jboss-modules.jar:1.4.3.Final] >> >>> at >> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >> >>> ... 10 more >> >>> >> >>> Remarks: >> >>> - it's attempting to load the "application:main" module?! >> that's not >> >>> what I'd expect from reading [1] >> >> >> >> This seems to be a bug. I hit it a few days ago when I packaged >> >> Hibernate ORM 4.1.x with an application (in a unit test) and >> forgot to >> >> set the persistence provider in persistence.xml. >> >> >> >>> - the provider should be available to the deployment >> classpath, so >> >>> I'm not sure why it's not finding the Provider? (I'm even exporting >> >>> it, although I'm not sure if that was required). >> >> >> >> Providers are always found through the >> >> javax.persistence.spi.PersistenceProviderResolver, not directly >> from the >> >> deployment classpath. >> >> >> >>> >> >>> Any suggestions to get this running please? >> >>> >> >>> Also I wonder if some of these should warrant opening a JIRA, >> but I'm >> >>> not sure how far I misunderstood the intentions of these JPA >> deployer >> >>> properties. >> >> >> >> Lets talk in a few days again on IRC. >> >> >> >>> >> >>> Thanks, >> >>> Sanne >> >>> >> >>> [1] - >> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >> >> _______________________________________________ >> >> 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 From tomaz.cerar at gmail.com Thu May 28 06:37:21 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 28 May 2015 12:37:21 +0200 Subject: [wildfly-dev] Reading Mgt Model from a Servlet In-Reply-To: <5564F115.3010900@redhat.com> References: <5564DCDC.4070405@redhat.com> <5564F115.3010900@redhat.com> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150528/9029a0a3/attachment.html From jason.greene at redhat.com Thu May 28 10:18:37 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 28 May 2015 09:18:37 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> Message-ID: We implement the standard JPA integration SPI, but it is absolutely awful. It forces: - The construction of duplicate class loaders with duplicate class definitions of every class in the deployment - Repeated runs of the deployment process - Double loading of any class related to JPA (and its dependencies) - The JPA provider to use reflection for all annotation discovery - Double use of reflection in the deployment process - Bugs from chicken and egg problems - Increased memory usage So for this reason WildFly and Hibernate have their own integration SPIs, and those SPIs are changing in hibernate 5. So WildFly (well currently JIPPAJAPPA) needs an update to be compatible with them. Additionally we have the Jandex 2 change which is pending that both projects are attempting to align on. Now what I am not sure about, Scott will have to answer this. Is if you can use the standard JPA integration SPI with newer versions of Hibernate and just live with the nastiness it brings. However, there is still a secondary issue, which I am sure you already know about is that the second level cache and hibernate search have integrations that need to be compatible and in sync and tested. > On May 28, 2015, at 5:30 AM, Sanne Grinovero wrote: > > Could someone explain please, why it's hard to have a deployer just > use a different JPA implementor which the user might want to provide? > > I'm pretty sure I know how to start a JPA context in plain JavaSE, and > don't need to know which implementor version I'm going to use, other > than for sake of configuration. > > The WildFly documentation mentions this property > "jboss.as.jpa.providerModule", which sounds great on paper and it > would be a nice usability improvement if it would also actually work > as it suggests. > > There's plenty of evidence on StackOverflow that the current > limitations are unexpected. For example, Spring moved to Hibernate 5 > and people won't be able to use your stable line of the application > server with Spring; I'd hope we could implement a plan to prevent this > from happening at the next upgrade cycles. > > Thanks, > Sanne > > On 21 May 2015 at 20:10, Scott Marlow wrote: >> >> >> On 05/21/2015 03:05 PM, Toma? Cerar wrote: >>> Scott, >>> >>> if you do one last jipijapa release that adds "support" for hibernate5 >>> hibernate guys could take that version and override it in wildfly 9 same >>> way as they add new h5 modules. >> >> I assume this will be an iterative process but sure, we could also push >> a release of the JIPI-31 branch. Lets keep talking about what is needed... >> >>> >>> -- >>> tomaz >>> >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >> > wrote: >>> >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >>>> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >>> >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >>> integration code that we will look at merging into WildFly 10. Are you >>> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >>> (doesn't seem as likely to me but I don't control the schedule)? >>> >>>> >>>> It would help speed up the Hibernate 5 stream adoption and avoid >>> a lot of duplicated work for 6+ months. >>>> >>>>> On 21 mai 2015, at 16:36, Scott Marlow >> > wrote: >>>>> >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >>> this soon >>>>> for WildFly 10. >>>>> >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>>>> Hi all, >>>>>> I'm attempting to deploy some integration tests on WildFly >>> 9.0.0.CR1 >>>>>> to use a preview of Hibernate ORM version 5. >>>>>> >>>>>> It seems the JPA deployer isn't allowing me to run such >>> experiments: >>>>>> >>>>>> # First experiment - providerModule set to custom module >>>>>> >>>>>> In my first attempt, I create a custom set of jboss modules which >>>>>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>>>>> instance and set the persistence.xml property: >>>>>> jboss.as.jpa.providerModule = my-custom-module-name >>>>>> >>>>>> and then get: >>>>>> >>>>>> Caused by: java.util.ServiceConfigurationError: >>>>>> org.hibernate.integrator.spi.Integrator: Provider >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >>> [rt.jar:1.7.0_51] >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >>> [rt.jar:1.7.0_51] >>>>>> at >>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>>>> [rt.jar:1.7.0_51] >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >>> [rt.jar:1.7.0_51] >>>>>> at >>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>>>> at >>> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >>>>>> at >>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>>>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>>>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >>>>>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >>>>>> at >>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>>>> at >>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>>>> at >>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >>>>>> at >>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>>>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>>>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>>>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>>>> ... 7 more >>>>>> >>>>>> Clearly it looks like I'm being served classes from the bundled >>>>>> Hibernate 4.x implementation - on top of those from the module I'm >>>>>> requesting. This isn't what the deployer should be doing, right? >>>>>> >>>>>> # Second experiment - use the "application provided" >>>>>> >>>>>> In this case I hope to hint the JPA deployer to not add the >>> default >>>>>> implementor but look for a JPA implementation within my deployment, >>>>>> but still package my custom Hibernate build as a module. >>>>>> >>>>>> - use the same custom module containing Hibernate ORM 5 (a >>> preview snapshot) >>>>>> - Add a "Dependency:" section to the manifest to import (and >>> export) >>>>>> my custom module >>>>>> - set the "jboss.as.jpa.providerModule" property to value >>> "application" >>>>>> >>>>>> This gets me: >>>>>> >>>>>> Caused by: >>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>>>> WFLYJPA0027: Persistence provider module load error application >>> (class >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>>>> at >>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>>>> ... 5 more >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >>> application:main >>>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>>>> [jboss-modules.jar:1.4.3.Final] >>>>>> at >>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>>>> ... 10 more >>>>>> >>>>>> Remarks: >>>>>> - it's attempting to load the "application:main" module?! >>> that's not >>>>>> what I'd expect from reading [1] >>>>> >>>>> This seems to be a bug. I hit it a few days ago when I packaged >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and >>> forgot to >>>>> set the persistence provider in persistence.xml. >>>>> >>>>>> - the provider should be available to the deployment >>> classpath, so >>>>>> I'm not sure why it's not finding the Provider? (I'm even exporting >>>>>> it, although I'm not sure if that was required). >>>>> >>>>> Providers are always found through the >>>>> javax.persistence.spi.PersistenceProviderResolver, not directly >>> from the >>>>> deployment classpath. >>>>> >>>>>> >>>>>> Any suggestions to get this running please? >>>>>> >>>>>> Also I wonder if some of these should warrant opening a JIRA, >>> but I'm >>>>>> not sure how far I misunderstood the intentions of these JPA >>> deployer >>>>>> properties. >>>>> >>>>> Lets talk in a few days again on IRC. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sanne >>>>>> >>>>>> [1] - >>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > 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 steve at hibernate.org Thu May 28 10:29:51 2015 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 May 2015 09:29:51 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> Message-ID: I am just not sure a lot of this is true. What EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA bootstrap SPI) contracts changed in 5.0? As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, but we currently do not use it. So that actually should also not cause any issues in regards to Hibernate 4.x or 5.0 As far as using the standard JPA bootstrap SPIs, I agree this is up to Scott. But it simply will not work for the way WildFly does stuff as I understand it. Second-level cache, yes, is a whole other ball of wax :) On Thu, May 28, 2015 at 9:18 AM, Jason Greene wrote: > We implement the standard JPA integration SPI, but it is absolutely awful. > > It forces: > > - The construction of duplicate class loaders with duplicate class > definitions of every class in the deployment > - Repeated runs of the deployment process > - Double loading of any class related to JPA (and its dependencies) > - The JPA provider to use reflection for all annotation discovery > - Double use of reflection in the deployment process > - Bugs from chicken and egg problems > - Increased memory usage > > So for this reason WildFly and Hibernate have their own integration SPIs, > and those SPIs are changing in hibernate 5. So WildFly (well currently > JIPPAJAPPA) needs an update to be compatible with them. Additionally we > have the Jandex 2 change which is pending that both projects are attempting > to align on. > > Now what I am not sure about, Scott will have to answer this. Is if you > can use the standard JPA integration SPI with newer versions of Hibernate > and just live with the nastiness it brings. > > However, there is still a secondary issue, which I am sure you already > know about is that the second level cache and hibernate search have > integrations that need to be compatible and in sync and tested. > > > On May 28, 2015, at 5:30 AM, Sanne Grinovero > wrote: > > > > Could someone explain please, why it's hard to have a deployer just > > use a different JPA implementor which the user might want to provide? > > > > I'm pretty sure I know how to start a JPA context in plain JavaSE, and > > don't need to know which implementor version I'm going to use, other > > than for sake of configuration. > > > > The WildFly documentation mentions this property > > "jboss.as.jpa.providerModule", which sounds great on paper and it > > would be a nice usability improvement if it would also actually work > > as it suggests. > > > > There's plenty of evidence on StackOverflow that the current > > limitations are unexpected. For example, Spring moved to Hibernate 5 > > and people won't be able to use your stable line of the application > > server with Spring; I'd hope we could implement a plan to prevent this > > from happening at the next upgrade cycles. > > > > Thanks, > > Sanne > > > > On 21 May 2015 at 20:10, Scott Marlow wrote: > >> > >> > >> On 05/21/2015 03:05 PM, Toma? Cerar wrote: > >>> Scott, > >>> > >>> if you do one last jipijapa release that adds "support" for hibernate5 > >>> hibernate guys could take that version and override it in wildfly 9 > same > >>> way as they add new h5 modules. > >> > >> I assume this will be an iterative process but sure, we could also push > >> a release of the JIPI-31 branch. Lets keep talking about what is > needed... > >> > >>> > >>> -- > >>> tomaz > >>> > >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >>> > wrote: > >>> > >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > >>>> Scott, No way to make ORM 5 work in 9 at all? With the user setting > the additional slotted modules of course. > >>> > >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the > >>> integration code that we will look at merging into WildFly 10. Are > you > >>> looking for a custom WildFly 9.x branch or actual changes in > WildFly 9 > >>> (doesn't seem as likely to me but I don't control the schedule)? > >>> > >>>> > >>>> It would help speed up the Hibernate 5 stream adoption and avoid > >>> a lot of duplicated work for 6+ months. > >>>> > >>>>> On 21 mai 2015, at 16:36, Scott Marlow >>> > wrote: > >>>>> > >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on > >>> this soon > >>>>> for WildFly 10. > >>>>> > >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >>>>>> Hi all, > >>>>>> I'm attempting to deploy some integration tests on WildFly > >>> 9.0.0.CR1 > >>>>>> to use a preview of Hibernate ORM version 5. > >>>>>> > >>>>>> It seems the JPA deployer isn't allowing me to run such > >>> experiments: > >>>>>> > >>>>>> # First experiment - providerModule set to custom module > >>>>>> > >>>>>> In my first attempt, I create a custom set of jboss modules which > >>>>>> include the snapshot builds of ORM 5, add them to my standalone WF9 > >>>>>> instance and set the persistence.xml property: > >>>>>> jboss.as.jpa.providerModule = my-custom-module-name > >>>>>> > >>>>>> and then get: > >>>>>> > >>>>>> Caused by: java.util.ServiceConfigurationError: > >>>>>> org.hibernate.integrator.spi.Integrator: Provider > >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype > >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > >>> [rt.jar:1.7.0_51] > >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) > >>> [rt.jar:1.7.0_51] > >>>>>> at > >>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >>>>>> [rt.jar:1.7.0_51] > >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > >>> [rt.jar:1.7.0_51] > >>>>>> at > >>> > org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >>>>>> at > >>> > org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > >>>>>> at > >>> > org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > >>>>>> at > >>> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >>>>>> at > >>> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >>>>>> at > >>> > org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > >>>>>> at > >>> > org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >>>>>> ... 7 more > >>>>>> > >>>>>> Clearly it looks like I'm being served classes from the bundled > >>>>>> Hibernate 4.x implementation - on top of those from the module I'm > >>>>>> requesting. This isn't what the deployer should be doing, right? > >>>>>> > >>>>>> # Second experiment - use the "application provided" > >>>>>> > >>>>>> In this case I hope to hint the JPA deployer to not add the > >>> default > >>>>>> implementor but look for a JPA implementation within my deployment, > >>>>>> but still package my custom Hibernate build as a module. > >>>>>> > >>>>>> - use the same custom module containing Hibernate ORM 5 (a > >>> preview snapshot) > >>>>>> - Add a "Dependency:" section to the manifest to import (and > >>> export) > >>>>>> my custom module > >>>>>> - set the "jboss.as.jpa.providerModule" property to value > >>> "application" > >>>>>> > >>>>>> This gets me: > >>>>>> > >>>>>> Caused by: > >>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >>>>>> WFLYJPA0027: Persistence provider module load error application > >>> (class > >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >>>>>> at > >>> > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >>>>>> ... 5 more > >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: > >>> application:main > >>>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >>>>>> [jboss-modules.jar:1.4.3.Final] > >>>>>> at > >>> > org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >>>>>> ... 10 more > >>>>>> > >>>>>> Remarks: > >>>>>> - it's attempting to load the "application:main" module?! > >>> that's not > >>>>>> what I'd expect from reading [1] > >>>>> > >>>>> This seems to be a bug. I hit it a few days ago when I packaged > >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and > >>> forgot to > >>>>> set the persistence provider in persistence.xml. > >>>>> > >>>>>> - the provider should be available to the deployment > >>> classpath, so > >>>>>> I'm not sure why it's not finding the Provider? (I'm even exporting > >>>>>> it, although I'm not sure if that was required). > >>>>> > >>>>> Providers are always found through the > >>>>> javax.persistence.spi.PersistenceProviderResolver, not directly > >>> from the > >>>>> deployment classpath. > >>>>> > >>>>>> > >>>>>> Any suggestions to get this running please? > >>>>>> > >>>>>> Also I wonder if some of these should warrant opening a JIRA, > >>> but I'm > >>>>>> not sure how far I misunderstood the intentions of these JPA > >>> deployer > >>>>>> properties. > >>>>> > >>>>> Lets talk in a few days again on IRC. > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Sanne > >>>>>> > >>>>>> [1] - > >>> > https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > >>>>> _______________________________________________ > >>>>> 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 > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150528/a64d95ef/attachment-0001.html From smarlow at redhat.com Thu May 28 10:56:13 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 28 May 2015 10:56:13 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> Message-ID: <55672C8D.4060907@redhat.com> On 05/28/2015 06:30 AM, Sanne Grinovero wrote: > Could someone explain please, why it's hard to have a deployer just > use a different JPA implementor which the user might want to provide? If you mean Hibernate 5.x specifically, we started the integration on https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 > > I'm pretty sure I know how to start a JPA context in plain JavaSE, and > don't need to know which implementor version I'm going to use, other > than for sake of configuration. > > The WildFly documentation mentions this property > "jboss.as.jpa.providerModule", which sounds great on paper and it > would be a nice usability improvement if it would also actually work > as it suggests. You are complaining a lot lately. We purposely designed for known use cases. There are other ways to get the dynamic environment that you are looking for then complaining that the WildFly JPA subsystem "jboss.as.jpa.providerModule" option doesn't work. > > There's plenty of evidence on StackOverflow that the current > limitations are unexpected. For example, Spring moved to Hibernate 5 > and people won't be able to use your stable line of the application > server with Spring; I'd hope we could implement a plan to prevent this > from happening at the next upgrade cycles. The question is whether the Hibernate 5.0 release schedule can align with the WildFly 10 schedule, so that we can do the work. > > Thanks, > Sanne > > On 21 May 2015 at 20:10, Scott Marlow wrote: >> >> >> On 05/21/2015 03:05 PM, Toma? Cerar wrote: >>> Scott, >>> >>> if you do one last jipijapa release that adds "support" for hibernate5 >>> hibernate guys could take that version and override it in wildfly 9 same >>> way as they add new h5 modules. >> >> I assume this will be an iterative process but sure, we could also push >> a release of the JIPI-31 branch. Lets keep talking about what is needed... >> >>> >>> -- >>> tomaz >>> >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >> > wrote: >>> >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >>> > Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >>> >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >>> integration code that we will look at merging into WildFly 10. Are you >>> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >>> (doesn't seem as likely to me but I don't control the schedule)? >>> >>> > >>> > It would help speed up the Hibernate 5 stream adoption and avoid >>> a lot of duplicated work for 6+ months. >>> > >>> >> On 21 mai 2015, at 16:36, Scott Marlow >> > wrote: >>> >> >>> >> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >>> this soon >>> >> for WildFly 10. >>> >> >>> >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>> >>> Hi all, >>> >>> I'm attempting to deploy some integration tests on WildFly >>> 9.0.0.CR1 >>> >>> to use a preview of Hibernate ORM version 5. >>> >>> >>> >>> It seems the JPA deployer isn't allowing me to run such >>> experiments: >>> >>> >>> >>> # First experiment - providerModule set to custom module >>> >>> >>> >>> In my first attempt, I create a custom set of jboss modules which >>> >>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>> >>> instance and set the persistence.xml property: >>> >>> jboss.as.jpa.providerModule = my-custom-module-name >>> >>> >>> >>> and then get: >>> >>> >>> >>> Caused by: java.util.ServiceConfigurationError: >>> >>> org.hibernate.integrator.spi.Integrator: Provider >>> >>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>> >>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >>> [rt.jar:1.7.0_51] >>> >>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >>> [rt.jar:1.7.0_51] >>> >>> at >>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>> >>> [rt.jar:1.7.0_51] >>> >>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >>> [rt.jar:1.7.0_51] >>> >>> at >>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>> >>> at >>> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >>> >>> at >>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>> >>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>> >>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >>> >>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >>> >>> at >>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>> >>> at >>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>> >>> at >>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >>> >>> at >>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>> >>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>> >>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>> >>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>> >>> ... 7 more >>> >>> >>> >>> Clearly it looks like I'm being served classes from the bundled >>> >>> Hibernate 4.x implementation - on top of those from the module I'm >>> >>> requesting. This isn't what the deployer should be doing, right? >>> >>> >>> >>> # Second experiment - use the "application provided" >>> >>> >>> >>> In this case I hope to hint the JPA deployer to not add the >>> default >>> >>> implementor but look for a JPA implementation within my deployment, >>> >>> but still package my custom Hibernate build as a module. >>> >>> >>> >>> - use the same custom module containing Hibernate ORM 5 (a >>> preview snapshot) >>> >>> - Add a "Dependency:" section to the manifest to import (and >>> export) >>> >>> my custom module >>> >>> - set the "jboss.as.jpa.providerModule" property to value >>> "application" >>> >>> >>> >>> This gets me: >>> >>> >>> >>> Caused by: >>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>> >>> WFLYJPA0027: Persistence provider module load error application >>> (class >>> >>> org.hibernate.jpa.HibernatePersistenceProvider) >>> >>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>> >>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>> >>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>> >>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>> >>> at >>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>> >>> at >>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>> >>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>> >>> ... 5 more >>> >>> Caused by: org.jboss.modules.ModuleNotFoundException: >>> application:main >>> >>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>> >>> [jboss-modules.jar:1.4.3.Final] >>> >>> at >>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>> >>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>> >>> ... 10 more >>> >>> >>> >>> Remarks: >>> >>> - it's attempting to load the "application:main" module?! >>> that's not >>> >>> what I'd expect from reading [1] >>> >> >>> >> This seems to be a bug. I hit it a few days ago when I packaged >>> >> Hibernate ORM 4.1.x with an application (in a unit test) and >>> forgot to >>> >> set the persistence provider in persistence.xml. >>> >> >>> >>> - the provider should be available to the deployment >>> classpath, so >>> >>> I'm not sure why it's not finding the Provider? (I'm even exporting >>> >>> it, although I'm not sure if that was required). >>> >> >>> >> Providers are always found through the >>> >> javax.persistence.spi.PersistenceProviderResolver, not directly >>> from the >>> >> deployment classpath. >>> >> >>> >>> >>> >>> Any suggestions to get this running please? >>> >>> >>> >>> Also I wonder if some of these should warrant opening a JIRA, >>> but I'm >>> >>> not sure how far I misunderstood the intentions of these JPA >>> deployer >>> >>> properties. >>> >> >>> >> Lets talk in a few days again on IRC. >>> >> >>> >>> >>> >>> Thanks, >>> >>> Sanne >>> >>> >>> >>> [1] - >>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >>> >> _______________________________________________ >>> >> 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 > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Thu May 28 10:56:19 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 28 May 2015 09:56:19 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> Message-ID: <70A7F8E2-539A-48A8-9ABD-587C188877D7@redhat.com> I don?t know all of the details on required changes (Scott will have to comment on those), but I do see lots of them in his integration branch for 5: https://github.com/scottmarlow/jipijapa/commits/JIPI-31 A quick glance shows at least a package rename: https://github.com/scottmarlow/jipijapa/commit/0a6a13532949bbe742b20eb47a318718ffc1d1e3 Regarding Jandex 2, I wasn?t explicitly referring 5, only that its in the works, My point was answering the question of why you can?t just slap any ol version of Hibernate into WildFly with no effort. We do integration collaboration on both sides to have a decent working container (as other vendors do). The JPA SPI works for other integrations and it is tested by the TCK so it should be possible, it will just have the issues I iterated below. > On May 28, 2015, at 9:29 AM, Steve Ebersole wrote: > > I am just not sure a lot of this is true. What EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA bootstrap SPI) contracts changed in 5.0? > > As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, but we currently do not use it. So that actually should also not cause any issues in regards to Hibernate 4.x or 5.0 > > As far as using the standard JPA bootstrap SPIs, I agree this is up to Scott. But it simply will not work for the way WildFly does stuff as I understand it. > > Second-level cache, yes, is a whole other ball of wax :) > > > On Thu, May 28, 2015 at 9:18 AM, Jason Greene > wrote: > We implement the standard JPA integration SPI, but it is absolutely awful. > > It forces: > > - The construction of duplicate class loaders with duplicate class definitions of every class in the deployment > - Repeated runs of the deployment process > - Double loading of any class related to JPA (and its dependencies) > - The JPA provider to use reflection for all annotation discovery > - Double use of reflection in the deployment process > - Bugs from chicken and egg problems > - Increased memory usage > > So for this reason WildFly and Hibernate have their own integration SPIs, and those SPIs are changing in hibernate 5. So WildFly (well currently JIPPAJAPPA) needs an update to be compatible with them. Additionally we have the Jandex 2 change which is pending that both projects are attempting to align on. > > Now what I am not sure about, Scott will have to answer this. Is if you can use the standard JPA integration SPI with newer versions of Hibernate and just live with the nastiness it brings. > > However, there is still a secondary issue, which I am sure you already know about is that the second level cache and hibernate search have integrations that need to be compatible and in sync and tested. > > > On May 28, 2015, at 5:30 AM, Sanne Grinovero > wrote: > > > > Could someone explain please, why it's hard to have a deployer just > > use a different JPA implementor which the user might want to provide? > > > > I'm pretty sure I know how to start a JPA context in plain JavaSE, and > > don't need to know which implementor version I'm going to use, other > > than for sake of configuration. > > > > The WildFly documentation mentions this property > > "jboss.as.jpa.providerModule", which sounds great on paper and it > > would be a nice usability improvement if it would also actually work > > as it suggests. > > > > There's plenty of evidence on StackOverflow that the current > > limitations are unexpected. For example, Spring moved to Hibernate 5 > > and people won't be able to use your stable line of the application > > server with Spring; I'd hope we could implement a plan to prevent this > > from happening at the next upgrade cycles. > > > > Thanks, > > Sanne > > > > On 21 May 2015 at 20:10, Scott Marlow > wrote: > >> > >> > >> On 05/21/2015 03:05 PM, Toma? Cerar wrote: > >>> Scott, > >>> > >>> if you do one last jipijapa release that adds "support" for hibernate5 > >>> hibernate guys could take that version and override it in wildfly 9 same > >>> way as they add new h5 modules. > >> > >> I assume this will be an iterative process but sure, we could also push > >> a release of the JIPI-31 branch. Lets keep talking about what is needed... > >> > >>> > >>> -- > >>> tomaz > >>> > >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow > >>> >> wrote: > >>> > >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > >>>> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. > >>> > >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the > >>> integration code that we will look at merging into WildFly 10. Are you > >>> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 > >>> (doesn't seem as likely to me but I don't control the schedule)? > >>> > >>>> > >>>> It would help speed up the Hibernate 5 stream adoption and avoid > >>> a lot of duplicated work for 6+ months. > >>>> > >>>>> On 21 mai 2015, at 16:36, Scott Marlow > >>> >> wrote: > >>>>> > >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on > >>> this soon > >>>>> for WildFly 10. > >>>>> > >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >>>>>> Hi all, > >>>>>> I'm attempting to deploy some integration tests on WildFly > >>> 9.0.0.CR1 > >>>>>> to use a preview of Hibernate ORM version 5. > >>>>>> > >>>>>> It seems the JPA deployer isn't allowing me to run such > >>> experiments: > >>>>>> > >>>>>> # First experiment - providerModule set to custom module > >>>>>> > >>>>>> In my first attempt, I create a custom set of jboss modules which > >>>>>> include the snapshot builds of ORM 5, add them to my standalone WF9 > >>>>>> instance and set the persistence.xml property: > >>>>>> jboss.as.jpa.providerModule = my-custom-module-name > >>>>>> > >>>>>> and then get: > >>>>>> > >>>>>> Caused by: java.util.ServiceConfigurationError: > >>>>>> org.hibernate.integrator.spi.Integrator: Provider > >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype > >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > >>> [rt.jar:1.7.0_51] > >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) > >>> [rt.jar:1.7.0_51] > >>>>>> at > >>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >>>>>> [rt.jar:1.7.0_51] > >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > >>> [rt.jar:1.7.0_51] > >>>>>> at > >>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >>>>>> at > >>> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > >>>>>> at > >>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >>>>>> at > >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >>>>>> at > >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > >>>>>> at > >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > >>>>>> at > >>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >>>>>> at > >>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >>>>>> at > >>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > >>>>>> at > >>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >>>>>> at > >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >>>>>> at > >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >>>>>> at > >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >>>>>> ... 7 more > >>>>>> > >>>>>> Clearly it looks like I'm being served classes from the bundled > >>>>>> Hibernate 4.x implementation - on top of those from the module I'm > >>>>>> requesting. This isn't what the deployer should be doing, right? > >>>>>> > >>>>>> # Second experiment - use the "application provided" > >>>>>> > >>>>>> In this case I hope to hint the JPA deployer to not add the > >>> default > >>>>>> implementor but look for a JPA implementation within my deployment, > >>>>>> but still package my custom Hibernate build as a module. > >>>>>> > >>>>>> - use the same custom module containing Hibernate ORM 5 (a > >>> preview snapshot) > >>>>>> - Add a "Dependency:" section to the manifest to import (and > >>> export) > >>>>>> my custom module > >>>>>> - set the "jboss.as.jpa.providerModule" property to value > >>> "application" > >>>>>> > >>>>>> This gets me: > >>>>>> > >>>>>> Caused by: > >>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >>>>>> WFLYJPA0027: Persistence provider module load error application > >>> (class > >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) > >>>>>> at > >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >>>>>> at > >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >>>>>> at > >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >>>>>> at > >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >>>>>> at > >>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >>>>>> at > >>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >>>>>> ... 5 more > >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: > >>> application:main > >>>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >>>>>> [jboss-modules.jar:1.4.3.Final] > >>>>>> at > >>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >>>>>> at > >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >>>>>> ... 10 more > >>>>>> > >>>>>> Remarks: > >>>>>> - it's attempting to load the "application:main" module?! > >>> that's not > >>>>>> what I'd expect from reading [1] > >>>>> > >>>>> This seems to be a bug. I hit it a few days ago when I packaged > >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and > >>> forgot to > >>>>> set the persistence provider in persistence.xml. > >>>>> > >>>>>> - the provider should be available to the deployment > >>> classpath, so > >>>>>> I'm not sure why it's not finding the Provider? (I'm even exporting > >>>>>> it, although I'm not sure if that was required). > >>>>> > >>>>> Providers are always found through the > >>>>> javax.persistence.spi.PersistenceProviderResolver, not directly > >>> from the > >>>>> deployment classpath. > >>>>> > >>>>>> > >>>>>> Any suggestions to get this running please? > >>>>>> > >>>>>> Also I wonder if some of these should warrant opening a JIRA, > >>> but I'm > >>>>>> not sure how far I misunderstood the intentions of these JPA > >>> deployer > >>>>>> properties. > >>>>> > >>>>> Lets talk in a few days again on IRC. > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Sanne > >>>>>> > >>>>>> [1] - > >>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > >>>>> _______________________________________________ > >>>>> 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 > > > > _______________________________________________ > > 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 -- 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/20150528/236a7708/attachment-0001.html From smarlow at redhat.com Thu May 28 11:26:02 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 28 May 2015 11:26:02 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> Message-ID: <5567338A.1090402@redhat.com> On 05/28/2015 10:18 AM, Jason Greene wrote: > We implement the standard JPA integration SPI, but it is absolutely awful. > > It forces: > > - The construction of duplicate class loaders with duplicate class definitions of every class in the deployment > - Repeated runs of the deployment process > - Double loading of any class related to JPA (and its dependencies) > - The JPA provider to use reflection for all annotation discovery > - Double use of reflection in the deployment process > - Bugs from chicken and egg problems > - Increased memory usage > > So for this reason WildFly and Hibernate have their own integration SPIs, and those SPIs are changing in hibernate 5. So WildFly (well currently JIPPAJAPPA) needs an update to be compatible with them. Additionally we have the Jandex 2 change which is pending that both projects are attempting to align on. > > Now what I am not sure about, Scott will have to answer this. Is if you can use the standard JPA integration SPI with newer versions of Hibernate and just live with the nastiness it brings. https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 contains some of the changes. There aren't extensive changes (from Hibernate 4.3.x), just minor so far. > > However, there is still a secondary issue, which I am sure you already know about is that the second level cache and hibernate search have integrations that need to be compatible and in sync and tested. One issue for the Hibernate projects like Search, is that they need Hibernate 5 to be included in WildFly, so they can start integrating with Hibernate 5 (with the understanding that WildFly 10 will include Hibernate 5). Part of this effort of integrating Hibernate 5, will be passing the various TCKs (from standalone JPA 2.1 TCK to EE TCKs). Once we have some TCK runs with Hibernate 5, we will have a better idea of how much work is remaining on the Hibernate ORM 5.x side. From a scheduling point of view, I'm not sure what will be done by August. We can either merge components changes in before they are known to pass all TCK tests or wait until they are ready. Since we are short on time, I wanted to pass the TCK tests before (merging Hibernate 5.0 into WildFly 10) but am flexible on that if the schedule could be flexible also. > >> On May 28, 2015, at 5:30 AM, Sanne Grinovero wrote: >> >> Could someone explain please, why it's hard to have a deployer just >> use a different JPA implementor which the user might want to provide? >> >> I'm pretty sure I know how to start a JPA context in plain JavaSE, and >> don't need to know which implementor version I'm going to use, other >> than for sake of configuration. >> >> The WildFly documentation mentions this property >> "jboss.as.jpa.providerModule", which sounds great on paper and it >> would be a nice usability improvement if it would also actually work >> as it suggests. >> >> There's plenty of evidence on StackOverflow that the current >> limitations are unexpected. For example, Spring moved to Hibernate 5 >> and people won't be able to use your stable line of the application >> server with Spring; I'd hope we could implement a plan to prevent this >> from happening at the next upgrade cycles. >> >> Thanks, >> Sanne >> >> On 21 May 2015 at 20:10, Scott Marlow wrote: >>> >>> >>> On 05/21/2015 03:05 PM, Toma? Cerar wrote: >>>> Scott, >>>> >>>> if you do one last jipijapa release that adds "support" for hibernate5 >>>> hibernate guys could take that version and override it in wildfly 9 same >>>> way as they add new h5 modules. >>> >>> I assume this will be an iterative process but sure, we could also push >>> a release of the JIPI-31 branch. Lets keep talking about what is needed... >>> >>>> >>>> -- >>>> tomaz >>>> >>>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >>> > wrote: >>>> >>>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >>>>> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >>>> >>>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >>>> integration code that we will look at merging into WildFly 10. Are you >>>> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >>>> (doesn't seem as likely to me but I don't control the schedule)? >>>> >>>>> >>>>> It would help speed up the Hibernate 5 stream adoption and avoid >>>> a lot of duplicated work for 6+ months. >>>>> >>>>>> On 21 mai 2015, at 16:36, Scott Marlow >>> > wrote: >>>>>> >>>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >>>> this soon >>>>>> for WildFly 10. >>>>>> >>>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>>>>> Hi all, >>>>>>> I'm attempting to deploy some integration tests on WildFly >>>> 9.0.0.CR1 >>>>>>> to use a preview of Hibernate ORM version 5. >>>>>>> >>>>>>> It seems the JPA deployer isn't allowing me to run such >>>> experiments: >>>>>>> >>>>>>> # First experiment - providerModule set to custom module >>>>>>> >>>>>>> In my first attempt, I create a custom set of jboss modules which >>>>>>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>>>>>> instance and set the persistence.xml property: >>>>>>> jboss.as.jpa.providerModule = my-custom-module-name >>>>>>> >>>>>>> and then get: >>>>>>> >>>>>>> Caused by: java.util.ServiceConfigurationError: >>>>>>> org.hibernate.integrator.spi.Integrator: Provider >>>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >>>> [rt.jar:1.7.0_51] >>>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >>>> [rt.jar:1.7.0_51] >>>>>>> at >>>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >>>> [rt.jar:1.7.0_51] >>>>>>> at >>>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>>>>> at >>>> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >>>>>>> at >>>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >>>>>>> at >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>>>>> at >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>>>>> at >>>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >>>>>>> at >>>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>>>>> ... 7 more >>>>>>> >>>>>>> Clearly it looks like I'm being served classes from the bundled >>>>>>> Hibernate 4.x implementation - on top of those from the module I'm >>>>>>> requesting. This isn't what the deployer should be doing, right? >>>>>>> >>>>>>> # Second experiment - use the "application provided" >>>>>>> >>>>>>> In this case I hope to hint the JPA deployer to not add the >>>> default >>>>>>> implementor but look for a JPA implementation within my deployment, >>>>>>> but still package my custom Hibernate build as a module. >>>>>>> >>>>>>> - use the same custom module containing Hibernate ORM 5 (a >>>> preview snapshot) >>>>>>> - Add a "Dependency:" section to the manifest to import (and >>>> export) >>>>>>> my custom module >>>>>>> - set the "jboss.as.jpa.providerModule" property to value >>>> "application" >>>>>>> >>>>>>> This gets me: >>>>>>> >>>>>>> Caused by: >>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>>>>> WFLYJPA0027: Persistence provider module load error application >>>> (class >>>>>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>>>>> at >>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>>>>> ... 5 more >>>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >>>> application:main >>>>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>>>>> [jboss-modules.jar:1.4.3.Final] >>>>>>> at >>>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>>>>> ... 10 more >>>>>>> >>>>>>> Remarks: >>>>>>> - it's attempting to load the "application:main" module?! >>>> that's not >>>>>>> what I'd expect from reading [1] >>>>>> >>>>>> This seems to be a bug. I hit it a few days ago when I packaged >>>>>> Hibernate ORM 4.1.x with an application (in a unit test) and >>>> forgot to >>>>>> set the persistence provider in persistence.xml. >>>>>> >>>>>>> - the provider should be available to the deployment >>>> classpath, so >>>>>>> I'm not sure why it's not finding the Provider? (I'm even exporting >>>>>>> it, although I'm not sure if that was required). >>>>>> >>>>>> Providers are always found through the >>>>>> javax.persistence.spi.PersistenceProviderResolver, not directly >>>> from the >>>>>> deployment classpath. >>>>>> >>>>>>> >>>>>>> Any suggestions to get this running please? >>>>>>> >>>>>>> Also I wonder if some of these should warrant opening a JIRA, >>>> but I'm >>>>>>> not sure how far I misunderstood the intentions of these JPA >>>> deployer >>>>>>> properties. >>>>>> >>>>>> Lets talk in a few days again on IRC. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sanne >>>>>>> >>>>>>> [1] - >>>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >>>>>> _______________________________________________ >>>>>> 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 >> >> _______________________________________________ >> 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 > From jason.greene at redhat.com Thu May 28 11:38:08 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 28 May 2015 10:38:08 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <55672C8D.4060907@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <55672C8D.4060907@redhat.com> Message-ID: <4165E7BC-4218-4D2C-A255-E1201B1585DB@redhat.com> > On May 28, 2015, at 9:56 AM, Scott Marlow wrote: > > > On 05/28/2015 06:30 AM, Sanne Grinovero wrote: >> Could someone explain please, why it's hard to have a deployer just >> use a different JPA implementor which the user might want to provide? > > If you mean Hibernate 5.x specifically, we started the integration on > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 > >> >> I'm pretty sure I know how to start a JPA context in plain JavaSE, and >> don't need to know which implementor version I'm going to use, other >> than for sake of configuration. >> >> The WildFly documentation mentions this property >> "jboss.as.jpa.providerModule", which sounds great on paper and it >> would be a nice usability improvement if it would also actually work >> as it suggests. > > You are complaining a lot lately. We purposely designed for known use > cases. There are other ways to get the dynamic environment that you are > looking for then complaining that the WildFly JPA subsystem > "jboss.as.jpa.providerModule" option doesn't work. I have probably missed other threads, but I didn?t take it as a complaint, just more surprise and questioning if the behavior made sense. Although, I shouldn?t speak for Sanne. I think its a sign that we may need to improve our docs in this area, so that the limitations are a bit more clear. As always I think its great for us to discuss if and how our integrations could be better. > >> >> There's plenty of evidence on StackOverflow that the current >> limitations are unexpected. For example, Spring moved to Hibernate 5 >> and people won't be able to use your stable line of the application >> server with Spring; I'd hope we could implement a plan to prevent this >> from happening at the next upgrade cycles. > > The question is whether the Hibernate 5.0 release schedule can align > with the WildFly 10 schedule, so that we can do the work. Getting 5 into 10 as early as possible would be great. We are aiming for a final release in Oct, which isn?t that far away. > >> >> Thanks, >> Sanne >> >> On 21 May 2015 at 20:10, Scott Marlow wrote: >>> >>> >>> On 05/21/2015 03:05 PM, Toma? Cerar wrote: >>>> Scott, >>>> >>>> if you do one last jipijapa release that adds "support" for hibernate5 >>>> hibernate guys could take that version and override it in wildfly 9 same >>>> way as they add new h5 modules. >>> >>> I assume this will be an iterative process but sure, we could also push >>> a release of the JIPI-31 branch. Lets keep talking about what is needed... >>> >>>> >>>> -- >>>> tomaz >>>> >>>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >>> > wrote: >>>> >>>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >>>>> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >>>> >>>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >>>> integration code that we will look at merging into WildFly 10. Are you >>>> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >>>> (doesn't seem as likely to me but I don't control the schedule)? >>>> >>>>> >>>>> It would help speed up the Hibernate 5 stream adoption and avoid >>>> a lot of duplicated work for 6+ months. >>>>> >>>>>> On 21 mai 2015, at 16:36, Scott Marlow >>> > wrote: >>>>>> >>>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >>>> this soon >>>>>> for WildFly 10. >>>>>> >>>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>>>>> Hi all, >>>>>>> I'm attempting to deploy some integration tests on WildFly >>>> 9.0.0.CR1 >>>>>>> to use a preview of Hibernate ORM version 5. >>>>>>> >>>>>>> It seems the JPA deployer isn't allowing me to run such >>>> experiments: >>>>>>> >>>>>>> # First experiment - providerModule set to custom module >>>>>>> >>>>>>> In my first attempt, I create a custom set of jboss modules which >>>>>>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>>>>>> instance and set the persistence.xml property: >>>>>>> jboss.as.jpa.providerModule = my-custom-module-name >>>>>>> >>>>>>> and then get: >>>>>>> >>>>>>> Caused by: java.util.ServiceConfigurationError: >>>>>>> org.hibernate.integrator.spi.Integrator: Provider >>>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >>>> [rt.jar:1.7.0_51] >>>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >>>> [rt.jar:1.7.0_51] >>>>>>> at >>>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >>>> [rt.jar:1.7.0_51] >>>>>>> at >>>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>>>>> at >>>> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >>>>>>> at >>>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >>>>>>> at >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>>>>> at >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>>>>> at >>>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >>>>>>> at >>>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>>>>> ... 7 more >>>>>>> >>>>>>> Clearly it looks like I'm being served classes from the bundled >>>>>>> Hibernate 4.x implementation - on top of those from the module I'm >>>>>>> requesting. This isn't what the deployer should be doing, right? >>>>>>> >>>>>>> # Second experiment - use the "application provided" >>>>>>> >>>>>>> In this case I hope to hint the JPA deployer to not add the >>>> default >>>>>>> implementor but look for a JPA implementation within my deployment, >>>>>>> but still package my custom Hibernate build as a module. >>>>>>> >>>>>>> - use the same custom module containing Hibernate ORM 5 (a >>>> preview snapshot) >>>>>>> - Add a "Dependency:" section to the manifest to import (and >>>> export) >>>>>>> my custom module >>>>>>> - set the "jboss.as.jpa.providerModule" property to value >>>> "application" >>>>>>> >>>>>>> This gets me: >>>>>>> >>>>>>> Caused by: >>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>>>>> WFLYJPA0027: Persistence provider module load error application >>>> (class >>>>>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>>>>> at >>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>>>>> ... 5 more >>>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >>>> application:main >>>>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>>>>> [jboss-modules.jar:1.4.3.Final] >>>>>>> at >>>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>>>>> ... 10 more >>>>>>> >>>>>>> Remarks: >>>>>>> - it's attempting to load the "application:main" module?! >>>> that's not >>>>>>> what I'd expect from reading [1] >>>>>> >>>>>> This seems to be a bug. I hit it a few days ago when I packaged >>>>>> Hibernate ORM 4.1.x with an application (in a unit test) and >>>> forgot to >>>>>> set the persistence provider in persistence.xml. >>>>>> >>>>>>> - the provider should be available to the deployment >>>> classpath, so >>>>>>> I'm not sure why it's not finding the Provider? (I'm even exporting >>>>>>> it, although I'm not sure if that was required). >>>>>> >>>>>> Providers are always found through the >>>>>> javax.persistence.spi.PersistenceProviderResolver, not directly >>>> from the >>>>>> deployment classpath. >>>>>> >>>>>>> >>>>>>> Any suggestions to get this running please? >>>>>>> >>>>>>> Also I wonder if some of these should warrant opening a JIRA, >>>> but I'm >>>>>>> not sure how far I misunderstood the intentions of these JPA >>>> deployer >>>>>>> properties. >>>>>> >>>>>> Lets talk in a few days again on IRC. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sanne >>>>>>> >>>>>>> [1] - >>>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >>>>>> _______________________________________________ >>>>>> 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 >> >> _______________________________________________ >> 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 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From smarlow at redhat.com Thu May 28 11:42:54 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 28 May 2015 11:42:54 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> Message-ID: <5567377E.3070400@redhat.com> On 05/28/2015 10:29 AM, Steve Ebersole wrote: > I am just not sure a lot of this is true. What > EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA > bootstrap SPI) contracts changed in 5.0? Minor changes so far: Some org.hibernate.jpa.boot.scan.spi package changes to org.hibernate.boot.archive.scan.spi. Configuration.USE_NEW_ID_GENERATOR_MAPPINGS is now AvailableSettings.USE_NEW_ID_GENERATOR_MAPPINGS. > > As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, > but we currently do not use it. So that actually should also not cause > any issues in regards to Hibernate 4.x or 5.0 We are not passing the IndexView in currently (we could if that becomes important in the future, as long as we don't keep a reference to the JandexView after the EMF is created). I don't think that would be helpful though as you need changes for XML file handling I think. > > As far as using the standard JPA bootstrap SPIs, I agree this is up to > Scott. But it simply will not work for the way WildFly does stuff as I > understand it. This is really the first time that I have heard a complaint. I think its a timing issue, that people (like Sanne) have work to do but cannot get to it until WildFly switches to Hibernate 5.0. > > Second-level cache, yes, is a whole other ball of wax :) Yep, sometimes the second-level cache breaks in ways that we don't detect, when we upgrade WildFly to a newer Infinispan version. > > > On Thu, May 28, 2015 at 9:18 AM, Jason Greene > wrote: > > We implement the standard JPA integration SPI, but it is absolutely > awful. > > It forces: > > - The construction of duplicate class loaders with duplicate class > definitions of every class in the deployment > - Repeated runs of the deployment process > - Double loading of any class related to JPA (and its dependencies) > - The JPA provider to use reflection for all annotation discovery > - Double use of reflection in the deployment process > - Bugs from chicken and egg problems > - Increased memory usage > > So for this reason WildFly and Hibernate have their own integration > SPIs, and those SPIs are changing in hibernate 5. So WildFly (well > currently JIPPAJAPPA) needs an update to be compatible with them. > Additionally we have the Jandex 2 change which is pending that both > projects are attempting to align on. > > Now what I am not sure about, Scott will have to answer this. Is if > you can use the standard JPA integration SPI with newer versions of > Hibernate and just live with the nastiness it brings. > > However, there is still a secondary issue, which I am sure you > already know about is that the second level cache and hibernate > search have integrations that need to be compatible and in sync and > tested. > > > On May 28, 2015, at 5:30 AM, Sanne Grinovero > wrote: > > > > Could someone explain please, why it's hard to have a deployer just > > use a different JPA implementor which the user might want to provide? > > > > I'm pretty sure I know how to start a JPA context in plain > JavaSE, and > > don't need to know which implementor version I'm going to use, other > > than for sake of configuration. > > > > The WildFly documentation mentions this property > > "jboss.as.jpa.providerModule", which sounds great on paper and it > > would be a nice usability improvement if it would also actually work > > as it suggests. > > > > There's plenty of evidence on StackOverflow that the current > > limitations are unexpected. For example, Spring moved to Hibernate 5 > > and people won't be able to use your stable line of the application > > server with Spring; I'd hope we could implement a plan to prevent > this > > from happening at the next upgrade cycles. > > > > Thanks, > > Sanne > > > > On 21 May 2015 at 20:10, Scott Marlow > wrote: > >> > >> > >> On 05/21/2015 03:05 PM, Toma? Cerar wrote: > >>> Scott, > >>> > >>> if you do one last jipijapa release that adds "support" for > hibernate5 > >>> hibernate guys could take that version and override it in > wildfly 9 same > >>> way as they add new h5 modules. > >> > >> I assume this will be an iterative process but sure, we could > also push > >> a release of the JIPI-31 branch. Lets keep talking about what > is needed... > >> > >>> > >>> -- > >>> tomaz > >>> > >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow > > >>> >> wrote: > >>> > >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > >>>> Scott, No way to make ORM 5 work in 9 at all? With the user > setting the additional slotted modules of course. > >>> > >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the > >>> integration code that we will look at merging into WildFly > 10. Are you > >>> looking for a custom WildFly 9.x branch or actual changes in > WildFly 9 > >>> (doesn't seem as likely to me but I don't control the schedule)? > >>> > >>>> > >>>> It would help speed up the Hibernate 5 stream adoption and avoid > >>> a lot of duplicated work for 6+ months. > >>>> > >>>>> On 21 mai 2015, at 16:36, Scott Marlow > >>> >> wrote: > >>>>> > >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on > >>> this soon > >>>>> for WildFly 10. > >>>>> > >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >>>>>> Hi all, > >>>>>> I'm attempting to deploy some integration tests on WildFly > >>> 9.0.0.CR1 > >>>>>> to use a preview of Hibernate ORM version 5. > >>>>>> > >>>>>> It seems the JPA deployer isn't allowing me to run such > >>> experiments: > >>>>>> > >>>>>> # First experiment - providerModule set to custom module > >>>>>> > >>>>>> In my first attempt, I create a custom set of jboss modules > which > >>>>>> include the snapshot builds of ORM 5, add them to my > standalone WF9 > >>>>>> instance and set the persistence.xml property: > >>>>>> jboss.as.jpa.providerModule = my-custom-module-name > >>>>>> > >>>>>> and then get: > >>>>>> > >>>>>> Caused by: java.util.ServiceConfigurationError: > >>>>>> org.hibernate.integrator.spi.Integrator: Provider > >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a > subtype > >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > >>> [rt.jar:1.7.0_51] > >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) > >>> [rt.jar:1.7.0_51] > >>>>>> at > >>> > java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >>>>>> [rt.jar:1.7.0_51] > >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > >>> [rt.jar:1.7.0_51] > >>>>>> at > >>> > org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >>>>>> at > >>> > org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > >>>>>> at > >>> > org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > >>>>>> at > >>> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >>>>>> at > >>> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >>>>>> at > >>> > org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > >>>>>> at > >>> > org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >>>>>> ... 7 more > >>>>>> > >>>>>> Clearly it looks like I'm being served classes from the bundled > >>>>>> Hibernate 4.x implementation - on top of those from the > module I'm > >>>>>> requesting. This isn't what the deployer should be doing, right? > >>>>>> > >>>>>> # Second experiment - use the "application provided" > >>>>>> > >>>>>> In this case I hope to hint the JPA deployer to not add the > >>> default > >>>>>> implementor but look for a JPA implementation within my > deployment, > >>>>>> but still package my custom Hibernate build as a module. > >>>>>> > >>>>>> - use the same custom module containing Hibernate ORM 5 (a > >>> preview snapshot) > >>>>>> - Add a "Dependency:" section to the manifest to import (and > >>> export) > >>>>>> my custom module > >>>>>> - set the "jboss.as.jpa.providerModule" property to value > >>> "application" > >>>>>> > >>>>>> This gets me: > >>>>>> > >>>>>> Caused by: > >>> > org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >>>>>> WFLYJPA0027: Persistence provider module load error application > >>> (class > >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >>>>>> at > >>> > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >>>>>> ... 5 more > >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: > >>> application:main > >>>>>> at > org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >>>>>> [jboss-modules.jar:1.4.3.Final] > >>>>>> at > >>> > org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >>>>>> ... 10 more > >>>>>> > >>>>>> Remarks: > >>>>>> - it's attempting to load the "application:main" module?! > >>> that's not > >>>>>> what I'd expect from reading [1] > >>>>> > >>>>> This seems to be a bug. I hit it a few days ago when I packaged > >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and > >>> forgot to > >>>>> set the persistence provider in persistence.xml. > >>>>> > >>>>>> - the provider should be available to the deployment > >>> classpath, so > >>>>>> I'm not sure why it's not finding the Provider? (I'm even > exporting > >>>>>> it, although I'm not sure if that was required). > >>>>> > >>>>> Providers are always found through the > >>>>> javax.persistence.spi.PersistenceProviderResolver, not directly > >>> from the > >>>>> deployment classpath. > >>>>> > >>>>>> > >>>>>> Any suggestions to get this running please? > >>>>>> > >>>>>> Also I wonder if some of these should warrant opening a JIRA, > >>> but I'm > >>>>>> not sure how far I misunderstood the intentions of these JPA > >>> deployer > >>>>>> properties. > >>>>> > >>>>> Lets talk in a few days again on IRC. > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Sanne > >>>>>> > >>>>>> [1] - > >>> > https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > >>>>> _______________________________________________ > >>>>> 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 > > > > _______________________________________________ > > 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 > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Thu May 28 11:47:03 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 28 May 2015 10:47:03 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <5567338A.1090402@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567338A.1090402@redhat.com> Message-ID: <270F918B-17CD-4142-9CB6-F3EAE9DF98FD@redhat.com> > On May 28, 2015, at 10:26 AM, Scott Marlow wrote: > > One issue for the Hibernate projects like Search, is that they need Hibernate 5 to be included in WildFly, so they can start integrating with Hibernate 5 (with the understanding that WildFly 10 will include Hibernate 5). Part of this effort of integrating Hibernate 5, will be passing the various TCKs (from standalone JPA 2.1 TCK to EE TCKs). Once we have some TCK runs with Hibernate 5, we will have a better idea of how much work is remaining on the Hibernate ORM 5.x side. > > From a scheduling point of view, I'm not sure what will be done by August. We can either merge components changes in before they are known to pass all TCK tests or wait until they are ready. Since we are short on time, I wanted to pass the TCK tests before (merging Hibernate 5.0 into WildFly 10) but am flexible on that if the schedule could be flexible also. I liked your idea on HipChat. You could create a JPA branch and get it far enough along to run the JPA tck tests on it, and in the meantime everyone could fork that branch as needed for their development branches. Once we get promising looking results the branch can be converted into one or more PRs. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Thu May 28 11:56:24 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 28 May 2015 10:56:24 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <5567377E.3070400@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567377E.3070400@redhat.com> Message-ID: > On May 28, 2015, at 10:42 AM, Scott Marlow wrote: > > > > On 05/28/2015 10:29 AM, Steve Ebersole wrote: >> I am just not sure a lot of this is true. What >> EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA >> bootstrap SPI) contracts changed in 5.0? > > Minor changes so far: > > Some org.hibernate.jpa.boot.scan.spi package changes to org.hibernate.boot.archive.scan.spi. > > Configuration.USE_NEW_ID_GENERATOR_MAPPINGS is now AvailableSettings.USE_NEW_ID_GENERATOR_MAPPINGS. > >> >> As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, >> but we currently do not use it. So that actually should also not cause >> any issues in regards to Hibernate 4.x or 5.0 > > We are not passing the IndexView in currently (we could if that becomes important in the future, as long as we don't keep a reference to the JandexView after the EMF is created). I don't think that would be helpful though as you need changes for XML file handling I think. That should be the eventual goal. We don?t want to process all classes for annotations N times for every framework that wants to read them, as it hurts deployment time. We had this before, we really need to bring it back. > >> >> As far as using the standard JPA bootstrap SPIs, I agree this is up to >> Scott. But it simply will not work for the way WildFly does stuff as I >> understand it. > > This is really the first time that I have heard a complaint. I think its a timing issue, that people (like Sanne) have work to do but cannot get to it until WildFly switches to Hibernate 5.0. We tend to update to the latest hibernate revs very quickly, so I haven?t seen much either, and so it might not be worth ?supporting". It?s usually supporting old versions of hibernate that comes up, but I think thats largely been addressed (we have integrations for 3 etc). > >> >> Second-level cache, yes, is a whole other ball of wax :) > > Yep, sometimes the second-level cache breaks in ways that we don't detect, when we upgrade WildFly to a newer Infinispan version. > >> >> >> On Thu, May 28, 2015 at 9:18 AM, Jason Greene > > wrote: >> >> We implement the standard JPA integration SPI, but it is absolutely >> awful. >> >> It forces: >> >> - The construction of duplicate class loaders with duplicate class >> definitions of every class in the deployment >> - Repeated runs of the deployment process >> - Double loading of any class related to JPA (and its dependencies) >> - The JPA provider to use reflection for all annotation discovery >> - Double use of reflection in the deployment process >> - Bugs from chicken and egg problems >> - Increased memory usage >> >> So for this reason WildFly and Hibernate have their own integration >> SPIs, and those SPIs are changing in hibernate 5. So WildFly (well >> currently JIPPAJAPPA) needs an update to be compatible with them. >> Additionally we have the Jandex 2 change which is pending that both >> projects are attempting to align on. >> >> Now what I am not sure about, Scott will have to answer this. Is if >> you can use the standard JPA integration SPI with newer versions of >> Hibernate and just live with the nastiness it brings. >> >> However, there is still a secondary issue, which I am sure you >> already know about is that the second level cache and hibernate >> search have integrations that need to be compatible and in sync and >> tested. >> >> > On May 28, 2015, at 5:30 AM, Sanne Grinovero > > wrote: >> > >> > Could someone explain please, why it's hard to have a deployer just >> > use a different JPA implementor which the user might want to provide? >> > >> > I'm pretty sure I know how to start a JPA context in plain >> JavaSE, and >> > don't need to know which implementor version I'm going to use, other >> > than for sake of configuration. >> > >> > The WildFly documentation mentions this property >> > "jboss.as.jpa.providerModule", which sounds great on paper and it >> > would be a nice usability improvement if it would also actually work >> > as it suggests. >> > >> > There's plenty of evidence on StackOverflow that the current >> > limitations are unexpected. For example, Spring moved to Hibernate 5 >> > and people won't be able to use your stable line of the application >> > server with Spring; I'd hope we could implement a plan to prevent >> this >> > from happening at the next upgrade cycles. >> > >> > Thanks, >> > Sanne >> > >> > On 21 May 2015 at 20:10, Scott Marlow > > wrote: >> >> >> >> >> >> On 05/21/2015 03:05 PM, Toma? Cerar wrote: >> >>> Scott, >> >>> >> >>> if you do one last jipijapa release that adds "support" for >> hibernate5 >> >>> hibernate guys could take that version and override it in >> wildfly 9 same >> >>> way as they add new h5 modules. >> >> >> >> I assume this will be an iterative process but sure, we could >> also push >> >> a release of the JIPI-31 branch. Lets keep talking about what >> is needed... >> >> >> >>> >> >>> -- >> >>> tomaz >> >>> >> >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >> >> >>> >> wrote: >> >>> >> >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >> >>>> Scott, No way to make ORM 5 work in 9 at all? With the user >> setting the additional slotted modules of course. >> >>> >> >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >> >>> integration code that we will look at merging into WildFly >> 10. Are you >> >>> looking for a custom WildFly 9.x branch or actual changes in >> WildFly 9 >> >>> (doesn't seem as likely to me but I don't control the schedule)? >> >>> >> >>>> >> >>>> It would help speed up the Hibernate 5 stream adoption and avoid >> >>> a lot of duplicated work for 6+ months. >> >>>> >> >>>>> On 21 mai 2015, at 16:36, Scott Marlow > >> >>> >> wrote: >> >>>>> >> >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >> >>> this soon >> >>>>> for WildFly 10. >> >>>>> >> >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >> >>>>>> Hi all, >> >>>>>> I'm attempting to deploy some integration tests on WildFly >> >>> 9.0.0.CR1 >> >>>>>> to use a preview of Hibernate ORM version 5. >> >>>>>> >> >>>>>> It seems the JPA deployer isn't allowing me to run such >> >>> experiments: >> >>>>>> >> >>>>>> # First experiment - providerModule set to custom module >> >>>>>> >> >>>>>> In my first attempt, I create a custom set of jboss modules >> which >> >>>>>> include the snapshot builds of ORM 5, add them to my >> standalone WF9 >> >>>>>> instance and set the persistence.xml property: >> >>>>>> jboss.as.jpa.providerModule = my-custom-module-name >> >>>>>> >> >>>>>> and then get: >> >>>>>> >> >>>>>> Caused by: java.util.ServiceConfigurationError: >> >>>>>> org.hibernate.integrator.spi.Integrator: Provider >> >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a >> subtype >> >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >> >>> [rt.jar:1.7.0_51] >> >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >> >>> [rt.jar:1.7.0_51] >> >>>>>> at >> >>> >> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >> >>>>>> [rt.jar:1.7.0_51] >> >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >> >>> [rt.jar:1.7.0_51] >> >>>>>> at >> >>> >> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >> >>>>>> at >> >>> >> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >> >>>>>> at >> >>> >> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >> >>>>>> at >> >>> >> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >> >>>>>> at >> >>> >> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >> >>>>>> at >> >>> >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >> >>>>>> at >> >>> >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >> >>>>>> at >> >>> >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >> >>>>>> ... 7 more >> >>>>>> >> >>>>>> Clearly it looks like I'm being served classes from the bundled >> >>>>>> Hibernate 4.x implementation - on top of those from the >> module I'm >> >>>>>> requesting. This isn't what the deployer should be doing, right? >> >>>>>> >> >>>>>> # Second experiment - use the "application provided" >> >>>>>> >> >>>>>> In this case I hope to hint the JPA deployer to not add the >> >>> default >> >>>>>> implementor but look for a JPA implementation within my >> deployment, >> >>>>>> but still package my custom Hibernate build as a module. >> >>>>>> >> >>>>>> - use the same custom module containing Hibernate ORM 5 (a >> >>> preview snapshot) >> >>>>>> - Add a "Dependency:" section to the manifest to import (and >> >>> export) >> >>>>>> my custom module >> >>>>>> - set the "jboss.as.jpa.providerModule" property to value >> >>> "application" >> >>>>>> >> >>>>>> This gets me: >> >>>>>> >> >>>>>> Caused by: >> >>> >> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >> >>>>>> WFLYJPA0027: Persistence provider module load error application >> >>> (class >> >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >> >>>>>> at >> >>> >> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >> >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >> >>>>>> ... 5 more >> >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >> >>> application:main >> >>>>>> at >> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >> >>>>>> [jboss-modules.jar:1.4.3.Final] >> >>>>>> at >> >>> >> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >> >>>>>> ... 10 more >> >>>>>> >> >>>>>> Remarks: >> >>>>>> - it's attempting to load the "application:main" module?! >> >>> that's not >> >>>>>> what I'd expect from reading [1] >> >>>>> >> >>>>> This seems to be a bug. I hit it a few days ago when I packaged >> >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and >> >>> forgot to >> >>>>> set the persistence provider in persistence.xml. >> >>>>> >> >>>>>> - the provider should be available to the deployment >> >>> classpath, so >> >>>>>> I'm not sure why it's not finding the Provider? (I'm even >> exporting >> >>>>>> it, although I'm not sure if that was required). >> >>>>> >> >>>>> Providers are always found through the >> >>>>> javax.persistence.spi.PersistenceProviderResolver, not directly >> >>> from the >> >>>>> deployment classpath. >> >>>>> >> >>>>>> >> >>>>>> Any suggestions to get this running please? >> >>>>>> >> >>>>>> Also I wonder if some of these should warrant opening a JIRA, >> >>> but I'm >> >>>>>> not sure how far I misunderstood the intentions of these JPA >> >>> deployer >> >>>>>> properties. >> >>>>> >> >>>>> Lets talk in a few days again on IRC. >> >>>>> >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Sanne >> >>>>>> >> >>>>>> [1] - >> >>> >> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >> >>>>> _______________________________________________ >> >>>>> 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 >> > >> > _______________________________________________ >> > 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 >> >> >> >> >> _______________________________________________ >> 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 smarlow at redhat.com Thu May 28 11:59:36 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 28 May 2015 11:59:36 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <270F918B-17CD-4142-9CB6-F3EAE9DF98FD@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567338A.1090402@redhat.com> <270F918B-17CD-4142-9CB6-F3EAE9DF98FD@redhat.com> Message-ID: <55673B68.9040301@redhat.com> On 05/28/2015 11:47 AM, Jason Greene wrote: > >> On May 28, 2015, at 10:26 AM, Scott Marlow wrote: >> >> One issue for the Hibernate projects like Search, is that they need Hibernate 5 to be included in WildFly, so they can start integrating with Hibernate 5 (with the understanding that WildFly 10 will include Hibernate 5). Part of this effort of integrating Hibernate 5, will be passing the various TCKs (from standalone JPA 2.1 TCK to EE TCKs). Once we have some TCK runs with Hibernate 5, we will have a better idea of how much work is remaining on the Hibernate ORM 5.x side. >> >> From a scheduling point of view, I'm not sure what will be done by August. We can either merge components changes in before they are known to pass all TCK tests or wait until they are ready. Since we are short on time, I wanted to pass the TCK tests before (merging Hibernate 5.0 into WildFly 10) but am flexible on that if the schedule could be flexible also. > > I liked your idea on HipChat. You could create a JPA branch and get it far enough along to run the JPA tck tests on it, and in the meantime everyone could fork that branch as needed for their development branches. Once we get promising looking results the branch can be converted into one or more PRs. This works for me, I mostly just wanted to get the Hibernate concerns about the schedule on the table (if there are any concerns). The only one that I know is that they would like Hibernate 5 support now, so Hibernate non-ORM projects can target WildFly now. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > From steve at hibernate.org Thu May 28 12:00:40 2015 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 May 2015 11:00:40 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567377E.3070400@redhat.com> Message-ID: I discussed this last point with Scott. I'd prefer to drop support for 4.x in WildFly 10. Ideally if that could mean "archiving" that support so users could easily drop it in *if they chose*, great. On Thu, May 28, 2015 at 10:56 AM, Jason Greene wrote: > > > On May 28, 2015, at 10:42 AM, Scott Marlow wrote: > > > > > > > > On 05/28/2015 10:29 AM, Steve Ebersole wrote: > >> I am just not sure a lot of this is true. What > >> EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA > >> bootstrap SPI) contracts changed in 5.0? > > > > Minor changes so far: > > > > Some org.hibernate.jpa.boot.scan.spi package changes to > org.hibernate.boot.archive.scan.spi. > > > > Configuration.USE_NEW_ID_GENERATOR_MAPPINGS is now > AvailableSettings.USE_NEW_ID_GENERATOR_MAPPINGS. > > > >> > >> As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, > >> but we currently do not use it. So that actually should also not cause > >> any issues in regards to Hibernate 4.x or 5.0 > > > > We are not passing the IndexView in currently (we could if that becomes > important in the future, as long as we don't keep a reference to the > JandexView after the EMF is created). I don't think that would be helpful > though as you need changes for XML file handling I think. > > That should be the eventual goal. We don?t want to process all classes for > annotations N times for every framework that wants to read them, as it > hurts deployment time. We had this before, we really need to bring it back. > > > > >> > >> As far as using the standard JPA bootstrap SPIs, I agree this is up to > >> Scott. But it simply will not work for the way WildFly does stuff as I > >> understand it. > > > > This is really the first time that I have heard a complaint. I think > its a timing issue, that people (like Sanne) have work to do but cannot get > to it until WildFly switches to Hibernate 5.0. > > We tend to update to the latest hibernate revs very quickly, so I haven?t > seen much either, and so it might not be worth ?supporting". It?s usually > supporting old versions of hibernate that comes up, but I think thats > largely been addressed (we have integrations for 3 etc). > > > > >> > >> Second-level cache, yes, is a whole other ball of wax :) > > > > Yep, sometimes the second-level cache breaks in ways that we don't > detect, when we upgrade WildFly to a newer Infinispan version. > > > >> > >> > >> On Thu, May 28, 2015 at 9:18 AM, Jason Greene >> > wrote: > >> > >> We implement the standard JPA integration SPI, but it is absolutely > >> awful. > >> > >> It forces: > >> > >> - The construction of duplicate class loaders with duplicate class > >> definitions of every class in the deployment > >> - Repeated runs of the deployment process > >> - Double loading of any class related to JPA (and its dependencies) > >> - The JPA provider to use reflection for all annotation discovery > >> - Double use of reflection in the deployment process > >> - Bugs from chicken and egg problems > >> - Increased memory usage > >> > >> So for this reason WildFly and Hibernate have their own integration > >> SPIs, and those SPIs are changing in hibernate 5. So WildFly (well > >> currently JIPPAJAPPA) needs an update to be compatible with them. > >> Additionally we have the Jandex 2 change which is pending that both > >> projects are attempting to align on. > >> > >> Now what I am not sure about, Scott will have to answer this. Is if > >> you can use the standard JPA integration SPI with newer versions of > >> Hibernate and just live with the nastiness it brings. > >> > >> However, there is still a secondary issue, which I am sure you > >> already know about is that the second level cache and hibernate > >> search have integrations that need to be compatible and in sync and > >> tested. > >> > >> > On May 28, 2015, at 5:30 AM, Sanne Grinovero >> > wrote: > >> > > >> > Could someone explain please, why it's hard to have a deployer > just > >> > use a different JPA implementor which the user might want to > provide? > >> > > >> > I'm pretty sure I know how to start a JPA context in plain > >> JavaSE, and > >> > don't need to know which implementor version I'm going to use, > other > >> > than for sake of configuration. > >> > > >> > The WildFly documentation mentions this property > >> > "jboss.as.jpa.providerModule", which sounds great on paper and it > >> > would be a nice usability improvement if it would also actually > work > >> > as it suggests. > >> > > >> > There's plenty of evidence on StackOverflow that the current > >> > limitations are unexpected. For example, Spring moved to > Hibernate 5 > >> > and people won't be able to use your stable line of the > application > >> > server with Spring; I'd hope we could implement a plan to prevent > >> this > >> > from happening at the next upgrade cycles. > >> > > >> > Thanks, > >> > Sanne > >> > > >> > On 21 May 2015 at 20:10, Scott Marlow >> > wrote: > >> >> > >> >> > >> >> On 05/21/2015 03:05 PM, Toma? Cerar wrote: > >> >>> Scott, > >> >>> > >> >>> if you do one last jipijapa release that adds "support" for > >> hibernate5 > >> >>> hibernate guys could take that version and override it in > >> wildfly 9 same > >> >>> way as they add new h5 modules. > >> >> > >> >> I assume this will be an iterative process but sure, we could > >> also push > >> >> a release of the JIPI-31 branch. Lets keep talking about what > >> is needed... > >> >> > >> >>> > >> >>> -- > >> >>> tomaz > >> >>> > >> >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow > >> > >> >>> >> wrote: > >> >>> > >> >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > >> >>>> Scott, No way to make ORM 5 work in 9 at all? With the user > >> setting the additional slotted modules of course. > >> >>> > >> >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains > the > >> >>> integration code that we will look at merging into WildFly > >> 10. Are you > >> >>> looking for a custom WildFly 9.x branch or actual changes in > >> WildFly 9 > >> >>> (doesn't seem as likely to me but I don't control the > schedule)? > >> >>> > >> >>>> > >> >>>> It would help speed up the Hibernate 5 stream adoption and > avoid > >> >>> a lot of duplicated work for 6+ months. > >> >>>> > >> >>>>> On 21 mai 2015, at 16:36, Scott Marlow >> > >> >>> >> > wrote: > >> >>>>> > >> >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on > >> >>> this soon > >> >>>>> for WildFly 10. > >> >>>>> > >> >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >> >>>>>> Hi all, > >> >>>>>> I'm attempting to deploy some integration tests on WildFly > >> >>> 9.0.0.CR1 > >> >>>>>> to use a preview of Hibernate ORM version 5. > >> >>>>>> > >> >>>>>> It seems the JPA deployer isn't allowing me to run such > >> >>> experiments: > >> >>>>>> > >> >>>>>> # First experiment - providerModule set to custom module > >> >>>>>> > >> >>>>>> In my first attempt, I create a custom set of jboss modules > >> which > >> >>>>>> include the snapshot builds of ORM 5, add them to my > >> standalone WF9 > >> >>>>>> instance and set the persistence.xml property: > >> >>>>>> jboss.as.jpa.providerModule = my-custom-module-name > >> >>>>>> > >> >>>>>> and then get: > >> >>>>>> > >> >>>>>> Caused by: java.util.ServiceConfigurationError: > >> >>>>>> org.hibernate.integrator.spi.Integrator: Provider > >> >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a > >> subtype > >> >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > >> >>> [rt.jar:1.7.0_51] > >> >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) > >> >>> [rt.jar:1.7.0_51] > >> >>>>>> at > >> >>> > >> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >> >>>>>> [rt.jar:1.7.0_51] > >> >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > >> >>> [rt.jar:1.7.0_51] > >> >>>>>> at > >> >>> > >> > org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >> >>>>>> at > >> >>> > >> > org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > >> >>>>>> at > >> >>> > >> > org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >> >>>>>> ... 7 more > >> >>>>>> > >> >>>>>> Clearly it looks like I'm being served classes from the > bundled > >> >>>>>> Hibernate 4.x implementation - on top of those from the > >> module I'm > >> >>>>>> requesting. This isn't what the deployer should be doing, > right? > >> >>>>>> > >> >>>>>> # Second experiment - use the "application provided" > >> >>>>>> > >> >>>>>> In this case I hope to hint the JPA deployer to not add the > >> >>> default > >> >>>>>> implementor but look for a JPA implementation within my > >> deployment, > >> >>>>>> but still package my custom Hibernate build as a module. > >> >>>>>> > >> >>>>>> - use the same custom module containing Hibernate ORM 5 (a > >> >>> preview snapshot) > >> >>>>>> - Add a "Dependency:" section to the manifest to import (and > >> >>> export) > >> >>>>>> my custom module > >> >>>>>> - set the "jboss.as.jpa.providerModule" property to value > >> >>> "application" > >> >>>>>> > >> >>>>>> This gets me: > >> >>>>>> > >> >>>>>> Caused by: > >> >>> > >> org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >> >>>>>> WFLYJPA0027: Persistence provider module load error > application > >> >>> (class > >> >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >> >>>>>> at > >> >>> > >> > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >> >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >> >>>>>> ... 5 more > >> >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: > >> >>> application:main > >> >>>>>> at > >> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >> >>>>>> [jboss-modules.jar:1.4.3.Final] > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >> >>>>>> ... 10 more > >> >>>>>> > >> >>>>>> Remarks: > >> >>>>>> - it's attempting to load the "application:main" module?! > >> >>> that's not > >> >>>>>> what I'd expect from reading [1] > >> >>>>> > >> >>>>> This seems to be a bug. I hit it a few days ago when I > packaged > >> >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and > >> >>> forgot to > >> >>>>> set the persistence provider in persistence.xml. > >> >>>>> > >> >>>>>> - the provider should be available to the deployment > >> >>> classpath, so > >> >>>>>> I'm not sure why it's not finding the Provider? (I'm even > >> exporting > >> >>>>>> it, although I'm not sure if that was required). > >> >>>>> > >> >>>>> Providers are always found through the > >> >>>>> javax.persistence.spi.PersistenceProviderResolver, not > directly > >> >>> from the > >> >>>>> deployment classpath. > >> >>>>> > >> >>>>>> > >> >>>>>> Any suggestions to get this running please? > >> >>>>>> > >> >>>>>> Also I wonder if some of these should warrant opening a JIRA, > >> >>> but I'm > >> >>>>>> not sure how far I misunderstood the intentions of these JPA > >> >>> deployer > >> >>>>>> properties. > >> >>>>> > >> >>>>> Lets talk in a few days again on IRC. > >> >>>>> > >> >>>>>> > >> >>>>>> Thanks, > >> >>>>>> Sanne > >> >>>>>> > >> >>>>>> [1] - > >> >>> > >> > https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > >> >>>>> _______________________________________________ > >> >>>>> 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 > >> > > >> > _______________________________________________ > >> > 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 > >> > >> > >> > >> > >> _______________________________________________ > >> 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/20150528/174fd5a7/attachment-0001.html From steve at hibernate.org Thu May 28 12:02:35 2015 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 May 2015 11:02:35 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <55673B68.9040301@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567338A.1090402@redhat.com> <270F918B-17CD-4142-9CB6-F3EAE9DF98FD@redhat.com> <55673B68.9040301@redhat.com> Message-ID: Yes, its a matter of adoption (Spring, etc) as well as integrating/testing other components such as Search, OGM, etc in WidlFly using 5.0. I released CR1 for 5.0 yesterday, so I have no concerns of the timeline in regards to feeling rushed to get it in or anything :) On Thu, May 28, 2015 at 10:59 AM, Scott Marlow wrote: > > > On 05/28/2015 11:47 AM, Jason Greene wrote: > > > >> On May 28, 2015, at 10:26 AM, Scott Marlow wrote: > >> > >> One issue for the Hibernate projects like Search, is that they need > Hibernate 5 to be included in WildFly, so they can start integrating with > Hibernate 5 (with the understanding that WildFly 10 will include Hibernate > 5). Part of this effort of integrating Hibernate 5, will be passing the > various TCKs (from standalone JPA 2.1 TCK to EE TCKs). Once we have some > TCK runs with Hibernate 5, we will have a better idea of how much work is > remaining on the Hibernate ORM 5.x side. > >> > >> From a scheduling point of view, I'm not sure what will be done by > August. We can either merge components changes in before they are known to > pass all TCK tests or wait until they are ready. Since we are short on > time, I wanted to pass the TCK tests before (merging Hibernate 5.0 into > WildFly 10) but am flexible on that if the schedule could be flexible also. > > > > I liked your idea on HipChat. You could create a JPA branch and get it > far enough along to run the JPA tck tests on it, and in the meantime > everyone could fork that branch as needed for their development branches. > Once we get promising looking results the branch can be converted into one > or more PRs. > > This works for me, I mostly just wanted to get the Hibernate concerns > about the schedule on the table (if there are any concerns). The only > one that I know is that they would like Hibernate 5 support now, so > Hibernate non-ORM projects can target WildFly now. > > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150528/f7a72c5d/attachment.html From jason.greene at redhat.com Thu May 28 12:06:31 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 28 May 2015 11:06:31 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <55673B68.9040301@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567338A.1090402@redhat.com> <270F918B-17CD-4142-9CB6-F3EAE9DF98FD@redhat.com> <55673B68.9040301@redhat.com> Message-ID: <77889EA1-0191-415F-9BEB-FDC94CB75CA5@redhat.com> > On May 28, 2015, at 10:59 AM, Scott Marlow wrote: > > > > On 05/28/2015 11:47 AM, Jason Greene wrote: >> >>> On May 28, 2015, at 10:26 AM, Scott Marlow wrote: >>> >>> One issue for the Hibernate projects like Search, is that they need Hibernate 5 to be included in WildFly, so they can start integrating with Hibernate 5 (with the understanding that WildFly 10 will include Hibernate 5). Part of this effort of integrating Hibernate 5, will be passing the various TCKs (from standalone JPA 2.1 TCK to EE TCKs). Once we have some TCK runs with Hibernate 5, we will have a better idea of how much work is remaining on the Hibernate ORM 5.x side. >>> >>> From a scheduling point of view, I'm not sure what will be done by August. We can either merge components changes in before they are known to pass all TCK tests or wait until they are ready. Since we are short on time, I wanted to pass the TCK tests before (merging Hibernate 5.0 into WildFly 10) but am flexible on that if the schedule could be flexible also. >> >> I liked your idea on HipChat. You could create a JPA branch and get it far enough along to run the JPA tck tests on it, and in the meantime everyone could fork that branch as needed for their development branches. Once we get promising looking results the branch can be converted into one or more PRs. > > This works for me, I mostly just wanted to get the Hibernate concerns about the schedule on the table (if there are any concerns). The only one that I know is that they would like Hibernate 5 support now, so Hibernate non-ORM projects can target WildFly now. I agree that we need the TCK picture before we merge. If there are a few minor failures thats fine, we can merge while those are being sorted out. The important thing would be to catch any major issues so that they can be addressed in time. Does 5 have significant TCK impacting changes? I heard there was work on a new query engine, but don?t remember if that was for 5 or the future. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From anmiller at redhat.com Thu May 28 12:07:18 2015 From: anmiller at redhat.com (Andrig T. Miller) Date: Thu, 28 May 2015 12:07:18 -0400 (EDT) Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <4165E7BC-4218-4D2C-A255-E1201B1585DB@redhat.com> References: <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <55672C8D.4060907@redhat.com> <4165E7BC-4218-4D2C-A255-E1201B1585DB@redhat.com> Message-ID: <12630729.1132.1432829235109.JavaMail.andrigtmiller@worklaptop.miller.org> ----- Original Message ----- > From: "Jason Greene" > To: "Scott Marlow" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, May 28, 2015 9:38:08 AM > Subject: Re: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 > > > > On May 28, 2015, at 9:56 AM, Scott Marlow > > wrote: > > > > > > On 05/28/2015 06:30 AM, Sanne Grinovero wrote: > >> Could someone explain please, why it's hard to have a deployer > >> just > >> use a different JPA implementor which the user might want to > >> provide? > > > > If you mean Hibernate 5.x specifically, we started the integration > > on > > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 > > > >> > >> I'm pretty sure I know how to start a JPA context in plain JavaSE, > >> and > >> don't need to know which implementor version I'm going to use, > >> other > >> than for sake of configuration. > >> > >> The WildFly documentation mentions this property > >> "jboss.as.jpa.providerModule", which sounds great on paper and it > >> would be a nice usability improvement if it would also actually > >> work > >> as it suggests. > > > > You are complaining a lot lately. We purposely designed for known > > use > > cases. There are other ways to get the dynamic environment that > > you are > > looking for then complaining that the WildFly JPA subsystem > > "jboss.as.jpa.providerModule" option doesn't work. > > I have probably missed other threads, but I didn?t take it as a > complaint, just more surprise and questioning if the behavior made > sense. Although, I shouldn?t speak for Sanne. I think its a sign > that we may need to improve our docs in this area, so that the > limitations are a bit more clear. > > As always I think its great for us to discuss if and how our > integrations could be better. > > > > >> > >> There's plenty of evidence on StackOverflow that the current > >> limitations are unexpected. For example, Spring moved to Hibernate > >> 5 > >> and people won't be able to use your stable line of the > >> application > >> server with Spring; I'd hope we could implement a plan to prevent > >> this > >> from happening at the next upgrade cycles. > > > > The question is whether the Hibernate 5.0 release schedule can > > align > > with the WildFly 10 schedule, so that we can do the work. > > Getting 5 into 10 as early as possible would be great. We are aiming > for a final release in Oct, which isn?t that far away. > +100. We need 5 in there from the performance teams perspective as early as possible. Andy > > > >> > >> Thanks, > >> Sanne > >> > >> On 21 May 2015 at 20:10, Scott Marlow wrote: > >>> > >>> > >>> On 05/21/2015 03:05 PM, Toma? Cerar wrote: > >>>> Scott, > >>>> > >>>> if you do one last jipijapa release that adds "support" for > >>>> hibernate5 > >>>> hibernate guys could take that version and override it in > >>>> wildfly 9 same > >>>> way as they add new h5 modules. > >>> > >>> I assume this will be an iterative process but sure, we could > >>> also push > >>> a release of the JIPI-31 branch. Lets keep talking about what is > >>> needed... > >>> > >>>> > >>>> -- > >>>> tomaz > >>>> > >>>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow > >>>> >>>> > wrote: > >>>> > >>>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > >>>>> Scott, No way to make ORM 5 work in 9 at all? With the user > >>>>> setting the additional slotted modules of course. > >>>> > >>>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 > >>>> contains the > >>>> integration code that we will look at merging into WildFly > >>>> 10. Are you > >>>> looking for a custom WildFly 9.x branch or actual changes in > >>>> WildFly 9 > >>>> (doesn't seem as likely to me but I don't control the > >>>> schedule)? > >>>> > >>>>> > >>>>> It would help speed up the Hibernate 5 stream adoption and > >>>>> avoid > >>>> a lot of duplicated work for 6+ months. > >>>>> > >>>>>> On 21 mai 2015, at 16:36, Scott Marlow >>>> > wrote: > >>>>>> > >>>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on > >>>> this soon > >>>>>> for WildFly 10. > >>>>>> > >>>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >>>>>>> Hi all, > >>>>>>> I'm attempting to deploy some integration tests on WildFly > >>>> 9.0.0.CR1 > >>>>>>> to use a preview of Hibernate ORM version 5. > >>>>>>> > >>>>>>> It seems the JPA deployer isn't allowing me to run such > >>>> experiments: > >>>>>>> > >>>>>>> # First experiment - providerModule set to custom module > >>>>>>> > >>>>>>> In my first attempt, I create a custom set of jboss modules > >>>>>>> which > >>>>>>> include the snapshot builds of ORM 5, add them to my > >>>>>>> standalone WF9 > >>>>>>> instance and set the persistence.xml property: > >>>>>>> jboss.as.jpa.providerModule = my-custom-module-name > >>>>>>> > >>>>>>> and then get: > >>>>>>> > >>>>>>> Caused by: java.util.ServiceConfigurationError: > >>>>>>> org.hibernate.integrator.spi.Integrator: Provider > >>>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a > >>>>>>> subtype > >>>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > >>>> [rt.jar:1.7.0_51] > >>>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) > >>>> [rt.jar:1.7.0_51] > >>>>>>> at > >>>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >>>>>>> [rt.jar:1.7.0_51] > >>>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > >>>> [rt.jar:1.7.0_51] > >>>>>>> at > >>>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >>>>>>> at > >>>> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > >>>>>>> at > >>>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >>>>>>> at > >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >>>>>>> at > >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > >>>>>>> at > >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > >>>>>>> at > >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >>>>>>> at > >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >>>>>>> at > >>>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > >>>>>>> at > >>>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >>>>>>> at > >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >>>>>>> at > >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >>>>>>> at > >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >>>>>>> ... 7 more > >>>>>>> > >>>>>>> Clearly it looks like I'm being served classes from the > >>>>>>> bundled > >>>>>>> Hibernate 4.x implementation - on top of those from the > >>>>>>> module I'm > >>>>>>> requesting. This isn't what the deployer should be doing, > >>>>>>> right? > >>>>>>> > >>>>>>> # Second experiment - use the "application provided" > >>>>>>> > >>>>>>> In this case I hope to hint the JPA deployer to not add the > >>>> default > >>>>>>> implementor but look for a JPA implementation within my > >>>>>>> deployment, > >>>>>>> but still package my custom Hibernate build as a module. > >>>>>>> > >>>>>>> - use the same custom module containing Hibernate ORM 5 (a > >>>> preview snapshot) > >>>>>>> - Add a "Dependency:" section to the manifest to import (and > >>>> export) > >>>>>>> my custom module > >>>>>>> - set the "jboss.as.jpa.providerModule" property to value > >>>> "application" > >>>>>>> > >>>>>>> This gets me: > >>>>>>> > >>>>>>> Caused by: > >>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >>>>>>> WFLYJPA0027: Persistence provider module load error > >>>>>>> application > >>>> (class > >>>>>>> org.hibernate.jpa.HibernatePersistenceProvider) > >>>>>>> at > >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >>>>>>> at > >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >>>>>>> at > >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >>>>>>> at > >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >>>>>>> at > >>>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >>>>>>> at > >>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >>>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >>>>>>> ... 5 more > >>>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: > >>>> application:main > >>>>>>> at > >>>>>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >>>>>>> [jboss-modules.jar:1.4.3.Final] > >>>>>>> at > >>>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >>>>>>> at > >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >>>>>>> ... 10 more > >>>>>>> > >>>>>>> Remarks: > >>>>>>> - it's attempting to load the "application:main" module?! > >>>> that's not > >>>>>>> what I'd expect from reading [1] > >>>>>> > >>>>>> This seems to be a bug. I hit it a few days ago when I > >>>>>> packaged > >>>>>> Hibernate ORM 4.1.x with an application (in a unit test) and > >>>> forgot to > >>>>>> set the persistence provider in persistence.xml. > >>>>>> > >>>>>>> - the provider should be available to the deployment > >>>> classpath, so > >>>>>>> I'm not sure why it's not finding the Provider? (I'm even > >>>>>>> exporting > >>>>>>> it, although I'm not sure if that was required). > >>>>>> > >>>>>> Providers are always found through the > >>>>>> javax.persistence.spi.PersistenceProviderResolver, not > >>>>>> directly > >>>> from the > >>>>>> deployment classpath. > >>>>>> > >>>>>>> > >>>>>>> Any suggestions to get this running please? > >>>>>>> > >>>>>>> Also I wonder if some of these should warrant opening a JIRA, > >>>> but I'm > >>>>>>> not sure how far I misunderstood the intentions of these JPA > >>>> deployer > >>>>>>> properties. > >>>>>> > >>>>>> Lets talk in a few days again on IRC. > >>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Sanne > >>>>>>> > >>>>>>> [1] - > >>>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > >>>>>> _______________________________________________ > >>>>>> 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 > >> > >> _______________________________________________ > >> 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 > > -- > 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 From steve at hibernate.org Thu May 28 12:09:22 2015 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 May 2015 11:09:22 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <77889EA1-0191-415F-9BEB-FDC94CB75CA5@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567338A.1090402@redhat.com> <270F918B-17CD-4142-9CB6-F3EAE9DF98FD@redhat.com> <55673B68.9040301@redhat.com> <77889EA1-0191-415F-9BEB-FDC94CB75CA5@redhat.com> Message-ID: On Thu, May 28, 2015 at 11:06 AM, Jason Greene wrote: Does 5 have significant TCK impacting changes? I heard there was work on a > new query engine, but don?t remember if that was for 5 or the future. There *should not* be. Of course, proof in always in the pudding :) The new query engine (its actually more ambitious than "just" the query engine) is a future roadmap item. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150528/2bd4668e/attachment-0001.html From smarlow at redhat.com Thu May 28 12:10:38 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 28 May 2015 12:10:38 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567377E.3070400@redhat.com> Message-ID: <55673DFE.5050100@redhat.com> On 05/28/2015 12:00 PM, Steve Ebersole wrote: > I discussed this last point with Scott. I'd prefer to drop support for > 4.x in WildFly 10. Ideally if that could mean "archiving" that support > so users could easily drop it in *if they chose*, great. By drop 4.x into WildFly, I think that we can allow users to copy jars into a 4.x static module and they can then use the "jboss.as.jpa.providerModule" hint in their persistence.xml. > > On Thu, May 28, 2015 at 10:56 AM, Jason Greene > wrote: > > > > On May 28, 2015, at 10:42 AM, Scott Marlow > wrote: > > > > > > > > On 05/28/2015 10:29 AM, Steve Ebersole wrote: > >> I am just not sure a lot of this is true. What > >> EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA > >> bootstrap SPI) contracts changed in 5.0? > > > > Minor changes so far: > > > > Some org.hibernate.jpa.boot.scan.spi package changes to org.hibernate.boot.archive.scan.spi. > > > > Configuration.USE_NEW_ID_GENERATOR_MAPPINGS is now AvailableSettings.USE_NEW_ID_GENERATOR_MAPPINGS. > > > >> > >> As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, > >> but we currently do not use it. So that actually should also not cause > >> any issues in regards to Hibernate 4.x or 5.0 > > > > We are not passing the IndexView in currently (we could if that becomes important in the future, as long as we don't keep a reference to the JandexView after the EMF is created). I don't think that would be helpful though as you need changes for XML file handling I think. > > That should be the eventual goal. We don?t want to process all > classes for annotations N times for every framework that wants to > read them, as it hurts deployment time. We had this before, we > really need to bring it back. > > > > >> > >> As far as using the standard JPA bootstrap SPIs, I agree this is up to > >> Scott. But it simply will not work for the way WildFly does stuff as I > >> understand it. > > > > This is really the first time that I have heard a complaint. I think its a timing issue, that people (like Sanne) have work to do but cannot get to it until WildFly switches to Hibernate 5.0. > > We tend to update to the latest hibernate revs very quickly, so I > haven?t seen much either, and so it might not be worth ?supporting". > It?s usually supporting old versions of hibernate that comes up, but > I think thats largely been addressed (we have integrations for 3 etc). > > > > >> > >> Second-level cache, yes, is a whole other ball of wax :) > > > > Yep, sometimes the second-level cache breaks in ways that we > don't detect, when we upgrade WildFly to a newer Infinispan version. > > > >> > >> > >> On Thu, May 28, 2015 at 9:18 AM, Jason Greene > > >> >> wrote: > >> > >> We implement the standard JPA integration SPI, but it is > absolutely > >> awful. > >> > >> It forces: > >> > >> - The construction of duplicate class loaders with duplicate > class > >> definitions of every class in the deployment > >> - Repeated runs of the deployment process > >> - Double loading of any class related to JPA (and its > dependencies) > >> - The JPA provider to use reflection for all annotation discovery > >> - Double use of reflection in the deployment process > >> - Bugs from chicken and egg problems > >> - Increased memory usage > >> > >> So for this reason WildFly and Hibernate have their own > integration > >> SPIs, and those SPIs are changing in hibernate 5. So WildFly > (well > >> currently JIPPAJAPPA) needs an update to be compatible with them. > >> Additionally we have the Jandex 2 change which is pending > that both > >> projects are attempting to align on. > >> > >> Now what I am not sure about, Scott will have to answer this. > Is if > >> you can use the standard JPA integration SPI with newer > versions of > >> Hibernate and just live with the nastiness it brings. > >> > >> However, there is still a secondary issue, which I am sure you > >> already know about is that the second level cache and hibernate > >> search have integrations that need to be compatible and in > sync and > >> tested. > >> > >> > On May 28, 2015, at 5:30 AM, Sanne Grinovero > > >> >> wrote: > >> > > >> > Could someone explain please, why it's hard to have a > deployer just > >> > use a different JPA implementor which the user might want > to provide? > >> > > >> > I'm pretty sure I know how to start a JPA context in plain > >> JavaSE, and > >> > don't need to know which implementor version I'm going to > use, other > >> > than for sake of configuration. > >> > > >> > The WildFly documentation mentions this property > >> > "jboss.as.jpa.providerModule", which sounds great on paper > and it > >> > would be a nice usability improvement if it would also > actually work > >> > as it suggests. > >> > > >> > There's plenty of evidence on StackOverflow that the current > >> > limitations are unexpected. For example, Spring moved to > Hibernate 5 > >> > and people won't be able to use your stable line of the > application > >> > server with Spring; I'd hope we could implement a plan to > prevent > >> this > >> > from happening at the next upgrade cycles. > >> > > >> > Thanks, > >> > Sanne > >> > > >> > On 21 May 2015 at 20:10, Scott Marlow > >> >> wrote: > >> >> > >> >> > >> >> On 05/21/2015 03:05 PM, Toma? Cerar wrote: > >> >>> Scott, > >> >>> > >> >>> if you do one last jipijapa release that adds "support" for > >> hibernate5 > >> >>> hibernate guys could take that version and override it in > >> wildfly 9 same > >> >>> way as they add new h5 modules. > >> >> > >> >> I assume this will be an iterative process but sure, we could > >> also push > >> >> a release of the JIPI-31 branch. Lets keep talking about > what > >> is needed... > >> >> > >> >>> > >> >>> -- > >> >>> tomaz > >> >>> > >> >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow > >> > > > >> >>> > >>> wrote: > >> >>> > >> >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > >> >>>> Scott, No way to make ORM 5 work in 9 at all? With the user > >> setting the additional slotted modules of course. > >> >>> > >> >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 > contains the > >> >>> integration code that we will look at merging into > WildFly > >> 10. Are you > >> >>> looking for a custom WildFly 9.x branch or actual > changes in > >> WildFly 9 > >> >>> (doesn't seem as likely to me but I don't control the > schedule)? > >> >>> > >> >>>> > >> >>>> It would help speed up the Hibernate 5 stream adoption > and avoid > >> >>> a lot of duplicated work for 6+ months. > >> >>>> > >> >>>>> On 21 mai 2015, at 16:36, Scott Marlow > > >> > > >> >>> >>> wrote: > >> >>>>> > >> >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will > push on > >> >>> this soon > >> >>>>> for WildFly 10. > >> >>>>> > >> >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >> >>>>>> Hi all, > >> >>>>>> I'm attempting to deploy some integration tests on > WildFly > >> >>> 9.0.0.CR1 > >> >>>>>> to use a preview of Hibernate ORM version 5. > >> >>>>>> > >> >>>>>> It seems the JPA deployer isn't allowing me to run such > >> >>> experiments: > >> >>>>>> > >> >>>>>> # First experiment - providerModule set to custom module > >> >>>>>> > >> >>>>>> In my first attempt, I create a custom set of jboss > modules > >> which > >> >>>>>> include the snapshot builds of ORM 5, add them to my > >> standalone WF9 > >> >>>>>> instance and set the persistence.xml property: > >> >>>>>> jboss.as.jpa.providerModule = my-custom-module-name > >> >>>>>> > >> >>>>>> and then get: > >> >>>>>> > >> >>>>>> Caused by: java.util.ServiceConfigurationError: > >> >>>>>> org.hibernate.integrator.spi.Integrator: Provider > >> >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a > >> subtype > >> >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > >> >>> [rt.jar:1.7.0_51] > >> >>>>>> at > java.util.ServiceLoader.access$300(ServiceLoader.java:181) > >> >>> [rt.jar:1.7.0_51] > >> >>>>>> at > >> >>> > >> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >> >>>>>> [rt.jar:1.7.0_51] > >> >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > >> >>> [rt.jar:1.7.0_51] > >> >>>>>> at > >> >>> > >> > org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >> >>>>>> at > >> >>> > >> > org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) > >> >>>>>> at > >> >>> > >> > org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >> >>>>>> at > >> >>> > >> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >> >>>>>> ... 7 more > >> >>>>>> > >> >>>>>> Clearly it looks like I'm being served classes from > the bundled > >> >>>>>> Hibernate 4.x implementation - on top of those from the > >> module I'm > >> >>>>>> requesting. This isn't what the deployer should be > doing, right? > >> >>>>>> > >> >>>>>> # Second experiment - use the "application provided" > >> >>>>>> > >> >>>>>> In this case I hope to hint the JPA deployer to not > add the > >> >>> default > >> >>>>>> implementor but look for a JPA implementation within my > >> deployment, > >> >>>>>> but still package my custom Hibernate build as a module. > >> >>>>>> > >> >>>>>> - use the same custom module containing Hibernate > ORM 5 (a > >> >>> preview snapshot) > >> >>>>>> - Add a "Dependency:" section to the manifest to > import (and > >> >>> export) > >> >>>>>> my custom module > >> >>>>>> - set the "jboss.as.jpa.providerModule" property to > value > >> >>> "application" > >> >>>>>> > >> >>>>>> This gets me: > >> >>>>>> > >> >>>>>> Caused by: > >> >>> > >> org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >> >>>>>> WFLYJPA0027: Persistence provider module load error > application > >> >>> (class > >> >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >> >>>>>> at > >> >>> > >> > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >> >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >> >>>>>> ... 5 more > >> >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: > >> >>> application:main > >> >>>>>> at > >> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >> >>>>>> [jboss-modules.jar:1.4.3.Final] > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >> >>>>>> at > >> >>> > >> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >> >>>>>> ... 10 more > >> >>>>>> > >> >>>>>> Remarks: > >> >>>>>> - it's attempting to load the "application:main" > module?! > >> >>> that's not > >> >>>>>> what I'd expect from reading [1] > >> >>>>> > >> >>>>> This seems to be a bug. I hit it a few days ago when > I packaged > >> >>>>> Hibernate ORM 4.1.x with an application (in a unit > test) and > >> >>> forgot to > >> >>>>> set the persistence provider in persistence.xml. > >> >>>>> > >> >>>>>> - the provider should be available to the deployment > >> >>> classpath, so > >> >>>>>> I'm not sure why it's not finding the Provider? (I'm even > >> exporting > >> >>>>>> it, although I'm not sure if that was required). > >> >>>>> > >> >>>>> Providers are always found through the > >> >>>>> javax.persistence.spi.PersistenceProviderResolver, not > directly > >> >>> from the > >> >>>>> deployment classpath. > >> >>>>> > >> >>>>>> > >> >>>>>> Any suggestions to get this running please? > >> >>>>>> > >> >>>>>> Also I wonder if some of these should warrant opening > a JIRA, > >> >>> but I'm > >> >>>>>> not sure how far I misunderstood the intentions of > these JPA > >> >>> deployer > >> >>>>>> properties. > >> >>>>> > >> >>>>> Lets talk in a few days again on IRC. > >> >>>>> > >> >>>>>> > >> >>>>>> Thanks, > >> >>>>>> Sanne > >> >>>>>> > >> >>>>>> [1] - > >> >>> > >> > https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties > >> >>>>> _______________________________________________ > >> >>>>> 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 > >> > > >> > _______________________________________________ > >> > 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 > >> > >> > >> > >> > >> _______________________________________________ > >> 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 jason.greene at redhat.com Thu May 28 12:16:12 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 28 May 2015 11:16:12 -0500 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <5567338A.1090402@redhat.com> <270F918B-17CD-4142-9CB6-F3EAE9DF98FD@redhat.com> <55673B68.9040301@redhat.com> <77889EA1-0191-415F-9BEB-FDC94CB75CA5@redhat.com> Message-ID: <3EA48A35-8632-4F14-BF19-A13A76B866A8@redhat.com> > On May 28, 2015, at 11:09 AM, Steve Ebersole wrote: > > On Thu, May 28, 2015 at 11:06 AM, Jason Greene > wrote: > > Does 5 have significant TCK impacting changes? I heard there was work on a new query engine, but don?t remember if that was for 5 or the future. > > There *should not* be. Of course, proof in always in the pudding :) > > The new query engine (its actually more ambitious than "just" the query engine) is a future roadmap item. Ah ok, In that case I think we should just try to merge it (when Scott has the WF test suite passing) and then chase down TCK regressions after. Hopefully that makes it better for everyone. -- 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/20150528/6cb8cba0/attachment.html From sanne at hibernate.org Thu May 28 16:26:12 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 May 2015 21:26:12 +0100 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: <4165E7BC-4218-4D2C-A255-E1201B1585DB@redhat.com> References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <55672C8D.4060907@redhat.com> <4165E7BC-4218-4D2C-A255-E1201B1585DB@redhat.com> Message-ID: On 28 May 2015 at 16:38, Jason Greene wrote: > >> On May 28, 2015, at 9:56 AM, Scott Marlow wrote: >> >> >> On 05/28/2015 06:30 AM, Sanne Grinovero wrote: >>> Could someone explain please, why it's hard to have a deployer just >>> use a different JPA implementor which the user might want to provide? >> >> If you mean Hibernate 5.x specifically, we started the integration on >> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 Thanks that's very nice, but I'm really just asking why such adapters are needed, and understand their purpose. For example since I have primarily "preview testing" needs I wonder if we could do something similar within our testing utilities, so to avoid bothering you in future for each and every update we might want to test. Another example could be to see if it makes sense to include the adapters within the Hibernate feature packs for WildFly - if the integration API is stable enough for the adapter to work with various servers that could lead us to work more together on jipijapa long before it's integrated in WF. For us it's not practical to lock Hibernate testing to WildFly releases, and doesn't help us to test new versions of Hibernate to run fine on versions of the application server which have already sailed. >> >>> >>> I'm pretty sure I know how to start a JPA context in plain JavaSE, and >>> don't need to know which implementor version I'm going to use, other >>> than for sake of configuration. >>> >>> The WildFly documentation mentions this property >>> "jboss.as.jpa.providerModule", which sounds great on paper and it >>> would be a nice usability improvement if it would also actually work >>> as it suggests. >> >> You are complaining a lot lately. We purposely designed for known use >> cases. There are other ways to get the dynamic environment that you are >> looking for then complaining that the WildFly JPA subsystem >> "jboss.as.jpa.providerModule" option doesn't work. > > I have probably missed other threads, but I didn?t take it as a complaint, just more surprise and questioning if the behavior made sense. Although, I shouldn?t speak for Sanne. I think its a sign that we may need to improve our docs in this area, so that the limitations are a bit more clear. Correct, and apologies for the wording Scott! I do realise I'm stretching the limits far beyond their intended usage, it's not shocking me to hit some surprises. I'm actually excited about the possibilities and didn't mean to "complain" but to point out an issue in hope to improve as I'd hope to use it. The documentation seems to claim this is as easy as to point to the module containing the JPA implementation of choice; that would be extremely handy to solve several testing issues we have - not only with Hibernate Search but across the board. Adding a clarification on which modules are accepted would be nice; although maybe then this option should rather be a closed enumeration of short hand names, rather than give the user the option to freely name any module? But please let's not change the meaning of this property if there is hope we could eventually get it to work with any custom JPA module. Thanks, Sanne > As always I think its great for us to discuss if and how our integrations could be better. > >> >>> >>> There's plenty of evidence on StackOverflow that the current >>> limitations are unexpected. For example, Spring moved to Hibernate 5 >>> and people won't be able to use your stable line of the application >>> server with Spring; I'd hope we could implement a plan to prevent this >>> from happening at the next upgrade cycles. >> >> The question is whether the Hibernate 5.0 release schedule can align >> with the WildFly 10 schedule, so that we can do the work. > > Getting 5 into 10 as early as possible would be great. We are aiming for a final release in Oct, which isn?t that far away. > >> >>> >>> Thanks, >>> Sanne >>> >>> On 21 May 2015 at 20:10, Scott Marlow wrote: >>>> >>>> >>>> On 05/21/2015 03:05 PM, Toma? Cerar wrote: >>>>> Scott, >>>>> >>>>> if you do one last jipijapa release that adds "support" for hibernate5 >>>>> hibernate guys could take that version and override it in wildfly 9 same >>>>> way as they add new h5 modules. >>>> >>>> I assume this will be an iterative process but sure, we could also push >>>> a release of the JIPI-31 branch. Lets keep talking about what is needed... >>>> >>>>> >>>>> -- >>>>> tomaz >>>>> >>>>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >>>> > wrote: >>>>> >>>>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >>>>>> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >>>>> >>>>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >>>>> integration code that we will look at merging into WildFly 10. Are you >>>>> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >>>>> (doesn't seem as likely to me but I don't control the schedule)? >>>>> >>>>>> >>>>>> It would help speed up the Hibernate 5 stream adoption and avoid >>>>> a lot of duplicated work for 6+ months. >>>>>> >>>>>>> On 21 mai 2015, at 16:36, Scott Marlow >>>> > wrote: >>>>>>> >>>>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >>>>> this soon >>>>>>> for WildFly 10. >>>>>>> >>>>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>>>>>> Hi all, >>>>>>>> I'm attempting to deploy some integration tests on WildFly >>>>> 9.0.0.CR1 >>>>>>>> to use a preview of Hibernate ORM version 5. >>>>>>>> >>>>>>>> It seems the JPA deployer isn't allowing me to run such >>>>> experiments: >>>>>>>> >>>>>>>> # First experiment - providerModule set to custom module >>>>>>>> >>>>>>>> In my first attempt, I create a custom set of jboss modules which >>>>>>>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>>>>>>> instance and set the persistence.xml property: >>>>>>>> jboss.as.jpa.providerModule = my-custom-module-name >>>>>>>> >>>>>>>> and then get: >>>>>>>> >>>>>>>> Caused by: java.util.ServiceConfigurationError: >>>>>>>> org.hibernate.integrator.spi.Integrator: Provider >>>>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>>>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >>>>> [rt.jar:1.7.0_51] >>>>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >>>>> [rt.jar:1.7.0_51] >>>>>>>> at >>>>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>>>>>> [rt.jar:1.7.0_51] >>>>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >>>>> [rt.jar:1.7.0_51] >>>>>>>> at >>>>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>>>>>> at >>>>> org.hibernate.integrator.internal.IntegratorServiceImpl.(IntegratorServiceImpl.java:57) >>>>>>>> at >>>>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>>>>>> at >>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>>>>>> at >>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:208) >>>>>>>> at >>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:188) >>>>>>>> at >>>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>>>>>> at >>>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>>>>>> at >>>>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.(TwoPhaseBootstrapImpl.java:38) >>>>>>>> at >>>>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>>>>>> at >>>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>>>>>> at >>>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>>>>>> at >>>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>>>>>> ... 7 more >>>>>>>> >>>>>>>> Clearly it looks like I'm being served classes from the bundled >>>>>>>> Hibernate 4.x implementation - on top of those from the module I'm >>>>>>>> requesting. This isn't what the deployer should be doing, right? >>>>>>>> >>>>>>>> # Second experiment - use the "application provided" >>>>>>>> >>>>>>>> In this case I hope to hint the JPA deployer to not add the >>>>> default >>>>>>>> implementor but look for a JPA implementation within my deployment, >>>>>>>> but still package my custom Hibernate build as a module. >>>>>>>> >>>>>>>> - use the same custom module containing Hibernate ORM 5 (a >>>>> preview snapshot) >>>>>>>> - Add a "Dependency:" section to the manifest to import (and >>>>> export) >>>>>>>> my custom module >>>>>>>> - set the "jboss.as.jpa.providerModule" property to value >>>>> "application" >>>>>>>> >>>>>>>> This gets me: >>>>>>>> >>>>>>>> Caused by: >>>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>>>>>> WFLYJPA0027: Persistence provider module load error application >>>>> (class >>>>>>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>>>>>> at >>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>>>>>> at >>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>>>>>> at >>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>>>>>> at >>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>>>>>> at >>>>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>>>>>> at >>>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>>>>>> ... 5 more >>>>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >>>>> application:main >>>>>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>>>>>> [jboss-modules.jar:1.4.3.Final] >>>>>>>> at >>>>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>>>>>> at >>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>>>>>> ... 10 more >>>>>>>> >>>>>>>> Remarks: >>>>>>>> - it's attempting to load the "application:main" module?! >>>>> that's not >>>>>>>> what I'd expect from reading [1] >>>>>>> >>>>>>> This seems to be a bug. I hit it a few days ago when I packaged >>>>>>> Hibernate ORM 4.1.x with an application (in a unit test) and >>>>> forgot to >>>>>>> set the persistence provider in persistence.xml. >>>>>>> >>>>>>>> - the provider should be available to the deployment >>>>> classpath, so >>>>>>>> I'm not sure why it's not finding the Provider? (I'm even exporting >>>>>>>> it, although I'm not sure if that was required). >>>>>>> >>>>>>> Providers are always found through the >>>>>>> javax.persistence.spi.PersistenceProviderResolver, not directly >>>>> from the >>>>>>> deployment classpath. >>>>>>> >>>>>>>> >>>>>>>> Any suggestions to get this running please? >>>>>>>> >>>>>>>> Also I wonder if some of these should warrant opening a JIRA, >>>>> but I'm >>>>>>>> not sure how far I misunderstood the intentions of these JPA >>>>> deployer >>>>>>>> properties. >>>>>>> >>>>>>> Lets talk in a few days again on IRC. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sanne >>>>>>>> >>>>>>>> [1] - >>>>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> _______________________________________________ >>> 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 > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > From sanne at hibernate.org Thu May 28 17:51:13 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 May 2015 22:51:13 +0100 Subject: [wildfly-dev] Moving component projects to a "feature pack" model? Message-ID: # WHAT WE DID SO FAR (and worked quite ok) Since a couple of years, when releasing Hibernate Search, Hibernate OGM, Infinispan and other projects, besides merely uploading our jar and pom.xml files to Nexus we also upload a large tarball containing modules for WildFly: an "add on layer", not only useful for end users but also some other projects rely on this (e.g. Infinispan consumes the Hibernate Search one to keep an aggressive improvement pace). With each build of the projects these modules are not just built but also tested: integration tests download the latest stable WildFly version which we target, untar it, untar our own modules as a layer, run some Arquillian tests. Invaluable to get all dependency definitions and classloading right! # GOALS -- to make sure people can download our latest release, and it will work on their favourite app server -- to be ready knowing how a stable module structure should be shaped, when a new version of WildFly integrates our latest -- to benefit from the modules system by allowing different versions to co-exist on the same appserver (some people/project/product require this) # NOT PERFECT This second goal had some issues recently, namely that while we know how we should structure the modules within WildFly, it happened that this wasn't re-creating exactly the model of what had been carefully tested within our project. The problem is that we have to repeat the build scripting - result might not be identical for obvious reasons - while most integration tests reside within the project. # FEATURE PACKS Tomaz was so nice to show me how to define feature packs, so that the WildFly build can - at build time - include the structure we define. It looks very promising, but on some areas we'll need some suggestions or perhaps a further evolution? # NEEDED IMPROVEMENTS / SUGGESTIONS ? How do we test the feature pack ? The goal of having WildFly use the module structure that we build "verbatim" is only interesting if we make sure these packs work correctly. Ideally we'd like to deploy them in Arquillian tests like we did with modules, and run integration tests on each commit. ? How can end users benefit from these ? We'd really want to enable our pool of users and contributors to use (and test!) any of our releases from "day zero". Typically people will want to run it on the latest stable version of WildFly, which implies something releases before "day zero". ? Versions and slot identifiers ? We release approximately every three weeks on average, and our slot conventions expect that "our" module releases use the slot={releaseVersion}, while the module included in WildFly has the slot="main". This seems to imply some need for slot transformations when the feature pack is consumed. ? Aliases ? We also include module aliases for each Major.Minor combination for the public-api module, which resolves to the latest major.minor.micro of the matching version. This is important to make sure we can include references to module dependencies maintained in other projects but limiting the scope to a compatible range, for example we have an optional dependency on Infinispan, not all Infinispan versions are compatible. My preferred solution would be to have WildFly actually not use "main" slot internally, but use our same alias pattern and in addition have an alias module - for the public API only - which has slot "main" resolve to the "major.minor" of the Hibernate Search version which was included. There are many benefits to this model, I'll avoid repeating them in this email; I shared some thoughts before: - http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003787.html I would love it if a similar pattern was to be applied to other modules, for example Hibernate Search doesn't work with any version of Hibernate ORM so depending on "slot main" has some dangers. Even more important when we deal with other modules released by other projects in similar packaging. ? "System" modules ? I noticed the feature pack structure includes the path to the module layer, i.e. modules/system/layers/base/.. But I take it we don't want to classify our "independently" released modules as belonging to the system/base layer? ? Conflicting versions ? I noticed the versions of all dependencies are listed once, in the root metadata of the feature pack. In some projects, like Hibernate OGM, we take strong advantage of modularity and actually bundle some libraries multiple times - of different versions - and use the modules magic to keep them strictly isolated. Is this going to be possible? Thanks in advance for any suggestions! Sanne From junior.jairo1 at gmail.com Thu May 28 19:39:52 2015 From: junior.jairo1 at gmail.com (Jairo Junior) Date: Thu, 28 May 2015 23:39:52 +0000 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> Message-ID: Heiko, Thank you, but how do I build a ModelNode from a CLI command? Before using JSON I was investigating how Administration Console perform operations and I realized (using firebug) that it uses application/dmr, but I presumed it uses ModelNode to build commands, not plain CLI syntax. On Thu, May 28, 2015 at 5:58 AM Heiko Braun wrote: > The DMR library can be found here: > > https://github.com/jbossas/jboss-dmr > > > On 28 May 2015, at 10:56, Heiko Braun wrote: > > > You can already use DMR over HTTP. It requires a different content-type > ('application/dmr-encoded') and uses a base64 encoded representation of the > payload ('ModelNode.toBase64String()'). > > You can describe an operation through the DMR API and then simply do HTTP > POST to ?/management? endpoint. make sure to use 'application/dmr-encoded? > for both 'Content-Type' and ?Accept? headers. > > The response can be parse using 'ModelNode.fromBase64()'. > > Hope this helps, > Heiko > > > > On 27 May 2015, at 19:54, Jairo Junior wrote: > > I've been working on a Puppet Module for Wildfly [1] that uses his HTTP > Management API to perform operations (manage resources/deploys and execute > commands), but my command execution code is a little bit limited cause I > have to transform from CLI syntax to JSON. e.g.: > > :shutdown(restart=true) > > becomes > > {"operation" : "shutdown", "restart" : "true" } > > Is there any specific reason to not support plain CLI commands through > HTTP API? I looked at the code and it didn't see hard to implement this... > > [1] https://github.com/biemond/biemond-wildfly > > _______________________________________________ > 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/20150528/d0e1165c/attachment.html From mazz at redhat.com Thu May 28 22:14:07 2015 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 28 May 2015 22:14:07 -0400 (EDT) Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> Message-ID: <154687439.7326852.1432865647477.JavaMail.zimbra@redhat.com> FYI: This might be useful... Hawkular has a DMR client library built on top of the ModelNode/ModelControllerClient stuff - it is meant to be a more strongly typed library that helps you not have to know how to do all the low level ModelNode stuff to do basic things (though it still allows you to send custom ModelNode requests). It's here: https://github.com/hawkular/hawkular-agent/tree/master/hawkular-dmr-client/src/main/java/org/hawkular/dmrclient released here: https://repository.jboss.org/nexus/content/groups/public/org/hawkular/agent/hawkular-dmr-client/ which includes javadoc/source jars. Doesn't give you "everything", but it has the basics and then some for what we need it for. This lib will get built out as we need more functionality. Example usage: ModelControllerClient mcc; // get this somehow - usually by ModelControllerClient.Factory.create CoreJBossASClient client = new CoreJBossASClient(mcc); // use one of the provided JBossASClient subclasses String dataDir = client.getAppServerDataDir(); // gets the app server's data directory ModelNode node = client.readResource(Address.parse("/deployment=foo.war")); // gets info on foo.war ... DeploymentJBossASClient dClient = new DeploymentJBossASClient(mcc); // to do deployment specific things dClient.enableDeployment("foo.war"); ... etc, etc... a bunch of subclasses to JBossASClient that lets you do specific things to things like datasources, logging, web connectors, etc. ----- Original Message ----- > Heiko, > > Thank you, but how do I build a ModelNode from a CLI command? > > Before using JSON I was investigating how Administration Console perform > operations and I realized (using firebug) that it uses application/dmr, but > I presumed it uses ModelNode to build commands, not plain CLI syntax. > > On Thu, May 28, 2015 at 5:58 AM Heiko Braun < hbraun at redhat.com > wrote: > > > > The DMR library can be found here: > > https://github.com/jbossas/jboss-dmr > > > > > > On 28 May 2015, at 10:56, Heiko Braun < hbraun at redhat.com > wrote: > > > You can already use DMR over HTTP. It requires a different content-type > ('application/dmr-encoded') and uses a base64 encoded representation of the > payload ('ModelNode.toBase64String()'). > > You can describe an operation through the DMR API and then simply do HTTP > POST to ?/management? endpoint. make sure to use 'application/dmr-encoded? > for both 'Content-Type' and ?Accept? headers. > > The response can be parse using 'ModelNode.fromBase64()'. > > Hope this helps, > Heiko > > > > > > On 27 May 2015, at 19:54, Jairo Junior < junior.jairo1 at gmail.com > wrote: > > I've been working on a Puppet Module for Wildfly [1] that uses his HTTP > Management API to perform operations (manage resources/deploys and execute > commands), but my command execution code is a little bit limited cause I > have to transform from CLI syntax to JSON. e.g.: > > :shutdown(restart=true) > > becomes > > {"operation" : "shutdown", "restart" : "true" } > > Is there any specific reason to not support plain CLI commands through HTTP > API? I looked at the code and it didn't see hard to implement this... > > [1] https://github.com/biemond/biemond-wildfly > > _______________________________________________ > 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 rstryker at redhat.com Fri May 29 03:25:24 2015 From: rstryker at redhat.com (Rob Stryker) Date: Fri, 29 May 2015 03:25:24 -0400 Subject: [wildfly-dev] Question on frozen management client Message-ID: <55681464.6020909@redhat.com> Hey All: I've been trying to dig into this for a while but really haven't gotten very far. Glance at https://issues.jboss.org/browse/JBIDE-19641 It seems our client (jbosstools) appears to have frozen while sending a large war over mgmt api for deployment. Unfortunately, looking at the stacks doesn't show anything strange. In fact, it seems the transfer is still in effect. However, our user indicates that disk activity (ie transfer) has ceased, and yet the client jar classes have not indicated the transfer was done or aborted. The class we use to perform the mgmt publish is https://github.com/jbosstools/jbosstools-server/blob/master/as/plugins/org.jboss.ide.eclipse.as.management.wildfly8/src/org/jboss/ide/eclipse/as/internal/management/wildfly8/Wildfly8Manager.java It's pretty simple, but QE is indicating it freezes and after a short while, nothing happens. I was wondering if anyone here might have any insight? QE indicates the transfer works fine over jboss-cli, but not in jbt. Thanks in advance. - Rob Stryker From psotirop at redhat.com Fri May 29 05:45:47 2015 From: psotirop at redhat.com (Panagiotis Sotiropoulos) Date: Fri, 29 May 2015 05:45:47 -0400 (EDT) Subject: [wildfly-dev] Moving component projects to a "feature pack" model? In-Reply-To: References: Message-ID: <2015403018.9084562.1432892747755.JavaMail.zimbra@redhat.com> # SOME ADDITIONAL CONCERNS 1. Addition of optional subsystems on Wildfly Is there some standardized way to add optional subsystems and addtional modules (using the feature pack model) on wildfly without building the server again? While trying to create such an optional subsystem (https://developer.jboss.org/wiki/JBoss-Automated-Metrics) , I came across wildfly-extension-plugin (http://lzoubek.github.io/wildfly-extension-maven-plugin/) created by Libor Zoubek, which seems to do the trick. Is this the standardized way that is used in general? 2 How about creating a unified testsuite for all the servers Would it make sense to create a unified testsuite where the tests would be tested against all the servers (eap, wildfly releases)? So, decoupling the testsuite from the servers, writing the tests once (one repo) and testing against all servers. ----- Original Message ----- From: "Sanne Grinovero" To: wildfly-dev at lists.jboss.org Sent: Thursday, May 28, 2015 11:51:13 PM Subject: [wildfly-dev] Moving component projects to a "feature pack" model? # WHAT WE DID SO FAR (and worked quite ok) Since a couple of years, when releasing Hibernate Search, Hibernate OGM, Infinispan and other projects, besides merely uploading our jar and pom.xml files to Nexus we also upload a large tarball containing modules for WildFly: an "add on layer", not only useful for end users but also some other projects rely on this (e.g. Infinispan consumes the Hibernate Search one to keep an aggressive improvement pace). With each build of the projects these modules are not just built but also tested: integration tests download the latest stable WildFly version which we target, untar it, untar our own modules as a layer, run some Arquillian tests. Invaluable to get all dependency definitions and classloading right! # GOALS -- to make sure people can download our latest release, and it will work on their favourite app server -- to be ready knowing how a stable module structure should be shaped, when a new version of WildFly integrates our latest -- to benefit from the modules system by allowing different versions to co-exist on the same appserver (some people/project/product require this) # NOT PERFECT This second goal had some issues recently, namely that while we know how we should structure the modules within WildFly, it happened that this wasn't re-creating exactly the model of what had been carefully tested within our project. The problem is that we have to repeat the build scripting - result might not be identical for obvious reasons - while most integration tests reside within the project. # FEATURE PACKS Tomaz was so nice to show me how to define feature packs, so that the WildFly build can - at build time - include the structure we define. It looks very promising, but on some areas we'll need some suggestions or perhaps a further evolution? # NEEDED IMPROVEMENTS / SUGGESTIONS ? How do we test the feature pack ? The goal of having WildFly use the module structure that we build "verbatim" is only interesting if we make sure these packs work correctly. Ideally we'd like to deploy them in Arquillian tests like we did with modules, and run integration tests on each commit. ? How can end users benefit from these ? We'd really want to enable our pool of users and contributors to use (and test!) any of our releases from "day zero". Typically people will want to run it on the latest stable version of WildFly, which implies something releases before "day zero". ? Versions and slot identifiers ? We release approximately every three weeks on average, and our slot conventions expect that "our" module releases use the slot={releaseVersion}, while the module included in WildFly has the slot="main". This seems to imply some need for slot transformations when the feature pack is consumed. ? Aliases ? We also include module aliases for each Major.Minor combination for the public-api module, which resolves to the latest major.minor.micro of the matching version. This is important to make sure we can include references to module dependencies maintained in other projects but limiting the scope to a compatible range, for example we have an optional dependency on Infinispan, not all Infinispan versions are compatible. My preferred solution would be to have WildFly actually not use "main" slot internally, but use our same alias pattern and in addition have an alias module - for the public API only - which has slot "main" resolve to the "major.minor" of the Hibernate Search version which was included. There are many benefits to this model, I'll avoid repeating them in this email; I shared some thoughts before: - http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003787.html I would love it if a similar pattern was to be applied to other modules, for example Hibernate Search doesn't work with any version of Hibernate ORM so depending on "slot main" has some dangers. Even more important when we deal with other modules released by other projects in similar packaging. ? "System" modules ? I noticed the feature pack structure includes the path to the module layer, i.e. modules/system/layers/base/.. But I take it we don't want to classify our "independently" released modules as belonging to the system/base layer? ? Conflicting versions ? I noticed the versions of all dependencies are listed once, in the root metadata of the feature pack. In some projects, like Hibernate OGM, we take strong advantage of modularity and actually bundle some libraries multiple times - of different versions - and use the modules magic to keep them strictly isolated. Is this going to be possible? Thanks in advance for any suggestions! Sanne _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From hbraun at redhat.com Fri May 29 07:17:03 2015 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 29 May 2015 13:17:03 +0200 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> Message-ID: What the constraints when developing a puppet module? Is plain java supported? > Am 29.05.2015 um 01:39 schrieb Jairo Junior : > > Heiko, > > Thank you, but how do I build a ModelNode from a CLI command? > > Before using JSON I was investigating how Administration Console perform operations and I realized (using firebug) that it uses application/dmr, but I presumed it uses ModelNode to build commands, not plain CLI syntax. > >> On Thu, May 28, 2015 at 5:58 AM Heiko Braun wrote: >> The DMR library can be found here: >> >> https://github.com/jbossas/jboss-dmr >> >> >>> On 28 May 2015, at 10:56, Heiko Braun wrote: >>> >>> >>> You can already use DMR over HTTP. It requires a different content-type ('application/dmr-encoded') and uses a base64 encoded representation of the payload ('ModelNode.toBase64String()'). >>> >>> You can describe an operation through the DMR API and then simply do HTTP POST to ?/management? endpoint. make sure to use 'application/dmr-encoded? for both 'Content-Type' and ?Accept? headers. >>> >>> The response can be parse using 'ModelNode.fromBase64()'. >>> >>> Hope this helps, >>> Heiko >>> >>> >>> >>>> On 27 May 2015, at 19:54, Jairo Junior wrote: >>>> >>>> I've been working on a Puppet Module for Wildfly [1] that uses his HTTP Management API to perform operations (manage resources/deploys and execute commands), but my command execution code is a little bit limited cause I have to transform from CLI syntax to JSON. e.g.: >>>> >>>> :shutdown(restart=true) >>>> >>>> becomes >>>> >>>> {"operation" : "shutdown", "restart" : "true" } >>>> >>>> Is there any specific reason to not support plain CLI commands through HTTP API? I looked at the code and it didn't see hard to implement this... >>>> >>>> [1] https://github.com/biemond/biemond-wildfly >>>> >>>> _______________________________________________ >>>> 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/20150529/80f0b207/attachment.html From junior.jairo1 at gmail.com Fri May 29 08:11:42 2015 From: junior.jairo1 at gmail.com (Jairo Junior) Date: Fri, 29 May 2015 12:11:42 +0000 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> Message-ID: No, it's not. Only ruby. Although, I could use JRuby to import and use Java classes, it would give me more trouble than solutions. What I want is: An interoperable way to talk with JBoss. application/dmr is a binary/proprietary format. On Fri, May 29, 2015 at 8:17 AM Heiko Braun wrote: > What the constraints when developing a puppet module? Is plain java > supported? > > > > > Am 29.05.2015 um 01:39 schrieb Jairo Junior : > > Heiko, > > Thank you, but how do I build a ModelNode from a CLI command? > > Before using JSON I was investigating how Administration Console perform > operations and I realized (using firebug) that it uses application/dmr, but > I presumed it uses ModelNode to build commands, not plain CLI syntax. > > On Thu, May 28, 2015 at 5:58 AM Heiko Braun wrote: > >> The DMR library can be found here: >> >> https://github.com/jbossas/jboss-dmr >> >> >> On 28 May 2015, at 10:56, Heiko Braun wrote: >> >> >> You can already use DMR over HTTP. It requires a different content-type >> ('application/dmr-encoded') and uses a base64 encoded representation of the >> payload ('ModelNode.toBase64String()'). >> >> You can describe an operation through the DMR API and then simply do HTTP >> POST to ?/management? endpoint. make sure to use 'application/dmr-encoded? >> for both 'Content-Type' and ?Accept? headers. >> >> The response can be parse using 'ModelNode.fromBase64()'. >> >> Hope this helps, >> Heiko >> >> >> >> On 27 May 2015, at 19:54, Jairo Junior wrote: >> >> I've been working on a Puppet Module for Wildfly [1] that uses his HTTP >> Management API to perform operations (manage resources/deploys and execute >> commands), but my command execution code is a little bit limited cause I >> have to transform from CLI syntax to JSON. e.g.: >> >> :shutdown(restart=true) >> >> becomes >> >> {"operation" : "shutdown", "restart" : "true" } >> >> Is there any specific reason to not support plain CLI commands through >> HTTP API? I looked at the code and it didn't see hard to implement this... >> >> [1] https://github.com/biemond/biemond-wildfly >> >> _______________________________________________ >> 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/20150529/291bd17a/attachment.html From darran.lofthouse at jboss.com Fri May 29 08:22:36 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 29 May 2015 13:22:36 +0100 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> Message-ID: <55685A0C.4000102@jboss.com> It was written a couple of years back but this is a good blog post to look at for different clients sending in management requests: - http://pilhuhn.blogspot.co.uk/2012/01/polyglot-management-of-secured-as7.html You don't need to go as far as the Base64 encoding and decoding if you do not want to and just create the json formatted requests and parse the json responses. Regards, Darran Lofthouse. On 29/05/15 13:11, Jairo Junior wrote: > No, it's not. Only ruby. Although, I could use JRuby to import and use > Java classes, it would give me more trouble than solutions. > > What I want is: An interoperable way to talk with JBoss. application/dmr > is a binary/proprietary format. > > On Fri, May 29, 2015 at 8:17 AM Heiko Braun > wrote: > > What the constraints when developing a puppet module? Is plain java > supported? > > > > > Am 29.05.2015 um 01:39 schrieb Jairo Junior >: > >> Heiko, >> >> Thank you, but how do I build a ModelNode from a CLI command? >> >> Before using JSON I was investigating how Administration Console >> perform operations and I realized (using firebug) that it uses >> application/dmr, but I presumed it uses ModelNode to build >> commands, not plain CLI syntax. >> >> On Thu, May 28, 2015 at 5:58 AM Heiko Braun > > wrote: >> >> The DMR library can be found here: >> >> https://github.com/jbossas/jboss-dmr >> >> >>> On 28 May 2015, at 10:56, Heiko Braun >> > wrote: >>> >>> >>> You can already use DMR over HTTP. It requires a different >>> content-type ('application/dmr-encoded') and uses a base64 >>> encoded representation of the payload >>> ('ModelNode.toBase64String()'). >>> >>> You can describe an operation through the DMR API and then >>> simply do HTTP POST to ?/management? endpoint. make sure to >>> use 'application/dmr-encoded? for both 'Content-Type' and >>> ?Accept? headers. >>> >>> The response can be parse using 'ModelNode.fromBase64()'. >>> >>> Hope this helps, >>> Heiko >>> >>> >>> >>>> On 27 May 2015, at 19:54, Jairo Junior >>>> > >>>> wrote: >>>> >>>> I've been working on a Puppet Module for Wildfly [1] that >>>> uses his HTTP Management API to perform operations (manage >>>> resources/deploys and execute commands), but my command >>>> execution code is a little bit limited cause I have to >>>> transform from CLI syntax to JSON. e.g.: >>>> >>>> :shutdown(restart=true) >>>> >>>> becomes >>>> >>>> {"operation" : "shutdown", "restart" : "true" } >>>> >>>> Is there any specific reason to not support plain CLI >>>> commands through HTTP API? I looked at the code and it >>>> didn't see hard to implement this... >>>> >>>> [1] https://github.com/biemond/biemond-wildfly >>>> >>>> _______________________________________________ >>>> 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 ttarrant at redhat.com Fri May 29 08:22:39 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 29 May 2015 14:22:39 +0200 Subject: [wildfly-dev] Transaction subsystem dependencies Message-ID: <55685A0F.6030405@redhat.com> Hi all, I'm reworking the Infinispan Server package so that it is built around WildFly Core as I want to keep it as lean as possible. I need to pull in a couple of additional subsystems from WildFly proper and one of them is causing some head-scratching: the transactions subsystem. It has a bunch of hard dependencies on a ton of modules which really sound optional. Examples: - the IIOP stuff - Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld) - HornetQ None of the above are really needed by Infinispan Server. I guess I could apply manual surgery to the module.xml file to remove stuff I think is unnecessary and let my testsuite verify if I'm being too aggressive, but I was wondering whether it would be better for the upstream project to be a bit more careful with the dependencies. Thanks for any suggestions Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From junior.jairo1 at gmail.com Fri May 29 08:38:38 2015 From: junior.jairo1 at gmail.com (Jairo Junior) Date: Fri, 29 May 2015 12:38:38 +0000 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: <55685A0C.4000102@jboss.com> References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> <55685A0C.4000102@jboss.com> Message-ID: Darran, Thank you, wish I had found your blog post before. Fortunately, I was able to build almost the same thing with a lot of effort: https://github.com/biemond/biemond-wildfly/blob/master/lib/puppet_x/util/wildfly_cli.rb My point is: Sysadmins often build CLI scripts to automate tasks and I want to "reuse" this knowledge in HTTP API. Sysadmins don't talk JSON, they talk CLI... I heard somewhere that jboss-cli.sh and Management Console are using the same HTTP API in Wildfly, but I'm not sure how jboss-cli.sh use this commands... In fact, I tried to use jboss-cli.sh but bash is incredible slow compared to HTTP API: https://github.com/cpitman/puppet-jboss_admin/issues/68 On Fri, May 29, 2015 at 9:22 AM Darran Lofthouse wrote: > It was written a couple of years back but this is a good blog post to > look at for different clients sending in management requests: - > > > http://pilhuhn.blogspot.co.uk/2012/01/polyglot-management-of-secured-as7.html > > You don't need to go as far as the Base64 encoding and decoding if you > do not want to and just create the json formatted requests and parse the > json responses. > > Regards, > Darran Lofthouse. > > On 29/05/15 13:11, Jairo Junior wrote: > > No, it's not. Only ruby. Although, I could use JRuby to import and use > > Java classes, it would give me more trouble than solutions. > > > > What I want is: An interoperable way to talk with JBoss. application/dmr > > is a binary/proprietary format. > > > > On Fri, May 29, 2015 at 8:17 AM Heiko Braun > > wrote: > > > > What the constraints when developing a puppet module? Is plain java > > supported? > > > > > > > > > > Am 29.05.2015 um 01:39 schrieb Jairo Junior > >: > > > >> Heiko, > >> > >> Thank you, but how do I build a ModelNode from a CLI command? > >> > >> Before using JSON I was investigating how Administration Console > >> perform operations and I realized (using firebug) that it uses > >> application/dmr, but I presumed it uses ModelNode to build > >> commands, not plain CLI syntax. > >> > >> On Thu, May 28, 2015 at 5:58 AM Heiko Braun >> > wrote: > >> > >> The DMR library can be found here: > >> > >> https://github.com/jbossas/jboss-dmr > >> > >> > >>> On 28 May 2015, at 10:56, Heiko Braun >>> > wrote: > >>> > >>> > >>> You can already use DMR over HTTP. It requires a different > >>> content-type ('application/dmr-encoded') and uses a base64 > >>> encoded representation of the payload > >>> ('ModelNode.toBase64String()'). > >>> > >>> You can describe an operation through the DMR API and then > >>> simply do HTTP POST to ?/management? endpoint. make sure to > >>> use 'application/dmr-encoded? for both 'Content-Type' and > >>> ?Accept? headers. > >>> > >>> The response can be parse using 'ModelNode.fromBase64()'. > >>> > >>> Hope this helps, > >>> Heiko > >>> > >>> > >>> > >>>> On 27 May 2015, at 19:54, Jairo Junior > >>>> > > >>>> wrote: > >>>> > >>>> I've been working on a Puppet Module for Wildfly [1] that > >>>> uses his HTTP Management API to perform operations (manage > >>>> resources/deploys and execute commands), but my command > >>>> execution code is a little bit limited cause I have to > >>>> transform from CLI syntax to JSON. e.g.: > >>>> > >>>> :shutdown(restart=true) > >>>> > >>>> becomes > >>>> > >>>> {"operation" : "shutdown", "restart" : "true" } > >>>> > >>>> Is there any specific reason to not support plain CLI > >>>> commands through HTTP API? I looked at the code and it > >>>> didn't see hard to implement this... > >>>> > >>>> [1] https://github.com/biemond/biemond-wildfly > >>>> > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev at lists.jboss.org 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/20150529/b60130e5/attachment-0001.html From smarlow at redhat.com Fri May 29 08:39:51 2015 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 29 May 2015 08:39:51 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: <555DED7C.2070607@redhat.com> <343653F6-64FA-4E29-BC46-4E081095FA8D@hibernate.org> <555E2B84.6020600@redhat.com> <555E2D93.3000700@redhat.com> <55672C8D.4060907@redhat.com> <4165E7BC-4218-4D2C-A255-E1201B1585DB@redhat.com> Message-ID: <55685E17.6060803@redhat.com> On 05/28/2015 04:26 PM, Sanne Grinovero wrote: > On 28 May 2015 at 16:38, Jason Greene wrote: >> >>> On May 28, 2015, at 9:56 AM, Scott Marlow wrote: >>> >>> >>> On 05/28/2015 06:30 AM, Sanne Grinovero wrote: >>>> Could someone explain please, why it's hard to have a deployer just >>>> use a different JPA implementor which the user might want to provide? >>> >>> If you mean Hibernate 5.x specifically, we started the integration on >>> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 > > Thanks that's very nice, but I'm really just asking why such adapters > are needed, and understand their purpose. I'll answer why we have adapters but first lets talk about modules and persistence providers. The JPA subsystem/container/deployer in WildFly, deals with mapping user application persistence units (e.g. parses persistence.xml) to an available persistence provider in the system. In mapping the persistence unit to an available persistence provider, we strive to make it easy for applications to deploy. Most applications do not have to fill in the "integration" level properties, that the persistence providers need to satisfy the javax.persistence.spi.PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map) call. Instead, we introduced integration adapters that set "integration level" properties on behalf of applications (e.g. see [1]). The "integration level" properties are set prior to the call to createContainerEntityManagerFactory(). There isn't a way to specify that a persistence provider adapter should not be used but that would be a small enhancement that we could talk about adding, if that is ever needed. > > For example since I have primarily "preview testing" needs I wonder if > we could do something similar within our testing utilities, so to > avoid bothering you in future for each and every update we might want > to test. I'll think about this and follow up with you on irc in the next few days. > > Another example could be to see if it makes sense to include the > adapters within the Hibernate feature packs for WildFly - if the > integration API is stable enough for the adapter to work with various > servers that could lead us to work more together on jipijapa long > before it's integrated in WF. > For us it's not practical to lock Hibernate testing to WildFly > releases, and doesn't help us to test new versions of Hibernate to run > fine on versions of the application server which have already sailed. As of yet, there has been almost zero community need for the separate Jipijapa project. To do what your looking for, we still may not need a separate Jipijapa project. External projects that align with the Jipijapa spi, can do so with the Jipijapa source in WildFly. There are two options for the external Hibernate testing. 1). Setup a static module that contains the persistence provider + adapter classes (these can be separate modules that depend on each other). 2). Deploy the persistence provider and adapter classes with each test deployment. > >>> >>>> >>>> I'm pretty sure I know how to start a JPA context in plain JavaSE, and >>>> don't need to know which implementor version I'm going to use, other >>>> than for sake of configuration. >>>> >>>> The WildFly documentation mentions this property >>>> "jboss.as.jpa.providerModule", which sounds great on paper and it >>>> would be a nice usability improvement if it would also actually work >>>> as it suggests. >>> >>> You are complaining a lot lately. We purposely designed for known use >>> cases. There are other ways to get the dynamic environment that you are >>> looking for then complaining that the WildFly JPA subsystem >>> "jboss.as.jpa.providerModule" option doesn't work. >> >> I have probably missed other threads, but I didn?t take it as a complaint, just more surprise and questioning if the behavior made sense. Although, I shouldn?t speak for Sanne. I think its a sign that we may need to improve our docs in this area, so that the limitations are a bit more clear. > > Correct, and apologies for the wording Scott! No problem, my mistake on thinking that you were complaining. We have worked together on a lot and I think its great that you are opening a dialog about the JPA container/subsystem/deployer in WildFly. I'm all for improving the documentation as well. In the WildFly 10 documentation, we could definitely say a lot more [2]. > > I do realise I'm stretching the limits far beyond their intended > usage, it's not shocking me to hit some surprises. I'm actually > excited about the possibilities and didn't mean to "complain" but to > point out an issue in hope to improve as I'd hope to use it. One limitation is that only the default persistence provider is wired for clustering. I looked at improving this last year but didn't have enough time. I think it will actually be easier to improve clustering of various persistence providers (if there is desire for that), after we merge Jipijapa back into WildFly (pr already created). > The documentation seems to claim this is as easy as to point to the > module containing the JPA implementation of choice; that would be > extremely handy to solve several testing issues we have - not only > with Hibernate Search but across the board. > Adding a clarification on which modules are accepted would be nice; > although maybe then this option should rather be a closed enumeration > of short hand names, rather than give the user the option to freely > name any module? Also see the "Determine the persistence provider module" below [2]. I have never had any issues specifying a custom module myself. There really isn't a fixed limit on the modules. If an adapter is not found for the module, a noop integration adapter is used. > But please let's not change the meaning of this property if there is > hope we could eventually get it to work with any custom JPA module. > > Thanks, > Sanne > >> As always I think its great for us to discuss if and how our integrations could be better. >> >>> >>>> >>>> There's plenty of evidence on StackOverflow that the current >>>> limitations are unexpected. For example, Spring moved to Hibernate 5 >>>> and people won't be able to use your stable line of the application >>>> server with Spring; I'd hope we could implement a plan to prevent this >>>> from happening at the next upgrade cycles. >>> >>> The question is whether the Hibernate 5.0 release schedule can align >>> with the WildFly 10 schedule, so that we can do the work. >> >> Getting 5 into 10 as early as possible would be great. We are aiming for a final release in Oct, which isn?t that far away. >> >>> >>>> >>>> Thanks, >>>> Sanne >>>> Scott [1] https://github.com/scottmarlow/wildfly/blob/jipijapa3_hibernate5/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernatePersistenceProviderAdaptor.java#L86 is setting the AvailableSettings.USE_NEW_ID_GENERATOR_MAPPING property if the application didn't. [2] https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties From darran.lofthouse at jboss.com Fri May 29 08:51:43 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 29 May 2015 13:51:43 +0100 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> <55685A0C.4000102@jboss.com> Message-ID: <556860DF.2050308@jboss.com> What we really have internally is a HTTP management interface and we used to expose a native (JBoss Remoting) management interface that the CLI would connect to - subsequently the CLI does connect to the HTTP management interface but it performs a HTTP upgrade to now talk Remoting over HTTP using DMR formatted messages. For the HTTP management interface json was selected as the payload type so that clients could be written in many languages that have libraries to talk HTTP and handle json. The CLI was then subsequently developed but with an emphasis on assisting administrators constructing a request so things like tab completion and automatic conversion. A couple of things this thread throws up that I think could be useful: - - The ability to enter raw json requests into the CLI. - The ability to output the json representation of a command constructed by the CLI. Regards, Darran Lofthouse. On 29/05/15 13:38, Jairo Junior wrote: > Darran, > > Thank you, wish I had found your blog post before. Fortunately, I was > able to build almost the same thing with a lot of effort: > https://github.com/biemond/biemond-wildfly/blob/master/lib/puppet_x/util/wildfly_cli.rb > > My point is: Sysadmins often build CLI scripts to automate tasks and I > want to "reuse" this knowledge in HTTP API. Sysadmins don't talk JSON, > they talk CLI... > > I heard somewhere that jboss-cli.sh and Management Console are using the > same HTTP API in Wildfly, but I'm not sure how jboss-cli.sh use this > commands... > > In fact, I tried to use jboss-cli.sh but bash is incredible slow > compared to HTTP API: > https://github.com/cpitman/puppet-jboss_admin/issues/68 > > On Fri, May 29, 2015 at 9:22 AM Darran Lofthouse > > wrote: > > It was written a couple of years back but this is a good blog post to > look at for different clients sending in management requests: - > > http://pilhuhn.blogspot.co.uk/2012/01/polyglot-management-of-secured-as7.html > > You don't need to go as far as the Base64 encoding and decoding if you > do not want to and just create the json formatted requests and parse the > json responses. > > Regards, > Darran Lofthouse. > > On 29/05/15 13:11, Jairo Junior wrote: > > No, it's not. Only ruby. Although, I could use JRuby to import > and use > > Java classes, it would give me more trouble than solutions. > > > > What I want is: An interoperable way to talk with JBoss. > application/dmr > > is a binary/proprietary format. > > > > On Fri, May 29, 2015 at 8:17 AM Heiko Braun > > >> wrote: > > > > What the constraints when developing a puppet module? Is > plain java > > supported? > > > > > > > > > > Am 29.05.2015 um 01:39 schrieb Jairo Junior > > > >>: > > > >> Heiko, > >> > >> Thank you, but how do I build a ModelNode from a CLI command? > >> > >> Before using JSON I was investigating how Administration Console > >> perform operations and I realized (using firebug) that it uses > >> application/dmr, but I presumed it uses ModelNode to build > >> commands, not plain CLI syntax. > >> > >> On Thu, May 28, 2015 at 5:58 AM Heiko Braun > > >> >> wrote: > >> > >> The DMR library can be found here: > >> > >> https://github.com/jbossas/jboss-dmr > >> > >> > >>> On 28 May 2015, at 10:56, Heiko Braun > > >>> >> > wrote: > >>> > >>> > >>> You can already use DMR over HTTP. It requires a different > >>> content-type ('application/dmr-encoded') and uses a base64 > >>> encoded representation of the payload > >>> ('ModelNode.toBase64String()'). > >>> > >>> You can describe an operation through the DMR API and then > >>> simply do HTTP POST to ?/management? endpoint. make sure to > >>> use 'application/dmr-encoded? for both 'Content-Type' and > >>> ?Accept? headers. > >>> > >>> The response can be parse using 'ModelNode.fromBase64()'. > >>> > >>> Hope this helps, > >>> Heiko > >>> > >>> > >>> > >>>> On 27 May 2015, at 19:54, Jairo Junior > >>>> >> > >>>> wrote: > >>>> > >>>> I've been working on a Puppet Module for Wildfly [1] that > >>>> uses his HTTP Management API to perform operations (manage > >>>> resources/deploys and execute commands), but my command > >>>> execution code is a little bit limited cause I have to > >>>> transform from CLI syntax to JSON. e.g.: > >>>> > >>>> :shutdown(restart=true) > >>>> > >>>> becomes > >>>> > >>>> {"operation" : "shutdown", "restart" : "true" } > >>>> > >>>> Is there any specific reason to not support plain CLI > >>>> commands through HTTP API? I looked at the code and it > >>>> didn't see hard to implement this... > >>>> > >>>> [1] https://github.com/biemond/biemond-wildfly > >>>> > >>>> _______________________________________________ > >>>> 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 ttarrant at redhat.com Fri May 29 08:53:42 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 29 May 2015 14:53:42 +0200 Subject: [wildfly-dev] Moving component projects to a "feature pack" model? In-Reply-To: References: Message-ID: <55686156.6000802@redhat.com> I just posted a partially related e-mail to this ML referencing an issue with the transaction subsystem, but I'd like to use that example in the context of feature packs. Sanne is mentioning the use of FPs as a way to layer components on top of an existing distribution, but I would also like to be able to use components from the main distribution in a more granular fashion. Are there any plans to further breakdown WF into component feature packs so that they can be imported individually without having to base on a larger FP which contains unwanted components ? Tristan On 28/05/2015 23:51, Sanne Grinovero wrote: > # WHAT WE DID SO FAR (and worked quite ok) > > Since a couple of years, when releasing Hibernate Search, Hibernate > OGM, Infinispan and other projects, besides merely uploading our jar > and pom.xml files to Nexus we also upload a large tarball containing > modules for WildFly: an "add on layer", not only useful for end users > but also some other projects rely on this (e.g. Infinispan consumes > the Hibernate Search one to keep an aggressive improvement pace). > > With each build of the projects these modules are not just built but > also tested: integration tests download the latest stable WildFly > version which we target, untar it, untar our own modules as a layer, > run some Arquillian tests. Invaluable to get all dependency > definitions and classloading right! > > # GOALS > > -- to make sure people can download our latest release, and it will > work on their favourite app server > -- to be ready knowing how a stable module structure should be > shaped, when a new version of WildFly integrates our latest > -- to benefit from the modules system by allowing different versions > to co-exist on the same appserver (some people/project/product require > this) > > # NOT PERFECT > > This second goal had some issues recently, namely that while we know > how we should structure the modules within WildFly, it happened that > this wasn't re-creating exactly the model of what had been carefully > tested within our project. The problem is that we have to repeat the > build scripting - result might not be identical for obvious reasons - > while most integration tests reside within the project. > > # FEATURE PACKS > > Tomaz was so nice to show me how to define feature packs, so that the > WildFly build can - at build time - include the structure we define. > It looks very promising, but on some areas we'll need some suggestions > or perhaps a further evolution? > > # NEEDED IMPROVEMENTS / SUGGESTIONS > > ? How do we test the feature pack ? > > The goal of having WildFly use the module structure that we build > "verbatim" is only interesting if we make sure these packs work > correctly. > Ideally we'd like to deploy them in Arquillian tests like we did with > modules, and run integration tests on each commit. > > ? How can end users benefit from these ? > > We'd really want to enable our pool of users and contributors to use > (and test!) any of our releases from "day zero". > Typically people will want to run it on the latest stable version of > WildFly, which implies something releases before "day zero". > > ? Versions and slot identifiers ? > > We release approximately every three weeks on average, and our slot > conventions expect that "our" module releases use the > slot={releaseVersion}, while the module included in WildFly has the > slot="main". > This seems to imply some need for slot transformations when the > feature pack is consumed. > > ? Aliases ? > > We also include module aliases for each Major.Minor combination for > the public-api module, which resolves to the latest major.minor.micro > of the matching version. > This is important to make sure we can include references to module > dependencies maintained in other projects but limiting the scope to a > compatible range, for example we have an optional dependency on > Infinispan, not all Infinispan versions are compatible. > > My preferred solution would be to have WildFly actually not use "main" > slot internally, but use our same alias pattern and in addition have > an alias module - for the public API only - which has slot "main" > resolve to the "major.minor" of the Hibernate Search version which was > included. > > There are many benefits to this model, I'll avoid repeating them in > this email; I shared some thoughts before: > - http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003787.html > > I would love it if a similar pattern was to be applied to other > modules, for example Hibernate Search doesn't work with any version of > Hibernate ORM so depending on "slot main" has some dangers. Even more > important when we deal with other modules released by other projects > in similar packaging. > > ? "System" modules ? > > I noticed the feature pack structure includes the path to the module layer, i.e. > modules/system/layers/base/.. > > But I take it we don't want to classify our "independently" released > modules as belonging to the system/base layer? > > ? Conflicting versions ? > > I noticed the versions of all dependencies are listed once, in the > root metadata of the feature pack. In some projects, like Hibernate > OGM, we take strong advantage of modularity and actually bundle some > libraries multiple times - of different versions - and use the modules > magic to keep them strictly isolated. > Is this going to be possible? > > Thanks in advance for any suggestions! > Sanne > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From lthon at redhat.com Fri May 29 09:10:48 2015 From: lthon at redhat.com (Ladislav Thon) Date: Fri, 29 May 2015 15:10:48 +0200 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> Message-ID: <55686558.8080204@redhat.com> > What I want is: An interoperable way to talk with JBoss. application/dmr > is a binary/proprietary format. It's also fairly small, self-contained and easy to reimplement, as proven by https://github.com/hal/dmr.js https://github.com/hal/dmr.dart https://github.com/hal/dmr.scala I'm not aware of a Ruby implementation, but it shouldn't be _that_ hard to build. Then, parsing the CLI strings into a ModelNode structure should be fairly simple too... for those CLI commands that translate directly to management operations. The "local" CLI commands (e.g. "batch", "patch" or "if") require client-side processing, and that is a whole new can of worms. LT > > On Fri, May 29, 2015 at 8:17 AM Heiko Braun > wrote: > > What the constraints when developing a puppet module? Is plain java > supported? > > > > > Am 29.05.2015 um 01:39 schrieb Jairo Junior >: > >> Heiko, >> >> Thank you, but how do I build a ModelNode from a CLI command? >> >> Before using JSON I was investigating how Administration Console >> perform operations and I realized (using firebug) that it uses >> application/dmr, but I presumed it uses ModelNode to build >> commands, not plain CLI syntax. >> >> On Thu, May 28, 2015 at 5:58 AM Heiko Braun > > wrote: >> >> The DMR library can be found here: >> >> https://github.com/jbossas/jboss-dmr >> >> >>> On 28 May 2015, at 10:56, Heiko Braun >> > wrote: >>> >>> >>> You can already use DMR over HTTP. It requires a different >>> content-type ('application/dmr-encoded') and uses a base64 >>> encoded representation of the payload >>> ('ModelNode.toBase64String()'). >>> >>> You can describe an operation through the DMR API and then >>> simply do HTTP POST to ?/management? endpoint. make sure to >>> use 'application/dmr-encoded? for both 'Content-Type' and >>> ?Accept? headers. >>> >>> The response can be parse using 'ModelNode.fromBase64()'. >>> >>> Hope this helps, >>> Heiko >>> >>> >>> >>>> On 27 May 2015, at 19:54, Jairo Junior >>>> > >>>> wrote: >>>> >>>> I've been working on a Puppet Module for Wildfly [1] that >>>> uses his HTTP Management API to perform operations (manage >>>> resources/deploys and execute commands), but my command >>>> execution code is a little bit limited cause I have to >>>> transform from CLI syntax to JSON. e.g.: >>>> >>>> :shutdown(restart=true) >>>> >>>> becomes >>>> >>>> {"operation" : "shutdown", "restart" : "true" } >>>> >>>> Is there any specific reason to not support plain CLI >>>> commands through HTTP API? I looked at the code and it >>>> didn't see hard to implement this... >>>> >>>> [1] https://github.com/biemond/biemond-wildfly >>>> >>>> _______________________________________________ >>>> 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 mmusgrov at redhat.com Fri May 29 09:14:56 2015 From: mmusgrov at redhat.com (Michael Musgrove) Date: Fri, 29 May 2015 14:14:56 +0100 Subject: [wildfly-dev] Transaction subsystem dependencies In-Reply-To: <55685A0F.6030405@redhat.com> References: <55685A0F.6030405@redhat.com> Message-ID: <55686650.7040705@redhat.com> On 29/05/15 13:22, Tristan Tarrant wrote: > Hi all, > > I'm reworking the Infinispan Server package so that it is built around > WildFly Core as I want to keep it as lean as possible. > I need to pull in a couple of additional subsystems from WildFly proper > and one of them is causing some head-scratching: the transactions > subsystem. It has a bunch of hard dependencies on a ton of modules which > really sound optional. Examples: > > - the IIOP stuff > - Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld) > - HornetQ We need IIOP for JTS support (we use the same jars for JTA and JTS so we need it regardless of whether you enable JTS) . We need hornetq to leverage their fast journal (for our transaction logs). I agree that Naryana compensations should not be required by the subsystem and this seems to be bringing in the bulk of the extra dependencies. I will look into why we need to include it in the subsystem. Do you have more examples or do you agree that if we addressed the need for compensations in the subsystem then that would be good enough. Mike > > None of the above are really needed by Infinispan Server. I guess I > could apply manual surgery to the module.xml file to remove stuff I > think is unnecessary and let my testsuite verify if I'm being too > aggressive, but I was wondering whether it would be better for the > upstream project to be a bit more careful with the dependencies. > > Thanks for any suggestions > > Tristan -- Michael Musgrove Red Hat UK Ltd, 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), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) From cdewolf at redhat.com Fri May 29 09:19:11 2015 From: cdewolf at redhat.com (Carlo de Wolf) Date: Fri, 29 May 2015 15:19:11 +0200 Subject: [wildfly-dev] Remove Xalan? Message-ID: <5568674F.2020903@redhat.com> We are keeping a (old) fork around for Xalan. Now and then the question pops whether we can backport more from upstream. Rather I want to rid of it at all as I don't want to maintain forks of third party projects and I don't see Xalan releasing soon with anything we would upstream. Can we remove Xalan? (Maybe we have some weird dependency on specifics.) What should be its replacement? Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions. Carlo From ttarrant at redhat.com Fri May 29 09:21:19 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 29 May 2015 15:21:19 +0200 Subject: [wildfly-dev] Transaction subsystem dependencies In-Reply-To: <55686650.7040705@redhat.com> References: <55685A0F.6030405@redhat.com> <55686650.7040705@redhat.com> Message-ID: <556867CF.10002@redhat.com> On 29/05/2015 15:14, Michael Musgrove wrote: > On 29/05/15 13:22, Tristan Tarrant wrote: >> Hi all, >> >> I'm reworking the Infinispan Server package so that it is built around >> WildFly Core as I want to keep it as lean as possible. >> I need to pull in a couple of additional subsystems from WildFly proper >> and one of them is causing some head-scratching: the transactions >> subsystem. It has a bunch of hard dependencies on a ton of modules which >> really sound optional. Examples: >> >> - the IIOP stuff >> - Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld) >> - HornetQ > > We need IIOP for JTS support (we use the same jars for JTA and JTS so we > need it regardless of whether you enable JTS) . > > We need hornetq to leverage their fast journal (for our transaction logs). > > I agree that Naryana compensations should not be required by the > subsystem and this seems to be bringing in the bulk of the extra > dependencies. I will look into why we need to include it in the subsystem. > > Do you have more examples or do you agree that if we addressed the need > for compensations in the subsystem then that would be good enough. Thanks for explaining the others, but yes, if anything can be made optional, I'm all for it. Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From tomaz.cerar at gmail.com Fri May 29 09:22:02 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 29 May 2015 15:22:02 +0200 Subject: [wildfly-dev] Moving component projects to a "feature pack" model? In-Reply-To: References: Message-ID: On Thu, May 28, 2015 at 11:51 PM, Sanne Grinovero wrote: > ? How do we test the feature pack ? > > The goal of having WildFly use the module structure that we build > "verbatim" is only interesting if we make sure these packs work > correctly. > Ideally we'd like to deploy them in Arquillian tests like we did with > modules, and run integration tests on each commit. > This is quite simple. As part of test run you provision thin WildFly with your feature pack and run run arquillian tests. As provisionied server is thin (doesn't contain any jars) it is also lightweight. an example would be how we test arquillian integration itself see for example with provisioning wildfly-core https://github.com/wildfly/wildfly-arquillian/blob/master/container-managed/pom.xml#L130 or by provisioning wildfly-servlet(aka wildfly-web) https://github.com/wildfly/wildfly-arquillian/tree/master/container-embedded Main config is in provisioning configuration https://github.com/wildfly/wildfly-arquillian/blob/master/container-embedded/embedded-server-provisioning.xml which can be configured to include as many feature packs as you want. for example, take wildfly-web(-servlet) distro and add hibernate-search next to it. then just run arquillian tests as you would normally do. We use this in wildfly-core testsuite already (but without arquillain ) and have plans to move our wildfly full testsuite to use it as well. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150529/66194d66/attachment.html From mmusgrov at redhat.com Fri May 29 09:26:51 2015 From: mmusgrov at redhat.com (Michael Musgrove) Date: Fri, 29 May 2015 14:26:51 +0100 Subject: [wildfly-dev] Transaction subsystem dependencies In-Reply-To: <556867CF.10002@redhat.com> References: <55685A0F.6030405@redhat.com> <55686650.7040705@redhat.com> <556867CF.10002@redhat.com> Message-ID: <5568691B.90703@redhat.com> On 29/05/15 14:21, Tristan Tarrant wrote: > > > On 29/05/2015 15:14, Michael Musgrove wrote: >> On 29/05/15 13:22, Tristan Tarrant wrote: >>> Hi all, >>> >>> I'm reworking the Infinispan Server package so that it is built around >>> WildFly Core as I want to keep it as lean as possible. >>> I need to pull in a couple of additional subsystems from WildFly proper >>> and one of them is causing some head-scratching: the transactions >>> subsystem. It has a bunch of hard dependencies on a ton of modules >>> which >>> really sound optional. Examples: >>> >>> - the IIOP stuff >>> - Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld) >>> - HornetQ >> >> We need IIOP for JTS support (we use the same jars for JTA and JTS so we >> need it regardless of whether you enable JTS) . >> >> We need hornetq to leverage their fast journal (for our transaction >> logs). >> >> I agree that Naryana compensations should not be required by the >> subsystem and this seems to be bringing in the bulk of the extra >> dependencies. I will look into why we need to include it in the >> subsystem. >> >> Do you have more examples or do you agree that if we addressed the need >> for compensations in the subsystem then that would be good enough. > > Thanks for explaining the others, but yes, if anything can be made > optional, I'm all for it. You can track our progress via the forum post I just made: https://developer.jboss.org/message/932005#932005 Mike > > Tristan > -- Michael Musgrove Red Hat UK Ltd, 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), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) From jason.greene at redhat.com Fri May 29 09:30:22 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Fri, 29 May 2015 09:30:22 -0400 (EDT) Subject: [wildfly-dev] Remove Xalan? In-Reply-To: <5568674F.2020903@redhat.com> References: <5568674F.2020903@redhat.com> Message-ID: The only reason we need Xalan is to provide a jaxp impl of transformer. Ideally we could just rely on the JDK, which uses a fork of xalan, but the translet code which is compiled by it is not compatible with modular classloading. So we just need that one patch. As of late the JDK fork is more current, so we could potentially switch to a fork of it instead. Since Java 9 is moving to modularity, I imagine they would fix the same issue, we could also send them a patch. > On May 29, 2015, at 8:21 AM, Carlo de Wolf wrote: > > We are keeping a (old) fork around for Xalan. Now and then the question > pops whether we can backport more from upstream. Rather I want to rid of > it at all as I don't want to maintain forks of third party projects and > I don't see Xalan releasing soon with anything we would upstream. > > Can we remove Xalan? (Maybe we have some weird dependency on specifics.) > What should be its replacement? > > Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions. > > Carlo > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From anmiller at redhat.com Fri May 29 09:42:27 2015 From: anmiller at redhat.com (Andrig T. Miller) Date: Fri, 29 May 2015 09:42:27 -0400 (EDT) Subject: [wildfly-dev] Transaction subsystem dependencies In-Reply-To: <55685A0F.6030405@redhat.com> References: <55685A0F.6030405@redhat.com> Message-ID: <27530020.1447.1432906944030.JavaMail.andrigtmiller@worklaptop.miller.org> ----- Original Message ----- > From: "Tristan Tarrant" > To: "WildFly Dev" > Sent: Friday, May 29, 2015 6:22:39 AM > Subject: [wildfly-dev] Transaction subsystem dependencies > > Hi all, > > I'm reworking the Infinispan Server package so that it is built > around > WildFly Core as I want to keep it as lean as possible. > I need to pull in a couple of additional subsystems from WildFly > proper > and one of them is causing some head-scratching: the transactions > subsystem. It has a bunch of hard dependencies on a ton of modules > which > really sound optional. Examples: > > - the IIOP stuff > - Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld) > - HornetQ > The HornetQ dependency is for using the HornetQ journal as the transaction journal. For transactions, you definitely want that for performance reasons. Andy > None of the above are really needed by Infinispan Server. I guess I > could apply manual surgery to the module.xml file to remove stuff I > think is unnecessary and let my testsuite verify if I'm being too > aggressive, but I was wondering whether it would be better for the > upstream project to be a bit more careful with the dependencies. > > Thanks for any suggestions > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Fri May 29 09:46:46 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 29 May 2015 08:46:46 -0500 Subject: [wildfly-dev] Remove Xalan? In-Reply-To: References: <5568674F.2020903@redhat.com> Message-ID: <55686DC6.9000601@redhat.com> It was proposed to consider switching to Saxon, since Xalan has basically been dead since 2007. Saxon apears to include a TransformerFactoryImpl (though I don't have any idea as to completeness of compatibility). On 05/29/2015 08:30 AM, Jason T. Greene wrote: > The only reason we need Xalan is to provide a jaxp impl of transformer. Ideally we could just rely on the JDK, which uses a fork of xalan, but the translet code which is compiled by it is not compatible with modular classloading. So we just need that one patch. As of late the JDK fork is more current, so we could potentially switch to a fork of it instead. Since Java 9 is moving to modularity, I imagine they would fix the same issue, we could also send them a patch. > >> On May 29, 2015, at 8:21 AM, Carlo de Wolf wrote: >> >> We are keeping a (old) fork around for Xalan. Now and then the question >> pops whether we can backport more from upstream. Rather I want to rid of >> it at all as I don't want to maintain forks of third party projects and >> I don't see Xalan releasing soon with anything we would upstream. >> >> Can we remove Xalan? (Maybe we have some weird dependency on specifics.) >> What should be its replacement? >> >> Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions. >> >> Carlo >> _______________________________________________ >> 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 > -- - DML From tomaz.cerar at gmail.com Fri May 29 09:55:09 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 29 May 2015 15:55:09 +0200 Subject: [wildfly-dev] Remove Xalan? In-Reply-To: <55686DC6.9000601@redhat.com> References: <5568674F.2020903@redhat.com> <55686DC6.9000601@redhat.com> Message-ID: from their website Saxon-HE 9.6 "The open-source implementation of XSLT 2.0, and XPath 2.0 and 3.0, and XQuery 1.0 and 3.0. This provides the "basic" conformance level of these languages; it also supports some optional features of the specifications such as serialization and support for XQuery modules. Not included in the Home Edition are: schema processing and schema aware XSLT and XQuery; support for higher-order functions; numerous Saxon extensions; calling out to Java methods; XQuery Update support; various optimizations including join optimization; streamed processing; and byte code generation." On Fri, May 29, 2015 at 3:46 PM, David M. Lloyd wrote: > It was proposed to consider switching to Saxon, since Xalan has > basically been dead since 2007. Saxon apears to include a > TransformerFactoryImpl (though I don't have any idea as to completeness > of compatibility). > > On 05/29/2015 08:30 AM, Jason T. Greene wrote: > > The only reason we need Xalan is to provide a jaxp impl of transformer. > Ideally we could just rely on the JDK, which uses a fork of xalan, but the > translet code which is compiled by it is not compatible with modular > classloading. So we just need that one patch. As of late the JDK fork is > more current, so we could potentially switch to a fork of it instead. Since > Java 9 is moving to modularity, I imagine they would fix the same issue, we > could also send them a patch. > > > >> On May 29, 2015, at 8:21 AM, Carlo de Wolf wrote: > >> > >> We are keeping a (old) fork around for Xalan. Now and then the question > >> pops whether we can backport more from upstream. Rather I want to rid of > >> it at all as I don't want to maintain forks of third party projects and > >> I don't see Xalan releasing soon with anything we would upstream. > >> > >> Can we remove Xalan? (Maybe we have some weird dependency on specifics.) > >> What should be its replacement? > >> > >> Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions. > >> > >> Carlo > >> _______________________________________________ > >> 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 > > > > -- > - DML > _______________________________________________ > 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/20150529/0b0cdccc/attachment-0001.html From asoldano at redhat.com Fri May 29 10:02:51 2015 From: asoldano at redhat.com (Alessio Soldano) Date: Fri, 29 May 2015 16:02:51 +0200 Subject: [wildfly-dev] Model attributes and default values Message-ID: <5568718B.5040409@redhat.com> Hi, QA has been testing various value transitions on the attributes in the webservices subsystem of the model and found something unexpected for attributes with default values. I had a look and found that when running the following commands: /subsystem=webservices:undefine-attribute(name=modify-wsdl-address) reload /subsystem=webservices:undefine-attribute(name=modify-wsdl-address) for the last command the WSServerConfigAttributeHandler#applyUpdateToRuntime method is passed true as resolvedValue and undefined as currentValue. The resolvedValue being true is because of the default value for that attribute being true, but is it correct to get undefined as currentValue in that case? Do I have to manually figure out there's a default value for the attribute and hence decide nothing was changed if currentValue is undefined and resolvedValue equals default value... or is there's a specific way to deal with this scenario? Thanks Alessio -- Alessio Soldano Web Service Lead, JBoss From ttarrant at redhat.com Fri May 29 10:11:09 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 29 May 2015 16:11:09 +0200 Subject: [wildfly-dev] Transaction subsystem dependencies In-Reply-To: <27530020.1447.1432906944030.JavaMail.andrigtmiller@worklaptop.miller.org> References: <55685A0F.6030405@redhat.com> <27530020.1447.1432906944030.JavaMail.andrigtmiller@worklaptop.miller.org> Message-ID: <5568737D.4000709@redhat.com> Couldn't this depend on org.hornetq:hornetq-journal only ? Depending on the whole hornetq module means we're pulling in all of the JMS functionality and APIs as well Tristan On 29/05/2015 15:42, Andrig T. Miller wrote: > > > ----- Original Message ----- >> From: "Tristan Tarrant" >> To: "WildFly Dev" >> Sent: Friday, May 29, 2015 6:22:39 AM >> Subject: [wildfly-dev] Transaction subsystem dependencies >> >> Hi all, >> >> I'm reworking the Infinispan Server package so that it is built >> around >> WildFly Core as I want to keep it as lean as possible. >> I need to pull in a couple of additional subsystems from WildFly >> proper >> and one of them is causing some head-scratching: the transactions >> subsystem. It has a bunch of hard dependencies on a ton of modules >> which >> really sound optional. Examples: >> >> - the IIOP stuff >> - Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld) >> - HornetQ >> > > The HornetQ dependency is for using the HornetQ journal as the transaction journal. For transactions, you definitely want that for performance reasons. > > Andy > >> None of the above are really needed by Infinispan Server. I guess I >> could apply manual surgery to the module.xml file to remove stuff I >> think is unnecessary and let my testsuite verify if I'm being too >> aggressive, but I was wondering whether it would be better for the >> upstream project to be a bit more careful with the dependencies. >> >> Thanks for any suggestions >> >> Tristan >> -- >> Tristan Tarrant >> Infinispan Lead >> JBoss, a division of Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From anmiller at redhat.com Fri May 29 10:17:38 2015 From: anmiller at redhat.com (Andrig T. Miller) Date: Fri, 29 May 2015 10:17:38 -0400 (EDT) Subject: [wildfly-dev] Transaction subsystem dependencies In-Reply-To: <5568737D.4000709@redhat.com> References: <55685A0F.6030405@redhat.com> <27530020.1447.1432906944030.JavaMail.andrigtmiller@worklaptop.miller.org> <5568737D.4000709@redhat.com> Message-ID: <18375281.1467.1432909055689.JavaMail.andrigtmiller@worklaptop.miller.org> I believe it could. If memory serves me correctly, when the transaction team added this, the HornetQ team had not yet split out the journal. Andy ----- Original Message ----- > From: "Tristan Tarrant" > To: "Andrig T. Miller" > Cc: "WildFly Dev" > Sent: Friday, May 29, 2015 8:11:09 AM > Subject: Re: [wildfly-dev] Transaction subsystem dependencies > > Couldn't this depend on org.hornetq:hornetq-journal only ? Depending > on > the whole hornetq module means we're pulling in all of the JMS > functionality and APIs as well > > Tristan > > On 29/05/2015 15:42, Andrig T. Miller wrote: > > > > > > ----- Original Message ----- > >> From: "Tristan Tarrant" > >> To: "WildFly Dev" > >> Sent: Friday, May 29, 2015 6:22:39 AM > >> Subject: [wildfly-dev] Transaction subsystem dependencies > >> > >> Hi all, > >> > >> I'm reworking the Infinispan Server package so that it is built > >> around > >> WildFly Core as I want to keep it as lean as possible. > >> I need to pull in a couple of additional subsystems from WildFly > >> proper > >> and one of them is causing some head-scratching: the transactions > >> subsystem. It has a bunch of hard dependencies on a ton of modules > >> which > >> really sound optional. Examples: > >> > >> - the IIOP stuff > >> - Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld) > >> - HornetQ > >> > > > > The HornetQ dependency is for using the HornetQ journal as the > > transaction journal. For transactions, you definitely want that > > for performance reasons. > > > > Andy > > > >> None of the above are really needed by Infinispan Server. I guess > >> I > >> could apply manual surgery to the module.xml file to remove stuff > >> I > >> think is unnecessary and let my testsuite verify if I'm being too > >> aggressive, but I was wondering whether it would be better for the > >> upstream project to be a bit more careful with the dependencies. > >> > >> Thanks for any suggestions > >> > >> Tristan > >> -- > >> Tristan Tarrant > >> Infinispan Lead > >> JBoss, a division of Red Hat > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > From alexey.loubyansky at redhat.com Fri May 29 10:34:47 2015 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Fri, 29 May 2015 16:34:47 +0200 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: <556860DF.2050308@jboss.com> References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> <55685A0C.4000102@jboss.com> <556860DF.2050308@jboss.com> Message-ID: <55687907.80008@redhat.com> On 05/29/2015 02:51 PM, Darran Lofthouse wrote: > What we really have internally is a HTTP management interface and we > used to expose a native (JBoss Remoting) management interface that the > CLI would connect to - subsequently the CLI does connect to the HTTP > management interface but it performs a HTTP upgrade to now talk Remoting > over HTTP using DMR formatted messages. > > For the HTTP management interface json was selected as the payload type > so that clients could be written in many languages that have libraries > to talk HTTP and handle json. > > The CLI was then subsequently developed but with an emphasis on > assisting administrators constructing a request so things like tab > completion and automatic conversion. > > A couple of things this thread throws up that I think could be useful: - > - The ability to enter raw json requests into the CLI. There is a Jira issue open for this https://issues.jboss.org/browse/WFCORE-418 > - The ability to output the json representation of a command > constructed by the CLI. This is an easy one. There is echo-dmr command already. It could accept --json argument to further transform the result to JSON. Alexey > > Regards, > Darran Lofthouse. > > > On 29/05/15 13:38, Jairo Junior wrote: >> Darran, >> >> Thank you, wish I had found your blog post before. Fortunately, I was >> able to build almost the same thing with a lot of effort: >> https://github.com/biemond/biemond-wildfly/blob/master/lib/puppet_x/util/wildfly_cli.rb >> >> My point is: Sysadmins often build CLI scripts to automate tasks and I >> want to "reuse" this knowledge in HTTP API. Sysadmins don't talk JSON, >> they talk CLI... >> >> I heard somewhere that jboss-cli.sh and Management Console are using the >> same HTTP API in Wildfly, but I'm not sure how jboss-cli.sh use this >> commands... >> >> In fact, I tried to use jboss-cli.sh but bash is incredible slow >> compared to HTTP API: >> https://github.com/cpitman/puppet-jboss_admin/issues/68 >> >> On Fri, May 29, 2015 at 9:22 AM Darran Lofthouse >> > wrote: >> >> It was written a couple of years back but this is a good blog post to >> look at for different clients sending in management requests: - >> >> http://pilhuhn.blogspot.co.uk/2012/01/polyglot-management-of-secured-as7.html >> >> You don't need to go as far as the Base64 encoding and decoding if you >> do not want to and just create the json formatted requests and parse the >> json responses. >> >> Regards, >> Darran Lofthouse. >> >> On 29/05/15 13:11, Jairo Junior wrote: >> > No, it's not. Only ruby. Although, I could use JRuby to import >> and use >> > Java classes, it would give me more trouble than solutions. >> > >> > What I want is: An interoperable way to talk with JBoss. >> application/dmr >> > is a binary/proprietary format. >> > >> > On Fri, May 29, 2015 at 8:17 AM Heiko Braun > >> > >> wrote: >> > >> > What the constraints when developing a puppet module? Is >> plain java >> > supported? >> > >> > >> > >> > >> > Am 29.05.2015 um 01:39 schrieb Jairo Junior >> >> > > >>: >> > >> >> Heiko, >> >> >> >> Thank you, but how do I build a ModelNode from a CLI command? >> >> >> >> Before using JSON I was investigating how Administration Console >> >> perform operations and I realized (using firebug) that it uses >> >> application/dmr, but I presumed it uses ModelNode to build >> >> commands, not plain CLI syntax. >> >> >> >> On Thu, May 28, 2015 at 5:58 AM Heiko Braun >> >> >> >> wrote: >> >> >> >> The DMR library can be found here: >> >> >> >> https://github.com/jbossas/jboss-dmr >> >> >> >> >> >>> On 28 May 2015, at 10:56, Heiko Braun >> >> >>> >> >> wrote: >> >>> >> >>> >> >>> You can already use DMR over HTTP. It requires a different >> >>> content-type ('application/dmr-encoded') and uses a base64 >> >>> encoded representation of the payload >> >>> ('ModelNode.toBase64String()'). >> >>> >> >>> You can describe an operation through the DMR API and then >> >>> simply do HTTP POST to ?/management? endpoint. make sure to >> >>> use 'application/dmr-encoded? for both 'Content-Type' and >> >>> ?Accept? headers. >> >>> >> >>> The response can be parse using 'ModelNode.fromBase64()'. >> >>> >> >>> Hope this helps, >> >>> Heiko >> >>> >> >>> >> >>> >> >>>> On 27 May 2015, at 19:54, Jairo Junior >> >>>> > > >> >> >>>> wrote: >> >>>> >> >>>> I've been working on a Puppet Module for Wildfly [1] that >> >>>> uses his HTTP Management API to perform operations (manage >> >>>> resources/deploys and execute commands), but my command >> >>>> execution code is a little bit limited cause I have to >> >>>> transform from CLI syntax to JSON. e.g.: >> >>>> >> >>>> :shutdown(restart=true) >> >>>> >> >>>> becomes >> >>>> >> >>>> {"operation" : "shutdown", "restart" : "true" } >> >>>> >> >>>> Is there any specific reason to not support plain CLI >> >>>> commands through HTTP API? I looked at the code and it >> >>>> didn't see hard to implement this... >> >>>> >> >>>> [1] https://github.com/biemond/biemond-wildfly >> >>>> >> >>>> _______________________________________________ >> >>>> 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 > From mmusgrov at redhat.com Fri May 29 11:12:22 2015 From: mmusgrov at redhat.com (Michael Musgrove) Date: Fri, 29 May 2015 16:12:22 +0100 Subject: [wildfly-dev] Transaction subsystem dependencies In-Reply-To: <18375281.1467.1432909055689.JavaMail.andrigtmiller@worklaptop.miller.org> References: <55685A0F.6030405@redhat.com> <27530020.1447.1432906944030.JavaMail.andrigtmiller@worklaptop.miller.org> <5568737D.4000709@redhat.com> <18375281.1467.1432909055689.JavaMail.andrigtmiller@worklaptop.miller.org> Message-ID: <556881D6.1010804@redhat.com> Thanks, I have added JBTM-2424 to get the dependency moved to hornetq-journal (instead of hornetq-core). Mike > I believe it could. If memory serves me correctly, when the transaction team added this, the HornetQ team had not yet split out the journal. > > Andy > > ----- Original Message ----- >> From: "Tristan Tarrant" >> To: "Andrig T. Miller" >> Cc: "WildFly Dev" >> Sent: Friday, May 29, 2015 8:11:09 AM >> Subject: Re: [wildfly-dev] Transaction subsystem dependencies >> >> Couldn't this depend on org.hornetq:hornetq-journal only ? Depending >> on >> the whole hornetq module means we're pulling in all of the JMS >> functionality and APIs as well >> >> Tristan >> >> On 29/05/2015 15:42, Andrig T. Miller wrote: >>> >>> ----- Original Message ----- >>>> From: "Tristan Tarrant" >>>> To: "WildFly Dev" >>>> Sent: Friday, May 29, 2015 6:22:39 AM >>>> Subject: [wildfly-dev] Transaction subsystem dependencies >>>> >>>> Hi all, >>>> >>>> I'm reworking the Infinispan Server package so that it is built >>>> around >>>> WildFly Core as I want to keep it as lean as possible. >>>> I need to pull in a couple of additional subsystems from WildFly >>>> proper >>>> and one of them is causing some head-scratching: the transactions >>>> subsystem. It has a bunch of hard dependencies on a ton of modules >>>> which >>>> really sound optional. Examples: >>>> >>>> - the IIOP stuff >>>> - Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld) >>>> - HornetQ >>>> >>> The HornetQ dependency is for using the HornetQ journal as the >>> transaction journal. For transactions, you definitely want that >>> for performance reasons. >>> >>> Andy >>> >>>> None of the above are really needed by Infinispan Server. I guess >>>> I >>>> could apply manual surgery to the module.xml file to remove stuff >>>> I >>>> think is unnecessary and let my testsuite verify if I'm being too >>>> aggressive, but I was wondering whether it would be better for the >>>> upstream project to be a bit more careful with the dependencies. >>>> >>>> Thanks for any suggestions >>>> >>>> Tristan >>>> -- >>>> Tristan Tarrant >>>> Infinispan Lead >>>> JBoss, a division of Red Hat >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >> -- >> Tristan Tarrant >> Infinispan Lead >> JBoss, a division of Red Hat >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Michael Musgrove Red Hat UK Ltd, 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), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) From jason.greene at redhat.com Fri May 29 12:52:26 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 29 May 2015 11:52:26 -0500 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: <55687907.80008@redhat.com> References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> <55685A0C.4000102@jboss.com> <556860DF.2050308@jboss.com> <55687907.80008@redhat.com> Message-ID: > On May 29, 2015, at 9:34 AM, Alexey Loubyansky wrote: > > On 05/29/2015 02:51 PM, Darran Lofthouse wrote: >> What we really have internally is a HTTP management interface and we >> used to expose a native (JBoss Remoting) management interface that the >> CLI would connect to - subsequently the CLI does connect to the HTTP >> management interface but it performs a HTTP upgrade to now talk Remoting >> over HTTP using DMR formatted messages. >> >> For the HTTP management interface json was selected as the payload type >> so that clients could be written in many languages that have libraries >> to talk HTTP and handle json. >> >> The CLI was then subsequently developed but with an emphasis on >> assisting administrators constructing a request so things like tab >> completion and automatic conversion. >> >> A couple of things this thread throws up that I think could be useful: - >> - The ability to enter raw json requests into the CLI. > > There is a Jira issue open for this > https://issues.jboss.org/browse/WFCORE-418 > >> - The ability to output the json representation of a command >> constructed by the CLI. > > This is an easy one. There is echo-dmr command already. It could accept > --json argument to further transform the result to JSON. Additionally I think we need: - Ability to transform a ModelNode into CLI calls, and potentially code in various languages (WFCORE-721) - Enhance the HTTP server API to follow REST patterns, including JSON patching (WFCORE-722) - Add support for CLI style addressing within a ModelNode operation (instead of doing a list of kv pairs, you just pass it a CLI style address string(?/foo=bar/blah=something/etc=etc?) -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From ehugonne at redhat.com Fri May 29 13:26:57 2015 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Fri, 29 May 2015 19:26:57 +0200 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> <55685A0C.4000102@jboss.com> <556860DF.2050308@jboss.com> <55687907.80008@redhat.com> Message-ID: <5568A161.4020002@redhat.com> Le 29/05/2015 18:52, Jason Greene a ?crit : > >> On May 29, 2015, at 9:34 AM, Alexey Loubyansky wrote: >> >> On 05/29/2015 02:51 PM, Darran Lofthouse wrote: >>> What we really have internally is a HTTP management interface and we >>> used to expose a native (JBoss Remoting) management interface that the >>> CLI would connect to - subsequently the CLI does connect to the HTTP >>> management interface but it performs a HTTP upgrade to now talk Remoting >>> over HTTP using DMR formatted messages. >>> >>> For the HTTP management interface json was selected as the payload type >>> so that clients could be written in many languages that have libraries >>> to talk HTTP and handle json. >>> >>> The CLI was then subsequently developed but with an emphasis on >>> assisting administrators constructing a request so things like tab >>> completion and automatic conversion. >>> >>> A couple of things this thread throws up that I think could be useful: - >>> - The ability to enter raw json requests into the CLI. >> >> There is a Jira issue open for this >> https://issues.jboss.org/browse/WFCORE-418 >> >>> - The ability to output the json representation of a command >>> constructed by the CLI. >> >> This is an easy one. There is echo-dmr command already. It could accept >> --json argument to further transform the result to JSON. > > Additionally I think we need: > > - Ability to transform a ModelNode into CLI calls, and potentially code in various languages (WFCORE-721) > - Enhance the HTTP server API to follow REST patterns, including JSON patching (WFCORE-722) > - Add support for CLI style addressing within a ModelNode operation (instead of doing a list of kv pairs, you just pass it a CLI style address string(?/foo=bar/blah=something/etc=etc?) This last bit is already in WF9 ;) https://issues.jboss.org/browse/WFCORE-537 Emmanuel > > -- > 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 > -------------- 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/20150529/8e9c1a58/attachment-0001.bin From jason.greene at redhat.com Fri May 29 13:48:18 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Fri, 29 May 2015 13:48:18 -0400 (EDT) Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: <5568A161.4020002@redhat.com> References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> <55685A0C.4000102@jboss.com> <556860DF.2050308@jboss.com> <55687907.80008@redhat.com> <5568A161.4020002@redhat.com> Message-ID: <18079FF4-F04E-4070-9581-669FBC23EDDE@redhat.com> > On May 29, 2015, at 12:27 PM, Emmanuel Hugonnet wrote: > > > > Le 29/05/2015 18:52, Jason Greene a ?crit : >> >>> On May 29, 2015, at 9:34 AM, Alexey Loubyansky wrote: >>> >>>> On 05/29/2015 02:51 PM, Darran Lofthouse wrote: >>>> What we really have internally is a HTTP management interface and we >>>> used to expose a native (JBoss Remoting) management interface that the >>>> CLI would connect to - subsequently the CLI does connect to the HTTP >>>> management interface but it performs a HTTP upgrade to now talk Remoting >>>> over HTTP using DMR formatted messages. >>>> >>>> For the HTTP management interface json was selected as the payload type >>>> so that clients could be written in many languages that have libraries >>>> to talk HTTP and handle json. >>>> >>>> The CLI was then subsequently developed but with an emphasis on >>>> assisting administrators constructing a request so things like tab >>>> completion and automatic conversion. >>>> >>>> A couple of things this thread throws up that I think could be useful: - >>>> - The ability to enter raw json requests into the CLI. >>> >>> There is a Jira issue open for this >>> https://issues.jboss.org/browse/WFCORE-418 >>> >>>> - The ability to output the json representation of a command >>>> constructed by the CLI. >>> >>> This is an easy one. There is echo-dmr command already. It could accept >>> --json argument to further transform the result to JSON. >> >> Additionally I think we need: >> >> - Ability to transform a ModelNode into CLI calls, and potentially code in various languages (WFCORE-721) >> - Enhance the HTTP server API to follow REST patterns, including JSON patching (WFCORE-722) >> - Add support for CLI style addressing within a ModelNode operation (instead of doing a list of kv pairs, you just pass it a CLI style address string(?/foo=bar/blah=something/etc=etc?) > > This last bit is already in WF9 ;) https://issues.jboss.org/browse/WFCORE-537 > Emmanuel Awesome! I didn't realize it was already in. > >> >> -- >> 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 > From jason.greene at redhat.com Fri May 29 23:55:12 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 29 May 2015 22:55:12 -0500 Subject: [wildfly-dev] 10.0.0.Alpha2 released & 9 status update Message-ID: Hello Everyone, WildFly 10.0.0.Alpha2 and WildFly Core 2.0.0.Alpha3 are released. As a reminder, we are doing bi-weekly alpha releases of full, and weekly of core. Due to the high frequency, I am currently not publishing them to the website, so that it does not clutter the WildFly download page. I plan to redesign the download site in the coming weeks to better fit this new approach. In the meantime, you can download the Alpha stream from maven: https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/wildfly-dist/10.0.0.Alpha2/wildfly-dist-10.0.0.Alpha2.zip Next week we are hoping to release 9 CR2. The last blocker is an issue with IIOP shutdown (requires a Naryana update). If all goes well it will be the last CR. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From kabir.khan at jboss.com Sat May 30 04:12:43 2015 From: kabir.khan at jboss.com (Kabir Khan) Date: Sat, 30 May 2015 10:12:43 +0200 Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands In-Reply-To: References: <90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com> <55685A0C.4000102@jboss.com> <556860DF.2050308@jboss.com> <55687907.80008@redhat.com> Message-ID: <055E007A-183D-4F0C-89C9-F26C8332016C@jboss.com> > On 29 May 2015, at 18:52, Jason Greene wrote: > > >> On May 29, 2015, at 9:34 AM, Alexey Loubyansky wrote: >> >> On 05/29/2015 02:51 PM, Darran Lofthouse wrote: >>> What we really have internally is a HTTP management interface and we >>> used to expose a native (JBoss Remoting) management interface that the >>> CLI would connect to - subsequently the CLI does connect to the HTTP >>> management interface but it performs a HTTP upgrade to now talk Remoting >>> over HTTP using DMR formatted messages. >>> >>> For the HTTP management interface json was selected as the payload type >>> so that clients could be written in many languages that have libraries >>> to talk HTTP and handle json. >>> >>> The CLI was then subsequently developed but with an emphasis on >>> assisting administrators constructing a request so things like tab >>> completion and automatic conversion. >>> >>> A couple of things this thread throws up that I think could be useful: - >>> - The ability to enter raw json requests into the CLI. >> >> There is a Jira issue open for this >> https://issues.jboss.org/browse/WFCORE-418 >> >>> - The ability to output the json representation of a command >>> constructed by the CLI. >> >> This is an easy one. There is echo-dmr command already. It could accept >> --json argument to further transform the result to JSON. > > Additionally I think we need: > > - Ability to transform a ModelNode into CLI calls, and potentially code in various languages (WFCORE-721) > - Enhance the HTTP server API to follow REST patterns, including JSON patching (WFCORE-722) I plan on working on this soon (once I?ve finished with Emanuel?s domain operations work) > - Add support for CLI style addressing within a ModelNode operation (instead of doing a list of kv pairs, you just pass it a CLI style address string(?/foo=bar/blah=something/etc=etc?) > > -- > 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