From boyd.nolan at tylertech.com Wed Jul 5 11:40:17 2017 From: boyd.nolan at tylertech.com (jboydnolan) Date: Wed, 5 Jul 2017 08:40:17 -0700 (MST) Subject: [wildfly-dev] Security policy problems migrating jBoss 6.1+Java7 to Wildfly10+Java8 Message-ID: <1499269217475-5718006.post@n5.nabble.com> Hello, All, I'm not sure if this forum is the right place to be asking this level of question, but I wanted to throw it out to see if anyone might have some insight. I am migrating an application from JBoss 6.1 with Java7 to Wildfly10 with Java8, and have found that our java security implementation has stopped working as expected. In our application we load up a dynamic policy (java.security.Policy object) with a collection of permissions representing actions you can take in the application. We then evaluate actions a user tries to do using the java.security.auth.Subject class and the doAsPrivileged method. When running this same code setup in Wildfly10 with Java 8, all the security policy data loads up just fine, however the doAsPrivileged strategy returns without exception for all actions and all users, essentially allowing everyone full access to everything regardless of whether or not they should be able to get to all the actions. When debugging the fully loaded policy objects down inside of the java.security.auth space, what I see is that in addition to the standard actions, there always seems to be an AllPermissions / AllActions entry showing up. It seems like this entry is what might be causing the security behavior I am seeing. I?ve tried removing all the configuration entries that refer to java.security.AllPermission in places like the java.policy, standalone_full.xml, etc. Even with all those removed, the AllPermission type of entry still shows up. Does anyone have any insight into this behavior, or have some suggested technical documentation that might help me figure it out? I appreciate any help or direction you can provide. -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/Security-policy-problems-migrating-jBoss-6-1-Java7-to-Wildfly10-Java8-tp5718006.html Sent from the WildFly Development mailing list archive at Nabble.com. From jmesnil at redhat.com Thu Jul 6 05:45:15 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 6 Jul 2017 11:45:15 +0200 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck Message-ID: Hi, I had a look at the Eclipse MicroProfile Healthcheck spec[1] and wanted to share some thoughts and experiments about it, how it relates to WildFly and its use in containers (such as OpenShift). # Eclipse MicroProfile Healthcheck The Eclipse MicroProfile Healthcheck (MPHC for short) is a specification to determine the healthiness of an application. It defines a Health Check Procedure (HCP for short) interface that can be implemented by application to determine its healthiness. It?s a single method that returns a Health Status: either UP or DOWN (+ some metadata). Typically, an application would provide one or more HCP to check healthiness of its parts. The overall healthiness of the application is determined by the aggregation of all the HCP provided by the application. If any HCP is DOWN, the overall outcome is DOWN. Else the application is considered as UP. The MPHC spec has a companion document[2] that specifies an HTTP format to check the healthiness of an application. Heiko is leading the spec and Swarm is the sample implementation for it (MicroProfile does not have the notion of reference implementation). The spec is still in flux and we have a good opportunity to contribute to it to ensure that it meets our requirements and use cases. # Use case Using the HTTP endpoint, a container can ask an application whether it is healthy. If it is not healthy, the container could stop the application and respin a new instance. For example, OpenShift/Kubernetes can configure liveness probes[3][4]. Supporting MPHC in WildFly would allow a better integration with containers and ensure that any unhealthy WildFly process is restarted promptly. # Prototype I?ve written a prototype of a WildFly extension to support MPHC for applications deployed in WildFly *and* add health check procedures inside WildFly: https://github.com/jmesnil/wildfly-microprofile-health and it passes the MPHC tck :) The microprofile-health subsystem supports an operation to check the health of the app server: [standalone at localhost:9990 /] /subsystem=microprofile-health:check { "outcome" => "success", "result" => { "checks" => [{ "id" => "heap-memory", "result" => "UP", "data" => { "max" => "477626368", "used" => "156216336" } }], "outcome" => "UP" } } It also exposes an (unauthenticated) HTTP endpoint: $ curl http://localhost:8080/health/: { "checks":[ { "id":"heap-memory", "result":"UP", "data":{ "max":"477626368", "used":"160137128" } } ], "outcome":"UP" } This HTTP endpoint can be used by OpenShift for its liveness probe. Any deployment that defines Health Check Procedures will have them registered to determine the overall healthiness of the process. # WildFly health check procedures The MPHC specification mainly targets user applications that can apply application logic to determine their healthiness. However I wonder if we could reuse the concepts *inside* WildFly. There are things that we could check to determine if the App server runtime is healthy, e.g.: * The amount of heap memory is close to the max * some deployments have failed * Excessive GC * Running out of disk space Subsystems inside WildFly could provide Health check procedures that would be queried to check the overall healthiness. We could for example provide a health check that the used heap memory is less that 90% of the max: HealthCheck.install(context, "heap-memory", () -> { MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean(); long memUsed = memoryBean.getHeapMemoryUsage().getUsed(); long memMax = memoryBean.getHeapMemoryUsage().getMax(); HealthResponse response = HealthResponse.named("heap-memory") .withAttribute("used", memUsed) .withAttribute("max", memMax); // status is is down is used memory is greater than 90% of max memory. HealthStatus status = (memUsed < memMax * 0.9) ? response.up() : response.down(); return status; }); HealthCheck.install creates a MSC service and makes sure that is is registered by the health monitor that queries all the procedures. A subsystem would just have to call HealthCheck.install/uninstall with a Health check procedures to help determine the healthiness of the app server. What do you think about this use case? I even wonder if this is something that should be instead provided by our core-management subsystem with a private API (1 interface and some data structures). The microprofile-health extension would then map our private API to the MPHC spec and handled health check procedures coming from deployments. # Summary To better integrate WildFly with OpenShift, we should provide a way to let OpenShift checks the healthiness of WildFly. The MPHC spec is a good candidate to provide such feature. It is worth exploring how we could leverage it for user deployments and also for WildFly internals (when that makes sense). Swarm is providing an implementation of the MPHC, we also need to see how we can collaborate between WildFly and Swarm to avoid duplicating code and efforts from providing the same feature to our users. jeff [1] https://github.com/eclipse/microprofile-evolution-process/blob/master/proposals/0003-health-checks.md [2] https://github.com/eclipse/microprofile-evolution-process/blob/master/proposals/0003-spec.md [3] https://docs.openshift.com/enterprise/3.0/dev_guide/application_health.html [4] https://kubernetes.io/v1.0/docs/user-guide/walkthrough/k8s201.html#health-checking -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From dlloyd at redhat.com Thu Jul 6 09:00:38 2017 From: dlloyd at redhat.com (David Lloyd) Date: Thu, 6 Jul 2017 08:00:38 -0500 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: References: Message-ID: On Thu, Jul 6, 2017 at 4:45 AM, Jeff Mesnil wrote: > Hi, > > I had a look at the Eclipse MicroProfile Healthcheck spec[1] and wanted to share some thoughts and experiments about it, how it relates to WildFly and its use in containers (such as OpenShift). > > # Eclipse MicroProfile Healthcheck > > The Eclipse MicroProfile Healthcheck (MPHC for short) is a specification to determine the healthiness of an application. > It defines a Health Check Procedure (HCP for short) interface that can be implemented by application to determine its healthiness. It?s a single method that returns a Health Status: either UP or DOWN (+ some metadata). > Typically, an application would provide one or more HCP to check healthiness of its parts. > The overall healthiness of the application is determined by the aggregation of all the HCP provided by the application. If any HCP is DOWN, the overall outcome is DOWN. Else the application is considered as UP. > > The MPHC spec has a companion document[2] that specifies an HTTP format to check the healthiness of an application. > > Heiko is leading the spec and Swarm is the sample implementation for it (MicroProfile does not have the notion of reference implementation). > The spec is still in flux and we have a good opportunity to contribute to it to ensure that it meets our requirements and use cases. > > # Use case > > Using the HTTP endpoint, a container can ask an application whether it is healthy. If it is not healthy, the container could stop the application and respin a new instance. > For example, OpenShift/Kubernetes can configure liveness probes[3][4]. > > Supporting MPHC in WildFly would allow a better integration with containers and ensure that any unhealthy WildFly process is restarted promptly. > > # Prototype > > I?ve written a prototype of a WildFly extension to support MPHC for applications deployed in WildFly *and* add health check procedures inside WildFly: > > https://github.com/jmesnil/wildfly-microprofile-health > > and it passes the MPHC tck :) > > The microprofile-health subsystem supports an operation to check the health of the app server: > > [standalone at localhost:9990 /] /subsystem=microprofile-health:check > { > "outcome" => "success", > "result" => { > "checks" => [{ > "id" => "heap-memory", > "result" => "UP", > "data" => { > "max" => "477626368", > "used" => "156216336" > } > }], > "outcome" => "UP" > } > } > > It also exposes an (unauthenticated) HTTP endpoint: > > $ curl http://localhost:8080/health/: > { > "checks":[ > { > "id":"heap-memory", > "result":"UP", > "data":{ > "max":"477626368", > "used":"160137128" > } > } > ], > "outcome":"UP" > } > > This HTTP endpoint can be used by OpenShift for its liveness probe. > > Any deployment that defines Health Check Procedures will have them registered to determine the overall healthiness of the process. > > # WildFly health check procedures > > The MPHC specification mainly targets user applications that can apply application logic to determine their healthiness. > However I wonder if we could reuse the concepts *inside* WildFly. There are things that we could check to determine if the App server runtime is healthy, e.g.: > * The amount of heap memory is close to the max > * some deployments have failed > * Excessive GC > * Running out of disk space > > Subsystems inside WildFly could provide Health check procedures that would be queried to check the overall healthiness. > We could for example provide a health check that the used heap memory is less that 90% of the max: > > HealthCheck.install(context, "heap-memory", () -> { > MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean(); > long memUsed = memoryBean.getHeapMemoryUsage().getUsed(); > long memMax = memoryBean.getHeapMemoryUsage().getMax(); > HealthResponse response = HealthResponse.named("heap-memory") > .withAttribute("used", memUsed) > .withAttribute("max", memMax); > // status is is down is used memory is greater than 90% of max memory. > HealthStatus status = (memUsed < memMax * 0.9) ? response.up() : response.down(); > return status; > }); > > HealthCheck.install creates a MSC service and makes sure that is is registered by the health monitor that queries all the procedures. > A subsystem would just have to call HealthCheck.install/uninstall with a Health check procedures to help determine the healthiness of the app server. > > What do you think about this use case? > > I even wonder if this is something that should be instead provided by our core-management subsystem with a private API (1 interface and some data structures). > The microprofile-health extension would then map our private API to the MPHC spec and handled health check procedures coming from deployments. > > # Summary > > To better integrate WildFly with OpenShift, we should provide a way to let OpenShift checks the healthiness of WildFly. The MPHC spec is a good candidate to provide such feature. > It is worth exploring how we could leverage it for user deployments and also for WildFly internals (when that makes sense). > Swarm is providing an implementation of the MPHC, we also need to see how we can collaborate between WildFly and Swarm to avoid duplicating code and efforts from providing the same feature to our users. I like the idea of having a WildFly health API that can bridge to MPHC via a subsystem; this is consistent with what we've done in other areas. I'm not so sure about having (more?) APIs which drive services. It might be better to use cap/req to have a health capability to which other systems can be registered. This might allow multiple independent health check resources to be defined, for systems which perform more than one function; downstream health providers could reference the resource(s) to register with by capability name. Is this a polling-only service, or is there a "push" mechanism? Just brainstorming, I can think of a few more potentially useful health checks beyond what you've listed: ? EJB failure rate (if an EJB starts failing more than some percentage of the last, say 50 or 100 invocations, it could report an "unhealthy" condition) ? Database failure rate (something with JDBC exceptions maybe) ? Authentication realm failure rate (Elytron's RealmUnavailableException) -- - DML From DLampsi at inttrust.ru Thu Jul 6 09:02:01 2017 From: DLampsi at inttrust.ru (Dmitriy S. Lampsi) Date: Thu, 6 Jul 2017 16:02:01 +0300 Subject: [wildfly-dev] =?koi8-r?b?QVVUTzogRG1pdHJpeSBTLiBMYW1wc2kgLSDP1NPV?= =?koi8-r?b?1NPU19XAIM7BINLBws/UxSAocmV0dXJuaW5nIFN1biAwNy8yMy8yMDE3KQ==?= Message-ID: An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170706/16ceaca5/attachment.html From jmesnil at redhat.com Thu Jul 6 09:37:31 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 6 Jul 2017 15:37:31 +0200 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: References: Message-ID: <0C1968AA-3FD3-459E-8071-771D5BBB8E5C@redhat.com> > On 6 Jul 2017, at 15:00, David Lloyd wrote: > >> To better integrate WildFly with OpenShift, we should provide a way to let OpenShift checks the healthiness of WildFly. The MPHC spec is a good candidate to provide such feature. >> It is worth exploring how we could leverage it for user deployments and also for WildFly internals (when that makes sense). >> Swarm is providing an implementation of the MPHC, we also need to see how we can collaborate between WildFly and Swarm to avoid duplicating code and efforts from providing the same feature to our users. > > I like the idea of having a WildFly health API that can bridge to MPHC > via a subsystem; this is consistent with what we've done in other > areas. I'm not so sure about having (more?) APIs which drive > services. It might be better to use cap/req to have a health > capability to which other systems can be registered. This might allow > multiple independent health check resources to be defined, for systems > which perform more than one function; downstream health providers > could reference the resource(s) to register with by capability name. You are right. If we provide our own health API, it will rely on req/cap to bind everything. My idea was to provide an API that hides the req/cap plumbing but is built on top of it. It?d be similar to what I?m doing in the messaging-activemq subsystem where I almost always hides the installation of service in static install() methods such as [1] that requires only some parameters and hides all the dependencies/capabilities service names and injection) [1]https://github.com/wildfly/wildfly/blob/master/messaging-activemq/src/main/java/org/wildfly/extension/messaging/activemq/HTTPUpgradeService.java#L91 > Is this a polling-only service, or is there a "push" mechanism? Polling only. The container (OpenShift) will call the HTTP endpoint regularly to check the application healthiness. > Just brainstorming, I can think of a few more potentially useful > health checks beyond what you've listed: > > ? EJB failure rate (if an EJB starts failing more than some percentage > of the last, say 50 or 100 invocations, it could report an "unhealthy" > condition) > ? Database failure rate (something with JDBC exceptions maybe) That one is interesting. I proposed a health check that pings a JDBC connection to Heiko when we talked about the API and he told me that might be a bad idea after all. If the database fails, the application will not function as expected. But restarting the application will not make the problem goes away (it?s likely the DB that has a problem). Having health checks that cross service boundaries (such as "my app" ?DB?) may have a snowballing effect where one unhealthy service (the DB) would propagate its unhealthiness to other services (?my app?). In that case, the DB should be probed and restarted asap but there is nothing that should be done in the app server. We would need guidelines to determine which health checks actually makes sense for WildFly extensions. Caucho has an interesting list of health checks[1] that could make sense for WildFly. There is the usual suspects (memory, CPU) and some more interesting ones: * JVM deadlock check * transaction failure rate We?d have to be careful implementing a JVM deadlock health check though. These health checks should not impact the app server runtime too much and should be fast (by default Kubernetes has a 1 second timeout for its liveness probe). jeff [1] http://www.caucho.com/resin-4.0/admin/health-checking.xtp#Defaulthealthconfiguration -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From rcernich at redhat.com Thu Jul 6 10:13:46 2017 From: rcernich at redhat.com (Rob Cernich) Date: Thu, 6 Jul 2017 10:13:46 -0400 (EDT) Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: References: Message-ID: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> > Hi, > > I had a look at the Eclipse MicroProfile Healthcheck spec[1] and wanted to > share some thoughts and experiments about it, how it relates to WildFly and > its use in containers (such as OpenShift). > > # Eclipse MicroProfile Healthcheck > > The Eclipse MicroProfile Healthcheck (MPHC for short) is a specification to > determine the healthiness of an application. > It defines a Health Check Procedure (HCP for short) interface that can be > implemented by application to determine its healthiness. It?s a single > method that returns a Health Status: either UP or DOWN (+ some metadata). > Typically, an application would provide one or more HCP to check healthiness > of its parts. > The overall healthiness of the application is determined by the aggregation > of all the HCP provided by the application. If any HCP is DOWN, the overall > outcome is DOWN. Else the application is considered as UP. > > The MPHC spec has a companion document[2] that specifies an HTTP format to > check the healthiness of an application. > > Heiko is leading the spec and Swarm is the sample implementation for it > (MicroProfile does not have the notion of reference implementation). > The spec is still in flux and we have a good opportunity to contribute to it > to ensure that it meets our requirements and use cases. > > # Use case > > Using the HTTP endpoint, a container can ask an application whether it is > healthy. If it is not healthy, the container could stop the application and > respin a new instance. > For example, OpenShift/Kubernetes can configure liveness probes[3][4]. > > Supporting MPHC in WildFly would allow a better integration with containers > and ensure that any unhealthy WildFly process is restarted promptly. > > # Prototype > > I?ve written a prototype of a WildFly extension to support MPHC for > applications deployed in WildFly *and* add health check procedures inside > WildFly: > > https://github.com/jmesnil/wildfly-microprofile-health > > and it passes the MPHC tck :) > > The microprofile-health subsystem supports an operation to check the health > of the app server: > > [standalone at localhost:9990 /] /subsystem=microprofile-health:check > { > "outcome" => "success", > "result" => { > "checks" => [{ > "id" => "heap-memory", > "result" => "UP", > "data" => { > "max" => "477626368", > "used" => "156216336" > } > }], > "outcome" => "UP" > } > } > > It also exposes an (unauthenticated) HTTP endpoint: > > $ curl http://localhost:8080/health/: > { > "checks":[ > { > "id":"heap-memory", > "result":"UP", > "data":{ > "max":"477626368", > "used":"160137128" > } > } > ], > "outcome":"UP" > } > > This HTTP endpoint can be used by OpenShift for its liveness probe. Regarding the probes, three states would be best, if you can swing it, as OpenShift defines two probe types: liveness and readiness. Live is running, but unable to handle requests, while ready means it's running and able to handle requests. For example, while the server is initializing, it's alive, but not ready. Something to think about. > > Any deployment that defines Health Check Procedures will have them registered > to determine the overall healthiness of the process. > > # WildFly health check procedures > > The MPHC specification mainly targets user applications that can apply > application logic to determine their healthiness. > However I wonder if we could reuse the concepts *inside* WildFly. There are > things that we could check to determine if the App server runtime is > healthy, e.g.: > * The amount of heap memory is close to the max > * some deployments have failed > * Excessive GC > * Running out of disk space > > Subsystems inside WildFly could provide Health check procedures that would be > queried to check the overall healthiness. > We could for example provide a health check that the used heap memory is less > that 90% of the max: > > HealthCheck.install(context, "heap-memory", () -> { > MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean(); > long memUsed = memoryBean.getHeapMemoryUsage().getUsed(); > long memMax = memoryBean.getHeapMemoryUsage().getMax(); > HealthResponse response = HealthResponse.named("heap-memory") > .withAttribute("used", memUsed) > .withAttribute("max", memMax); > // status is is down is used memory is greater than 90% of max > memory. > HealthStatus status = (memUsed < memMax * 0.9) ? response.up() : > response.down(); > return status; > }); > > HealthCheck.install creates a MSC service and makes sure that is is > registered by the health monitor that queries all the procedures. > A subsystem would just have to call HealthCheck.install/uninstall with a > Health check procedures to help determine the healthiness of the app server. > > What do you think about this use case? > > I even wonder if this is something that should be instead provided by our > core-management subsystem with a private API (1 interface and some data > structures). > The microprofile-health extension would then map our private API to the MPHC > spec and handled health check procedures coming from deployments. > > # Summary > > To better integrate WildFly with OpenShift, we should provide a way to let > OpenShift checks the healthiness of WildFly. The MPHC spec is a good > candidate to provide such feature. > It is worth exploring how we could leverage it for user deployments and also > for WildFly internals (when that makes sense). > Swarm is providing an implementation of the MPHC, we also need to see how we > can collaborate between WildFly and Swarm to avoid duplicating code and > efforts from providing the same feature to our users. > > jeff > > > [1] > https://github.com/eclipse/microprofile-evolution-process/blob/master/proposals/0003-health-checks.md > [2] > https://github.com/eclipse/microprofile-evolution-process/blob/master/proposals/0003-spec.md > [3] > https://docs.openshift.com/enterprise/3.0/dev_guide/application_health.html > [4] > https://kubernetes.io/v1.0/docs/user-guide/walkthrough/k8s201.html#health-checking > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jmesnil at redhat.com Thu Jul 6 10:30:25 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 6 Jul 2017 16:30:25 +0200 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> References: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> Message-ID: > On 6 Jul 2017, at 16:13, Rob Cernich wrote: > >> Hi, >> >> I had a look at the Eclipse MicroProfile Healthcheck spec[1] and wanted to >> share some thoughts and experiments about it, how it relates to WildFly and >> its use in containers (such as OpenShift). >> >> # Eclipse MicroProfile Healthcheck >> >> The Eclipse MicroProfile Healthcheck (MPHC for short) is a specification to >> determine the healthiness of an application. >> It defines a Health Check Procedure (HCP for short) interface that can be >> implemented by application to determine its healthiness. It?s a single >> method that returns a Health Status: either UP or DOWN (+ some metadata). >> Typically, an application would provide one or more HCP to check healthiness >> of its parts. >> The overall healthiness of the application is determined by the aggregation >> of all the HCP provided by the application. If any HCP is DOWN, the overall >> outcome is DOWN. Else the application is considered as UP. >> >> The MPHC spec has a companion document[2] that specifies an HTTP format to >> check the healthiness of an application. >> >> Heiko is leading the spec and Swarm is the sample implementation for it >> (MicroProfile does not have the notion of reference implementation). >> The spec is still in flux and we have a good opportunity to contribute to it >> to ensure that it meets our requirements and use cases. >> >> # Use case >> >> Using the HTTP endpoint, a container can ask an application whether it is >> healthy. If it is not healthy, the container could stop the application and >> respin a new instance. >> For example, OpenShift/Kubernetes can configure liveness probes[3][4]. >> >> Supporting MPHC in WildFly would allow a better integration with containers >> and ensure that any unhealthy WildFly process is restarted promptly. >> >> # Prototype >> >> I?ve written a prototype of a WildFly extension to support MPHC for >> applications deployed in WildFly *and* add health check procedures inside >> WildFly: >> >> https://github.com/jmesnil/wildfly-microprofile-health >> >> and it passes the MPHC tck :) >> >> The microprofile-health subsystem supports an operation to check the health >> of the app server: >> >> [standalone at localhost:9990 /] /subsystem=microprofile-health:check >> { >> "outcome" => "success", >> "result" => { >> "checks" => [{ >> "id" => "heap-memory", >> "result" => "UP", >> "data" => { >> "max" => "477626368", >> "used" => "156216336" >> } >> }], >> "outcome" => "UP" >> } >> } >> >> It also exposes an (unauthenticated) HTTP endpoint: >> >> $ curl http://localhost:8080/health/: >> { >> "checks":[ >> { >> "id":"heap-memory", >> "result":"UP", >> "data":{ >> "max":"477626368", >> "used":"160137128" >> } >> } >> ], >> "outcome":"UP" >> } >> >> This HTTP endpoint can be used by OpenShift for its liveness probe. > > Regarding the probes, three states would be best, if you can swing it, as OpenShift defines two probe types: liveness and readiness. Live is running, but unable to handle requests, while ready means it's running and able to handle requests. For example, while the server is initializing, it's alive, but not ready. Something to think about. Three states (red/orange/green) was discussed when the healthcheck API was proposed. It was rejected as it puts the burden on the consumer to determine the overall healthiness. Besides, Kubernetes expects a binary response from its probes. If the HTTP status code is between 200 and 400, it is successful[1]. Anything else is considered as a failure. Kubernetes distinguishes between readiness and liveness. As defined, the healthcheck API deals mainly with liveness. But it could be possible provide some annotation to specify that some health check procedures can determine when an application is ready. For example, WildFly could be considered ready (i.e. Kubernetes will start to route request to it) when: * it status health check is ?up and running? * its deployment health check verifies that all its deployments are enabled. We could then provide a 2nd HTTP endpoint that Kubernetes could query to check that the server is ready to serve requests. jeff [1] https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#examples -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From hbraun at redhat.com Thu Jul 6 15:00:18 2017 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 6 Jul 2017 21:00:18 +0200 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: References: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> Message-ID: <759C5FE8-AECF-44F1-A1A6-9A8894817E93@redhat.com> > Am 06.07.2017 um 16:30 schrieb Jeff Mesnil : > > Kubernetes distinguishes between readiness and liveness. As defined, the healthcheck API deals mainly with liveness. Kubernetes has different semantics for live and ready, i.e how it interprets and reacts to certain health responses, but underneath its the same protocol. With the health api it's no different: you can model readiness or liveness checks with it. I think the only constraint we are facing atm, is the usage of a single protocol entrypoint. This approach disallows to have live and readiness checks for the same node (i.e there is just /health) Maybe we should change that to support multiple protocol entry points? These could either be custom ones or defined in the spec. For instance rather then having /health, we could introduce /live and /ready. The api underneath however would remain the same. Food for thought. From rcernich at redhat.com Thu Jul 6 15:26:44 2017 From: rcernich at redhat.com (Rob Cernich) Date: Thu, 6 Jul 2017 15:26:44 -0400 (EDT) Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: References: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> Message-ID: <1757801213.28995998.1499369204169.JavaMail.zimbra@redhat.com> > > Regarding the probes, three states would be best, if you can swing it, as > > OpenShift defines two probe types: liveness and readiness. Live is > > running, but unable to handle requests, while ready means it's running and > > able to handle requests. For example, while the server is initializing, > > it's alive, but not ready. Something to think about. > > Three states (red/orange/green) was discussed when the healthcheck API was > proposed. It was rejected as it puts the burden on the consumer to determine > the overall healthiness. > Besides, Kubernetes expects a binary response from its probes. If the HTTP > status code is between 200 and 400, it is successful[1]. Anything else is > considered as a failure. > > Kubernetes distinguishes between readiness and liveness. As defined, the > healthcheck API deals mainly with liveness. > But it could be possible provide some annotation to specify that some health > check procedures can determine when an application is ready. > For example, WildFly could be considered ready (i.e. Kubernetes will start to > route request to it) when: > * it status health check is ?up and running? > * its deployment health check verifies that all its deployments are enabled. I think this is a bit over simplistic, e.g. what happens if a deployment failed to start? The pod would be marked as alive, but would never become ready. If the deployment failed, presumably, the pod should be marked as dead. One use case we've seen is using JPA to initialize a DB. If the DB isn't available, the deployment fails and the pod continues to bounce until the DB is accessible. (Yes, this is not good practice, but it illustrates the point, and some of our layered products actually do this, so...) > > We could then provide a 2nd HTTP endpoint that Kubernetes could query to > check that the server is ready to serve requests. > > jeff > > [1] > https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#examples > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > From jmesnil at redhat.com Fri Jul 7 04:41:34 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 7 Jul 2017 10:41:34 +0200 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: <759C5FE8-AECF-44F1-A1A6-9A8894817E93@redhat.com> References: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> <759C5FE8-AECF-44F1-A1A6-9A8894817E93@redhat.com> Message-ID: <0BD0CA25-383A-4D02-B7A0-4CEBEE5D5C7A@redhat.com> > On 6 Jul 2017, at 21:00, Heiko Braun wrote: > Kubernetes has different semantics for live and ready, i.e how it interprets and reacts to certain health responses, but underneath its the same protocol. > > With the health api it's no different: you can model readiness or liveness checks with it. I think the only constraint we are facing atm, is the usage of a single protocol entrypoint. This approach disallows to have live and readiness checks for the same node (i.e there is just /health) > > Maybe we should change that to support multiple protocol entry points? These could either be custom ones or defined in the spec. For instance rather then having /health, we could introduce /live and /ready. The api underneath however would remain the same. Some further food for thought (that will go in an issue in the spec later today): Maybe the spec could provide some additional metadata to further characterize the health check procedures. For example a procedure annotated with @Ready would return UP when the component is ?ready? (for whatever it is doing) and DOWN otherwise. The same component could have another procedure (without any annotation or a @Live one) that returns UP when the component checks it is healthy. The component would return different status depending on its state: * during its initialization (READY = DOWN, LIVE = UP) * after its initialization (READY = UP, LIVE = UP) * if it is encountering some issues, (LIVE = DOWN, READY = ). The spec could then provide a different entry point that only checks procedures annotated with @Ready. TL;DR: the spec should enforce only 2 states (UP and DOWN) for each check procedures but could characterise them to let consumers query different type of healthiness (live and ready) jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jmesnil at redhat.com Fri Jul 7 04:45:04 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 7 Jul 2017 10:45:04 +0200 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: <1757801213.28995998.1499369204169.JavaMail.zimbra@redhat.com> References: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> <1757801213.28995998.1499369204169.JavaMail.zimbra@redhat.com> Message-ID: <69CB08A2-B2C5-4239-8482-E986D7FB861C@redhat.com> > On 6 Jul 2017, at 21:26, Rob Cernich wrote: > >>> Regarding the probes, three states would be best, if you can swing it, as >>> OpenShift defines two probe types: liveness and readiness. Live is >>> running, but unable to handle requests, while ready means it's running and >>> able to handle requests. For example, while the server is initializing, >>> it's alive, but not ready. Something to think about. >> >> Three states (red/orange/green) was discussed when the healthcheck API was >> proposed. It was rejected as it puts the burden on the consumer to determine >> the overall healthiness. >> Besides, Kubernetes expects a binary response from its probes. If the HTTP >> status code is between 200 and 400, it is successful[1]. Anything else is >> considered as a failure. >> >> Kubernetes distinguishes between readiness and liveness. As defined, the >> healthcheck API deals mainly with liveness. >> But it could be possible provide some annotation to specify that some health >> check procedures can determine when an application is ready. >> For example, WildFly could be considered ready (i.e. Kubernetes will start to >> route request to it) when: >> * it status health check is ?up and running? >> * its deployment health check verifies that all its deployments are enabled. > > I think this is a bit over simplistic, e.g. what happens if a deployment failed to start? The pod would be marked as alive, but would never become ready. If the deployment failed, presumably, the pod should be marked as dead. One use case we've seen is using JPA to initialize a DB. If the DB isn't available, the deployment fails and the pod continues to bounce until the DB is accessible. (Yes, this is not good practice, but it illustrates the point, and some of our layered products actually do this, so?) You are right, these were only some (simple) ideas but not actual definitions of health checks. The deployment healthiness is a bit complex. It needs to identify deployment that failed but to do that we need to know about deployment attempts (I don?t think we get such info at the moment). We could check when the server is started if there is any deployment in the deployments directories and correlates that with /deployment resource after the server is started, etc. But the idea remains the same: WildFly should be able to identify whether its deployments status is healthy or not. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From rcernich at redhat.com Fri Jul 7 08:27:58 2017 From: rcernich at redhat.com (Rob Cernich) Date: Fri, 7 Jul 2017 08:27:58 -0400 (EDT) Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: <78284373-22C3-44F0-A412-C560F2F9D980@redhat.com> References: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> <78284373-22C3-44F0-A412-C560F2F9D980@redhat.com> Message-ID: <1346968013.29159256.1499430478067.JavaMail.zimbra@redhat.com> > On 6 Jul 2017, at 16:13, Rob Cernich wrote: > > Regarding the probes, three states would be best, if you can swing it, > > as OpenShift defines two probe types: liveness and readiness. Live is > > running, but unable to handle requests, while ready means it's running > > and able to handle requests. For example, while the server is > > initializing, it's alive, but not ready. Something to think about. > > OpenShift / Kube only cares about up down. > So instead of three states, there should be a parameter > to the endpoint ?ready to indicate that the readiness > HCP is queried and not the liveliness (or the other > way around). > It cares about live and ready. Dead implies not ready. Not ready does not imply dead. From jmesnil at redhat.com Fri Jul 7 08:32:17 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 7 Jul 2017 14:32:17 +0200 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: <5348EDD8-3E68-466A-ABEC-D42BD09F900F@redhat.com> References: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> <759C5FE8-AECF-44F1-A1A6-9A8894817E93@redhat.com> <5348EDD8-3E68-466A-ABEC-D42BD09F900F@redhat.com> Message-ID: > On 7 Jul 2017, at 14:22, Heiko Rupp wrote: > > On 6 Jul 2017, at 21:00, Heiko Braun wrote: >> Maybe we should change that to support multiple protocol entry points? These could either be custom ones or defined in the spec. For instance rather then having /health, we could introduce /live and /ready. The api underneath however would remain the same. > > I think only keeping /health and adding a parameter > is better, as it "pollutes" less the namespace of urls > left to applications. Related issues to improve the spec that are relevant to this conversation. * Provide different types of health check - https://github.com/eclipse/microprofile-health/issues/35 * Health check endpoint should have app name - https://github.com/eclipse/microprofile-health/issues/29 jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jmesnil at redhat.com Fri Jul 7 09:02:51 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 7 Jul 2017 15:02:51 +0200 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: <885EE46E-7672-4B35-8D9B-46C314D4B803@redhat.com> References: <885EE46E-7672-4B35-8D9B-46C314D4B803@redhat.com> Message-ID: <9A21AE80-0D2A-4B45-B8E8-175AA5A8A261@redhat.com> > On 7 Jul 2017, at 14:18, Heiko Rupp wrote: > > On 6 Jul 2017, at 15:00, David Lloyd wrote: >> Is this a polling-only service, or is there a "push" mechanism? > > Right now poll only, basically building the counterpart > of the Kubernetes/OpenShift health check calls. > >> Just brainstorming, I can think of a few more potentially useful health checks beyond what you've listed: >> >> ? EJB failure rate (if an EJB starts failing more than some percentage of the last, say 50 or 100 invocations, it could report an "unhealthy" >> condition) >> ? Database failure rate (something with JDBC exceptions maybe) >> ? Authentication realm failure rate (Elytron's RealmUnavailableException) > > I think those are internal implementation details and something > each application needs to come up with good values. > > While the HCP can have a detailed payload as above, it is not > required, and could only return 204 UP or 503 DOWN. > Kube will not look at the body anyway. Some food for thought. It?s not clear to me if any checks dealing with ranges ("over time" or "over invocations" such a failure rate) should be handled by a health check procedure at all. Heiko R. has proposed a spec to cover Metrics via HTTP endpoints[1] that is also relevant here. Anything dealing with such range might be better addressed by monitoring tools with can detect trends. Health checks and telemetry are somehow related but it?s not clear to me where the boundaries lie. [1] https://github.com/eclipse/microprofile-evolution-process/blob/master/proposals/0002-metrics.md -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From rcernich at redhat.com Fri Jul 7 09:10:38 2017 From: rcernich at redhat.com (Rob Cernich) Date: Fri, 7 Jul 2017 09:10:38 -0400 (EDT) Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: <36D404F9-64A5-47F1-9C0B-66F2213CDE4E@redhat.com> References: <999088161.28939160.1499350426227.JavaMail.zimbra@redhat.com> <78284373-22C3-44F0-A412-C560F2F9D980@redhat.com> <1346968013.29159256.1499430478067.JavaMail.zimbra@redhat.com> <36D404F9-64A5-47F1-9C0B-66F2213CDE4E@redhat.com> Message-ID: <1494545719.29172707.1499433038826.JavaMail.zimbra@redhat.com> > On 7 Jul 2017, at 14:27, Rob Cernich wrote: > > > It cares about live and ready. Dead implies not ready. Not ready > > does not imply dead. > > Isn't that what I wrote? The query from Kube expects > a binary result (or no result at all), but not up/down/perhaps/white > It does, and that would imply you have two different interfaces, one for ready and one for liveness. For EAP, we've been using the Exec probes, which provide more flexibility for reading state, beyond just status code good/bad. From david.lloyd at redhat.com Fri Jul 7 11:10:11 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 7 Jul 2017 10:10:11 -0500 Subject: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck In-Reply-To: <885EE46E-7672-4B35-8D9B-46C314D4B803@redhat.com> References: <885EE46E-7672-4B35-8D9B-46C314D4B803@redhat.com> Message-ID: On Fri, Jul 7, 2017 at 7:18 AM, Heiko Rupp wrote: > On 6 Jul 2017, at 15:00, David Lloyd wrote: >> >> Is this a polling-only service, or is there a "push" mechanism? > > Right now poll only, basically building the counterpart > of the Kubernetes/OpenShift health check calls. > >> Just brainstorming, I can think of a few more potentially useful health >> checks beyond what you've listed: >> >> ? EJB failure rate (if an EJB starts failing more than some percentage of >> the last, say 50 or 100 invocations, it could report an "unhealthy" >> condition) >> ? Database failure rate (something with JDBC exceptions maybe) >> ? Authentication realm failure rate (Elytron's RealmUnavailableException) > > I think those are internal implementation details and something > each application needs to come up with good values. > > While the HCP can have a detailed payload as above, it is not > required, and could only return 204 UP or 503 DOWN. > Kube will not look at the body anyway. Right I'm thinking of the data that we can feed to the internal health SPI, not the actual payload of the service (which would presumably be one implementation of a more general SPI), based on Jeff's description. Thinking ahead, it would probably be good if the SPI itself were agnostic of push/poll unless we can determine that all existent or likely implementations are poll-only. From gunnar at hibernate.org Thu Jul 13 04:50:31 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 13 Jul 2017 10:50:31 +0200 Subject: [wildfly-dev] Bringing Bean Validation 2.0 to WildFly Message-ID: Hi, Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or should new modules be added for those, letting the user to choose the version to enable? The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to discuss how BV 2 and its reference implementation HV 6 can be integrated into WildFly. BV 2 will be part of Java EE 8. I can think of two approaches: 1) Just updating the existing WildFly modules for BV API and HV to the new versions 2) Leave the existing modules for BV 1.1 (+ implementation) and add separate modules for BV 2.0 1) would be easier and less effort. But I'm not sure how feasible it is, in case that WF should remain Java EE 7 compatible for the time being. Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate Validator amends the spec API with some extended functionality. In that extended HV-specific API some changes were required, mostly as previous experimental features were replaced by equivalent standardized functionality in the BV API. 2) would let the user chose between BV 1.1 and 2.0, but it'd entail some more work: * A place for that configuration is required. I think it could be done similarly to JPA, i.e. via a property with the module name in META-INF/validation.xml * Depending on that configuration, the right set of modules needs to be enabled. Several modules currently have a fixed dependency to the "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which would have be made more dynamic, based on the version chosen by the user. What does everyone think on this? And what could be a suitable WildFly target version for such change? Could we aim at incorporating BV 2.0 into WF 11? Thanks, --Gunnar [1] http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170713/4e996463/attachment.html From mkouba at redhat.com Thu Jul 13 05:18:16 2017 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 13 Jul 2017 11:18:16 +0200 Subject: [wildfly-dev] Bringing Bean Validation 2.0 to WildFly In-Reply-To: References: Message-ID: FYI the same applies to Weld 3.0/CDI 2 except that CDI 2.0 and Weld 3.0.0.Final were released already. Right now, we provide a patch for both WildFly 10.1.0 and 11.0.0.Alpha1 [1]. BTW there is also SWARM-731 [2] - Investigate creation of CDI 2.0 / Weld 3.0 fractions. Martin [1] http://download.jboss.org/weld/3.0.0.Final/ [2] https://issues.jboss.org/browse/SWARM-731 Dne 13.7.2017 v 10:50 Gunnar Morling napsal(a): > Hi, > > Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, > or should new modules be added for those, letting the user to choose the > version to enable? > > The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like > to discuss how BV 2 and its reference implementation HV 6 can be > integrated into WildFly. BV 2 will be part of Java EE 8. > > I can think of two approaches: > > 1) Just updating the existing WildFly modules for BV API and HV to the > new versions > 2) Leave the existing modules for BV 1.1 (+ implementation) and add > separate modules for BV 2.0 > > 1) would be easier and less effort. But I'm not sure how feasible it is, > in case that WF should remain Java EE 7 compatible for the time being. > Also, while BV 2 is fully backwards compatible at the spec-level, > Hibernate Validator amends the spec API with some extended > functionality. In that extended HV-specific API some changes were > required, mostly as previous experimental features were replaced by > equivalent standardized functionality in the BV API. > > 2) would let the user chose between BV 1.1 and 2.0, but it'd entail some > more work: > > * A place for that configuration is required. I think it could be done > similarly to JPA, i.e. via a property with the module name in > META-INF/validation.xml > * Depending on that configuration, the right set of modules needs to be > enabled. Several modules currently have a fixed dependency to the > "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) > which would have be made more dynamic, based on the version chosen by > the user. > > What does everyone think on this? And what could be a suitable WildFly > target version for such change? Could we aim at incorporating BV 2.0 > into WF 11? > > Thanks, > > --Gunnar > > [1] > http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/ > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From jperkins at redhat.com Thu Jul 13 11:31:22 2017 From: jperkins at redhat.com (James Perkins) Date: Thu, 13 Jul 2017 08:31:22 -0700 Subject: [wildfly-dev] Bringing Bean Validation 2.0 to WildFly In-Reply-To: References: Message-ID: I think either approach is going to have to wait until WildFly 12. We can't upgrade specs at this point unfortunately. On Thu, Jul 13, 2017 at 1:50 AM, Gunnar Morling wrote: > Hi, > > Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or > should new modules be added for those, letting the user to choose the > version to enable? > > The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to > discuss how BV 2 and its reference implementation HV 6 can be integrated > into WildFly. BV 2 will be part of Java EE 8. > > I can think of two approaches: > > 1) Just updating the existing WildFly modules for BV API and HV to the new > versions > 2) Leave the existing modules for BV 1.1 (+ implementation) and add > separate modules for BV 2.0 > > 1) would be easier and less effort. But I'm not sure how feasible it is, > in case that WF should remain Java EE 7 compatible for the time being. > Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate > Validator amends the spec API with some extended functionality. In that > extended HV-specific API some changes were required, mostly as previous > experimental features were replaced by equivalent standardized > functionality in the BV API. > > 2) would let the user chose between BV 1.1 and 2.0, but it'd entail some > more work: > > * A place for that configuration is required. I think it could be done > similarly to JPA, i.e. via a property with the module name in > META-INF/validation.xml > * Depending on that configuration, the right set of modules needs to be > enabled. Several modules currently have a fixed dependency to the > "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which > would have be made more dynamic, based on the version chosen by the user. > > What does everyone think on this? And what could be a suitable WildFly > target version for such change? Could we aim at incorporating BV 2.0 into > WF 11? > > Thanks, > > --Gunnar > > [1] http://beanvalidation.org/news/2017/07/12/bean- > validation-2-0-cr3-submitted-to-final-approval-ballot/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170713/7630cd7a/attachment.html From emmanuel at hibernate.org Thu Jul 13 13:06:02 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 13 Jul 2017 19:06:02 +0200 Subject: [wildfly-dev] Bringing Bean Validation 2.0 to WildFly In-Reply-To: References: Message-ID: <0CD110FE-B5BD-42A1-90A3-1A1B7A995257@hibernate.org> Barring other constraints, I would think we would want to move forward to the latest in the next WF major. What?s the point of holding up technology? Likewise there is very little value in keeping the old one in in parallel. More knobs and more pain in the subsystems. > On 13 Jul 2017, at 10:50, Gunnar Morling wrote: > > Hi, > > Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or should new modules be added for those, letting the user to choose the version to enable? > > The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to discuss how BV 2 and its reference implementation HV 6 can be integrated into WildFly. BV 2 will be part of Java EE 8. > > I can think of two approaches: > > 1) Just updating the existing WildFly modules for BV API and HV to the new versions > 2) Leave the existing modules for BV 1.1 (+ implementation) and add separate modules for BV 2.0 > > 1) would be easier and less effort. But I'm not sure how feasible it is, in case that WF should remain Java EE 7 compatible for the time being. Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate Validator amends the spec API with some extended functionality. In that extended HV-specific API some changes were required, mostly as previous experimental features were replaced by equivalent standardized functionality in the BV API. > > 2) would let the user chose between BV 1.1 and 2.0, but it'd entail some more work: > > * A place for that configuration is required. I think it could be done similarly to JPA, i.e. via a property with the module name in META-INF/validation.xml > * Depending on that configuration, the right set of modules needs to be enabled. Several modules currently have a fixed dependency to the "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which would have be made more dynamic, based on the version chosen by the user. > > What does everyone think on this? And what could be a suitable WildFly target version for such change? Could we aim at incorporating BV 2.0 into WF 11? > > Thanks, > > --Gunnar > > [1] http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/ > > _______________________________________________ > 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/20170713/55e3499f/attachment-0001.html From tomaz.cerar at gmail.com Thu Jul 13 13:46:10 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 13 Jul 2017 19:46:10 +0200 Subject: [wildfly-dev] Bringing Bean Validation 2.0 to WildFly In-Reply-To: References: Message-ID: Any work on such features is something that cannot go into 11, as we are mostly at cut-off point with development. Such work should target WildFly 12. On Thu, Jul 13, 2017 at 10:50 AM, Gunnar Morling wrote: > Hi, > > Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or > should new modules be added for those, letting the user to choose the > version to enable? > > The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to > discuss how BV 2 and its reference implementation HV 6 can be integrated > into WildFly. BV 2 will be part of Java EE 8. > > I can think of two approaches: > > 1) Just updating the existing WildFly modules for BV API and HV to the new > versions > 2) Leave the existing modules for BV 1.1 (+ implementation) and add > separate modules for BV 2.0 > > 1) would be easier and less effort. But I'm not sure how feasible it is, > in case that WF should remain Java EE 7 compatible for the time being. > Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate > Validator amends the spec API with some extended functionality. In that > extended HV-specific API some changes were required, mostly as previous > experimental features were replaced by equivalent standardized > functionality in the BV API. > > 2) would let the user chose between BV 1.1 and 2.0, but it'd entail some > more work: > > * A place for that configuration is required. I think it could be done > similarly to JPA, i.e. via a property with the module name in > META-INF/validation.xml > * Depending on that configuration, the right set of modules needs to be > enabled. Several modules currently have a fixed dependency to the > "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which > would have be made more dynamic, based on the version chosen by the user. > > What does everyone think on this? And what could be a suitable WildFly > target version for such change? Could we aim at incorporating BV 2.0 into > WF 11? > > Thanks, > > --Gunnar > > [1] http://beanvalidation.org/news/2017/07/12/bean- > validation-2-0-cr3-submitted-to-final-approval-ballot/ > > > _______________________________________________ > 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/20170713/8e5ffa48/attachment.html From ttarrant at redhat.com Fri Jul 14 11:38:39 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 14 Jul 2017 17:38:39 +0200 Subject: [wildfly-dev] Bringing Bean Validation 2.0 to WildFly In-Reply-To: <0CD110FE-B5BD-42A1-90A3-1A1B7A995257@hibernate.org> References: <0CD110FE-B5BD-42A1-90A3-1A1B7A995257@hibernate.org> Message-ID: +1. Where are the Alphas (aside from Alpha1), the Betas, the CRs for WildFly 11 ? Tristan On 7/13/17 7:06 PM, Emmanuel Bernard wrote: > Barring other constraints, I would think we would want to move forward > to the latest in the next WF major. What?s the point of holding up > technology? Likewise there is very little value in keeping the old one > in in parallel. More knobs and more pain in the subsystems. > >> On 13 Jul 2017, at 10:50, Gunnar Morling > > wrote: >> >> Hi, >> >> Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, >> or should new modules be added for those, letting the user to choose >> the version to enable? >> >> The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like >> to discuss how BV 2 and its reference implementation HV 6 can be >> integrated into WildFly. BV 2 will be part of Java EE 8. >> >> I can think of two approaches: >> >> 1) Just updating the existing WildFly modules for BV API and HV to the >> new versions >> 2) Leave the existing modules for BV 1.1 (+ implementation) and add >> separate modules for BV 2.0 >> >> 1) would be easier and less effort. But I'm not sure how feasible it >> is, in case that WF should remain Java EE 7 compatible for the time >> being. Also, while BV 2 is fully backwards compatible at the >> spec-level, Hibernate Validator amends the spec API with some extended >> functionality. In that extended HV-specific API some changes were >> required, mostly as previous experimental features were replaced by >> equivalent standardized functionality in the BV API. >> >> 2) would let the user chose between BV 1.1 and 2.0, but it'd entail >> some more work: >> >> * A place for that configuration is required. I think it could be done >> similarly to JPA, i.e. via a property with the module name in >> META-INF/validation.xml >> * Depending on that configuration, the right set of modules needs to >> be enabled. Several modules currently have a fixed dependency to the >> "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) >> which would have be made more dynamic, based on the version chosen by >> the user. >> >> What does everyone think on this? And what could be a suitable WildFly >> target version for such change? Could we aim at incorporating BV 2.0 >> into WF 11? >> >> Thanks, >> >> --Gunnar >> >> [1] >> http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/ >> >> _______________________________________________ >> 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 > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From gunnar at hibernate.org Sun Jul 16 03:19:09 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Sun, 16 Jul 2017 09:19:09 +0200 Subject: [wildfly-dev] Bringing Bean Validation 2.0 to WildFly In-Reply-To: References: <0CD110FE-B5BD-42A1-90A3-1A1B7A995257@hibernate.org> Message-ID: I was wondering the same thing; just from looking at it from the outside, being after Alpha1 seems like the right time to do this kind of update. Also is there any public schedule available for WF 11 and 12? It'd be sad if we could get BV 2 into WF only in a year or so (wildly guessing here when to expect WF 12), while e.g. Spring 5 with BV 2 support is planned to be released this summer. --Gunnar 2017-07-14 18:38 GMT+03:00 Tristan Tarrant : > +1. > > Where are the Alphas (aside from Alpha1), the Betas, the CRs for WildFly > 11 ? > > Tristan > > On 7/13/17 7:06 PM, Emmanuel Bernard wrote: > > Barring other constraints, I would think we would want to move forward > > to the latest in the next WF major. What?s the point of holding up > > technology? Likewise there is very little value in keeping the old one > > in in parallel. More knobs and more pain in the subsystems. > > > >> On 13 Jul 2017, at 10:50, Gunnar Morling >> > wrote: > >> > >> Hi, > >> > >> Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, > >> or should new modules be added for those, letting the user to choose > >> the version to enable? > >> > >> The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like > >> to discuss how BV 2 and its reference implementation HV 6 can be > >> integrated into WildFly. BV 2 will be part of Java EE 8. > >> > >> I can think of two approaches: > >> > >> 1) Just updating the existing WildFly modules for BV API and HV to the > >> new versions > >> 2) Leave the existing modules for BV 1.1 (+ implementation) and add > >> separate modules for BV 2.0 > >> > >> 1) would be easier and less effort. But I'm not sure how feasible it > >> is, in case that WF should remain Java EE 7 compatible for the time > >> being. Also, while BV 2 is fully backwards compatible at the > >> spec-level, Hibernate Validator amends the spec API with some extended > >> functionality. In that extended HV-specific API some changes were > >> required, mostly as previous experimental features were replaced by > >> equivalent standardized functionality in the BV API. > >> > >> 2) would let the user chose between BV 1.1 and 2.0, but it'd entail > >> some more work: > >> > >> * A place for that configuration is required. I think it could be done > >> similarly to JPA, i.e. via a property with the module name in > >> META-INF/validation.xml > >> * Depending on that configuration, the right set of modules needs to > >> be enabled. Several modules currently have a fixed dependency to the > >> "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) > >> which would have be made more dynamic, based on the version chosen by > >> the user. > >> > >> What does everyone think on this? And what could be a suitable WildFly > >> target version for such change? Could we aim at incorporating BV 2.0 > >> into WF 11? > >> > >> Thanks, > >> > >> --Gunnar > >> > >> [1] > >> http://beanvalidation.org/news/2017/07/12/bean- > validation-2-0-cr3-submitted-to-final-approval-ballot/ > >> > >> _______________________________________________ > >> 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 > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170716/65261860/attachment.html From rory.odonnell at oracle.com Mon Jul 17 08:20:57 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 17 Jul 2017 13:20:57 +0100 Subject: [wildfly-dev] JDK 9 EA Build 178 & JDK 8u152 b05 are available on jdk.java.net Message-ID: <4798dc06-98ae-c86a-2192-446d8bfeae90@oracle.com> Hi Jason/Tomaz, *JDK 9 Early Access* build 178 is available at : - jdk.java.net/9/ A summary of all the changes in this build are listed here . Changes which were introduced since the last availability email that may be of interest : * b175 - Module system implementation refresh**(6/2017 update) * b175 - no longer has "-ea" in the version string and the system property "java version" is now simply "9" o *java -version* >java version "9" >Java(TM) SE Runtime Environment (build 9+175) >Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode) o *Bundle name changes:* e.g. jdk-9+175_linux-x86_bin.tar.gz *JDK 8u152 Early Access* build 05 is available at : - jdk.java.net/8/ A summary of all the changes in this build are listed here . 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/20170717/4cf2cfac/attachment-0001.html From manickumaran at yahoo.com Tue Jul 18 07:16:58 2017 From: manickumaran at yahoo.com (Muthukumaran Manickavasagam) Date: Tue, 18 Jul 2017 11:16:58 +0000 (UTC) Subject: [wildfly-dev] WIldfly 10, Java 8, Spring 4x References: <1349089508.3005018.1500376618268.ref@mail.yahoo.com> Message-ID: <1349089508.3005018.1500376618268@mail.yahoo.com> I have been trying to bring up my application with Wildfly 10, Java8 and Spring 4x libraries. I have got stuck with following issues for last two days and my suspect that i get below exception when Wildfly try to compile my JSP files. Any idea, when we get such exception? javax.servlet.ServletException: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found? ? ? ? at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:355)? ? ? ? at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)? ? ? ? at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)? ? ? ? at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)? ? ? ? at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)? ? ? ? at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)? ? ? ? at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)? ? ? ? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)? ? ? ? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)? ? ? ? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209)? ? ? ? at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:221)? ? ? ? at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:147)? ? ? ? at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:111)? ? ? ? at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:168)? ? ? ? at com.myapp.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:46)? ? ? ? at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:303)? ? ? ? at org.springframework.webflow.mvc.servlet.ServletMvcView.doRender(ServletMvcView.java:55)? ? ? ? at org.springframework.webflow.mvc.view.AbstractMvcView.render(AbstractMvcView.java:199)? ? ? ? at org.springframework.webflow.action.ViewFactoryActionAdapter.doExecute(ViewFactoryActionAdapter.java:40)? ? ? ? at org.springframework.webflow.action.AbstractAction.execute(AbstractAction.java:188)? ? ? ? at org.springframework.webflow.execution.ActionExecutor.execute(ActionExecutor.java:51)? ? ? ? at org.springframework.webflow.engine.EndState.doEnter(EndState.java:100)? ? ? ? at org.springframework.webflow.engine.State.enter(State.java:194)? ? ? ? at org.springframework.webflow.engine.Transition.execute(Transition.java:228)? ? ? ? at org.springframework.webflow.engine.impl.FlowExecutionImpl.execute(FlowExecutionImpl.java:395)? ? ? ? at org.springframework.webflow.engine.impl.RequestControlContextImpl.execute(RequestControlContextImpl.java:214)? ? ? ? at org.springframework.webflow.engine.TransitionableState.handleEvent(TransitionableState.java:116)? ? ? ? at org.springframework.webflow.engine.Flow.handleEvent(Flow.java:547)? ? ? ? at org.springframework.webflow.engine.impl.FlowExecutionImpl.handleEvent(FlowExecutionImpl.java:390)? ? ? ? at org.springframework.webflow.engine.impl.RequestControlContextImpl.handleEvent(RequestControlContextImpl.java:210)? ? ? ? at org.springframework.webflow.engine.ActionState.doEnter(ActionState.java:105)? ? ? ? at org.springframework.webflow.engine.State.enter(State.java:194)? ? ? ? at org.springframework.webflow.engine.Transition.execute(Transition.java:228)? ? ? ? at org.springframework.webflow.engine.impl.FlowExecutionImpl.execute(FlowExecutionImpl.java:395)? ? ? ? at org.springframework.webflow.engine.impl.RequestControlContextImpl.execute(RequestControlContextImpl.java:214)? ? ? ? at org.springframework.webflow.engine.TransitionableState.handleEvent(TransitionableState.java:116)? ? ? ? at org.springframework.webflow.engine.Flow.handleEvent(Flow.java:547)? ? ? ? at org.springframework.webflow.engine.impl.FlowExecutionImpl.handleEvent(FlowExecutionImpl.java:390)? ? ? ? at org.springframework.webflow.engine.impl.RequestControlContextImpl.handleEvent(RequestControlContextImpl.java:210)? ? ? ? at org.springframework.webflow.engine.ActionState.doEnter(ActionState.java:105)? ? ? ? at org.springframework.webflow.engine.State.enter(State.java:194)? ? ? ? at org.springframework.webflow.engine.Transition.execute(Transition.java:228)? ? ? ? at org.springframework.webflow.engine.impl.FlowExecutionImpl.execute(FlowExecutionImpl.java:395)? ? ? ? at org.springframework.webflow.engine.impl.RequestControlContextImpl.execute(RequestControlContextImpl.java:214)? ? ? ? at org.springframework.webflow.engine.TransitionableState.handleEvent(TransitionableState.java:116)? ? ? ? at org.springframework.webflow.engine.Flow.handleEvent(Flow.java:547)? ? ? ? at org.springframework.webflow.engine.impl.FlowExecutionImpl.handleEvent(FlowExecutionImpl.java:390)? ? ? ? at org.springframework.webflow.engine.impl.RequestControlContextImpl.handleEvent(RequestControlContextImpl.java:210)? ? ? ? at org.springframework.webflow.engine.ActionState.doEnter(ActionState.java:105)? ? ? ? at org.springframework.webflow.engine.State.enter(State.java:194)? ? ? ? at org.springframework.webflow.engine.Flow.start(Flow.java:527)? ? ? ? at org.springframework.webflow.engine.impl.FlowExecutionImpl.start(FlowExecutionImpl.java:368)? ? ? ? at org.springframework.webflow.engine.impl.FlowExecutionImpl.start(FlowExecutionImpl.java:223)? ? ? ? at org.springframework.webflow.executor.FlowExecutorImpl.launchExecution(FlowExecutorImpl.java:140)? ? ? ? at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:263)? ? ? ? at org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:174)? ? ? ? at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:50)? ? ? ? at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967)? ? ? ? at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)? ? ? ? at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)? ? ? ? at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)? ? ? ? at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)? ? ? ? at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)? ? ? ? at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)? ? ? ? at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)? ? ? ? at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)? ? ? ? at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197)? ? ? ? at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)? ? ? ? at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)? ? ? ? at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)? ? ? ? at com.myapp.HTTPInstrumentedFilter.doFilter(HTTPInstrumentedFilter.java:152)? ? ? ? at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)? ? ? ? at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)? ? ? ? at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)? ? ? ? at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)? ? ? ? at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)? ? ? ? at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)? ? ? ? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)? ? ? ? at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)? ? ? ? at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)? ? ? ? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)? ? ? ? at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)? ? ? ? at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)? ? ? ? at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)? ? ? ? at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)? ? ? ? at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)? ? ? ? at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)? ? ? ? at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)? ? ? ? at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)? ? ? ? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)? ? ? ? at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)? ? ? ? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)? ? ? ? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)? ? ? ? at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)? ? ? ? at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)? ? ? ? at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)? ? ? ? at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)? ? ? ? at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)? ? ? ? at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)? ? ? ? at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)? ? ? ? at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)? ? ? ? at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)? ? ? ? at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)? ? ? ? at java.lang.Thread.run(Thread.java:745)Caused by: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found? ? ? ? at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:200)? ? ? ? at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:152)? ? ? ? at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:232)? ? ? ? at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:120)? ? ? ? at org.apache.taglibs.standard.util.XmlUtil$1.call(XmlUtil.java:83)? ? ? ? at org.apache.taglibs.standard.util.XmlUtil$1.call(XmlUtil.java:81)? ? ? ? at org.apache.taglibs.standard.util.XmlUtil$5.run(XmlUtil.java:395)? ? ? ? at java.security.AccessController.doPrivileged(Native Method)? ? ? ? at org.apache.taglibs.standard.util.XmlUtil.runWithOurClassLoader(XmlUtil.java:403)? ? ? ? at org.apache.taglibs.standard.util.XmlUtil.(XmlUtil.java:81)? ? ? ? at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:154)? ? ? ? at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97)? ? ? ? at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:565)? ? ? ? at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856)? ? ? ? at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825)? ? ? ? at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218)? ? ? ? at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)? ? ? ? at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)? ? ? ? at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)? ? ? ? at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652)? ? ? ? at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)? ? ? ? at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402)? ? ? ? at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346)? ? ? ? ... 113 moreCaused by: java.lang.ClassNotFoundException: org/apache/xerces/jaxp/DocumentBuilderFactoryImpl? ? ? ? at java.lang.Class.forName0(Native Method)? ? ? ? at java.lang.Class.forName(Class.java:340)? ? ? ? at javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:124)? ? ? ? at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:188)? ? ? ? ... 135 more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170718/49d7c61e/attachment-0001.html From kustos at gmx.net Wed Jul 19 06:01:45 2017 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 19 Jul 2017 12:01:45 +0200 Subject: [wildfly-dev] WIldfly 10, Java 8, Spring 4x In-Reply-To: <1349089508.3005018.1500376618268@mail.yahoo.com> References: <1349089508.3005018.1500376618268.ref@mail.yahoo.com> <1349089508.3005018.1500376618268@mail.yahoo.com> Message-ID: <3fbc1cb7-0fa9-f7d3-a685-03e7845eb8d4@gmx.net> This is not really a support forum and your stack trace is badly formatted Caused by: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:200) at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:152) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:232) atjavax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:120) at org.apache.taglibs.standard.util.XmlUtil$1.call(XmlUtil.java:83) at org.apache.taglibs.standard.util.XmlUtil$1.call(XmlUtil.java:81) at org.apache.taglibs.standard.util.XmlUtil$5.run(XmlUtil.java:395) at java.security.AccessController.doPrivileged(Native Method) at org.apache.taglibs.standard.util.XmlUtil.runWithOurClassLoader(XmlUtil.java:403) at org.apache.taglibs.standard.util.XmlUtil.(XmlUtil.java:81) at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:154) at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:565) at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) ... 113 moreCaused by: java.lang.ClassNotFoundException: org/apache/xerces/jaxp/DocumentBuilderFactoryImpl at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:340) at javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:124) at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:188) ... 135 more Looks like your missing Xerces. OTHO I would have a look at your deployment. My guess it that your bundling at least JSTL. As a rule of thumb you should not package any Java EE APIs or implementations with your deplyoment. You should use the provided scope in Maven for such things. Cheers Philippe On 18.07.2017 13:16, Muthukumaran Manickavasagam wrote: > I have been trying to bring up my application with Wildfly 10, Java8 and Spring 4x libraries. I have got stuck with following issues for last two days and my suspect that i get below exception when Wildfly try to compile my JSP files. Any idea, when we get such exception? > javax.servlet.ServletException: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:355) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209) at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:221) at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:147) at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:111) at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:168) at com.myapp.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:46) at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:303) at org.springframework.webflow.mvc.servlet.ServletMvcView.doRender(ServletMvcView.java:55) at org.springframework.webflow.mvc .view.AbstractMvcView.render(AbstractMvcView.java:199) at org.springframework.webflow.action.ViewFactoryActionAdapter.doExecute(ViewFactoryActionAdapter.java:40) at org.springframework.webflow.action.AbstractAction.execute(AbstractAction.java:188) at org.springframework.webflow.execution.ActionExecutor.execute(ActionExecutor.java:51) at org.springframework.webflow.engine.EndState.doEnter(EndState.java:100) at org.springframework.webflow.engine.State.enter(State.java:194) at org.springframework.webflow.engine.Transition.execute(Transition.java:228) at org.springframework.webflow.engine.impl.FlowExecutionImpl.execute(FlowExecutionImpl.java:395) at org.springframework.webflow.engine.impl.RequestControlContextImpl.execute(RequestControlContextImpl.java:214) at org.springframework.webflow.engine.TransitionableState.handleEvent(TransitionableState.java:116) at org.springframework.webflow.engine.Flow.handleEvent(Flow.java:547) at org.springframework.webflow.engine.impl.FlowExecutionImpl.handleEvent(FlowExecutionImpl.java:390) at org.springframework.webflow.engine.impl.RequestControlContextImpl.handleEvent(RequestControlContextImpl.java:210) at org.springframework.webflow.engine.ActionState.doEnter(ActionState.java:105) at org.springframework.webflow.engine.State.enter(State.java:194) at org.springframework.webflow.engine.Transition.execute(Transition.java:228) at org.springframework.webflow.engine.impl.FlowExecutionImpl.execute(FlowExecutionImpl.java:395) at org.springframework.webflow.engine.impl.RequestControlContextImpl.execute(RequestControlContextImpl.java:214) at org.springframework.webflow.engine.TransitionableState.handleEvent(TransitionableState.java:116) at org.springframework.webflow.engine.Flow.handleEvent(Flow.java:547) at org.springframework.webflow.engine.impl.FlowExecutionImpl.handleEvent(FlowExecutionImpl.java:390) at org.springframework.webflow.engine.impl.R equestControlContextImpl.handleEvent(RequestControlContextImpl.java:210) at org.springframework.webflow.engine.ActionState.doEnter(ActionState.java:105) at org.springframework.webflow.engine.State.enter(State.java:194) at org.springframework.webflow.engine.Transition.execute(Transition.java:228) at org.springframework.webflow.engine.impl.FlowExecutionImpl.execute(FlowExecutionImpl.java:395) at org.springframework.webflow.engine.impl.RequestControlContextImpl.execute(RequestControlContextImpl.java:214) at org.springframework.webflow.engine.TransitionableState.handleEvent(TransitionableState.java:116) at org.springframework.webflow.engine.Flow.handleEvent(Flow.java:547) at org.springframework.webflow.engine.impl.FlowExecutionImpl.handleEvent(FlowExecutionImpl.java:390) at org.springframework.webflow.engine.impl.RequestControlContextImpl.handleEvent(RequestControlContextImpl.java:210) at org.springframework.webflow.engine.ActionState.doEnter(ActionState.java:105) at org.springframework.webflow.engine.State.enter(State.java:194) at org.springframework.webflow.engine.Flow.start(Flow.java:527) at org.springframework.webflow.engine.impl.FlowExecutionImpl.start(FlowExecutionImpl.java:368) at org.springframework.webflow.engine.impl.FlowExecutionImpl.start(FlowExecutionImpl.java:223) at org.springframework.webflow.executor.FlowExecutorImpl.launchExecution(FlowExecutorImpl.java:140) at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:263) at org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:174) at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:50) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901) at org.spri ngframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at com.myapp.HTTPInstrumentedFilter.doFilter(HTTPInstrumentedFilter.java:152) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCa llHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java: 135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)Caused by: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:200) at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:152) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:232) at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:120) at org.apache.taglibs.standard.util.XmlUtil$1.call(XmlUtil.java:83) at org.apache.taglibs.standard.util.XmlUtil$1.call(XmlUtil.java:81) at org.apache.taglibs.standard.util.XmlUtil$5.run(XmlUtil.java:395) at java.security.AccessController.doPrivileged(Native Method) at org.apache.taglibs.standard.util.XmlUtil.runWithOurClassLoader(XmlUtil.java:403) at org.apache.taglibs.standard.util.XmlUtil.(XmlUtil.java:81) at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:154) at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:565) at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) ... 113 moreCaused by: java.lang.ClassNotFoundException: org/apache/xerces/jaxp/DocumentBuilderFactoryImpl at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:340) at javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:124) at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:188) ... 135 more > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jkalina at redhat.com Wed Jul 19 10:56:35 2017 From: jkalina at redhat.com (Jan Kalina) Date: Wed, 19 Jul 2017 16:56:35 +0200 Subject: [wildfly-dev] WFCORE-3075 - KeyStore/KeyManager password Message-ID: I have written analysis/design notes for KeyManager/KeyStore improvement in Elytron: Analysis / Design - KeyStore password as default KeyManager password https://developer.jboss.org/wiki/AnalysisDesign-KeyStorePasswordAsDefaultKeyManagerPassword The goal is to allow not specifying keystore item password - only keystore password would be specified. Item (private key) would be in such case decrypted using keystore password. (This is how it works in legacy security) Problem in Elytron is how to deliver this password from KeyStore into KeyManager, as KeyManager and KeyStore are two independent resources in Elytron. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170719/e969204d/attachment.html From emmanuel at hibernate.org Thu Jul 27 12:16:55 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 27 Jul 2017 18:16:55 +0200 Subject: [wildfly-dev] Component upgrade window callback Message-ID: <235D3210-249F-49B3-8507-4E2096E19F03@hibernate.org> Hey all, In the past, the Hibernate team has missed quite a few Wildfly upgrade trains or had to run alongside to jump in it while it was taking off. I?m sure other components are in the same boat. The main problem is that we don?t really have a clear signal saying component upgrade window opened until date yyyy-mm-dd, or if it exists we are not watching it. Since our objective is to get the latest and greatest of our tech in Wildfly as soon as possible, I wonder if we can put in place some kind of callback process to know when we should get our act together is a less stressful way. Thoughts? Emmanuel From bburke at redhat.com Thu Jul 27 17:44:11 2017 From: bburke at redhat.com (Bill Burke) Date: Thu, 27 Jul 2017 17:44:11 -0400 Subject: [wildfly-dev] Component upgrade window callback In-Reply-To: <235D3210-249F-49B3-8507-4E2096E19F03@hibernate.org> References: <235D3210-249F-49B3-8507-4E2096E19F03@hibernate.org> Message-ID: <98130dd5-d08e-c36c-70b5-e63e8cd84739@redhat.com> Maybe start using wildfly-dev list again instead of IRC? On 7/27/17 12:16 PM, Emmanuel Bernard wrote: > Hey all, > > In the past, the Hibernate team has missed quite a few Wildfly upgrade trains or had to run alongside to jump in it while it was taking off. I?m sure other components are in the same boat. The main problem is that we don?t really have a clear signal saying component upgrade window opened until date yyyy-mm-dd, or if it exists we are not watching it. > > Since our objective is to get the latest and greatest of our tech in Wildfly as soon as possible, I wonder if we can put in place some kind of callback process to know when we should get our act together is a less stressful way. > > Thoughts? > > Emmanuel > _______________________________________________ > 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 Jul 27 22:06:19 2017 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 27 Jul 2017 21:06:19 -0500 Subject: [wildfly-dev] Component upgrade window callback In-Reply-To: <235D3210-249F-49B3-8507-4E2096E19F03@hibernate.org> References: <235D3210-249F-49B3-8507-4E2096E19F03@hibernate.org> Message-ID: <3CA4AB57-9CBA-454A-91CD-BBE09D05A745@redhat.com> We usually launch a call at the start of the release for suggestions of features of significance, including notable updates. 11 has been focused on the Elytron work that was set aside on the back burner for 10, and for 10.1 we decided to target out of the box HTTP/2. In the hibernate case Scott M usually coordinates major updates with Steve, since he usually has to update the integration code. We want to make two major improvements though: 1) Less time between releases (speed them up a bit more) - hopefully reducing the friction for getting updates in 2) We have a provisioning project that is underway, which will facilitate the ability to have overlaying update feature streams, so that, for example, the hibernate project could have a ?latest? stream that users could subscribe to (Although we would like for WildFly master to still stay current, as long as there is a plan for how compatibility is handled) -Jason > On Jul 27, 2017, at 11:16 AM, Emmanuel Bernard wrote: > > Hey all, > > In the past, the Hibernate team has missed quite a few Wildfly upgrade trains or had to run alongside to jump in it while it was taking off. I?m sure other components are in the same boat. The main problem is that we don?t really have a clear signal saying component upgrade window opened until date yyyy-mm-dd, or if it exists we are not watching it. > > Since our objective is to get the latest and greatest of our tech in Wildfly as soon as possible, I wonder if we can put in place some kind of callback process to know when we should get our act together is a less stressful way. > > Thoughts? > > Emmanuel > _______________________________________________ > 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 ttarrant at redhat.com Fri Jul 28 04:33:16 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 28 Jul 2017 10:33:16 +0200 Subject: [wildfly-dev] Component upgrade window callback In-Reply-To: <3CA4AB57-9CBA-454A-91CD-BBE09D05A745@redhat.com> References: <235D3210-249F-49B3-8507-4E2096E19F03@hibernate.org> <3CA4AB57-9CBA-454A-91CD-BBE09D05A745@redhat.com> Message-ID: Jason, I guess I'm not the only one who feels that the WildFly development process has become excessively opaque: - no regular tags from the development branch. There was an Alpha1 release which was announced only on Twitter with no real release notes (nobody is going to look at an arid list of Jiras) and nothing on the wildfly.org site. Without milestones releases it is difficult to plan checkpoints for testing integration. - no public high-level roadmap on wildfly.org. Again, Jira is really for the consumption of the core developers, not for the wider community. I'm sure Elytron is not the only thing that is landing in WildFly 11 aside from the usual slew of component upgrades. - no blogging on any new features / changes / designs. Tristan On 7/28/17 4:06 AM, Jason Greene wrote: > We usually launch a call at the start of the release for suggestions of features of significance, including notable updates. 11 has been focused on the Elytron work that was set aside on the back burner for 10, and for 10.1 we decided to target out of the box HTTP/2. In the hibernate case Scott M usually coordinates major updates with Steve, since he usually has to update the integration code. We want to make two major improvements though: > > 1) Less time between releases (speed them up a bit more) - hopefully reducing the friction for getting updates in > 2) We have a provisioning project that is underway, which will facilitate the ability to have overlaying update feature streams, so that, for example, the hibernate project could have a ?latest? stream that users could subscribe to (Although we would like for WildFly master to still stay current, as long as there is a plan for how compatibility is handled) > > -Jason > >> On Jul 27, 2017, at 11:16 AM, Emmanuel Bernard wrote: >> >> Hey all, >> >> In the past, the Hibernate team has missed quite a few Wildfly upgrade trains or had to run alongside to jump in it while it was taking off. I?m sure other components are in the same boat. The main problem is that we don?t really have a clear signal saying component upgrade window opened until date yyyy-mm-dd, or if it exists we are not watching it. >> >> Since our objective is to get the latest and greatest of our tech in Wildfly as soon as possible, I wonder if we can put in place some kind of callback process to know when we should get our act together is a less stressful way. >> >> Thoughts? >> >> Emmanuel >> _______________________________________________ >> 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 > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From emmanuel at hibernate.org Fri Jul 28 07:19:14 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 28 Jul 2017 13:19:14 +0200 Subject: [wildfly-dev] Component upgrade window callback In-Reply-To: <3CA4AB57-9CBA-454A-91CD-BBE09D05A745@redhat.com> References: <235D3210-249F-49B3-8507-4E2096E19F03@hibernate.org> <3CA4AB57-9CBA-454A-91CD-BBE09D05A745@redhat.com> Message-ID: <6965CEF5-ED2C-41EF-B363-377D220CF59F@hibernate.org> Thanks for the input. One thing to note. While Scott looks at the Hibernate ORM / Wildfly combo, we also have Hibernate Validator and Hibernate Search. +1 for the suggestion call on Wildfly-Dev - as long as the release is not too many months in the future otherwise we enter a very blurry picture of what can be accomplished. We (library-ists) will try and make concrete actions when we see the call, instead of ignoring it today. I like the provisioning project idea. As you say, it's not a full substitute as you want the primary distro to be as fresh as possible. > On 28 Jul 2017, at 04:06, Jason Greene wrote: > > We usually launch a call at the start of the release for suggestions of features of significance, including notable updates. 11 has been focused on the Elytron work that was set aside on the back burner for 10, and for 10.1 we decided to target out of the box HTTP/2. In the hibernate case Scott M usually coordinates major updates with Steve, since he usually has to update the integration code. We want to make two major improvements though: > > 1) Less time between releases (speed them up a bit more) - hopefully reducing the friction for getting updates in > 2) We have a provisioning project that is underway, which will facilitate the ability to have overlaying update feature streams, so that, for example, the hibernate project could have a ?latest? stream that users could subscribe to (Although we would like for WildFly master to still stay current, as long as there is a plan for how compatibility is handled) > > -Jason > >> On Jul 27, 2017, at 11:16 AM, Emmanuel Bernard wrote: >> >> Hey all, >> >> In the past, the Hibernate team has missed quite a few Wildfly upgrade trains or had to run alongside to jump in it while it was taking off. I?m sure other components are in the same boat. The main problem is that we don?t really have a clear signal saying component upgrade window opened until date yyyy-mm-dd, or if it exists we are not watching it. >> >> Since our objective is to get the latest and greatest of our tech in Wildfly as soon as possible, I wonder if we can put in place some kind of callback process to know when we should get our act together is a less stressful way. >> >> Thoughts? >> >> Emmanuel >> _______________________________________________ >> 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 gunnar at hibernate.org Fri Jul 28 09:51:31 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 28 Jul 2017 15:51:31 +0200 Subject: [wildfly-dev] Component upgrade window callback In-Reply-To: <6965CEF5-ED2C-41EF-B363-377D220CF59F@hibernate.org> References: <235D3210-249F-49B3-8507-4E2096E19F03@hibernate.org> <3CA4AB57-9CBA-454A-91CD-BBE09D05A745@redhat.com> <6965CEF5-ED2C-41EF-B363-377D220CF59F@hibernate.org> Message-ID: > We (library-ists) will try and make concrete actions when we see the call, instead of ignoring it today. +1 It'd help to have an announcement on wildfly-dev with some dates until when updates can be easily delivered for a given release. > I like the provisioning project idea. As you say, it's not a full substitute as you want the primary distro to be as fresh as possible. On that one, we already provide module ZIPs or even patch files which make it very easy to upgrade WF to the latest and greatest, e.g. for Hibernate Validator. But of course it'd be even better if that's not required for the user. 2017-07-28 13:19 GMT+02:00 Emmanuel Bernard : > Thanks for the input. > > One thing to note. While Scott looks at the Hibernate ORM / Wildfly combo, > we also have Hibernate Validator and Hibernate Search. > > +1 for the suggestion call on Wildfly-Dev - as long as the release is not > too many months in the future otherwise we enter a very blurry picture of > what can be accomplished. We (library-ists) will try and make concrete > actions when we see the call, instead of ignoring it today. > I like the provisioning project idea. As you say, it's not a full > substitute as you want the primary distro to be as fresh as possible. > > > On 28 Jul 2017, at 04:06, Jason Greene wrote: > > > > We usually launch a call at the start of the release for suggestions of > features of significance, including notable updates. 11 has been focused on > the Elytron work that was set aside on the back burner for 10, and for 10.1 > we decided to target out of the box HTTP/2. In the hibernate case Scott M > usually coordinates major updates with Steve, since he usually has to > update the integration code. We want to make two major improvements though: > > > > 1) Less time between releases (speed them up a bit more) - hopefully > reducing the friction for getting updates in > > 2) We have a provisioning project that is underway, which will > facilitate the ability to have overlaying update feature streams, so that, > for example, the hibernate project could have a ?latest? stream that users > could subscribe to (Although we would like for WildFly master to still stay > current, as long as there is a plan for how compatibility is handled) > > > > -Jason > > > >> On Jul 27, 2017, at 11:16 AM, Emmanuel Bernard > wrote: > >> > >> Hey all, > >> > >> In the past, the Hibernate team has missed quite a few Wildfly upgrade > trains or had to run alongside to jump in it while it was taking off. I?m > sure other components are in the same boat. The main problem is that we > don?t really have a clear signal saying component upgrade window opened > until date yyyy-mm-dd, or if it exists we are not watching it. > >> > >> Since our objective is to get the latest and greatest of our tech in > Wildfly as soon as possible, I wonder if we can put in place some kind of > callback process to know when we should get our act together is a less > stressful way. > >> > >> Thoughts? > >> > >> Emmanuel > >> _______________________________________________ > >> 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/20170728/5f5685e6/attachment.html