July 2017 - wildfly-dev - Jboss List Archives

by Emmanuel Bernard

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

7 years

5
5
0 / 0

WFCORE-3075 - KeyStore/KeyManager password

by Jan Kalina

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-KeyStorePasswordAsDefault... 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.

7 years

1
0
0 / 0

WIldfly 10, Java 8, Spring 4x

by Muthukumaran Manickavasagam

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.<clinit>(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

7 years

2
1
0 / 0

JDK 9 EA Build 178 & JDK 8u152 b05 are available on jdk.java.net

by Rory O'Donnell

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 <http://download.java.net/java/jdk9/changes/jdk-9+178.html>. 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/ <http://jdk.java.net/8/> A summary of all the changes in this build are listed here <http://download.java.net/java/jdk8u152/changes/jdk8u152-b05.html>. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

7 years

1
0
0 / 0

Bringing Bean Validation 2.0 to WildFly

by Gunnar Morling

Hi, <TL,DR>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?</TL,DR> 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-submitt...

7 years

6
6
0 / 0

Re: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck

by David Lloyd

On Fri, Jul 7, 2017 at 7:18 AM, Heiko Rupp <hrupp(a)redhat.com> 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.

7 years

1
0
0 / 0

Re: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck

by Rob Cernich

> 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.

7 years

1
0
0 / 0

Re: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck

by Jeff Mesnil

> On 7 Jul 2017, at 14:18, Heiko Rupp <hrupp(a)redhat.com> 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/pro... -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/

7 years

1
0
0 / 0

Re: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck

by Jeff Mesnil

> On 7 Jul 2017, at 14:22, Heiko Rupp <hrupp(a)redhat.com> 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/

7 years

1
0
0 / 0

Re: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck

by Rob Cernich

> 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.

7 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wildfly-dev July 2017