January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1191) Vault usage in a master-slave setup in AS7/EAP6

by Lami Akagwu (JIRA)

[ https://issues.jboss.org/browse/WFLY-1191?page=com.atlassian.jira.plugin.... ] Lami Akagwu commented on WFLY-1191: ----------------------------------- Is this being considered for EAP 7 > Vault usage in a master-slave setup in AS7/EAP6 > ----------------------------------------------- > > Key: WFLY-1191 > URL: https://issues.jboss.org/browse/WFLY-1191 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Hisanobu Okuda > Assignee: Anil Saldanha > > In domain mode, you need to copy over the vault files(keystore, Shared.dat, ENC.dat) to each machine within the domain. This is a very bad solution when your security policy requires password updates frequently. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-406) Add a KeyStore implementation backed by a databse

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-406: ------------------------------------ Summary: Add a KeyStore implementation backed by a databse Key: ELY-406 URL: https://issues.jboss.org/browse/ELY-406 Project: WildFly Elytron Issue Type: Feature Request Components: SSL Reporter: Darran Lofthouse Fix For: 2.0.0.Alpha1 Would suggest ensuring ELY-405 is addressed first as that gives us a pre-existing schema to work with - after that we can apply anything we learned in ELY-405 as the database approach will be much more generic. Also we can compare the features we achieve in ELY-405 and at least match if not exceed them. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-405) Add a KeyStore implementation backed by LDAP

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-405: ------------------------------------ Summary: Add a KeyStore implementation backed by LDAP Key: ELY-405 URL: https://issues.jboss.org/browse/ELY-405 Project: WildFly Elytron Issue Type: Feature Request Components: SSL Reporter: Darran Lofthouse Fix For: 2.0.0.Alpha1 It is possible for private keys, public keys and certificates to all be stored in LDAP - this task is to create a Java KeyStore implementation that can work with this. LDAP most likely will take a reasonable amount of configuration so it may not be possible to be purely provider based and instead this type of KeyStore may need to be manually configured and instantiated. Properties could be passed in using the InputStream to initialise the KeyStore but that doesn't help where we may want to pass in factories for connecting to a remote LDAP server. In addition to the usual keys and certificates the entry types as used for CredentialStore should also be considered. The implementation should also support manipulation of the entries - in this case this may mean immediate updates to the directory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2006) Remove deprecated classes/methods/attributes

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2006?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2006: -------------------------------- * TCP_NIO2 * FD_PING * MERGE2 * UNICAST * UNICAST2 * NAKACK * PEER_LOCK * FC * Shared transport * SCOPE > Remove deprecated classes/methods/attributes > -------------------------------------------- > > Key: JGRP-2006 > URL: https://issues.jboss.org/browse/JGRP-2006 > Project: JGroups > Issue Type: Sub-task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Remove all elements marked with {{@Deprecated}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2645) SFSB containing injected DataSource fails to passivate/serialize

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2645?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2645: ----------------------------------------------- Tomas Hofman <thofman(a)redhat.com> changed the Status of [bug 901300|https://bugzilla.redhat.com/show_bug.cgi?id=901300] from ASSIGNED to POST > SFSB containing injected DataSource fails to passivate/serialize > ---------------------------------------------------------------- > > Key: WFLY-2645 > URL: https://issues.jboss.org/browse/WFLY-2645 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Stefano Maestri > Priority: Critical > > See JBPAPP6-1762 for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2006) Remove deprecated classes/methods/attributes

by Bela Ban (JIRA)

Bela Ban created JGRP-2006: ------------------------------ Summary: Remove deprecated classes/methods/attributes Key: JGRP-2006 URL: https://issues.jboss.org/browse/JGRP-2006 Project: JGroups Issue Type: Sub-task Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Remove all elements marked with {{@Deprecated}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5989) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFLY-5989?page=com.atlassian.jira.plugin.... ] Ondrej Kotek updated WFLY-5989: ------------------------------- Summary: FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager (was: Remoting requires FilePermission for XNIO and marshalling modules to run with security manager) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-5989 > URL: https://issues.jboss.org/browse/WFLY-5989 > Project: WildFly > Issue Type: Bug > Components: Remoting, Security Manager > Affects Versions: 10.0.0.CR5 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > > Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6047) NPE in InfinispanBeanManager.getWeakAffinity in split-brain test case

by Ladislav Thon (JIRA)

Ladislav Thon created WFLY-6047: ----------------------------------- Summary: NPE in InfinispanBeanManager.getWeakAffinity in split-brain test case Key: WFLY-6047 URL: https://issues.jboss.org/browse/WFLY-6047 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Ladislav Thon Assignee: Paul Ferraro In a DIST_SYNC test case involving remote EJBs and split brain ({{eap-7x-failover-ejb-ejbremote-netDown-dist-sync}}), I'm seeing NPEs in {{InfinispanBeanManager.getWeakAffinity}}: {code} 06:10:50,514 ERROR [org.jboss.as.ejb3.remote] (default task-82) WFLYEJB0150: Could not write method invocation failure for method public abstract int org.jboss.test.clusterbench.common.ejb.CommonStatefulSB.getSerialAndIncrement() on bean named RemoteStatefulSBImpl for appname clusterbench-ee7 modulename clusterbench-ee7-ejb distinctname due to: java.lang.NullPointerException at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.getWeakAffinity(InfinispanBeanManager.java:185) at org.jboss.as.ejb3.cache.distributable.DistributableCache.getWeakAffinity(DistributableCache.java:71) at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.getWeakAffinity(MethodInvocationMessageHandler.java:260) at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$500(MethodInvocationMessageHandler.java:68) at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:230) at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:254) at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717) 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} Various weird things are expected during split brain ({{AvailabilityException}}, replication timeouts etc.), but a NPE seems JIRA-worth. Links: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1038) Cann't debug in eclipse

by 李玥 (JIRA)

李玥 created DROOLS-1038: --------------------------- Summary: Cann't debug in eclipse Key: DROOLS-1038 URL: https://issues.jboss.org/browse/DROOLS-1038 Project: Drools Issue Type: Bug Components: eclipse plugin Affects Versions: 6.3.0.Final Reporter: 李玥 Assignee: Robert (Bob) Brodt Priority: Minor Fix For: 6.3.0.Final Hi. I am new to the Drools. I used the Drools eclipse plug-in function. I tried to toggled a break-point in the .drl (the rule file) and tried to run the program as a Drools project. However, I got an error message as following: java.lang.RuntimeException: no debugger registered to handle breakpoint at org.mvel2.debug.DebuggerContext.checkBreak(DebuggerContext.java:98) at org.mvel2.MVELRuntime.execute(MVELRuntime.java:76) at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123) at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119) at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113) at org.mvel2.MVEL.executeExpression(MVEL.java:930) at org.drools.core.util.MVELSafeHelper$RawMVELEvaluator.executeExpression(MVELSafeHelper.java:496) at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:92) at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:77) at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248) at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:204) at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141) at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:374) at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298) at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93) at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289) at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260) at com.sample.DroolsTest.main(DroolsTest.java:24) How could I fix this problem? Thanks! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1980) Improve throughput under contention for FlowControl.Credit

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1980?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1980. ---------------------------- Resolution: Partially Completed Moved a synchronized get() into the if(log.isTraceEnabled()) block. Other than that, I didn't spot any oppurtunities for improvement... Perhaps replace synchronized with ReentrantLock and Object.wait()/notifyAll() with Condition.await()/signalAl()? Googling for the cost of these didn't reveal any insights... Feel free to reopen this issue if we see any real contention in flight recorder. > Improve throughput under contention for FlowControl.Credit > ---------------------------------------------------------- > > Key: JGRP-1980 > URL: https://issues.jboss.org/browse/JGRP-1980 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: Sanne Grinovero > Assignee: Bela Ban > Fix For: 3.6.8 > > Attachments: bla.java > > > The methods {{org.jgroups.protocols.FlowControl.Credit.decrementIfEnoughCredits(long, long)}} and {{org.jgroups.protocols.FlowControl.Credit.decrementAndGet(long)}} are contending the locks on class synchronization when stress testing JGroups. > Wondering if we can think of polishing the implementation, although it looks like challenging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 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 January 2016