September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5261) Can't reload server when JTS transactions are used

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka reassigned WFLY-5261: -------------------------------------- Assignee: Tomasz Adamski (was: Tom Jenkinson) > Can't reload server when JTS transactions are used > -------------------------------------------------- > > Key: WFLY-5261 > URL: https://issues.jboss.org/browse/WFLY-5261 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ondřej Chaloupka > Assignee: Tomasz Adamski > Priority: Critical > > It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown. > [1] > {code} > WARN [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException > at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329) > at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889) > at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678) > at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687) > at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60) > at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142) > at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353) > at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196) > at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141) > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5261) Can't reload server when JTS transactions are used

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka updated WFLY-5261: ----------------------------------- Component/s: IIOP > Can't reload server when JTS transactions are used > -------------------------------------------------- > > Key: WFLY-5261 > URL: https://issues.jboss.org/browse/WFLY-5261 > Project: WildFly > Issue Type: Bug > Components: IIOP, Transactions > Reporter: Ondřej Chaloupka > Assignee: Tomasz Adamski > Priority: Critical > > It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown. > [1] > {code} > WARN [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException > at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329) > at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889) > at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678) > at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687) > at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60) > at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142) > at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353) > at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196) > at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141) > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5020) Server fails to start with transactions configured to be run with JDBCObject store

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-5020: ------------------------------------- Hi Stefano, now that JBJCA-1291 is ready please can you raise the PR for this one from your branch? > Server fails to start with transactions configured to be run with JDBCObject store > ---------------------------------------------------------------------------------- > > Key: WFLY-5020 > URL: https://issues.jboss.org/browse/WFLY-5020 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Hayk Hovsepyan > Assignee: Stefano Maestri > Fix For: 10.0.0.CR1 > > > When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below. > Error message: > {code} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store] > {code} > Datasource configuration is: > {code} > <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true"> > <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url> > <driver>sqljdbc4.jar</driver> > <security> > <user-name>username1</user-name> > <password>password1</password> > </security> > </datasource> > {code} > and the transaction config looks like this > {code} > <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-944?page=com.atlassian.jira.plugin... ] Darran Lofthouse moved WFLY-5259 to WFCORE-944: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-944 (was: WFLY-5259) Component/s: Security (was: Security) Affects Version/s: (was: 9.0.1.Final) > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFCORE-944 > URL: https://issues.jboss.org/browse/WFCORE-944 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Arto Huusko > Assignee: Darran Lofthouse > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5259) truststore path is ignored if provider is not JKS

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-5259?page=com.atlassian.jira.plugin.... ] Thomas Diesler updated WFLY-5259: --------------------------------- Component/s: (was: ConfigAdmin) > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFLY-5259 > URL: https://issues.jboss.org/browse/WFLY-5259 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 9.0.1.Final > Reporter: Arto Huusko > Assignee: Thomas Diesler > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5259) truststore path is ignored if provider is not JKS

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-5259?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-5259: ------------------------------------ Assignee: Darran Lofthouse (was: Thomas Diesler) > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFLY-5259 > URL: https://issues.jboss.org/browse/WFLY-5259 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 9.0.1.Final > Reporter: Arto Huusko > Assignee: Darran Lofthouse > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5076) Enhance testsuite with WS-Trust/STS tests

by Jan Blizňák (JIRA)

[ https://issues.jboss.org/browse/WFLY-5076?page=com.atlassian.jira.plugin.... ] Jan Blizňák updated WFLY-5076: ------------------------------ Fix Version/s: 10.0.0.CR1 > Enhance testsuite with WS-Trust/STS tests > ----------------------------------------- > > Key: WFLY-5076 > URL: https://issues.jboss.org/browse/WFLY-5076 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Jan Blizňák > Assignee: Jan Blizňák > Fix For: 10.0.0.CR1 > > > Port WS-Trust tests from JBossWS testsuite, try to reuse as much as possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1959) TCPPING: initial_hosts are not read in the order in which they're listed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1959?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1959. ---------------------------- Resolution: Done > TCPPING: initial_hosts are not read in the order in which they're listed > ------------------------------------------------------------------------ > > Key: JGRP-1959 > URL: https://issues.jboss.org/browse/JGRP-1959 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.5 > > > {{TCPPING}} doesn't contact the members listed in {{initial_hosts}} in the order in which they are defined. A user might list them in decreasing order of availability, so this is not optimal. > The reason is that we add {{initial_hosts}} and {{dynamic_hosts}} into a *hashset*, which causes reordering. > SOLUTION: use an ArrayList and add a presence check. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-897) Binding variable or condition

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-897?page=com.atlassian.jira.plugin... ] Mario Fusco commented on DROOLS-897: ------------------------------------ I thought that we agreed that none of the solutions you suggested was doable and I tried to explain why. The only solution that I see in your case is refactoring your domain model as I suggested above. > Binding variable or condition > ----------------------------- > > Key: DROOLS-897 > URL: https://issues.jboss.org/browse/DROOLS-897 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final > Environment: Windows 8 > Reporter: Sante Stanisci > Assignee: Mario Fusco > Labels: dynamic, instanciation, variable > Fix For: 6.3.0.Final > > Attachments: rule.drl, workaround.drl > > > In this example I have more classes that extends EntityBase (my class). In my intention, i would assign to variable $entity one of this class that is inserted in Ksession fact. > I insert fact of CtbMovrCoan class > In when statement of the rule at row 16, variable $entity is correctely, > but in then statement variable $entity becomes JtbRLavt class (first declared in then cond) and this behavior throw a ClassCastException, obviously. > Can Help me? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1959) TCPPING: initial_hosts are not read in the order in which they're listed

by Bela Ban (JIRA)

Bela Ban created JGRP-1959: ------------------------------ Summary: TCPPING: initial_hosts are not read in the order in which they're listed Key: JGRP-1959 URL: https://issues.jboss.org/browse/JGRP-1959 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.6.5 {{TCPPING}} doesn't contact the members listed in {{initial_hosts}} in the order in which they are defined. A user might list them in decreasing order of availability, so this is not optimal. The reason is that we add {{initial_hosts}} and {{dynamic_hosts}} into a *hashset*, which causes reordering. SOLUTION: use an ArrayList and add a presence check. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

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