[JBoss JIRA] (WFLY-5687) max-active-sessions doesn't work with enabled statistics
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-5687?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet commented on WFLY-5687:
-----------------------------------------
Yes, now we have the same behaviour with and without statistics enabled: when the max number of session is hit we have a 500 error:
08:30:57,522 ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /simple-servlet/counter: java.lang.IllegalStateException: UT000121: Session was rejected as the maximum number of sessions (3) has been hit
> max-active-sessions doesn't work with enabled statistics
> --------------------------------------------------------
>
> Key: WFLY-5687
> URL: https://issues.jboss.org/browse/WFLY-5687
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR4
> Reporter: Radim Hatlapatka
> Assignee: ehsavoie Hugonnet
> Attachments: simple-servlet.war
>
>
> When having defined max-active-sessions and enabled statistics {{/subsystem=undertow:write-attribute(name=statistics-enabled, value=true)}} the setting of max-active-sessions is ignored.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Ladislav Thon updated WFLY-5850:
--------------------------------
Priority: Critical (was: Blocker)
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Eduardo Martins
> Priority: Critical
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5856) Missing equivalent handler for CrawlerSessionManagerValve
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5856?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-2427 to WFLY-5856:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5856 (was: JBEAP-2427)
Issue Type: Feature Request (was: Bug)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Target Release: (was: 7.0.0.GA)
Affects Version/s: (was: 7.0.0.DR13 (Alpha))
> Missing equivalent handler for CrawlerSessionManagerValve
> ---------------------------------------------------------
>
> Key: WFLY-5856
> URL: https://issues.jboss.org/browse/WFLY-5856
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Labels: valves
>
> In JBoss Web there is possible to use CrawlerSessionManagerValve, this is valve which detects requests from crawlers and makes sure that they are associated with single session to prevent
> significant memory consumption. Detection is done based on UserAgent header.
> There is no handler with equivalent functionality in Undertow
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-985) different startup behaviour: commandline parameters and jboss.properties files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-985?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFCORE-985.
-------------------------------------
Resolution: Won't Fix
I don't foresee us fixing this.
This is because the VM configures java.util.logging before the WildFly process has a chance to see the --properties param and parse the file. The properties that affect the logging behavior have to be passed via -D, either on the command line or via domain.conf.
To improve this we'd have to either:
1) Detect --properties in domain.sh | domain.ps1, open and parse the file in the script and pass -D to the VM launch. We're not going to do this.
2) Strip the .sh | .ps1 scripts down to almost nothing and launch a small "launcher" process that in turn has all the logic currently in the scripts, and in turn launches the regular process currently launched by the scripts. The launcher process could then deal with --properties. It's possible (not IMHO probable) we'll do the launcher process some day, and if we do we can revisit this.
> different startup behaviour: commandline parameters and jboss.properties files
> ------------------------------------------------------------------------------
>
> Key: WFCORE-985
> URL: https://issues.jboss.org/browse/WFCORE-985
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Gernot P
>
> Starting my domain with
> ${JBOSS_HOME}/bin/domain.sh -Djboss.domain.base.dir=/domain1
> the host-controller.log and process-controller.log are written (as expected) to /domain1/log
> But starting my domain with
> ${JBOSS_HOME}/bin/domain.sh --properties=/domain1/jboss.properties
> where /domain1/jboss.properties contains following line
> jboss.domain.base.dir=/domain1
> the host-controller.log and process-controller.log are written to ${JBOSS_HOME}/domain/log
> The same result (logfiles are written to ${JBOSS_HOME}/domain/log) with /domain1/jboss.properties with following two lines:
> jboss.domain.base.dir=/domain1
> jboss.domain.log.dir=/domain1/log
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1230) Drop OperationContextImpl.DescriptionCaching(Immutable)ResourceRegistration
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1230:
----------------------------------------
Summary: Drop OperationContextImpl.DescriptionCaching(Immutable)ResourceRegistration
Key: WFCORE-1230
URL: https://issues.jboss.org/browse/WFCORE-1230
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha1
The OperationContextImpl.DescriptionCaching(Immutable)ResourceRegistration classes and the usage thereof are no longer needed. They were used for RBAC checks in cases where an MRR had attributes without an AttributeDefinition. But those are no longer possible so this code is unnecessary.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5855) NPE in ApplicationSecurityDomainService#desiredMechanisms when loginConfig is null
by Farah Juma (JIRA)
Farah Juma created WFLY-5855:
--------------------------------
Summary: NPE in ApplicationSecurityDomainService#desiredMechanisms when loginConfig is null
Key: WFLY-5855
URL: https://issues.jboss.org/browse/WFLY-5855
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Farah Juma
Assignee: Farah Juma
Fix For: 11.0.0.Alpha1
The following NPE occurs when attempting to access an application that doesn't specify the {{login-config}}:
{code}
ESC[0mESC[31m15:10:23,906 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /: java.lang.NullPointerException
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.desiredMechanisms(ApplicationSecurityDomainDefinition.java:272)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$null$2(ApplicationSecurityDomainDefinition.java:289)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.getAuthenticationMechanisms(ApplicationSecurityDomainDefinition.java:285)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$3(ApplicationSecurityDomainDefinition.java:289)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:85)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:74)
at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:63)
at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:62)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.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.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
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)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5855) NPE in ApplicationSecurityDomainService#desiredMechanisms when loginConfig is null
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-5855?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-5855:
-----------------------------
Labels: affects_elytron (was: )
> NPE in ApplicationSecurityDomainService#desiredMechanisms when loginConfig is null
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5855
> URL: https://issues.jboss.org/browse/WFLY-5855
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Farah Juma
> Labels: affects_elytron
> Fix For: 11.0.0.Alpha1
>
>
> The following NPE occurs when attempting to access an application that doesn't specify the {{login-config}}:
> {code}
> ESC[0mESC[31m15:10:23,906 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /: java.lang.NullPointerException
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.desiredMechanisms(ApplicationSecurityDomainDefinition.java:272)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$null$2(ApplicationSecurityDomainDefinition.java:289)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.getAuthenticationMechanisms(ApplicationSecurityDomainDefinition.java:285)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$3(ApplicationSecurityDomainDefinition.java:289)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:85)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:74)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:63)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:62)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.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.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months