July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2067) Protocol: add down(Message) and up(Message)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2067?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2067. ---------------------------- Resolution: Done > Protocol: add down(Message) and up(Message) > ------------------------------------------- > > Key: JGRP-2067 > URL: https://issues.jboss.org/browse/JGRP-2067 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Oftentime we have code like this, e.g. in a protocol: > {code:java} > void send(Message msg) { > ... > down_prot.down(new Event(Event.MSG, msg)); > } > {code} > Most protocols deal mainly with {{Message}} types, so adding {{down(Message msg)}} and {{up(Message msg)}} would simplify the code above to: > {code:java} > void send(Message msg) { > ... > down_prot.down(msg); > } > {code} > This would also lead to a (massive) reduction of {{Event}} class creations. > Downside: this requires a lot of code changes (mainly in protocols)! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ] Petr Široký commented on DROOLS-355: ------------------------------------ Hello [~hkonsek]. Would it possible to attach a reproducer which shows the error you are encountering? It would help us a lot. Thanks! > Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9 > ------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-355 > URL: https://issues.jboss.org/browse/DROOLS-355 > Project: Drools > Issue Type: Task > Affects Versions: 6.0.0.Final > Reporter: Geoffrey De Smet > Assignee: Petr Široký > Priority: Blocker > > By importing com.sun.tools.xjc, 3 problems arise: > * OSGi and Karaf trip over it. > {code} > [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final) > {code} > * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013. > * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this? > Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now. > Where do we use it? > {code} > Targets > String 'com.sun.tools.xjc' > Found usages (38 usages found) > drools-compiler (7 usages found) > /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found) > pom.xml (1 usage found) > (246: 15) com.sun.tools.xjc.*;resolution:=optional, > org.drools.compiler.builder.impl (1 usage found) > KnowledgeBuilderFactoryServiceImpl.java (1 usage found) > (18: 8) import com.sun.tools.xjc.Options; > org.drools.compiler.runtime.pipeline.impl (5 usages found) > DroolsJaxbHelperProviderImpl.java (5 usages found) > (77: 8) import com.sun.tools.xjc.BadCommandLineException; > (78: 8) import com.sun.tools.xjc.ErrorReceiver; > (79: 8) import com.sun.tools.xjc.ModelLoader; > (80: 8) import com.sun.tools.xjc.Options; > (81: 8) import com.sun.tools.xjc.model.Model; > drools-core (2 usages found) > org.drools.core.builder.conf.impl (2 usages found) > JaxbConfigurationImpl.java (2 usages found) > (28: 8) import com.sun.tools.xjc.Language; > (34: 8) import com.sun.tools.xjc.Options; > kie-internal (6 usages found) > /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found) > pom.xml (1 usage found) > (27: 15) com.sun.tools.xjc;resolution:=optional, > org.kie.internal.builder (3 usages found) > JaxbConfiguration.java (1 usage found) > (23: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactory.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactoryService.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > org.kie.internal.builder.help (2 usages found) > DroolsJaxbHelperProvider.java (1 usage found) > (29: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderHelper.java (1 usage found) > (30: 8) import com.sun.tools.xjc.Options; > knowledge-api (8 usages found) > org.drools.builder (3 usages found) > JaxbConfiguration.java (1 usage found) > (21: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactory.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactoryService.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > org.drools.builder.help (3 usages found) > DroolsJaxbHelperProvider.java (1 usage found) > (29: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderHelper.java (2 usages found) > (32: 8) import com.sun.tools.xjc.Language; > (33: 8) import com.sun.tools.xjc.Options; > org.drools.impl (1 usage found) > KnowledgeBuilderFactoryServiceImpl.java (1 usage found) > (16: 8) import com.sun.tools.xjc.Options; > org.drools.impl.adapters (1 usage found) > JaxbConfigurationAdapter.java (1 usage found) > (3: 8) import com.sun.tools.xjc.Options; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1671) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1671?page=com.atlassian.jira.plugi... ] Lin Gao commented on WFCORE-1671: --------------------------------- [~brian.stansberry] My plan is to add the dependency:{{<module name="org.jboss.as.security" optional="true" services="import"/>}} in module: {{core-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/server/main/module.xml}}. The dependency was removed when fixing another Jira: WFCORE-114, do you see any problem if I add the dependency back? > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security > ---------------------------------------------------------------------------------------- > > Key: WFCORE-1671 > URL: https://issues.jboss.org/browse/WFCORE-1671 > Project: WildFly Core > Issue Type: Bug > Components: Security, Server > Reporter: Derek Horton > Assignee: Lin Gao > > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following: > <security-realm name="ManagementRealm"> > <authentication> > <jaas name="jmx-console"/> > </authentication> > <authorization map-groups-to-roles="false"> > <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> > </authorization> > </security-realm> > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="RealmUsersRoles" flag="required"> > <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > </login-module> > </authentication> > </security-domain> > The following error is logged during the authentication attempt: > 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))] > at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794) > at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) > at javax.security.auth.login.LoginContext.login(LoginContext.java:587) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347) > at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174) > at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141) > at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161) > at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-600) Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-600: ------------------------------------ Summary: Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults. Key: ELY-600 URL: https://issues.jboss.org/browse/ELY-600 Project: WildFly Elytron Issue Type: Task Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta7 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE2: merge never happens

by Bela Ban (JIRA)

