[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1119:
-------------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1280235|https://bugzilla.redhat.com/show_bug.cgi?id=1280235] from ASSIGNED to POST
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Brian Stansberry
> Fix For: 2.0.2.Final
>
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1658) JBEAP-2830 enhancements were not forward ported to upstream
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1658?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1658:
-------------------------------------
Description:
JBEAP-2830 includes changes to the logging subsystem's template.xml that EAP full relies upon. These were never forward ported to upstream, meaning that EAP builds can't consume core 2.2 or later.
I believe there's no problem applying the changes. EAP will use one of the supplements while WildFly will not.
was:
JBEAP-2830 includes changes to the logging subsystem's template.xml that EAP full relies upon. These were never forward ported to upstream, meaning that EAP builds can't consume core 2.2 or later.
I believe there's no problem applying the changes. EAP will use on of the supplements while WildFly will not.
> JBEAP-2830 enhancements were not forward ported to upstream
> -----------------------------------------------------------
>
> Key: WFCORE-1658
> URL: https://issues.jboss.org/browse/WFCORE-1658
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Blocker
> Fix For: 2.2.0.CR8
>
>
> JBEAP-2830 includes changes to the logging subsystem's template.xml that EAP full relies upon. These were never forward ported to upstream, meaning that EAP builds can't consume core 2.2 or later.
> I believe there's no problem applying the changes. EAP will use one of the supplements while WildFly will not.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1658) JBEAP-2830 enhancements were not forward ported to upstream
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1658:
----------------------------------------
Summary: JBEAP-2830 enhancements were not forward ported to upstream
Key: WFCORE-1658
URL: https://issues.jboss.org/browse/WFCORE-1658
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Blocker
Fix For: 2.2.0.CR8
JBEAP-2830 includes changes to the logging subsystem's template.xml that EAP full relies upon. These were never forward ported to upstream, meaning that EAP builds can't consume core 2.2 or later.
I believe there's no problem applying the changes. EAP will use on of the supplements while WildFly will not.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6636) WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6636?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6636:
-----------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1338093|https://bugzilla.redhat.com/show_bug.cgi?id=1338093] from POST to ASSIGNED
> WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6636
> URL: https://issues.jboss.org/browse/WFLY-6636
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Tomas Hofman
> Attachments: test.ear
>
>
> If a sub deployment uses another sub deployment's module-alias as a dependency, it will deploy successfully, but if hot deployed, it will fail with the error below. Attached reproducer.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
> <sub-deployment name="ejb1.jar">
> <module-alias name="deployment.ejb1"/>
> </sub-deployment>
> <sub-deployment name="ejb2.jar">
> <dependencies>
> <!-- works
> <module name="deployment.test.ear.ejb1.jar" slot="main"/>
> -->
> <!-- fails with WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default on redeploy / hot deploy -->
> <module name="deployment.ejb1" slot="main"/>
> </dependencies>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> {code}
> 10:43:42,140 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."test.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
> at test.TestEJB2.test1(TestEJB2.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 10:43:42,144 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
> at test.TestEJB2.test1(TestEJB2.java:0)
> "}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6809) Web authentication not treating "**" role constraint as expected
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-6809?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-6809:
-----------------------------------
The Servlet spec lead essentially has clarified this some time ago on his personal blog. See this archived version:
https://web.archive.org/web/20150912103140/https://weblogs.java.net/blog/...
(or the current automatically migrated one, which however formats horribly: https://community.oracle.com/blogs/swchan2/2013/04/19/role-servlet-31-sec...)
I also had a chat with the JACC spec lead about this some time ago. He clarified that in a full Java EE product, the Servlet container *must* follow the JACC spec. So in this case 3.1.3.2 of the JACC spec applies, where a {{WebResourcePermission}} must indeed be added and enforced for the pre-dispatch (authorization) outcome.
_(actually according to the JACC spec lead the Servlet container in a full Java EE server must use the default JACC provider at run time for the pre-dispatch outcome as well as the programmatic role checks. Although in JBoss/WildFly the default JACC provider is available and initialised, it's not actually used by the Servlet container)_
> Web authentication not treating "**" role constraint as expected
> ----------------------------------------------------------------
>
> Key: WFLY-6809
> URL: https://issues.jboss.org/browse/WFLY-6809
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
> Attachments: rolestest.war
>
>
> Servlet spec 3.1 states at point 13.3:
> ??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.??
> But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403):
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
> version="3.1">
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>**</role-name>
> </auth-constraint>
> </security-constraint>
> <login-config>
> <auth-method>BASIC</auth-method>
> </login-config>
> </web-app>
> {code}
> With the following, and authenticating a user that has a role "**", the requested page is shown:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
> version="3.1">
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>**</role-name>
> </auth-constraint>
> </security-constraint>
> <login-config>
> <auth-method>BASIC</auth-method>
> </login-config>
> <security-role>
> <role-name>**</role-name>
> </security-role>
> </web-app>
> {code}
> Reproducer war is attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6838) RPCs to non-existant FORK channel are dropped
by Dennis Reed (JIRA)
Dennis Reed created WFLY-6838:
---------------------------------
Summary: RPCs to non-existant FORK channel are dropped
Key: WFLY-6838
URL: https://issues.jboss.org/browse/WFLY-6838
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Dennis Reed
Assignee: Dennis Reed
RPCs sent to a FORK channel that is not currently running are not responded to correctly, causing the caller to eventually time out.
An error response is being sent by org.jboss.as.clustering.jgroups.JChannelFactory, but the request ID is hard-coded to 0 so the reply can not be routed back to the sender and gets dropped.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6837) [GSS](7.0.z) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee
by Robert Bost (JIRA)
Robert Bost created WFLY-6837:
---------------------------------
Summary: [GSS](7.0.z) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee
Key: WFLY-6837
URL: https://issues.jboss.org/browse/WFLY-6837
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Reporter: Robert Bost
Assignee: Aaron Ogburn
Fix For: 10.1.0.Final
JASPICSecureResponseHandler.handleRequest can throw a NPE for a redirect from a CONFIDENTIAL transport guarantee:
{code}
java.lang.NullPointerException
at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:35)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
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 occurs because io.undertow.security.handlers.AbstractConfidentialityHandler generates the redirect before any JASPICContext is placed on the request, so JASPICSecureResponseHandler sees the null.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2044) RequestCorrelator causes frequent boxing and autoboxing by using a Map<Long, Request>
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2044?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2044 at 7/15/16 12:27 PM:
----------------------------------------------------------
How do you see boxing/unboxing in JFR? And what was the percentage you were seeing?
I've looked into this before in JGRP-1982 and decided against it.
I've changed this in my private branch to use Trove's {{TLongObjectHashMap}}, but this
* introduces a dependency which I don't want and
* {{TLongObjectHashMap}} is not concurrent (as {{ConcurrentHashMap}}, and therefore every access needs to be synchronized, slowing things down
was (Author: belaban):
How do you see boxing/unboxing in JFR?
> RequestCorrelator causes frequent boxing and autoboxing by using a Map<Long,Request>
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2044
> URL: https://issues.jboss.org/browse/JGRP-2044
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> The JFR profiler is highlighting a significant amount of boxing and autoboxing, as the request is is treated as a {{long}} but this is used as an key for the {{Map<Long,Request>}}.
> We could try to either consistently use {{Long}} rather than {{long}}, or even better figure out an optimal data structure to replace the implementation of the Map to not require boxing of the keys.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months