March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-475) Update the CLIENT_CERT authentication mechanism to be able to make use of an established security identity

by Farah Juma (JIRA)

Farah Juma created ELY-475: ------------------------------ Summary: Update the CLIENT_CERT authentication mechanism to be able to make use of an established security identity Key: ELY-475 URL: https://issues.jboss.org/browse/ELY-475 Project: WildFly Elytron Issue Type: Task Components: API / SPI, HTTP Reporter: Farah Juma Assignee: Farah Juma There's currently a TODO in [ClientCertAuthenticationMechanism#evaluateRequest|https://github.com/wild...] for making use of an established {{SecurityIdentity}} from an {{SSLSession}}. It should be possible to do this by making use of the API for propagating an identity between domains (ELY-178). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1440) Expression resolver breaks return value for empty lists

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1440?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1440: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1477 > Expression resolver breaks return value for empty lists > ------------------------------------------------------- > > Key: WFCORE-1440 > URL: https://issues.jboss.org/browse/WFCORE-1440 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha1 > > > ExpressionResolverImpl#resolveExpressionsRecursively > does > {code} > else if (type == ModelType.LIST) { > resolved = node.clone(); > ModelNode list = new ModelNode(); > for (ModelNode current : resolved.asList()) { > list.add(resolveExpressionsRecursively(current)); > } > resolved = list; > } > {code} > for list attributes, but in case that resolved value is empty list it would return list that is undefined instead of empty list. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6445) Upgrade to JBoss Negotiation 3.0.2.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-6445: -------------------------------------- Summary: Upgrade to JBoss Negotiation 3.0.2.Final Key: WFLY-6445 URL: https://issues.jboss.org/browse/WFLY-6445 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 10.1.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-940) Release JBoss Negotiation 3.0.2.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created SECURITY-940: ----------------------------------------- Summary: Release JBoss Negotiation 3.0.2.Final Key: SECURITY-940 URL: https://issues.jboss.org/browse/SECURITY-940 Project: PicketBox Issue Type: Release Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_3_0_2_CR1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-939) Contents of NegotiationContext getting cleared before challenge is sent to client.

by Darran Lofthouse (JIRA)

Darran Lofthouse created SECURITY-939: ----------------------------------------- Summary: Contents of NegotiationContext getting cleared before challenge is sent to client. Key: SECURITY-939 URL: https://issues.jboss.org/browse/SECURITY-939 Project: PicketBox Issue Type: Bug Components: Negotiation Affects Versions: Negotiation_3_0_0_Final Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_3_0_2_CR1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1448) AttributeParser for ObjectListAttributeDefinitions doesn't differentiate between empty and absent object lists

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1448?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1448: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1477 > AttributeParser for ObjectListAttributeDefinitions doesn't differentiate between empty and absent object lists > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1448 > URL: https://issues.jboss.org/browse/WFCORE-1448 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha1 > > > Attributes of type ObjectList are left undefined when their enclosing element is empty, which makes it impossible to differentiate an empty object list from an unspecified one. > The ability to distinguish the two scenarios is important in the security manager subsystem. Consider this configuration: > {code:xml} > <subsystem xmlns="urn:jboss:domain:security-manager:1.0"> > <deployment-permissions> > <mininum-set> > .... > </minimum-set> > </deployment-permissions> > </subsystem> > {code} > The maximum-set is absent and this case we want to use a default set with AllPermission. Now consider another configuration: > {code:xml} > <subsystem xmlns="urn:jboss:domain:security-manager:1.0"> > <deployment-permissions> > <mininum-set/> > <maximum-set/> > </deployment-permissions> > </subsystem> > {code} > In this case, maximum-set has been specified but it is empty, which means the admin/user deliberately wants to use an emtpy set, possibly to enforce that no deployments with special permissions requirements get deployed. > The problem is that both scenarios result in an undefined attribute for the maximum-set, which means that the default AllPermission set ends up being used in both cases. The parser doesn't initialize the attribute with an empty list when the enclosing element is present but is empty. So in the end, both approaches result in an undefined attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6444) Apache http classes not found

by Andrei Ivanov (JIRA)

