From sanne at hibernate.org Mon Sep 3 07:30:25 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 3 Sep 2018 12:30:25 +0100 Subject: [wildfly-dev] org.apache.httpcomponents.core requires org.apache.commons.codec Message-ID: Hi all, the Elasticsearch integration feature we have in Hibernate Search uses the Apache httpcomponents module from WildFly. In WildFly 14 we get: Exception in thread "Hibernate Search: Elasticsearch transport thread-2" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.BasicScheme.authenticate(BasicScheme.java:168) 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239) 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:218) 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.nio.client.MainClientExec.generateRequest(MainClientExec.java:224) Seems that the `org.apache.httpcomponents.core` is not declaring the dependency on module `org.apache.commons.codec`. One complexity is that the first one is included in WildFly core, the second is only added by WildFly full. I guess I could add an optional dependency, but I wonder if many more users would expect the basic authentication scheme to work in WildFly core? In that case you would probably prefer to include the codec in WildFly Core. I can try fixing this but would need to know which solution you all prefer. Also, not sure about the severity: definitely bad for Hibernate Search users, but I don't know which other components might be using this module. Created: https://issues.jboss.org/browse/WFCORE-4083 Thanks, Sanne From claudio at claudius.com.br Mon Sep 3 10:58:13 2018 From: claudio at claudius.com.br (Claudio Miranda) Date: Mon, 3 Sep 2018 11:58:13 -0300 Subject: [wildfly-dev] Changes to Wildfly model that affects HAL Message-ID: Hi, I would like to propose to add a label "affects-hal" to WFLY/WFCORE issues that may affect HAL, for example if the resulting change may add/change/remove resources/operations or dependent resources, this way once the PR is open, we may test the changes before it is merged or work on a HAL feature branch. I have had manually looking (and following) for PR that contains those changes, but it is more of a guessing work. An alternative to add the label, would be to add the "Web Console" component to the issue, but this would not work as there should be two issues one for WFLY/WFCORE and one for HAL. I would like to hear your opinions on this topic to help us track those incoming changes. Thanks -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From tom.jenkinson at redhat.com Tue Sep 4 04:31:41 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Tue, 4 Sep 2018 09:31:41 +0100 Subject: [wildfly-dev] Changes to Wildfly model that affects HAL In-Reply-To: References: Message-ID: Perhaps it would be simplest to ask that people who make changes that affect the console raise a HAL enhancement request directly in the HAL issue tracker? Would that be possible? On 3 September 2018 at 15:58, Claudio Miranda wrote: > Hi, I would like to propose to add a label "affects-hal" to > WFLY/WFCORE issues that may affect HAL, for example if the resulting > change may add/change/remove resources/operations or dependent > resources, this way once the PR is open, we may test the changes > before it is merged or work on a HAL feature branch. > > I have had manually looking (and following) for PR that contains those > changes, but it is more of a guessing work. > > An alternative to add the label, would be to add the "Web Console" > component to the issue, but this would not work as there should be two > issues one for WFLY/WFCORE and one for HAL. > > I would like to hear your opinions on this topic to help us track > those incoming changes. > > Thanks > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > 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/20180904/1d7ed851/attachment.html From claudio at claudius.com.br Tue Sep 4 08:20:08 2018 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 4 Sep 2018 09:20:08 -0300 Subject: [wildfly-dev] Changes to Wildfly model that affects HAL In-Reply-To: References: Message-ID: On Tue, Sep 4, 2018 at 5:31 AM, Tom Jenkinson wrote: > Perhaps it would be simplest to ask that people who make changes that affect > the console raise a HAL enhancement request directly in the HAL issue > tracker? Would that be possible? This would be the preferable option. I didn't ask it at first as that would require a bit more work of the developer, but I prefer this option. Thanks Tom -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From brian.stansberry at redhat.com Tue Sep 4 12:37:45 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 4 Sep 2018 11:37:45 -0500 Subject: [wildfly-dev] Making More Use of wildfly-proposals In-Reply-To: References: Message-ID: This is a really good idea. Where would the cross-ref page live, how would publication work, etc? On Thu, Aug 30, 2018 at 12:01 PM, Darran Lofthouse < darran.lofthouse at redhat.com> wrote: > At the moment we have a lot of effort going into populating the > wildfly-proposals repository with the proposals for new features as they > are added to the application server - but at the end other than them > sitting in the repository we don't really do anything with them. > > I was wondering if we could maybe do something to add a table of contents > per WildFly release cross referencing the proposals added in that release > and at the end we could generate publishable documentation. > > This could give us some quite detailed release notes without a huge amount > of additional effort taking advantage of the effort that goes into writing > these 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 Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180904/b65e32e8/attachment.html From darran.lofthouse at redhat.com Wed Sep 5 04:50:54 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Wed, 5 Sep 2018 09:50:54 +0100 Subject: [wildfly-dev] Making More Use of wildfly-proposals In-Reply-To: References: Message-ID: I was thinking the cross reference page would likely need to live in the proposals repo so any links can be added with the proposal. If this repo was also tagged at the same time as the WildFly release that would also have the benefit of allowing us to diff between two releases to double check all additions are cross referenced. I think this project would need a pom adding to define the build like we do for the WildFly docs. Then for location I suppose we could either be with the WildFly docs - of if not just publish the resulting html via GitHub using the same repo. On Tue, 4 Sep 2018 at 17:37 Brian Stansberry wrote: > This is a really good idea. Where would the cross-ref page live, how would > publication work, etc? > > On Thu, Aug 30, 2018 at 12:01 PM, Darran Lofthouse < > darran.lofthouse at redhat.com> wrote: > >> At the moment we have a lot of effort going into populating the >> wildfly-proposals repository with the proposals for new features as they >> are added to the application server - but at the end other than them >> sitting in the repository we don't really do anything with them. >> >> I was wondering if we could maybe do something to add a table of contents >> per WildFly release cross referencing the proposals added in that release >> and at the end we could generate publishable documentation. >> >> This could give us some quite detailed release notes without a huge >> amount of additional effort taking advantage of the effort that goes into >> writing these 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 > Manager, Senior Principal Software Engineer > Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180905/bc7f485f/attachment-0001.html From kkhan at redhat.com Wed Sep 5 06:43:57 2018 From: kkhan at redhat.com (Kabir Khan) Date: Wed, 5 Sep 2018 11:43:57 +0100 Subject: [wildfly-dev] Making More Use of wildfly-proposals In-Reply-To: References: Message-ID: > On 5 Sep 2018, at 09:50, Darran Lofthouse wrote: > > I was thinking the cross reference page would likely need to live in the proposals repo so any links can be added with the proposal. > > If this repo was also tagged at the same time as the WildFly release that would also have the benefit of allowing us to diff between two releases to double check all additions are cross referenced. Tagging is a bit hard to do fix once done (we sometimes forget to merge the analysis documents), but perhaps that isn't too big a deal. Another thing is to do a JQL query of the EAP7 issues resolved for a particular CD, and include the Analysis Document column in the query results. Those generally link to pull requests though, so something would need to be done to pull out the relevant files. I realise the use of EAP7 isn't strictly 'community', but once I get some cycles to get back on the Kanban tooling, the plan is to move/duplicate this information in the WFLY/WFCORE feature requests. > > I think this project would need a pom adding to define the build like we do for the WildFly docs. > > Then for location I suppose we could either be with the WildFly docs - of if not just publish the resulting html via GitHub using the same repo. > > > On Tue, 4 Sep 2018 at 17:37 Brian Stansberry wrote: > This is a really good idea. Where would the cross-ref page live, how would publication work, etc? > > On Thu, Aug 30, 2018 at 12:01 PM, Darran Lofthouse wrote: > At the moment we have a lot of effort going into populating the wildfly-proposals repository with the proposals for new features as they are added to the application server - but at the end other than them sitting in the repository we don't really do anything with them. > > I was wondering if we could maybe do something to add a table of contents per WildFly release cross referencing the proposals added in that release and at the end we could generate publishable documentation. > > This could give us some quite detailed release notes without a huge amount of additional effort taking advantage of the effort that goes into writing these 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 > Manager, Senior Principal Software Engineer > 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 Fri Sep 7 05:08:49 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 7 Sep 2018 10:08:49 +0100 Subject: [wildfly-dev] JDK 12 & JMC 7.0.0 Early Access builds are available Message-ID: <4025068c-e14a-e207-0223-555606031b53@oracle.com> Hi David & Richard,* * *JDK 11 build 28 is our first JDK 11 Release Candidate [1] * * JDK 11 build 28 is available at : - jdk.java.net/11/ *JDK 12 Early Access build 10 is available at : - jdk.java.net/12/* * Release Notes for JDK 12 [2] * *JEPs integrated to JDK 12:* o 325: Switch Expressions (Preview [3]) * *JEPs proposed to target JDK 12:* o 326: Raw String Literals (Preview [3]) *FOSS bug fixes in recent builds.* * Apache Ant - JDK-8209965(b09) *Other important fixes in JDK 12* * Disabled all DES TLS Cipher Suites (JDK-8208350 ) o DES-based TLS cipher suites are considered obsolete and should no longer be used *JMC 7.0.0 Early Access build 04 is available at :- **http://jdk.java.net/jmc/* * Overview - summary [4] * These early-access, open-source builds are provided under the Universal Permissive License, version?1.0. * Feedback via the http://bugreport.java.com/ o Be sure to include jmc application Build id from "Help" - "About JDK Mission Control". Rgds, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html [2] http://jdk.java.net/12/release-notes [3] http://openjdk.java.net/jeps/12 [4] https://download.java.net/java/early_access/jmc7/core/common/docs/api/overview-summary.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/20180907/6075b03d/attachment.html From hpehl at redhat.com Tue Sep 18 11:56:45 2018 From: hpehl at redhat.com (Harald Pehl) Date: Tue, 18 Sep 2018 17:56:45 +0200 Subject: [wildfly-dev] Changes to Wildfly model that affects HAL In-Reply-To: References: Message-ID: <238BEB68-27DC-46C8-937B-36B2DAEFEA62@redhat.com> I really like your idea Claudio. Having such a label would make our work a lot easier. At the same time this would be the least time-consuming option for the reporter of the issue. Having such a label, we could setup filters and create the related HAL issues on our own. > On 4. Sep 2018, at 14:20, Claudio Miranda wrote: > > On Tue, Sep 4, 2018 at 5:31 AM, Tom Jenkinson wrote: >> Perhaps it would be simplest to ask that people who make changes that affect >> the console raise a HAL enhancement request directly in the HAL issue >> tracker? Would that be possible? > > This would be the preferable option. I didn't ask it at first as that > would require a bit more work of the developer, but I prefer this > option. > > Thanks Tom > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ppalaga at redhat.com Tue Sep 18 12:01:23 2018 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 18 Sep 2018 18:01:23 +0200 Subject: [wildfly-dev] Completion of DeploymentUnitProcessor.deploy(ear, war1, war2) observed in a subsequent phase? Message-ID: Hi *, I cannot find any info about what (if any) are the guarantees for ordering and exit of DeploymentUnitProcessors (DUPs) in case of an EAR that contains multiple WARs. I have a situation like this: MyDUP1 is registered for Phase.PARSE and MyDup2 is registered for Phase.DEPENDENCIES. I can see from the logs that MyDUP1.deploy(ear), MyDUP1.deploy(ear.war1), MyDUP1.deploy(war2), etc. are executed by distinct threads which is perfectly OK. I'd like to know if there is any guarantee that MyDup2.deploy(*) observes the completion of MyDUP1.deploy(ear), MyDUP1.deploy(ear.war1), MyDUP1.deploy(ear.war2), etc.? MyDUP1.deploy() collects some info from the EAR and the WARs and stores it as an attachment of the DeploymentUnit. MyDup2.deploy() is supposed to read that attachment and so it is important that the info is complete when MyDup2.deploy() reads it. Thanks, -- Peter From brian.stansberry at redhat.com Tue Sep 18 15:39:11 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 18 Sep 2018 14:39:11 -0500 Subject: [wildfly-dev] Completion of DeploymentUnitProcessor.deploy(ear, war1, war2) observed in a subsequent phase? In-Reply-To: References: Message-ID: The DUPs in each Phase are executed in the start method of an MSC Service that represents that Phase for that deployment.[1] The start method executes the DUPs associated with the phase and then installs the service for the next phase. So, all DUPs for PARSE will have run before any DEPENDENCIES DUPs are run. [1] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentUnitPhaseService.java#L85 On Tue, Sep 18, 2018 at 11:01 AM, Peter Palaga wrote: > Hi *, > > I cannot find any info about what (if any) are the guarantees for > ordering and exit of DeploymentUnitProcessors (DUPs) in case of an EAR > that contains multiple WARs. > > I have a situation like this: MyDUP1 is registered for Phase.PARSE and > MyDup2 is registered for Phase.DEPENDENCIES. > I can see from the logs that MyDUP1.deploy(ear), > MyDUP1.deploy(ear.war1), MyDUP1.deploy(war2), etc. are executed by > distinct threads which is perfectly OK. > I'd like to know if there is any guarantee that MyDup2.deploy(*) > observes the completion of MyDUP1.deploy(ear), MyDUP1.deploy(ear.war1), > MyDUP1.deploy(ear.war2), etc.? > > MyDUP1.deploy() collects some info from the EAR and the WARs and stores > it as an attachment of the DeploymentUnit. MyDup2.deploy() is supposed > to read that attachment and so it is important that the info is complete > when MyDup2.deploy() reads it. > > Thanks, > > -- Peter > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180918/d0375603/attachment-0001.html From stuart.w.douglas at gmail.com Tue Sep 18 17:41:23 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 19 Sep 2018 07:41:23 +1000 Subject: [wildfly-dev] Completion of DeploymentUnitProcessor.deploy(ear, war1, war2) observed in a subsequent phase? In-Reply-To: References: Message-ID: For ear deployments each phase is first run for the ear, then run for all sub deployments in parallel. This means that any changes made by the ear deployer are visible, however you need to be careful about thread safety for the sub deployments if you are working with things attached to the top level ear, as multiple threads may be doing the same thing. Stuart On Wed, Sep 19, 2018 at 2:19 AM Peter Palaga wrote: > Hi *, > > I cannot find any info about what (if any) are the guarantees for > ordering and exit of DeploymentUnitProcessors (DUPs) in case of an EAR > that contains multiple WARs. > > I have a situation like this: MyDUP1 is registered for Phase.PARSE and > MyDup2 is registered for Phase.DEPENDENCIES. > I can see from the logs that MyDUP1.deploy(ear), > MyDUP1.deploy(ear.war1), MyDUP1.deploy(war2), etc. are executed by > distinct threads which is perfectly OK. > I'd like to know if there is any guarantee that MyDup2.deploy(*) > observes the completion of MyDUP1.deploy(ear), MyDUP1.deploy(ear.war1), > MyDUP1.deploy(ear.war2), etc.? > > MyDUP1.deploy() collects some info from the EAR and the WARs and stores > it as an attachment of the DeploymentUnit. MyDup2.deploy() is supposed > to read that attachment and so it is important that the info is complete > when MyDup2.deploy() reads it. > > Thanks, > > -- Peter > _______________________________________________ > 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/20180919/41ba7e23/attachment.html From ppalaga at redhat.com Wed Sep 19 03:14:50 2018 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 19 Sep 2018 09:14:50 +0200 Subject: [wildfly-dev] Completion of DeploymentUnitProcessor.deploy(ear, war1, war2) observed in a subsequent phase? In-Reply-To: References: Message-ID: <11d7ab15-1879-63e8-ee95-0426be2ad689@redhat.com> Very helpful, thanks a lot Brian and Stuart! -- P On 18/09/18 23:41, Stuart Douglas wrote: > For ear deployments each phase is first run for the ear, then run for > all sub deployments in parallel. This means that any changes made by the > ear deployer are visible, however you need to be careful about thread > safety for the sub deployments if you are working with things attached > to the top level ear, as multiple threads may be doing the same thing. > > Stuart > > On Wed, Sep 19, 2018 at 2:19 AM Peter Palaga > wrote: > > Hi *, > > I cannot find any info about what (if any) are the guarantees for > ordering and exit of DeploymentUnitProcessors (DUPs) in case of an EAR > that contains multiple WARs. > > I have a situation like this: MyDUP1 is registered for Phase.PARSE and > MyDup2 is registered for Phase.DEPENDENCIES. > I can see from the logs that MyDUP1.deploy(ear), > MyDUP1.deploy(ear.war1), MyDUP1.deploy(war2), etc. are executed by > distinct threads which is perfectly OK. > I'd like to know if there is any guarantee that MyDup2.deploy(*) > observes the completion of MyDUP1.deploy(ear), MyDUP1.deploy(ear.war1), > MyDUP1.deploy(ear.war2), etc.? > > MyDUP1.deploy() collects some info from the EAR and the WARs and stores > it as an attachment of the DeploymentUnit. MyDup2.deploy() is supposed > to read that attachment and so it is important that the info is > complete > when MyDup2.deploy() reads it. > > Thanks, > > -- Peter > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From ppalaga at redhat.com Mon Sep 24 12:08:40 2018 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 24 Sep 2018 18:08:40 +0200 Subject: [wildfly-dev] How to test for leak-less undeployments? Message-ID: <1fad1abf-de5c-3f05-ff4e-9c7cf005fd57@redhat.com> Hi *, we accidentally found out that WildFly Camel keeps some Camel objects in memory after the given app was undeployed [1]. I was able to figure out how to fix it, but I'd also like to make sure that it does not happen again. I wonder if WildFly/EAP has tests in place where we could look for an inspiration? Thanks, -- Peter [1] https://github.com/wildfly-extras/wildfly-camel/issues/2649 From rory.odonnell at oracle.com Wed Sep 26 04:37:31 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 26 Sep 2018 09:37:31 +0100 Subject: [wildfly-dev] Release Announcement: General Availability of JDK 11 Message-ID: <5d592a13-fad7-9634-5213-c152633f7f7e@oracle.com> Hi David & Richard,* * *1) Release Announcement: General Availability of JDK 11 * * JDK 11, the reference implementation of Java 11 and the first long-term support release produced under the six-month rapid-cadence release model [1][2], is now Generally Available. * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/11 This release includes seventeen features: * 181: Nest-Based Access Control * 309: Dynamic Class-File Constants * 315: Improve Aarch64 Intrinsics * 318: Epsilon: A No-Op Garbage Collector * 320: Remove the Java EE and CORBA Modules * 321: HTTP Client (Standard) * 323: Local-Variable Syntax for Lambda Parameters * 324: Key Agreement with Curve25519 and Curve448 * 327: Unicode 10 * 328: Flight Recorder * 329: ChaCha20 and Poly1305 Cryptographic Algorithms * 330: Launch Single-File Source-Code Programs * 331: Low-Overhead Heap Profiling * 332: Transport Layer Security (TLS) 1.3 * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) * 335: Deprecate the Nashorn JavaScript Engine * 336: Deprecate the Pack200 Tools and API 2) Quality Outreach Report for September 2018 is available* * * Quality Outreach report September 2018 *Thanks to everyone who contributed to JDK 11 by downloading and testing the early-access builds. In particular the following developers who logged **18 issues in the JDK Bug System.* * Netty * Eclipse Jetty * Apache Lucene * JUnit5 * Apache Tomcat * Apache Ant * Apache POI * AssertJ * Eclipse Collections * Byte Buddy * RxJava 3) JDK 12 EA build 12, under both the GPL and Oracle EA licenses, are now available at http://jdk.java.net/11 . * Schedule , Status & Features o http://openjdk.java.net/projects/jdk/12/ * Release Notes: o http://jdk.java.net/12/release-notes ** 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/20180926/c4b4a590/attachment.html From darran.lofthouse at jboss.com Wed Sep 26 09:15:20 2018 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 26 Sep 2018 14:15:20 +0100 Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages Message-ID: During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet. We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder. I have put together a blog post describing some of the general issues we want to look into: - http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html Some of these changes will have an impact on any subsystem currently referencing the credential store. Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three. I am also going to share this link in the community forums to try and obtain some additional feedback from end users. Regards, Darran Lofthouse. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180926/3e984d20/attachment-0001.html