[JBoss JIRA] Created: (JBTM-746) remove config MBean setters
by Jonathan Halliday (JIRA)
remove config MBean setters
---------------------------
Key: JBTM-746
URL: https://jira.jboss.org/browse/JBTM-746
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 4.11.0
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.12.0
The EnvironmentBeanMBean interfaces have both getters and setters. However, most config variables are read at startup and subsequent modifications don't have an effect on the running system. This is confusing for users, who wonder why changes via the MBean don't seem to work. Remove the setters for now, add then back individually as/when we move to supporting dynamic property updates.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBTM-735) provide bean based configuration, part 3
by Jonathan Halliday (JIRA)
provide bean based configuration, part 3
----------------------------------------
Key: JBTM-735
URL: https://jira.jboss.org/jira/browse/JBTM-735
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 4.9.0
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.12.0
Many points in our code read a String property and treat it as a class name to load. Move this functionality to the EnvironmentBeans, so the instantiated class can be retrieved directly. This will reduce classloading duplication and also help with integration to DI frameworks that wish to pass in a pre-instantiated instance of some class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBTM-730) JBossTS embedded tools startup fails on EAP5.0.1 CR1
by Ivo Studensky (JIRA)
JBossTS embedded tools startup fails on EAP5.0.1 CR1
----------------------------------------------------
Key: JBTM-730
URL: https://jira.jboss.org/jira/browse/JBTM-730
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tooling
Affects Versions: 4.6.1.CP04
Environment: EAP5.0.1.CR1
Reporter: Ivo Studensky
In EAP5.0.1.CR1 the embedded tools fails with the error below.
snippet of server.log:
2010-03-12 11:13:00,841 ERROR [STDERR] (Thread-27) java.io.FileNotFoundException: /home/studensky/job/EAP5/5.0.1.cr1/jboss-eap-5.0/jboss-as/server/all/tmp/jboss_tools_tmp/META-INF/MANIFEST.MF (No such file or directory)
2010-03-12 11:13:00,841 ERROR [STDERR] (Thread-27) at java.io.FileOutputStream.open(Native Method)
2010-03-12 11:13:00,841 ERROR [STDERR] (Thread-27) at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
2010-03-12 11:13:00,841 ERROR [STDERR] (Thread-27) at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
2010-03-12 11:13:00,841 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.plugin.ToolPluginInformation.externalizeFile(ToolPluginInformation.java:172)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ToolsClassLoader.processSar(ToolsClassLoader.java:121)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ToolsClassLoader.init(ToolsClassLoader.java:87)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ToolsClassLoader.<init>(ToolsClassLoader.java:68)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ToolsClassLoader.<init>(ToolsClassLoader.java:73)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ArjunaToolsFramework.<init>(ArjunaToolsFramework.java:106)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at org.jboss.jbosstm.tools.embedded.EmbeddedToolsFramework.<init>(EmbeddedToolsFramework.java:37)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at org.jboss.jbosstm.tools.mbean.EmbeddedTools$1.run(EmbeddedTools.java:37)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) Exception in thread "Thread-27"
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) java.lang.RuntimeException: Unable to unpack tools sar: /home/studensky/job/EAP5/5.0.1.cr1/jboss-eap-5.0/jboss-as/server/all/tmp/jboss_tools_tmp/META-INF/MANIFEST.MF (No such file or directory)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ToolsClassLoader.processSar(ToolsClassLoader.java:140)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ToolsClassLoader.init(ToolsClassLoader.java:87)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ToolsClassLoader.<init>(ToolsClassLoader.java:68)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ToolsClassLoader.<init>(ToolsClassLoader.java:73)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at com.arjuna.ats.tools.toolsframework.ArjunaToolsFramework.<init>(ArjunaToolsFramework.java:106)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at org.jboss.jbosstm.tools.embedded.EmbeddedToolsFramework.<init>(EmbeddedToolsFramework.java:37)
2010-03-12 11:13:00,842 ERROR [STDERR] (Thread-27) at org.jboss.jbosstm.tools.mbean.EmbeddedTools$1.run(EmbeddedTools.java:37)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBTM-753) FaultTo ednpoints provided to allow asynchronous soap fault Delivery specify wrong service/endpoint
by Andrew Dinn (JIRA)
FaultTo ednpoints provided to allow asynchronous soap fault Delivery specify wrong service/endpoint
---------------------------------------------------------------------------------------------------
Key: JBTM-753
URL: https://jira.jboss.org/browse/JBTM-753
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: XTS
Affects Versions: 4.11.0
Reporter: Andrew Dinn
Assignee: Andrew Dinn
The move to CXF 2.2.9 has identified a problem with the mechanism used by the WS-T services to deliver asynchronous soap faults. Each (OneWay) service request includes a FaultTo endpoint which addresses to the pair service/port and this endpoint is used to deliver soap faults reporting any problems which may arise after the one way message has been delivered. So, for example when the Participant service running in a transactional web service's container is sent a Prepare request the FaultTo endpoint addresses the Coordinator service running in the JBossTS/XTS coordinator's container.
Soap faults are sent using JaxWS by invoking a proxy cloned from a SoapFaultService instance. All the WS-T endpoints implement the web method declared by this service so they can handle the incoming request. Unfortunately, with CXF 2.2.9 the endpoint now includes metadata identifying the originating service/port used when the endpoint is created. The client validates any proxy create (getPort) request against this metadata. Since the endpoint and create refer to different services getPort fails.
The endpoint should either be created with no metadata or should contain metadata for the SoapFaultService and associated port. It may still be appropriate to address the fault back to the WS-T service or it may be necessary to install a distinct endpoint for a SoapFaultService and have it route faults to the relevant WS-T service. Which of these is necessary depends upon the outcome of a related JBossWS issue addressing this problem from the CXF side (JBWS-3069)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBTM-749) WSTX WSDL should not be using wsa:Action attribute
by Andrew Dinn (JIRA)
WSTX WSDL should not be using wsa:Action attribute
--------------------------------------------------
Key: JBTM-749
URL: https://jira.jboss.org/browse/JBTM-749
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: XTS
Affects Versions: 4.11.0
Reporter: Andrew Dinn
Assignee: Andrew Dinn
Fix For: 4.12.0
The switch over to CXF as the default stack in AS 6 has exposed a problem with the WSTX WSDL files. XTS currently employs the 1.1 WSDL as originally published by OASIS. This WSDL includes wsa:Action attributes in the port type declarations. This causes a problem on CXF 2.2.8 where the Message Addressing Properties (MAP) handler fails to locate the Action attribute installed in response messages -- it does nto check for the 2005/08 wsa space -- and, consequently, runs into a null pointer exception.
The OASIS 1.1. WSDL has been republished (somewhat sneakily) without the Action attributes. This later version should be used. Instead of relying on the wsa:Action attribute the server endpoint implementation classes should employ @Action attributes on the implementation methods to define the input and output Actions associated with the web methods.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months