November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5615) Secutiry module optioins not parsed

by Heiko Braun (JIRA)

Heiko Braun created WFLY-5615: --------------------------------- Summary: Secutiry module optioins not parsed Key: WFLY-5615 URL: https://issues.jboss.org/browse/WFLY-5615 Project: WildFly Issue Type: Bug Components: Domain Management, Security Affects Versions: 10.0.0.CR4 Reporter: Heiko Braun Assignee: Brian Stansberry Priority: Critical I've created a login module with several options and the result appears in standalone.xml. However when I read the resource using the CLI, these options are not shown. {noformat} <security-domain name="myDomain" cache-type="default"> <authentication> <login-module name="myauth" code="Simple" flag="optional"/> <login-module name="myauth2" code="SimpleUsers" flag="sufficient"> <module-option name="foo" value="bar"/> <module-option name="one" value="two"/> </login-module> </authentication> </security-domain> {noformat} {noformat} [standalone@localhost:9990 /] /subsystem=security/security-domain=myDomain/authentication=classic/login-module=myauth:read-resource(recursive=true) { "outcome" => "success", "result" => { "code" => "Simple", "flag" => "optional", "module" => undefined, "module-options" => undefined } } {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka reassigned WFLY-5413: -------------------------------------- Assignee: Tomasz Adamski (was: Ondřej Chaloupka) > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: Tomasz Adamski > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka commented on WFLY-5413: ---------------------------------------- Sure, agree, no problem. Just I thought that I can fill this jira as a bug per mail conversation for being fixed in WFLY 10. > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: Ondřej Chaloupka > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka updated WFLY-5413: ----------------------------------- Issue Type: Enhancement (was: Bug) > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: Ondřej Chaloupka > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1972) Problem with tcp-cluster in Wildfly 8.2.1.Final

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1972?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-1972. -------------------------- Resolution: Rejected > Problem with tcp-cluster in Wildfly 8.2.1.Final > ----------------------------------------------- > > Key: JGRP-1972 > URL: https://issues.jboss.org/browse/JGRP-1972 > Project: JGroups > Issue Type: Feature Request > Reporter: Manu Forensic > Assignee: Bela Ban > Attachments: server.log, standalone-ha.xml > > > I´ve some problems with a cluster tcp configuration with wildfly 8.2.1.Final. This is my standalone-ha.xml (attached file). > Now when I try to start server in standalone mode: > # ./standalone.sh -c standalone-ha.xml -b 10.10.10.1 & (server.log attached file). > It seems not starting a TCP socket in port 7600: > # netstat -nlpt|grep java > tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN 30348/java > tcp 0 0 10.10.10.1:8009 0.0.0.0:* LISTEN 30348/java > tcp 0 0 10.10.10.1:8080 0.0.0.0:* LISTEN 30348/java > > > However there is multicast in UDP: > > # netstat -nlpu|grep java > udp 0 0 224.0.1.105:23364 0.0.0.0:* 30348/java > Where is the problem? > Thank for your support > Best regards. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1972) Problem with tcp-cluster in Wildfly 8.2.1.Final

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1972?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1972: -------------------------------- I don't think a cluster was started, as this is done just-in-time when (e.g.) a distributable app is deployed. You could use -Djgroups.bind_addr=x.x.x.x to pick an interface to bind to. This is a Wildfly question, not a JGroups question; I suggest ask on the Wildfly mailing list. > Problem with tcp-cluster in Wildfly 8.2.1.Final > ----------------------------------------------- > > Key: JGRP-1972 > URL: https://issues.jboss.org/browse/JGRP-1972 > Project: JGroups > Issue Type: Feature Request > Reporter: Manu Forensic > Assignee: Bela Ban > Attachments: server.log, standalone-ha.xml > > > I´ve some problems with a cluster tcp configuration with wildfly 8.2.1.Final. This is my standalone-ha.xml (attached file). > Now when I try to start server in standalone mode: > # ./standalone.sh -c standalone-ha.xml -b 10.10.10.1 & (server.log attached file). > It seems not starting a TCP socket in port 7600: > # netstat -nlpt|grep java > tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN 30348/java > tcp 0 0 10.10.10.1:8009 0.0.0.0:* LISTEN 30348/java > tcp 0 0 10.10.10.1:8080 0.0.0.0:* LISTEN 30348/java > > > However there is multicast in UDP: > > # netstat -nlpu|grep java > udp 0 0 224.0.1.105:23364 0.0.0.0:* 30348/java > Where is the problem? > Thank for your support > Best regards. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-969) Kie Blueprint integration is not as powerful as the Spring one

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-969: ---------------------------------- Summary: Kie Blueprint integration is not as powerful as the Spring one Key: DROOLS-969 URL: https://issues.jboss.org/browse/DROOLS-969 Project: Drools Issue Type: Enhancement Reporter: Mario Fusco Assignee: Mario Fusco Kie integration seems to be more powerful when using Spring. For example, you can defined KieModule using RelesaeId and you can even enable KieScanner https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.2.x/kie-sprin... This is not possible when using Blueprint https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-arie... The 2 implementations have to be functionally equivalent. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5603) Get data source information

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-5603?page=com.atlassian.jira.plugin.... ] Lin Gao reassigned WFLY-5603: ----------------------------- Assignee: Lin Gao > Get data source information > --------------------------- > > Key: WFLY-5603 > URL: https://issues.jboss.org/browse/WFLY-5603 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Jesper Pedersen > Assignee: Lin Gao > > Create a DMR operation that returns the available properties for the data source class, and xa data source class for the <driver> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-968) Random Nullpointer

by Michal Letynski (JIRA)

Michal Letynski created DROOLS-968: -------------------------------------- Summary: Random Nullpointer Key: DROOLS-968 URL: https://issues.jboss.org/browse/DROOLS-968 Project: Drools Issue Type: Bug Affects Versions: 5.6.0.Final Environment: Windows, Jetty Reporter: Michal Letynski Assignee: Mark Proctor >From time to time i.m getting weird Nullpointer exception. I didn't reproduce the problem when the app is deployed on Glassfish. Only on jetty and only on windows system (with MAC OS everything is ok) Stacktrace: java.lang.NullPointerException at org.drools.base.evaluators.EvaluatorRegistry.addEvaluatorDefinition(EvaluatorRegistry.java:155) at org.drools.base.evaluators.EvaluatorRegistry.<init>(EvaluatorRegistry.java:77) at org.drools.compiler.PackageBuilderConfiguration.buildEvaluatorRegistry(PackageBuilderConfiguration.java:544) at org.drools.compiler.PackageBuilderConfiguration.init(PackageBuilderConfiguration.java:196) at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:170) at org.drools.compiler.PackageBuilder.<init>(PackageBuilder.java:308) at org.drools.compiler.PackageBuilder.<init>(PackageBuilder.java:236) And my code is a simple object creation: PackageBuilder packageBuilder = new PackageBuilder(); Any hint why this might occur ? Or should i just ignore it because on production we have Glassfish server ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ] James Livingston commented on WFLY-5596: ---------------------------------------- In addition, stop() calls deactivate() even when deliveryActive is false, which means activate() may never have been called. > MessageDrivenComponent startDelivery/stopDelivery is not thread safe > -------------------------------------------------------------------- > > Key: WFLY-5596 > URL: https://issues.jboss.org/browse/WFLY-5596 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 10.0.0.CR4 > Reporter: James Livingston > Assignee: Jeff Mesnil > > WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously. > Possible effects include: > * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly > * activate() and deactivate() running in the wrong order if done by separate threads > Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 November 2015