Bela Ban created JGRP-2092: ------------------------------ Summary: MERGE2: merge never happens Key: JGRP-2092 URL: https://issues.jboss.org/browse/JGRP-2092 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.11, 4.0 (Reported by Neal Dillman) In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. {noformat} Host A view: B, X, Y, Z, A (where B should be coordinator) Host B view: C, Q, R, S, B (where C should be coordinator) Host C view: A, M, N, O, C (where A should be coordinator) {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1015) jconsole Wildfly CLI tab not loading when using remote

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1015?page=com.atlassian.jira.plugi... ] Enrique González Martínez reassigned WFCORE-1015: ------------------------------------------------- Assignee: Enrique González Martínez (was: Brad Maxwell) > jconsole Wildfly CLI tab not loading when using remote > ------------------------------------------------------ > > Key: WFCORE-1015 > URL: https://issues.jboss.org/browse/WFCORE-1015 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Brad Maxwell > Assignee: Enrique González Martínez > > Issue introduced with WFLY-1548, the dialog added with WFLY-1548 is to get a connection with jconsole local process connection is used to establish a connection to the management api. This bug is because when using remote, the init(...) is not being called with the existing CommandContext -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1672) Add 'Vary: Origin' header to CorsHttpHandler

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1672?page=com.atlassian.jira.plugi... ] Harald Pehl updated WFCORE-1672: -------------------------------- Description: The management endpoint can be accessed from a list of allowed origins. In that case CORS relevant headers such as {{Access-Control-Allow-Origin: <allowed origin>}} are added to response. Since the list of allowed origins is dynamic, the header {{Vary: Origin}} should be added as well. See [https://www.w3.org/TR/cors/#resource-implementation]. Without the {{Vary}} header being present in the response, the client uses responses from the cache which have an origin that does not match the current origin. Consider this scenario: # http://localhost:3000 (client1) and http://localhost:4000 (client2) are both configured as allowed origins # client1 reads a resource description using http://localhost:9990/management/profile/default/subsystem/batch-jberet?o.... Since it's a GET request the response is cached. # client2 reads the same resource description Without the {{Vary}} header, client2 would use the cached response. However the origin in the cached response (http://localhost:3000) does not match the current origin (http://localhost:4000), which causes errors. was: The management endpoint can be accessed from a list of allowed origins. In that case CORS relevant headers such as {{Access-Control-Allow-Origin: <allowed origin>}} are added to response. Since the list of allowed origins is dynamic, the header {{Vary: Origin}} should be added as well. See [https://www.w3.org/TR/cors/#resource-implementation]. > Add 'Vary: Origin' header to CorsHttpHandler > -------------------------------------------- > > Key: WFCORE-1672 > URL: https://issues.jboss.org/browse/WFCORE-1672 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Harald Pehl > Assignee: Harald Pehl > > The management endpoint can be accessed from a list of allowed origins. In that case CORS relevant headers such as {{Access-Control-Allow-Origin: <allowed origin>}} are added to response. > Since the list of allowed origins is dynamic, the header {{Vary: Origin}} should be added as well. See [https://www.w3.org/TR/cors/#resource-implementation]. > Without the {{Vary}} header being present in the response, the client uses responses from the cache which have an origin that does not match the current origin. Consider this scenario: > # http://localhost:3000 (client1) and http://localhost:4000 (client2) are both configured as allowed origins > # client1 reads a resource description using http://localhost:9990/management/profile/default/subsystem/batch-jberet?o.... Since it's a GET request the response is cached. > # client2 reads the same resource description > Without the {{Vary}} header, client2 would use the cached response. However the origin in the cached response (http://localhost:3000) does not match the current origin (http://localhost:4000), which causes errors. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1672) Add 'Vary: Origin' header to CorsHttpHandler

by Harald Pehl (JIRA)

Harald Pehl created WFCORE-1672: ----------------------------------- Summary: Add 'Vary: Origin' header to CorsHttpHandler Key: WFCORE-1672 URL: https://issues.jboss.org/browse/WFCORE-1672 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Harald Pehl Assignee: Harald Pehl The management endpoint can be accessed from a list of allowed origins. In that case CORS relevant headers such as {{Access-Control-Allow-Origin: <allowed origin>}} are added to response. Since the list of allowed origins is dynamic, the header {{Vary: Origin}} should be added as well. See [https://www.w3.org/TR/cors/#resource-implementation]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6639) Upgrade IronJacamar from 1.3.3.Final to 1.3.4.Final

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6639?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6639: -------------------------------- Sprint: (was: EAP 7.0.1) > Upgrade IronJacamar from 1.3.3.Final to 1.3.4.Final > --------------------------------------------------- > > Key: WFLY-6639 > URL: https://issues.jboss.org/browse/WFLY-6639 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Blocker > Labels: downstream_dependency > Fix For: 10.1.0.CR1 > > > If the password for any datasource is invalid, and there are multiple datasources defined, it is difficult to identify the problematic datasource from the the console log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1565) Upgrade JBoss Remoting from 4.0.18 to 4.0.21

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1565?page=com.atlassian.jira.plugi... ] Carlo de Wolf updated WFCORE-1565: ---------------------------------- Sprint: (was: EAP 7.0.1) > Upgrade JBoss Remoting from 4.0.18 to 4.0.21 > -------------------------------------------- > > Key: WFCORE-1565 > URL: https://issues.jboss.org/browse/WFCORE-1565 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Bartosz Baranowski > Assignee: David Lloyd > Fix For: 2.2.0.CR3, 3.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016