Andrei Ivanov created WFLY-6444: ----------------------------------- Summary: Apache http classes not found Key: WFLY-6444 URL: https://issues.jboss.org/browse/WFLY-6444 Project: WildFly Issue Type: Bug Affects Versions: 10.0.0.Final, 10.1.0.Final Reporter: Andrei Ivanov Assignee: Jason Greene Attachments: wildfly-httpclient-test.zip Hi, I've created a trivial JAX-RS application with a CDI producer for a RestEasy JAX-RS client proxy. I also need to customize the HTTP engine a bit. The app deploys fine on JBoss 7.1.1. Trying to upgrade to WildFly 10.0, I got a weird error: {noformat} DEBUG [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) Catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error while loading class siteaccess.web.backend.service.RestEasyClientProducer at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:186) at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:194) at org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:113) at org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.createContext(FastAnnotatedTypeLoader.java:102) at org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:91) at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:97) at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:65) at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62) 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) Caused by: java.lang.NoClassDefFoundError: org/apache/http/conn/socket/LayeredConnectionSocketFactory at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getDeclaredConstructors(Class.java:2020) at org.jboss.weld.annotated.slim.backed.SecurityActions.getDeclaredConstructors(SecurityActions.java:57) at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.computeValue(BackedAnnotatedType.java:163) at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.computeValue(BackedAnnotatedType.java:160) at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:35) at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$EagerlyInitializedLazyValueHolder.<init>(BackedAnnotatedType.java:156) at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.<init>(BackedAnnotatedType.java:160) at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.<init>(BackedAnnotatedType.java:160) at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.<init>(BackedAnnotatedType.java:61) at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.of(BackedAnnotatedType.java:44) at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:83) at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:80) at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527) at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2319) at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2282) at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2197) at com.google.common.cache.LocalCache.get(LocalCache.java:3937) at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941) at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824) at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49) at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74) at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:175) ... 14 more Caused by: java.lang.ClassNotFoundException: org.apache.http.conn.socket.LayeredConnectionSocketFactory from [Module "deployment.wildfly-httpclient-test.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 38 more {noformat} I've upgraded Weld to 2.3.3 and the http client jars to the latest versions (using details from https://developer.jboss.org/thread/242798). Now I get the exception for a different class: {noformat} Caused by: java.lang.ClassNotFoundException: org.apache.http.protocol.HttpContext from [Module "deployment.wildfly-httpclient-test.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) ... 38 more {noformat} I'm getting this exception also when testing with an unmodified WildFly 10.1 snapshot ( Build #2244 (Mar 24, 2016 1:10:44 PM) from https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/) I've first asked for help on the [forum|https://developer.jboss.org/thread/268871], but got no answers :( -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on JBEE-161: ----------------------------------- released jboss-el-api_2.2_spec-1.0.6.Final > BeanELResolver does not support methods that use varargs > -------------------------------------------------------- > > Key: JBEE-161 > URL: https://issues.jboss.org/browse/JBEE-161 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-el-api > Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1 > Reporter: Ingo Weiss > Assignee: Scott Marlow > Labels: el > Fix For: jboss-el-api_3.0_spec-1.0.6.Final > > Attachments: beanELResolver4VarArgs.zip > > > When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception: > {code} > java.lang.IllegalArgumentException: wrong number of arguments > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834) > at javax.el.BeanELResolver.invoke(BeanELResolver.java:527) > at org.apache.el.parser.AstValue.getValue(AstValue.java:156) > at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32) > at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on JBEE-161: ---------------------------------------------- Dmitrii Tikhomirov <dtikhomi(a)redhat.com> changed the Status of [bug 1292891|https://bugzilla.redhat.com/show_bug.cgi?id=1292891] from POST to MODIFIED > BeanELResolver does not support methods that use varargs > -------------------------------------------------------- > > Key: JBEE-161 > URL: https://issues.jboss.org/browse/JBEE-161 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-el-api > Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1 > Reporter: Ingo Weiss > Assignee: Scott Marlow > Labels: el > Fix For: jboss-el-api_3.0_spec-1.0.6.Final > > Attachments: beanELResolver4VarArgs.zip > > > When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception: > {code} > java.lang.IllegalArgumentException: wrong number of arguments > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834) > at javax.el.BeanELResolver.invoke(BeanELResolver.java:527) > at org.apache.el.parser.AstValue.getValue(AstValue.java:156) > at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32) > at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6443) Inconsistent behavior of journal object store for heuristic state

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-6443: ----------------------------------- Summary: Inconsistent behavior of journal object store for heuristic state Key: WFLY-6443 URL: https://issues.jboss.org/browse/WFLY-6443 Project: WildFly Issue Type: Bug Components: Transactions Reporter: Tom Jenkinson Assignee: Michael Musgrove Priority: Blocker Fix For: 10.1.0.Final We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. Our test case: * enlist activemq JMS resource * enlist test XA resource * prepare JMS resource * prepare test XA resource * commit JMS resource * commit test XA resource ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}} * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} ** expecting one indoubt participant in HEURISTIC state * calling operation {{recovery}} on all transaction's participants * do recovery This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016