[JBoss JIRA] (WFLY-5564) Unable to set use-journal-store if use-jdbc-store was set to true before
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5564?page=com.atlassian.jira.plugin.... ]
Tomas Hofman commented on WFLY-5564:
------------------------------------
In addition to the problem described in "Steps to Reproduce", there is another problem, allowing user to set USE_JDBC_STORE without setting JDBC_STORE_DATASOURCE which results in failures during restart.
I'm solving both problems in this issue, because they are related. Test cases for both problems will be provided.
See linked JBEAP issue for more details.
> Unable to set use-journal-store if use-jdbc-store was set to true before
> ------------------------------------------------------------------------
>
> Key: WFLY-5564
> URL: https://issues.jboss.org/browse/WFLY-5564
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR3
> Environment: EAP 7.0.0.DR11
> Reporter: Jan Kašík
> Assignee: Tomas Hofman
>
> It is impossible to set use-journal-store or use-jdbc-store after other was set. The other has to have its default value, although setting it back to its default value won't help.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5564) Unable to set use-journal-store if use-jdbc-store was set to true before
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5564?page=com.atlassian.jira.plugin.... ]
Tomas Hofman moved HAL-883 to WFLY-5564:
----------------------------------------
Project: WildFly (was: HAL)
Key: WFLY-5564 (was: HAL-883)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Transactions
(was: Subsystem Configuration)
Affects Version/s: 10.0.0.CR3
(was: 2.8.11)
> Unable to set use-journal-store if use-jdbc-store was set to true before
> ------------------------------------------------------------------------
>
> Key: WFLY-5564
> URL: https://issues.jboss.org/browse/WFLY-5564
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR3
> Environment: EAP 7.0.0.DR11
> Reporter: Jan Kašík
> Assignee: Tomas Hofman
>
> It is impossible to set use-journal-store or use-jdbc-store after other was set. The other has to have its default value, although setting it back to its default value won't help.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5166) LookupTestCase can not create session factory with secman
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5166?page=com.atlassian.jira.plugin.... ]
Ivo Studensky reassigned WFLY-5166:
-----------------------------------
Assignee: Ivo Studensky (was: Ondřej Chaloupka)
> LookupTestCase can not create session factory with secman
> ---------------------------------------------------------
>
> Key: WFLY-5166
> URL: https://issues.jboss.org/browse/WFLY-5166
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Ivo Studensky
>
> *Description of problem:*
> org.jboss.as.test.integration.ee.remotelookup.LookupTestCase can not create session factory with secman. Test runs in "basic-integration-default-full.surefire" execution of basic profile.
> *How reproducible:*
> Always with security manager
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dtest=LookupTestCase -Dsecurity.manager -Dts.basic
> *Actual results:*
> {noformat}
> javax.jms.JMSException: Failed to create session factory
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:921)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:726)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:170)
> at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.lookupConnectionFactory(LookupTestCase.java:81)
> at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.testServerLocalLookup(LookupTestCase.java:66)
> {noformat}
> *Expected results:*
> No errors on output
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5532) LinkageError when loading CXF NamespaceHandler
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5532?page=com.atlassian.jira.plugin.... ]
Thomas Diesler closed WFLY-5532.
--------------------------------
Resolution: Done
Done
> LinkageError when loading CXF NamespaceHandler
> ----------------------------------------------
>
> Key: WFLY-5532
> URL: https://issues.jboss.org/browse/WFLY-5532
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 10.0.0.CR2
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 10.0.0.CR4
>
>
> {code}
> Caused by: java.lang.LinkageError: Failed to link org/apache/cxf/configuration/spring/AbstractBeanDefinitionParser (Module "org.apache.cxf:main" from local module loader @24b1d79b (finder: local module finder @68ceda24 (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/basic/target/wildfly-10.0.0.CR2/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/basic/target/wildfly-10.0.0.CR2/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/basic/target/wildfly-10.0.0.CR2/modules/system/layers/base)))
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:269)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77)
> at org.jboss.modules.Module.loadModuleClass(Module.java:560)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:353)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:432)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:269)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77)
> at org.jboss.modules.Module.loadModuleClass(Module.java:560)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:353)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:432)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:269)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77)
> at org.jboss.modules.Module.loadModuleClass(Module.java:560)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> at org.apache.camel.component.cxf.spring.NamespaceHandler.init(NamespaceHandler.java:25)
> at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.resolve(DefaultNamespaceHandlerResolver.java:131)
> ... 19 more
> Caused by: java.lang.NoClassDefFoundError: org/springframework/beans/factory/xml/AbstractSingleBeanDefinitionParser
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:353)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:432)
> ... 53 more
> Caused by: java.lang.ClassNotFoundException: org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser from [Module "org.apache.cxf:main" from local module loader @24b1d79b (finder: local module finder @68ceda24 (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/basic/target/wildfly-10.0.0.CR2/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/basic/target/wildfly-10.0.0.CR2/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/basic/target/wildfly-10.0.0.CR2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 57 more
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/902
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (JGRP-1970) UDP: use MulticastSocket to send messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1970?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1970:
---------------------------
Fix Version/s: 3.6.7
> UDP: use MulticastSocket to send messages
> -----------------------------------------
>
> Key: JGRP-1970
> URL: https://issues.jboss.org/browse/JGRP-1970
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Currently, due to [1], we use a {{MulticastSocket}} to _receive_ multicast packets, but a {{DatagramSocket}} to _send_ multicast packets (and send and receive unicast packets).
> The reason was that we needed to get the IP address and port of the sender of a message. Due to a programming error, this was not the case earlier.
> Now, I changed the code to use a {{MulticastSocket}} instead of a {{DatagramSocket}} to send multicasts (and send/receive unicasts).
> Works perfectly and performance (4 nodes) is about the same.
> In addition, we can now call {{MulticastSocket.setTimeToLive()}}, even on Windows, preventing the exception trying to set {{ip_ttl}} on Windows (java.net.DualStackPlainDatagramSocketImpl.setTimeToLive()).
> [1] https://issues.jboss.org/browse/JGRP-1765
> [2] https://github.com/belaban/JGroups/wiki/FAQ
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (JGRP-1970) UDP: use MulticastSocket to send messages
by Bela Ban (JIRA)
Bela Ban created JGRP-1970:
------------------------------
Summary: UDP: use MulticastSocket to send messages
Key: JGRP-1970
URL: https://issues.jboss.org/browse/JGRP-1970
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Currently, due to [1], we use a {{MulticastSocket}} to _receive_ multicast packets, but a {{DatagramSocket}} to _send_ multicast packets (and send and receive unicast packets).
The reason was that we needed to get the IP address and port of the sender of a message. Due to a programming error, this was not the case earlier.
Now, I changed the code to use a {{MulticastSocket}} instead of a {{DatagramSocket}} to send multicasts (and send/receive unicasts).
Works perfectly and performance (4 nodes) is about the same.
In addition, we can now call {{MulticastSocket.setTimeToLive()}}, even on Windows, preventing the exception trying to set {{ip_ttl}} on Windows (java.net.DualStackPlainDatagramSocketImpl.setTimeToLive()).
[1] https://issues.jboss.org/browse/JGRP-1765
[2] https://github.com/belaban/JGroups/wiki/FAQ
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5412) IIOP migrate operation missing warning if on/off elements are in default (deactivated) state
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5412?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5412:
----------------------------------------
Ok, I see. Thank you for explanation. Taken this in account I'm going to reject this issue as it's not an issue :)
> IIOP migrate operation missing warning if on/off elements are in default (deactivated) state
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5412
> URL: https://issues.jboss.org/browse/WFLY-5412
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Tomasz Adamski
>
> I've mentioned that I'm missing migrate warnings for {{jacorb}} subsystem when values are in default (deactivated state). E.g. this configuration won't show any migration warning despite it should as non-supported values are used
> {code}
> <subsystem xmlns="urn:jboss:domain:jacorb:2.0">
> <orb cache-poa-names="off" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
> <initializers security="identity" transactions="spec"/>
> </orb>
> <poa monitoring="off"/>
> <interop sun="on" chunk-custom-rmi-valuetypes="off"/>
> </subsystem>
> {code}
> if e.g. I set {{monitoring="on"}} then the warning is shown.
> *Additionally*
> there seems to be mistake for {{sun}} property because setting {{sun="off"}} will case that warning will be shown in this way
> {code}
> "WFLYORB0132: Properties [monitoring] cannot be emulated using OpenJDK ORB and are not supported"
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5412) IIOP migrate operation missing warning if on/off elements are in default (deactivated) state
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5412?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka closed WFLY-5412.
----------------------------------
Resolution: Rejected
> IIOP migrate operation missing warning if on/off elements are in default (deactivated) state
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5412
> URL: https://issues.jboss.org/browse/WFLY-5412
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Tomasz Adamski
>
> I've mentioned that I'm missing migrate warnings for {{jacorb}} subsystem when values are in default (deactivated state). E.g. this configuration won't show any migration warning despite it should as non-supported values are used
> {code}
> <subsystem xmlns="urn:jboss:domain:jacorb:2.0">
> <orb cache-poa-names="off" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
> <initializers security="identity" transactions="spec"/>
> </orb>
> <poa monitoring="off"/>
> <interop sun="on" chunk-custom-rmi-valuetypes="off"/>
> </subsystem>
> {code}
> if e.g. I set {{monitoring="on"}} then the warning is shown.
> *Additionally*
> there seems to be mistake for {{sun}} property because setting {{sun="off"}} will case that warning will be shown in this way
> {code}
> "WFLYORB0132: Properties [monitoring] cannot be emulated using OpenJDK ORB and are not supported"
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5563) Login Module changes via CLI not getting reflected without jboss restart
by J Prasanna Venkatesan (JIRA)
J Prasanna Venkatesan created WFLY-5563:
-------------------------------------------
Summary: Login Module changes via CLI not getting reflected without jboss restart
Key: WFLY-5563
URL: https://issues.jboss.org/browse/WFLY-5563
Project: WildFly
Issue Type: Bug
Components: CLI
Reporter: J Prasanna Venkatesan
Assignee: Alexey Loubyansky
Priority: Critical
I am running few login module related commands through cli add() .
It is successfully added in standalone-full.xml. But this is not getting reflected without jboss restart.
I tried adding {allow-resource-service-restart=true} at the end of the command. But no luck.
I tried to reload using 'reload' command, but I am getting the following exception and the whole application goes down :-(
Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:9990. The connection failed
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:117)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
... 13 more
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:319)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:78)
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:109)
... 23 more
I like to see the changes getting reflected without jboss restart.
Am I doing something wrong? Please give me some solution or alternatives.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months