From slaskawi at redhat.com Wed Oct 5 04:39:33 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Wed, 5 Oct 2016 10:39:33 +0200 Subject: [wildfly-dev] WildFly and Kubernetes/OpenShift Message-ID: Hey! I was asked whether Wildfly or EAP support Kubernetes/OpenShift deployment [1]. For EAP I'm certain that the answer is yes [2] but what about WildFly? Can it be deployed on those environments out of the box? Thanks Sebastian [1] https://github.com/jgroups-extras/jgroups-kubernetes/issues/12 [2] https://developers.openshift.com/servers/jbosseap/getting-started.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161005/01e7a473/attachment.html From rory.odonnell at oracle.com Fri Oct 7 06:46:01 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 7 Oct 2016 11:46:01 +0100 Subject: [wildfly-dev] Early Access builds of JDK 8u122 b01 & JDK 9 EA b138 are available. Message-ID: <7d11e6eb-fc70-f654-9e0d-111553f920b3@oracle.com> Hi Jason/Tomaz, Early Access b01 for JDK 8u122 is available on java.net. Early Access b138 for JDK 9 is available on java.net, summary of changes are listed here . Early Access b138 (#5561) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here . There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * 8038348 - b137 - Instance field load is replaced by wrong data Phi * 8041480 - b137 - ArrayIndexOutOfBoundsException when JTable contains certain string * 8145542 - b137 - The case failed automatically and thrown java.lang.ArrayIndexOutOfBoundsException exception. * 8151725 - b137 - [macosx] ArrayIndexOOB exception when displaying Devanagari text in JEditorPane There are two proposals requesting feedback via mailing lists : - More proposals for open JPMS issues [1] * One proposal to call out is #AwkwardStrongEncapsulation as this proposes to change setAccessible(true) so that it can't be used to break into non-public types/members in exported packages. This is a non-issue when using setAccessible to get access to non-public types/members of classes on the class path but will be an issue for code that uses this method to break into JDK-internals. We would appreciate as much help as possible testing these builds. If InaccessibleObjectException is thrown then examine the stack trace (run with -Dsun.reflect.debugModuleAccessChecks=true to uncover failed access attempts in code that shallows exceptions). If it looks like a library is attempting to access a non-public method or field of a platform class and make sure to *submit a bug in the issue tracker for the library.* - Proposal to Reorganize source classes in src.zip by modules [2] * This proposal might have a compatibility impact on IDEs or other tools that look in src.zip * Feedback via the jigsaw-dev mailing list Other points of interest: * JavaOne Presentations o Recorded Presentations * JDK 9 Schedule change proposal o for proposed schedule proposal see [3] Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009365.html [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009550.html [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004887.html -- 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/20161007/e4a907ee/attachment.html From tdiesler at redhat.com Thu Oct 13 05:10:43 2016 From: tdiesler at redhat.com (Thomas Diesler) Date: Thu, 13 Oct 2016 11:10:43 +0200 Subject: [wildfly-dev] Announcing WildFly-Camel 4.3.0 Message-ID: <4843AFFB-F0FB-4E5F-BE81-DD154A463BE1@redhat.com> Dear Friends, I?m happy to let you know that WildFly-Camel 4.3.0 has been released. It provides Camel-2.18 integration with WildFly-10.1.0 This is a major upgrade release for Camel and various other components. The WildFly-Camel examples now live here . Additional components in the supported set are: camel-base64 camel-bean-validator camel-cassandra camel-hystrix camel-irc camel-jdbc camel-jsch camel-mongodb camel-olingo2 camel-pdf camel-servicenow camel-vertx camel-zipkin Additional data formats in the supported set are: Barcode YAML Syslog Component upgrades include Camel-2.18.0 Elasticsearch-2.3.5 Fuse-Patch-2.6.0 Lucene-5.5.0 Mvel-2.3.1 Netty-4.1.5 Spring-4.3.3 WildFly-10.1.0 XStream-1.4.9 In addition to that, we also resolved a number of other features, tasks and bugfixes . For details please see the 4.3.0 Milestone . Enjoy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161013/175bd2f8/attachment-0001.html From mmusgrov at redhat.com Mon Oct 17 07:30:23 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Mon, 17 Oct 2016 12:30:23 +0100 Subject: [wildfly-dev] How can I add a subsystem model step to a different context? Message-ID: I have subsystem model operation that removes a model node: { "address" => [ ("subsystem" => "transactions"), ("log-store" => "log-store"), ("transactions" => "0:ffffac11829d:83bb:57f3b02a:1e"), ("participants" => "1") ], "operation" => "delete", "operation-headers" => { "caller-type" => "user", "access-mechanism" => "NATIVE" } } After removing the node (which can result in removing the participant and transaction) I need to add a step that will refresh the model. I cannot do the refresh from the current context (which will be the node I am deleting) so I need to refresh from a context that is "higher up the tree". Ideally I want to do PathAddress logStoreAddress = context.getCurrentAddress().getParent().getParent(); and then do a refresh from logStoreAddress. My question is how can I trigger a refresh when I am in the "wrong context"? Mike -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161017/7e3df1ac/attachment.html From kabir.khan at jboss.com Mon Oct 17 16:20:06 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 17 Oct 2016 22:20:06 +0200 Subject: [wildfly-dev] How can I add a subsystem model step to a different context? In-Reply-To: References: Message-ID: Try in your operation's execute(): public void execute(OperationContext context, ModelNode operation) { ModelNode operation = Util.createEmptyOperation("whatever", context.getCurrentAddress().getParent().getParent()); context.addStep(final ModelNode operation, new OperationStepHandler{ public void execute(OperationContext context, ModelNode operation) { } }, MODEL); } > On 17 Oct 2016, at 13:30, Michael Musgrove wrote: > > I have subsystem model operation that removes a model node: > > { > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffffac11829d:83bb:57f3b02a:1e"), > ("participants" => "1") > ], > "operation" => "delete", > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE" > } > } > > After removing the node (which can result in removing the participant and transaction) I need to add a step that will refresh the model. I cannot do the refresh from the current context (which will be the node I am deleting) so I need to refresh from a context that is "higher up the tree". Ideally I want to do > > PathAddress logStoreAddress = context.getCurrentAddress().getParent().getParent(); > > and then do a refresh from logStoreAddress. > > My question is how can I trigger a refresh when I am in the "wrong context"? > > Mike > > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From mmusgrov at redhat.com Tue Oct 18 10:14:47 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Tue, 18 Oct 2016 15:14:47 +0100 Subject: [wildfly-dev] How can I add a subsystem model step to a different context? In-Reply-To: References: Message-ID: Thanks Karbir, that works great. Mike On Mon, Oct 17, 2016 at 9:20 PM, Kabir Khan wrote: > Try in your operation's execute(): > > public void execute(OperationContext context, ModelNode operation) { > ModelNode operation = Util.createEmptyOperation("whatever", > context.getCurrentAddress().getParent().getParent()); > context.addStep(final ModelNode operation, new > OperationStepHandler{ > public void execute(OperationContext context, ModelNode > operation) { > > } > }, MODEL); > } > > > > On 17 Oct 2016, at 13:30, Michael Musgrove wrote: > > > > I have subsystem model operation that removes a model node: > > > > { > > "address" => [ > > ("subsystem" => "transactions"), > > ("log-store" => "log-store"), > > ("transactions" => "0:ffffac11829d:83bb:57f3b02a:1e"), > > ("participants" => "1") > > ], > > "operation" => "delete", > > "operation-headers" => { > > "caller-type" => "user", > > "access-mechanism" => "NATIVE" > > } > > } > > > > After removing the node (which can result in removing the participant > and transaction) I need to add a step that will refresh the model. I cannot > do the refresh from the current context (which will be the node I am > deleting) so I need to refresh from a context that is "higher up the tree". > Ideally I want to do > > > > PathAddress logStoreAddress = context.getCurrentAddress(). > getParent().getParent(); > > > > and then do a refresh from logStoreAddress. > > > > My question is how can I trigger a refresh when I am in the "wrong > context"? > > > > Mike > > > > > > -- > > Michael Musgrove > > Transactions Team > > e: mmusgrov at redhat.com > > t: +44 191 243 0870 > > > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > > (US), Charles Peters (US) > > > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161018/8c5ffbd9/attachment.html From tomaz.cerar at gmail.com Tue Oct 18 11:19:02 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 18 Oct 2016 17:19:02 +0200 Subject: [wildfly-dev] Remove PL from WFLY In-Reply-To: <8115B373-BAF8-4443-B79B-68F2A033D4D1@redhat.com> References: <1216624997.6100331.1471614566720.JavaMail.zimbra@redhat.com> <784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com> <8115B373-BAF8-4443-B79B-68F2A033D4D1@redhat.com> Message-ID: Another complaint https://developer.jboss.org/thread/272652 On Mon, Aug 22, 2016 at 4:02 PM, Jason Greene wrote: > > On Aug 19, 2016, at 9:11 AM, Toma? Cerar wrote: > > There have also be complains from community why we downgraded the > PicketLink in WF10 > and now there is a migration problem from WF9 --> 10. [1] > > If we remove it, we would just keep the mgmt stub so we can still manage > mixed-domain with older versions. > Similarly as we did with osgi & friends back in the day. > It was already deprecated in 10, so we could remove it in 11 or later. > > -- > tomaz > > [1] https://issues.jboss.org/browse/WFLY-5196 > > > This is a pretty strong reason to remove it, if on top of deprecation, > most of its users in community want a different version > > -- > 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/20161018/d14a240a/attachment.html From alexey.loubyansky at redhat.com Wed Oct 19 08:27:59 2016 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Wed, 19 Oct 2016 14:27:59 +0200 Subject: [wildfly-dev] selecting packages from feature-packs Message-ID: <2cf7a2f5-33bb-2305-aa3b-fda65906f698@redhat.com> Me and Stuart have been thinking about how to express feature-pack package selection in an XML. Each one came up with a proposal but we appear to have slightly different preferences. In case anybody has an opinion or a better suggestion, please, share. Brief description: feature-pack consists of packages. A package is a unit of content. So a set of packages determines the target installation content-wise. Feature-pack has a set of default packages. These are the packages that get installed by default, i.e. when the user installs the feature-pack w/o specifying any package preferences. In addition to the default ones a feature-pack may contains non-default packages, these are present in the feature-pack but will be installed only if the user explicitly asks for them. So, the question is how to express these package preferences in an XML. Proposal 1. - include-default flag (element or attribute) which defaults to true (meaning the default packages will be included by default); - if include-default is false (meaning nothing is installed by default), then 'include' element can be used to pick the specific packages (default and non-default ones) to be installed; - otherwise (when include-default is true) 'exclude' element can be used to exclude specific undesired default packages. Proposal 2. - exclude element - applicable to any package and means do not install the package (and its dependencies); - include element - applicable to non-default packages and means do install the non-default package (and its dependencies); - pick element - applicable to any package and means install only the picked package(s) ignoring other default and non-default ones. pick cannot be used in combination with exclude and include. Basically, 'include' and 'exclude' in both proposals are practically the same. The difference is how the picking is expressed. In the first one, everything is explicitly excluded and then the desired ones are explicitly included, in the second one the desired ones are simply explicitly picked. Thanks, Alexey From brian.stansberry at redhat.com Fri Oct 21 09:50:29 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 21 Oct 2016 08:50:29 -0500 Subject: [wildfly-dev] selecting packages from feature-packs In-Reply-To: <2cf7a2f5-33bb-2305-aa3b-fda65906f698@redhat.com> References: <2cf7a2f5-33bb-2305-aa3b-fda65906f698@redhat.com> Message-ID: <49115A4F-FD03-4767-9E06-C02EB1B40D75@redhat.com> > On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky wrote: > > Me and Stuart have been thinking about how to express feature-pack > package selection in an XML. Each one came up with a proposal but we > appear to have slightly different preferences. In case anybody has an > opinion or a better suggestion, please, share. > > Brief description: feature-pack consists of packages. A package is a > unit of content. So a set of packages determines the target installation > content-wise. Feature-pack has a set of default packages. These are the > packages that get installed by default, i.e. when the user installs the > feature-pack w/o specifying any package preferences. In addition to the > default ones a feature-pack may contains non-default packages, these are > present in the feature-pack but will be installed only if the user > explicitly asks for them. > So, the question is how to express these package preferences in an XML. > > Proposal 1. > > - include-default flag (element or attribute) which defaults to true > (meaning the default packages will be included by default); > Th ?include? element is still supported here, right? So, I can get all the default ones and then use include elements to pull in additional ones. > - if include-default is false (meaning nothing is installed by default), > then 'include' element can be used to pick the specific packages > (default and non-default ones) to be installed; > > - otherwise (when include-default is true) 'exclude' element can be used > to exclude specific undesired default packages. > Can ?exclude? be used to exclude dependencies? So I want ?a? but not its dependency ?b?? If the answer is yes for optional dependencies, what if the dependency isn?t optional? > > Proposal 2. > > - exclude element - applicable to any package and means do not install > the package (and its dependencies); > > - include element - applicable to non-default packages and means do > install the non-default package (and its dependencies); > What happens if it?s used for a default package? The tool forgives this, right? > - pick element - applicable to any package and means install only the > picked package(s) and it?s dependencies? If yes, all its dependencies or only non-optional? > ignoring other default and non-default ones. pick > cannot be used in combination with exclude and include. > > > Basically, 'include' and 'exclude' in both proposals are practically the > same. The difference is how the picking is expressed. In the first one, > everything is explicitly excluded and then the desired ones are > explicitly included, in the second one the desired ones are simply > explicitly picked. > The answers to my questions on Proposal 1 impact the semantics of include/exclude in different cases, so I?ll defer expressing an opinion for now. :) > > Thanks, > Alexey > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From alexey.loubyansky at redhat.com Fri Oct 21 10:20:16 2016 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Fri, 21 Oct 2016 16:20:16 +0200 Subject: [wildfly-dev] selecting packages from feature-packs In-Reply-To: <49115A4F-FD03-4767-9E06-C02EB1B40D75@redhat.com> References: <2cf7a2f5-33bb-2305-aa3b-fda65906f698@redhat.com> <49115A4F-FD03-4767-9E06-C02EB1B40D75@redhat.com> Message-ID: <11f9df8c-da21-9ffc-c0f6-1a7ad6fc8113@redhat.com> On 10/21/2016 03:50 PM, Brian Stansberry wrote: > >> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky wrote: >> >> Me and Stuart have been thinking about how to express feature-pack >> package selection in an XML. Each one came up with a proposal but we >> appear to have slightly different preferences. In case anybody has an >> opinion or a better suggestion, please, share. >> >> Brief description: feature-pack consists of packages. A package is a >> unit of content. So a set of packages determines the target installation >> content-wise. Feature-pack has a set of default packages. These are the >> packages that get installed by default, i.e. when the user installs the >> feature-pack w/o specifying any package preferences. In addition to the >> default ones a feature-pack may contains non-default packages, these are >> present in the feature-pack but will be installed only if the user >> explicitly asks for them. >> So, the question is how to express these package preferences in an XML. >> >> Proposal 1. >> >> - include-default flag (element or attribute) which defaults to true >> (meaning the default packages will be included by default); >> > > Th ?include? element is still supported here, right? So, I can get all the default ones and then use include elements to pull in additional ones. Right. >> - if include-default is false (meaning nothing is installed by default), >> then 'include' element can be used to pick the specific packages >> (default and non-default ones) to be installed; >> >> - otherwise (when include-default is true) 'exclude' element can be used >> to exclude specific undesired default packages. >> > > Can ?exclude? be used to exclude dependencies? So I want ?a? but not its dependency ?b?? If the answer is yes for optional dependencies, what if the dependency isn?t optional? Yes, it can be used to exclude dependencies. If a required (non-optional) dependency is excluded, that'll be an error. >> Proposal 2. >> >> - exclude element - applicable to any package and means do not install >> the package (and its dependencies); >> >> - include element - applicable to non-default packages and means do >> install the non-default package (and its dependencies); >> > What happens if it?s used for a default package? The tool forgives this, right? That would be redundant, of course. We could ignore that or issue a warning. >> - pick element - applicable to any package and means install only the >> picked package(s) > > and it?s dependencies? If yes, all its dependencies or only non-optional? No, the dependencies would have to be picked explicitly. Otherwise, we have to allow exclude and include to be used in combination with pick which will look too confusing. >> ignoring other default and non-default ones. pick >> cannot be used in combination with exclude and include. >> >> >> Basically, 'include' and 'exclude' in both proposals are practically the >> same. The difference is how the picking is expressed. In the first one, >> everything is explicitly excluded and then the desired ones are >> explicitly included, in the second one the desired ones are simply >> explicitly picked. >> > > The answers to my questions on Proposal 1 impact the semantics of include/exclude in different cases, so I?ll defer expressing an opinion for now. :) Thanks, Alexey > >> >> Thanks, >> Alexey >> _______________________________________________ >> 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 Oct 21 11:03:58 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 21 Oct 2016 10:03:58 -0500 Subject: [wildfly-dev] selecting packages from feature-packs In-Reply-To: <11f9df8c-da21-9ffc-c0f6-1a7ad6fc8113@redhat.com> References: <2cf7a2f5-33bb-2305-aa3b-fda65906f698@redhat.com> <49115A4F-FD03-4767-9E06-C02EB1B40D75@redhat.com> <11f9df8c-da21-9ffc-c0f6-1a7ad6fc8113@redhat.com> Message-ID: > On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky wrote: > > On 10/21/2016 03:50 PM, Brian Stansberry wrote: >> >>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky wrote: >>> >>> Me and Stuart have been thinking about how to express feature-pack >>> package selection in an XML. Each one came up with a proposal but we >>> appear to have slightly different preferences. In case anybody has an >>> opinion or a better suggestion, please, share. >>> >>> Brief description: feature-pack consists of packages. A package is a >>> unit of content. So a set of packages determines the target installation >>> content-wise. Feature-pack has a set of default packages. These are the >>> packages that get installed by default, i.e. when the user installs the >>> feature-pack w/o specifying any package preferences. In addition to the >>> default ones a feature-pack may contains non-default packages, these are >>> present in the feature-pack but will be installed only if the user >>> explicitly asks for them. >>> So, the question is how to express these package preferences in an XML. >>> >>> Proposal 1. >>> >>> - include-default flag (element or attribute) which defaults to true >>> (meaning the default packages will be included by default); >>> >> >> Th ?include? element is still supported here, right? So, I can get all the default ones and then use include elements to pull in additional ones. > > Right. > >>> - if include-default is false (meaning nothing is installed by default), >>> then 'include' element can be used to pick the specific packages >>> (default and non-default ones) to be installed; >>> >>> - otherwise (when include-default is true) 'exclude' element can be used >>> to exclude specific undesired default packages. >>> >> >> Can ?exclude? be used to exclude dependencies? So I want ?a? but not its dependency ?b?? If the answer is yes for optional dependencies, what if the dependency isn?t optional? > > Yes, it can be used to exclude dependencies. If a required (non-optional) dependency is excluded, that'll be an error. > >>> Proposal 2. >>> >>> - exclude element - applicable to any package and means do not install >>> the package (and its dependencies); >>> >>> - include element - applicable to non-default packages and means do >>> install the non-default package (and its dependencies); >>> >> What happens if it?s used for a default package? The tool forgives this, right? > > That would be redundant, of course. We could ignore that or issue a warning. That question was kind of a tangent. I asked because I could imagine a case where a package is not default in version 1, so the user adds an ?include?. Then in a later version the package is now a default one. You don?t want to break the user for no good reason. > >>> - pick element - applicable to any package and means install only the >>> picked package(s) >> >> and it?s dependencies? If yes, all its dependencies or only non-optional? > > No, the dependencies would have to be picked explicitly. Otherwise, we have to allow exclude and include to be used in combination with pick which will look too confusing. > Ok, then assuming that in Proposal 1 an ?include? element always means pull in dependencies, I prefer Proposal 1. Forcing people to list everything just to get a subset of the default packages is painful and will likely break things if the feature-pack adds a new dependency in a later version. But? There are cases where people do want to explicitly list things and not have unexpected things brought in. See discussion on https://issues.apache.org/jira/browse/MNG-2315 (for which I voted). I do think it?s good to account for that kind of use case. >>> ignoring other default and non-default ones. pick >>> cannot be used in combination with exclude and include. >>> >>> >>> Basically, 'include' and 'exclude' in both proposals are practically the >>> same. The difference is how the picking is expressed. In the first one, >>> everything is explicitly excluded and then the desired ones are >>> explicitly included, in the second one the desired ones are simply >>> explicitly picked. >>> >> >> The answers to my questions on Proposal 1 impact the semantics of include/exclude in different cases, so I?ll defer expressing an opinion for now. :) > > Thanks, > Alexey > >> >>> >>> Thanks, >>> Alexey >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Fri Oct 21 11:31:24 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 21 Oct 2016 10:31:24 -0500 Subject: [wildfly-dev] selecting packages from feature-packs In-Reply-To: References: <2cf7a2f5-33bb-2305-aa3b-fda65906f698@redhat.com> <49115A4F-FD03-4767-9E06-C02EB1B40D75@redhat.com> <11f9df8c-da21-9ffc-c0f6-1a7ad6fc8113@redhat.com> Message-ID: <2623C11B-E4AE-418B-953F-4C869A79BD1E@redhat.com> > On Oct 21, 2016, at 10:03 AM, Brian Stansberry wrote: > > >> On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky wrote: >> >> On 10/21/2016 03:50 PM, Brian Stansberry wrote: >>> >>>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky wrote: >>>> >>>> Me and Stuart have been thinking about how to express feature-pack >>>> package selection in an XML. Each one came up with a proposal but we >>>> appear to have slightly different preferences. In case anybody has an >>>> opinion or a better suggestion, please, share. >>>> >>>> Brief description: feature-pack consists of packages. A package is a >>>> unit of content. So a set of packages determines the target installation >>>> content-wise. Feature-pack has a set of default packages. These are the >>>> packages that get installed by default, i.e. when the user installs the >>>> feature-pack w/o specifying any package preferences. In addition to the >>>> default ones a feature-pack may contains non-default packages, these are >>>> present in the feature-pack but will be installed only if the user >>>> explicitly asks for them. >>>> So, the question is how to express these package preferences in an XML. >>>> >>>> Proposal 1. >>>> >>>> - include-default flag (element or attribute) which defaults to true >>>> (meaning the default packages will be included by default); >>>> >>> >>> Th ?include? element is still supported here, right? So, I can get all the default ones and then use include elements to pull in additional ones. >> >> Right. >> >>>> - if include-default is false (meaning nothing is installed by default), >>>> then 'include' element can be used to pick the specific packages >>>> (default and non-default ones) to be installed; >>>> >>>> - otherwise (when include-default is true) 'exclude' element can be used >>>> to exclude specific undesired default packages. >>>> >>> >>> Can ?exclude? be used to exclude dependencies? So I want ?a? but not its dependency ?b?? If the answer is yes for optional dependencies, what if the dependency isn?t optional? >> >> Yes, it can be used to exclude dependencies. If a required (non-optional) dependency is excluded, that'll be an error. >> >>>> Proposal 2. >>>> >>>> - exclude element - applicable to any package and means do not install >>>> the package (and its dependencies); >>>> >>>> - include element - applicable to non-default packages and means do >>>> install the non-default package (and its dependencies); >>>> >>> What happens if it?s used for a default package? The tool forgives this, right? >> >> That would be redundant, of course. We could ignore that or issue a warning. > > That question was kind of a tangent. I asked because I could imagine a case where a package is not default in version 1, so the user adds an ?include?. Then in a later version the package is now a default one. You don?t want to break the user for no good reason. > >> >>>> - pick element - applicable to any package and means install only the >>>> picked package(s) >>> >>> and it?s dependencies? If yes, all its dependencies or only non-optional? >> >> No, the dependencies would have to be picked explicitly. Otherwise, we have to allow exclude and include to be used in combination with pick which will look too confusing. >> > > Ok, then assuming that in Proposal 1 an ?include? element always means pull in dependencies, I prefer Proposal 1. Forcing people to list everything just to get a subset of the default packages is painful and will likely break things if the feature-pack adds a new dependency in a later version. I realize my response didn?t account for the fact that in the Proposal 1 section you answered one of my questions by stating that excluding a non-optional dependency is an error. If the general rule is non-optional dependencies can?t be excluded, I see no reason why ?pick? shouldn?t automatically bring them in. And then the only things a user would want to ?exclude? in the context of a ?pick? are optional dependencies. Which means always excluding them and forcing the user to include them via additional ?pick? elements is less terrible. I still prefer Proposal 1, but not as strongly as I did. > > But? > > There are cases where people do want to explicitly list things and not have unexpected things brought in. See discussion on https://issues.apache.org/jira/browse/MNG-2315 (for which I voted). I do think it?s good to account for that kind of use case. > >>>> ignoring other default and non-default ones. pick >>>> cannot be used in combination with exclude and include. >>>> >>>> >>>> Basically, 'include' and 'exclude' in both proposals are practically the >>>> same. The difference is how the picking is expressed. In the first one, >>>> everything is explicitly excluded and then the desired ones are >>>> explicitly included, in the second one the desired ones are simply >>>> explicitly picked. >>>> >>> >>> The answers to my questions on Proposal 1 impact the semantics of include/exclude in different cases, so I?ll defer expressing an opinion for now. :) >> >> Thanks, >> Alexey >> >>> >>>> >>>> Thanks, >>>> Alexey >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Fri Oct 21 12:09:02 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 21 Oct 2016 18:09:02 +0200 Subject: [wildfly-dev] Remove PL from WFLY In-Reply-To: References: <1216624997.6100331.1471614566720.JavaMail.zimbra@redhat.com> <784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com> <8115B373-BAF8-4443-B79B-68F2A033D4D1@redhat.com> Message-ID: Created PR to remove it https://github.com/wildfly/wildfly/pull/9286 It removes all runtime related things, but keeps mgmt stub, so latest DC can still manage legacy HC. -- tomaz On Tue, Oct 18, 2016 at 5:19 PM, Toma? Cerar wrote: > Another complaint https://developer.jboss.org/thread/272652 > > On Mon, Aug 22, 2016 at 4:02 PM, Jason Greene > wrote: > >> >> On Aug 19, 2016, at 9:11 AM, Toma? Cerar wrote: >> >> There have also be complains from community why we downgraded the >> PicketLink in WF10 >> and now there is a migration problem from WF9 --> 10. [1] >> >> If we remove it, we would just keep the mgmt stub so we can still manage >> mixed-domain with older versions. >> Similarly as we did with osgi & friends back in the day. >> It was already deprecated in 10, so we could remove it in 11 or later. >> >> -- >> tomaz >> >> [1] https://issues.jboss.org/browse/WFLY-5196 >> >> >> This is a pretty strong reason to remove it, if on top of deprecation, >> most of its users in community want a different version >> >> -- >> 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/20161021/0b16ebb6/attachment-0001.html From alexey.loubyansky at redhat.com Fri Oct 21 15:03:10 2016 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Fri, 21 Oct 2016 21:03:10 +0200 Subject: [wildfly-dev] selecting packages from feature-packs In-Reply-To: <2623C11B-E4AE-418B-953F-4C869A79BD1E@redhat.com> References: <2cf7a2f5-33bb-2305-aa3b-fda65906f698@redhat.com> <49115A4F-FD03-4767-9E06-C02EB1B40D75@redhat.com> <11f9df8c-da21-9ffc-c0f6-1a7ad6fc8113@redhat.com> <2623C11B-E4AE-418B-953F-4C869A79BD1E@redhat.com> Message-ID: Thanks! I'm going with the proposal 1. Alexey On 10/21/2016 05:31 PM, Brian Stansberry wrote: > >> On Oct 21, 2016, at 10:03 AM, Brian Stansberry wrote: >> >> >>> On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky wrote: >>> >>> On 10/21/2016 03:50 PM, Brian Stansberry wrote: >>>> >>>>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky wrote: >>>>> >>>>> Me and Stuart have been thinking about how to express feature-pack >>>>> package selection in an XML. Each one came up with a proposal but we >>>>> appear to have slightly different preferences. In case anybody has an >>>>> opinion or a better suggestion, please, share. >>>>> >>>>> Brief description: feature-pack consists of packages. A package is a >>>>> unit of content. So a set of packages determines the target installation >>>>> content-wise. Feature-pack has a set of default packages. These are the >>>>> packages that get installed by default, i.e. when the user installs the >>>>> feature-pack w/o specifying any package preferences. In addition to the >>>>> default ones a feature-pack may contains non-default packages, these are >>>>> present in the feature-pack but will be installed only if the user >>>>> explicitly asks for them. >>>>> So, the question is how to express these package preferences in an XML. >>>>> >>>>> Proposal 1. >>>>> >>>>> - include-default flag (element or attribute) which defaults to true >>>>> (meaning the default packages will be included by default); >>>>> >>>> >>>> Th ?include? element is still supported here, right? So, I can get all the default ones and then use include elements to pull in additional ones. >>> >>> Right. >>> >>>>> - if include-default is false (meaning nothing is installed by default), >>>>> then 'include' element can be used to pick the specific packages >>>>> (default and non-default ones) to be installed; >>>>> >>>>> - otherwise (when include-default is true) 'exclude' element can be used >>>>> to exclude specific undesired default packages. >>>>> >>>> >>>> Can ?exclude? be used to exclude dependencies? So I want ?a? but not its dependency ?b?? If the answer is yes for optional dependencies, what if the dependency isn?t optional? >>> >>> Yes, it can be used to exclude dependencies. If a required (non-optional) dependency is excluded, that'll be an error. >>> >>>>> Proposal 2. >>>>> >>>>> - exclude element - applicable to any package and means do not install >>>>> the package (and its dependencies); >>>>> >>>>> - include element - applicable to non-default packages and means do >>>>> install the non-default package (and its dependencies); >>>>> >>>> What happens if it?s used for a default package? The tool forgives this, right? >>> >>> That would be redundant, of course. We could ignore that or issue a warning. >> >> That question was kind of a tangent. I asked because I could imagine a case where a package is not default in version 1, so the user adds an ?include?. Then in a later version the package is now a default one. You don?t want to break the user for no good reason. >> >>> >>>>> - pick element - applicable to any package and means install only the >>>>> picked package(s) >>>> >>>> and it?s dependencies? If yes, all its dependencies or only non-optional? >>> >>> No, the dependencies would have to be picked explicitly. Otherwise, we have to allow exclude and include to be used in combination with pick which will look too confusing. >>> >> >> Ok, then assuming that in Proposal 1 an ?include? element always means pull in dependencies, I prefer Proposal 1. Forcing people to list everything just to get a subset of the default packages is painful and will likely break things if the feature-pack adds a new dependency in a later version. > > I realize my response didn?t account for the fact that in the Proposal 1 section you answered one of my questions by stating that excluding a non-optional dependency is an error. > > If the general rule is non-optional dependencies can?t be excluded, I see no reason why ?pick? shouldn?t automatically bring them in. And then the only things a user would want to ?exclude? in the context of a ?pick? are optional dependencies. Which means always excluding them and forcing the user to include them via additional ?pick? elements is less terrible. > > I still prefer Proposal 1, but not as strongly as I did. > >> >> But? >> >> There are cases where people do want to explicitly list things and not have unexpected things brought in. See discussion on https://issues.apache.org/jira/browse/MNG-2315 (for which I voted). I do think it?s good to account for that kind of use case. >> >>>>> ignoring other default and non-default ones. pick >>>>> cannot be used in combination with exclude and include. >>>>> >>>>> >>>>> Basically, 'include' and 'exclude' in both proposals are practically the >>>>> same. The difference is how the picking is expressed. In the first one, >>>>> everything is explicitly excluded and then the desired ones are >>>>> explicitly included, in the second one the desired ones are simply >>>>> explicitly picked. >>>>> >>>> >>>> The answers to my questions on Proposal 1 impact the semantics of include/exclude in different cases, so I?ll defer expressing an opinion for now. :) >>> >>> Thanks, >>> Alexey >>> >>>> >>>>> >>>>> Thanks, >>>>> Alexey >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> JBoss by Red Hat >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From rory.odonnell at oracle.com Sat Oct 22 09:57:18 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Sat, 22 Oct 2016 21:57:18 +0800 Subject: [wildfly-dev] Early Access builds for JDK 8u122 b02 , JDK 9 & JDK 9 with Project Jigsaw b140 are available on java.net Message-ID: <5bf82ddf-78fa-68f0-4c3c-571160dc535f@oracle.com> Hi Jason/Tomaz, Early Access b02 for JDK 8u122 is available , summary of changes are listed here. Early Access b140 (#5625) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here. Early Access b140 for JDK 9 is available on java.net, summary of changes are listed here . A couple of items to point out with regard to b140: 1. A fix for Cyclic interface initialization causes JVM crash is included in b140 2. We are requesting feedback on a change that went into JDK 9 b140 The java.io.FilePermission class was changed to remove pathname canonicalization from its creation, along with a system property to revert the behavior back to way it worked in the previous JDK release. We do this mainly for performance enhancement so that there is no need to consult the file system every time a FilePermisson is created. If you use a security manager and file permissions then you should read the details as described on the jdk9 mailing list [1] Feedback is requested via core-libs-dev at openjdk.java.net The new GA date of JDK 9 has been updated on the JDK 9 Project page [2], further details in Mark Reinhold's email [3]. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/005062.html [2] http://openjdk.java.net/projects/jdk9/ [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/005092.html -- 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/20161022/ae7e13d4/attachment.html From will.milspec at gmail.com Wed Oct 26 10:20:31 2016 From: will.milspec at gmail.com (Will Milspec) Date: Wed, 26 Oct 2016 09:20:31 -0500 Subject: [wildfly-dev] classloading problem prevents Wildfly from running (Wildfly 10.1, LogManager, IBM JDK8, yajsw) Message-ID: Hi all, I've run into a classloading problem that prevents wildfly 10.1 from running with the following stack: -Wildfly 10.1 -IBM JDK 8 (the latest, 8.0-3.12) -YAJSW ("Yet Another Java Service Wrapper") -Ubuntu 14.04 linux AMD 64 LogManager Classloader check fails with IBMJDK8 and YAJSW ========================================================== This stack fails because wildfly/jboss thinks the logManager is not loaded properly. Wildfly concludes as such because this check returns true: if (LogManager.getLogManager().getClass() == LogManager.class) { To clarify: with this tech stack, the system classloader loads both LogManager.getLogManager() and LogManager.class. Thus the two classes are identical, i.e. "==" I'll call this stack: Stack1) IBMJDK8 and Yajsw Log Manager Classloader check succeeds with other stacks ========================================================== This 'class==" check succeeds (returns false) in all other stacks I've tested with Wildfly 10.1 Stack2) IBMJDK8 from the command line (no yasw) Stack3) Oracle JDK8 with yajsw Stack4) Oracle JDK8 from the command line (no yajsw) With stacks 2-4, the jboss-module-classloader loads "LogManager.getLogManager()", whereas the system classloader loads "LogManager.class" I have no idea why the difference, i.e. why "ibmjdk8 and yajsw" uses "system classloader" to load LogManager.getLogManager and why the difference for the other stacks. Note that between "Stack1" and "Stack2", I only changed "which java command". All other configurations are identical. Code Details: Where this check occurs ============================= I've searched the wildfly code and found this check in two places: jboss-modules: Main.java wildfly-core: LoggingExtension.java I may have missed something. (I checked the versions in the shipped-with-wildfly-10.1 jar, cloned the various git repos and checked out the corresponding versions for jboss-modules and wildlfy-core) Xref, Xpost =================== As this problem has several components, I've posted it in a few places: yajsw forums, ibm jdk forums etc. Yeah, I know cross-posting is bad form. Mea culpa. But as user, I did not know (and still don't) if the problem lies in "yajsw code" or "wildfly/jboss code" or in the IBM JDK. This is "low-level stuff" Other posts (same information): https://www.ibm.com/developerworks/community/forums/html/topic?id=8e9e4ae2-53a7-42e8-8086-6208b80e2910&ps=25 https://sourceforge.net/p/yajsw/discussion/810311/thread/e730451b/?limit=25 Questions ===================== -Any workarounds? (i've tried all sorts of tweaks, all dead end) -Any idea why the difference, i.e. why would systemclassloader load "LogManager.getLogManager()" with "Stack1" vs "Stacks2-4" thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161026/f04da732/attachment.html From gunnar at hibernate.org Thu Oct 27 08:42:37 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 27 Oct 2016 14:42:37 +0200 Subject: [wildfly-dev] Making Jandex annotation index available to components Message-ID: Hi, --- TL,DR: Hibernate components would like to receive the Jandex index during deployment. A new method IndexView#close() may help to address concerns about long-living index view references --- Different projects from the Hibernate umbrella (e.g. ORM, Validator and Search) rely heavily on meta-data given via annotations. In order to speed up annotation retrieval, we are looking into using the Jandex index created for deployments by the container. This would require subsystems like JipiJapa or the one for Bean Validation to pass the IndexView for the deployment to the bootstrapped component. The change itself should be easy, I hope. But Scott expressed concerns about components keeping references to the index after the deployment phase has succeeded. As indexes can be large, this may potentially block a big chunk of memory for as long as the deployment is running. Of course we can promise that Hibernate components wouldn't keep such references ;) But if that's not enough, could this concern be mitigated by adding a new method IndexView#close()? This method would free all resources of the index and would be called by the container after the deployment has finished. Any operation on a closed index view would throw an exception indicating that the view has been closed. Then, even if a component accidentally kept a reference to an IndexView, it wouldn't retain much memory (of course the index view wouldn't be of much use to the component in that state). Would that be an acceptable way forward? If so, I could send a pull request towards Jandex. In a next step WF would have to make use of that new version and invoke close() on a deployment's index at a suitable time during the deployment lifecycle and eventually pass the index to ORM et al. In a subsequent step we may consider to address use cases such as dynamic reconfiguration which would require to access the index *after* deployment time. One way for addressing this may be to allow for passing in some kind of executor which would expect e.g. a Lambda doing work on an IndexView passed in by the executor. That way components could access the index at runtime, while not keeping a reference to it themselves and thus allowing the container to manage the index and e.g. close or re-open it upon execution. But I think this could be done as a follow-up. Any thoughts? Thanks, --Gunnar PS: As a side note, Hibernate Validator currently reads annotations lazily at runtime (when first validating a specific bean type). When using Jandex, we'd have to change this to eagerly build up all the meta-data for the types listed in the index passed during bootstrap. A bit of work, but as said we hope to gain a nice performance improvement from it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161027/489acf62/attachment-0001.html From jai.forums2013 at gmail.com Thu Oct 27 08:47:06 2016 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 27 Oct 2016 18:17:06 +0530 Subject: [wildfly-dev] classloading problem prevents Wildfly from running (Wildfly 10.1, LogManager, IBM JDK8, yajsw) In-Reply-To: References: Message-ID: <5811F74A.4020904@gmail.com> WildFly forums https://developer.jboss.org/en/wildfly would be a better place to discuss this. When you open the thread there, can you post what the startup wrapper script for YAJSW look like? -Jaikiran On Wednesday 26 October 2016 07:50 PM, Will Milspec wrote: > Hi all, > > I've run into a classloading problem that prevents wildfly 10.1 from > running with the following stack: > > -Wildfly 10.1 > -IBM JDK 8 (the latest, 8.0-3.12) > -YAJSW ("Yet Another Java Service Wrapper") > -Ubuntu 14.04 linux AMD 64 > > LogManager Classloader check fails with IBMJDK8 and YAJSW > ========================================================== > This stack fails because wildfly/jboss thinks the logManager is not > loaded properly. > > Wildfly concludes as such because this check returns true: > if (LogManager.getLogManager().getClass() == LogManager.class) { > > To clarify: with this tech stack, the system classloader loads both > LogManager.getLogManager() and LogManager.class. Thus the two classes > are identical, i.e. "==" > > I'll call this stack: > Stack1) IBMJDK8 and Yajsw > > Log Manager Classloader check succeeds with other stacks > ========================================================== > This 'class==" check succeeds (returns false) in all other stacks I've > tested with Wildfly 10.1 > > Stack2) IBMJDK8 from the command line (no yasw) > Stack3) Oracle JDK8 with yajsw > Stack4) Oracle JDK8 from the command line (no yajsw) > > > With stacks 2-4, the jboss-module-classloader loads > "LogManager.getLogManager()", whereas the system classloader loads > "LogManager.class" > > I have no idea why the difference, i.e. why "ibmjdk8 and yajsw" uses > "system classloader" to load LogManager.getLogManager and why the > difference for the other stacks. > > Note that between "Stack1" and "Stack2", I only changed "which java > command". All other configurations are identical. > > Code Details: Where this check occurs > ============================= > I've searched the wildfly code and found this check in two places: > jboss-modules: Main.java > wildfly-core: LoggingExtension.java > > I may have missed something. (I checked the versions in the > shipped-with-wildfly-10.1 jar, cloned the various git repos and > checked out the corresponding versions for jboss-modules and wildlfy-core) > > Xref, Xpost > =================== > As this problem has several components, I've posted it in a few > places: yajsw forums, ibm jdk forums etc. > > Yeah, I know cross-posting is bad form. Mea culpa. But as user, I did > not know (and still don't) if the problem lies in "yajsw code" or > "wildfly/jboss code" or in the IBM JDK. This is "low-level stuff" > > Other posts (same information): > https://www.ibm.com/developerworks/community/forums/html/topic?id=8e9e4ae2-53a7-42e8-8086-6208b80e2910&ps=25 > > https://sourceforge.net/p/yajsw/discussion/810311/thread/e730451b/?limit=25 > > > Questions > ===================== > -Any workarounds? (i've tried all sorts of tweaks, all dead end) > > -Any idea why the difference, i.e. why would systemclassloader load > "LogManager.getLogManager()" with "Stack1" vs "Stacks2-4" > > thanks in advance! > > > _______________________________________________ > 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/20161027/36b5ad99/attachment.html From gunnar at hibernate.org Mon Oct 31 11:47:06 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 31 Oct 2016 16:47:06 +0100 Subject: [wildfly-dev] Updating components in WildFly Message-ID: Hi, Users of the different Hibernate projects often wish to upgrade their WildFly installation to the latest releases of Hibernate ORM, Search or Validator. For that purpose we began to provide ZIP files containing the newer JARs and module.xml descriptors, to be unzipped into the server's module directory. We use separate slot names, so to not overwrite existing modules but just add newer versions next to them. But sometimes redefining the default slot actually is desirable. If an update for instance is just a bugfix release, it's sensible to push this to the main slot so users can benefit from it without having to explicitly specify a slot name, suppress any implicit default module and so on. But as I said we don't want to mess with any existing modules, so I've been looking into alternatives. One thing I found was to provide the updated modules in a separate layer, which then overrides the original modules from the "base" layer, without physically altering them. The user can go back to the original ones just by removing an entry in layers.conf. That works nicely, but then I also learned about the patch mechanism. So I wondered whether that should be the approach for us to follow, e.g. I also saw that Weld is providing patches for WF. Is this then the officially recommended way (TM) for upstream projects for shipping easy-to-use updates of their components for WF? One thing getting in the way of this is the lack of a Maven plug-in for the patch-gen tool. This makes patch creation quite unwieldy in an automated build process. Is there any chance for getting a Maven plug-in for patch-gen? If there is interest, I'd also be volunteering to provide it, it shouldn't take too long. Thanks for any hints, --Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161031/c1d83b70/attachment.html From jperkins at redhat.com Mon Oct 31 17:18:02 2016 From: jperkins at redhat.com (James Perkins) Date: Mon, 31 Oct 2016 14:18:02 -0700 Subject: [wildfly-dev] log4j2 Support in WildFly Message-ID: Hello All, tl;dr; Do users expect their log4j2 configurations to be picked up and used to configure a log manager? Or do they just want to use the log4j2 API and have the logging subsystem be the spot where the configuration is kept Long version: It's been requested for some time to have log4j2 support in WildFly [1]. About a month ago I was finally able to start looking into this. In log4j2 [2] they "separated" the API from the implementation to make it "clear for application developers which classes and methods they can use while ensuring forward compatibility". However API has no configuration options. It's essentially like a logging facade which requires log4j-core [3] if you want appenders, layouts, etc. While it was pretty easy to implement just the API [4], I'm not sure this is what users are looking for. Implementing the API will allow you to use log4j2 loggers which just delegate to JBoss Log Manager. However none of the log4j2 appenders, async logging or log4j2 configurations could be used. This would require log4j-core [3]. If users expect their log4j2 configuration files within their deployment to configure a log4j2 LogManager we run into problems, since this would require log4j-core to work. The simple solution seemed to be if they want that to work they just need to include log4j-core in their deployment. However in the awesomeness that is log4j2 (where's a SarcMark TM when you need it?) parts of log4j-core seem to require a org.apache.logging.log4j.core.LoggerContext instead of the LoggerContext from the API. This means we can't simply just use our own LoggerContext implementation and just delegate to the log4j-core embedded in the deployment. I guess that got into a little too much detail there :) The real question is do we want to support user defined log4j2 configurations? If so it may get a bit tricky getting this to work. If not we can easily support just delegating the log4j2 loggers to JBoss Log Manager loggers. Any feedback is appreciated. Especially if you're familiar with log4j2 and have opinions on how it should work with WildFly. [1]: https://issues.jboss.org/browse/WFCORE-482 [2]: http://logging.apache.org/log4j/2.x/ [3]: https://logging.apache.org/log4j/2.x/log4j-core/ [4]: https://github.com/jamezp/log4j2-jboss-logmanager -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161031/1c2d9df8/attachment.html