July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6842) Impossible to read/configure messaging provider journal directory path

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6842?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski reassigned WFLY-6842: ---------------------------------------- Assignee: Michal Petrov (was: Bartosz Baranowski) > Impossible to read/configure messaging provider journal directory path > ---------------------------------------------------------------------- > > Key: WFLY-6842 > URL: https://issues.jboss.org/browse/WFLY-6842 > Project: WildFly > Issue Type: Bug > Reporter: Bartosz Baranowski > Assignee: Michal Petrov > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6842) Impossible to read/configure messaging provider journal directory path

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFLY-6842: ---------------------------------------- Summary: Impossible to read/configure messaging provider journal directory path Key: WFLY-6842 URL: https://issues.jboss.org/browse/WFLY-6842 Project: WildFly Issue Type: Bug Reporter: Bartosz Baranowski Assignee: Jason Greene Priority: Critical -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2090: --------------------------- Fix Version/s: 3.6.11 4.0 > JGRP000027: failed passing message up > ------------------------------------- > > Key: JGRP-2090 > URL: https://issues.jboss.org/browse/JGRP-2090 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Will Wright > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > > The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header. > The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine. > java.lang.NullPointerException: null > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872) > 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] (WFLY-6726) Add help text about jboss.undefinded.host for the wsdl-host attribute

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFLY-6726?page=com.atlassian.jira.plugin.... ] Claudio Miranda updated WFLY-6726: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9047 > Add help text about jboss.undefinded.host for the wsdl-host attribute > --------------------------------------------------------------------- > > Key: WFLY-6726 > URL: https://issues.jboss.org/browse/WFLY-6726 > Project: WildFly > Issue Type: Enhancement > Components: Web Services > Reporter: Claudio Miranda > Assignee: Alessio Soldano > > would be doable to add the text to the > resource-description of wsdl-url, related to the use of > jboss.undefined.host ? > The path > /deployment=*/subsystem=webservices/endpoint=*:read-resource-description > I ask that because HAL consumes and exposes the resource-description > of each attribute and having the help text about the > jboss.undefined.host in wsdl-host also helps CLI users. > A suggestion for the text: > "Webservice endpoint WSDL URL. If wsdl-host is set to > jbossws.undefined.host, Wildfly uses the requester's host when > rewriting the <soap:address>" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6841) Add backup service support for singleton services

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6841?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6841: ------------------------------- Description: Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. (was: Currently, singleton services are started on the primary node only - no service is started on the backup node. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.) > Add backup service support for singleton services > ------------------------------------------------- > > Key: WFLY-6841 > URL: https://issues.jboss.org/browse/WFLY-6841 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-314) FormAuthenticator duplicates original request GET parameters

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-314?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBWEB-314: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1302434, https://bugzilla.redhat.com/show_bug.cgi?id=1357678 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1302434) > FormAuthenticator duplicates original request GET parameters > ------------------------------------------------------------ > > Key: JBWEB-314 > URL: https://issues.jboss.org/browse/JBWEB-314 > Project: JBoss Web > Issue Type: Bug > Reporter: Dominik Pospisil > Assignee: Remy Maucherat > Attachments: FormAuthenticator.diff > > > The FormAuthenticator duplicates original request GET parameters. This is a regression since rev. 2320. > The FormAuth does saved.addParameter(name, val) which results in parameter value stored twice. > request.getParameter(String name) retutns the original value which is fine > but request.getParameterValues(String name) returns String[] {val,val} incorrectly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6841) Add backup service support for singleton services

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-6841: ---------------------------------- Summary: Add backup service support for singleton services Key: WFLY-6841 URL: https://issues.jboss.org/browse/WFLY-6841 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 Currently, singleton services are started on the primary node only - no service is started on the backup node. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

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

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-405?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-405: -------------------------------- objectClasses and attributes usable for this: * inetOrgPerson ** certificate - X.509 certificate of user ** userSMIMECertificate - PKCS#7 certificate chain (.p7b) ** userPKCS12 - PKCS#12 keypair (certificate+encrypted private key) > 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 > Assignee: Jan Kalina > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1069) UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple

by Anantjot Anand (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1069?page=com.atlassian.jira.plugi... ] Anantjot Anand commented on DROOLS-1069: ---------------------------------------- Mario, I don't have reproducer for it. This happen during muti-threaded evaluation where each evaluation was using it own ksession and RHS has initiated retarct of a Object from WM. > UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple > ---------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1069 > URL: https://issues.jboss.org/browse/DROOLS-1069 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final > Reporter: Anantjot Anand > Assignee: Mario Fusco > > BaseLeftTuple class is inherited by EvalNodeLeftTuple, FromNodeLeftTuple, JoinNodeLeftTuple, LeftTupleImpl, NotNodeLeftTuple, QueryElementNodeLeftTuple, QueryRiaFixerNodeLeftTuple, RuleTerminalNodeLeftTuple classes. > FromNodeLeftTuple, JoinNodeLeftTuple, QueryElementNodeLeftTuple, QueryRiaFixerNodeLeftTuple and RuleTerminalNodeLeftTuple doesn’t implement its overridden methods. > at org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535) > at org.drools.core.phreak.PhreakExistsNode.doLeftDeletes(PhreakExistsNode.java:425) > at org.drools.core.phreak.PhreakExistsNode.doNode(PhreakExistsNode.java:53) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:560) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536) > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292) > 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.wellsfargo.ARGenT.Execution.RuleBase.processDataWithRules(RuleBase.java:1618) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6782) Unable to add JGroups protocol at a given index via CLI

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6782?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-6782: -------------------------------------- I agree above/below-protocol (before/after would be a bit more vague as it's not clear in which representation; above/below is more suited with jgroups terminology) would improve :add command usability, although I don't think it would justify the effort unless there is an explicit request for it. Surely you could open a Jira with PM. Moreover, in jgroups its possible to have the same protocol multiple times which would defeat the purpose completely (although, this is not allowed in wildfly iiuc). Also note that the "add-index" attribute is a generic concept for ordered children resource, not a jgroups subsystem specific one, although, it's the only usage of it at the moment. > Unable to add JGroups protocol at a given index via CLI > ------------------------------------------------------- > > Key: WFLY-6782 > URL: https://issues.jboss.org/browse/WFLY-6782 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 10.1.0.Final > > > Unable to use this via CLI, tests pass since they use management client which won't check against the operation description: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add(add-index=4) > 'add-index' is not found among the supported properties: [socket-binding, module, properties, type] > {noformat} > add index is missing in the description, after the fix: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=MPING:read-operation-description(name=add > { > "outcome" => "success", > "result" => { > "operation-name" => "add", > "description" => "Add a protocol to a protocol stack.", > "request-properties" => { > "add-index" => { > "type" => INT, > "description" => "If specified inserts the protocol at the given (zero-based) index. If null it will add at the end.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true > }, > {noformat} -- 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