[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-2589:
----------------------------------
When doing this when reading the legacy model, it should be done with :read-resource(recursive=true,include-aliases=false,include-defaults=false) so that we don't have defaults in either the directly transformed model or the model built up from the operations.
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-2589:
----------------------------------
In domain mode the defaults are not passed in. For the comparison in the tests, the defaults are nice in a way. Still, we should probably work with what is correct.
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ]
Stefano Maestri resolved WFLY-1569.
-----------------------------------
Resolution: Duplicate Issue
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
> Key: WFLY-1569
> URL: https://issues.jboss.org/browse/WFLY-1569
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
> - <jts/> tag under transactions subsystem
> - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
> at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)
> at org.jacorb.poa.POA.set_servant(POA.java:1979)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)
> ... 5 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2469) Upgrade to HornetQ 2.4.0.CR1
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2469?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-2469:
------------------------------
Comment: was deleted
(was: Jeff Mesnil <jmesnil(a)redhat.com> made a comment on [bug 1029836|https://bugzilla.redhat.com/show_bug.cgi?id=1029836]
Description of problem:
If an error occurs and the JMS bridge tries to reconnect to the JMS provider to look up the JMS resources from its FailureHandler, it fails with the exception:
10:37:02,546 INFO [org.hornetq.jms.server] (pool-3-thread-3) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 1,000 ms
10:37:03,547 WARN [org.hornetq.jms.server] (pool-3-thread-3) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.apache.qpid.jndi.PropertiesFileInitialContextFactory from classloader ModuleClassLoader for Module "org.hornetq:main" from local module loader @ac44b88 (finder: local module finder @5d3ad33d (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
at org.jboss.as.naming.InitialContextFactoryBuilder.createInitialContextFactory(InitialContextFactoryBuilder.java:64)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:681) [rt.jar:1.6.0_24]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305) [rt.jar:1.6.0_24]
at javax.naming.InitialContext.init(InitialContext.java:240) [rt.jar:1.6.0_24]
at javax.naming.InitialContext.<init>(InitialContext.java:214) [rt.jar:1.6.0_24]
at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1222) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1460) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2000(JMSBridgeImpl.java:83) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2049) [hornetq-jms-server.jar:]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
How reproducible:
Always
Steps to Reproduce:
1. run a jms-bridge with a JMS provider loaded from a module
2. disconnect the network to make the jms-bridge fails
3. reconnect the network. The jms-bridge will handle the failure and reconnects to the JMS provider
Actual results:
The jms-bridge FailureHandler is not able to load the JMS provider classes.
Expected results:
The jms-bridge FailureHandler must be able to load the JMS provider classes from the module specified when the jms-bridge is added.)
> Upgrade to HornetQ 2.4.0.CR1
> ----------------------------
>
> Key: WFLY-2469
> URL: https://issues.jboss.org/browse/WFLY-2469
> Project: WildFly
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.CR1
>
>
> HornetQ 2.4.0.CR1 depends on Netty 4.0.x versions that broke compatibility with Netty 3.x
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2590) Zero Timeout Stateful EJB Leak
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-2590:
-------------------------------------
Summary: Zero Timeout Stateful EJB Leak
Key: WFLY-2590
URL: https://issues.jboss.org/browse/WFLY-2590
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: EJB
Reporter: Eduardo Martins
Assignee: Eduardo Martins
Stateful EJB instances are not removed from cache upon release, if the timeout is zero.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-2589 at 11/29/13 2:35 AM:
-------------------------------------------------------------
I remember mentioning that when I refactored the messaging subsystem transformers.
The new attributes that I added were reaching the legacy version with the default value set. At first, I thought about setting include-defaults to false when :read-resource is called by ReadTransformedResourceOperation but changed my mind on further notice.
The resources are resolving every attributes and uses the default value if they are not set. If we do not include the default values when transforming the resources, we let the legacy versions resolve the attribute based on its own default value, not the one from the current version. That could lead to issues if such a value change between versions.
I preferred to handle that explicitly when transforming the resources.
For example, for new attributes, I discard them if they are undefined or set to the default value and reject them if they have any other value.
was (Author: jmesnil):
I remember mentioning that when I refactored the messaging subsystem transformers.
The new attributes that I added were reaching the legacy version with the default value set. At first, I thought about setting include-defaults to false when :read-resource is called by ReadTransformedResourceOperation but changed my mind on further notice.
The resources are resolving every attributes and uses the default value if they are not set. If we do not include the default values when transforming the resources, we let the legacy versions resolve the attribute based on its own default value, not the one from the current version. That could lead to issues if such a value change between versions.
I preferred to handle tha
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-2589:
-----------------------------------
I remember mentioning that when I refactored the messaging subsystem transformers.
The new attributes that I added were reaching the legacy version with the default value set. At first, I thought about setting include-defaults to false when :read-resource is called by ReadTransformedResourceOperation but changed my mind on further notice.
The resources are resolving every attributes and uses the default value if they are not set. If we do not include the default values when transforming the resources, we let the legacy versions resolve the attribute based on its own default value, not the one from the current version. That could lead to issues if such a value change between versions.
I preferred to handle tha
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months