[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1876:
--------------------------------
{quote}
The question is: It is better to wait a little and process a merge based on MergeInfos coming from all coords or making partial merge and isolate an alive coord from its own cluster.
{quote}
This is an edge case, so IMO it is better to proceed and install a partial merge view. The application can still decide to not act on the view and wait for the next one. As a matter of fact, Infinispan does this.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS commented on JGRP-1876:
------------------------------------
The question is: It is better to wait a little and process a merge based on MergeInfos coming from all coords or making partial merge and isolate an alive coord from its own cluster.
The use case I reported here was caused by a Network interface flapping (UP/DOWN/UP) (concrete and frequent scenario). That problems concerned only one host among a cluster of 200 members but disturbed the entire system.
If your are still skeptical, we can review the condition to skip a merge.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-48) EOFException when address of a mgmt operation is of a bad data type
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-48?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFCORE-48:
--------------------------------------
Assignee: Emmanuel Hugonnet (was: Brian Stansberry)
Emmanuel,
My expectation here is the ModelControllerImpl is assuming the incoming operation has a valid address field (undefined is valid) and the request is blowing up before it ever gets to the point where the OperationContext deals with exceptions.
So the ModelControllerImpl should early on validate the types of the "operation" and "address" fields and return an appropriate OperationResponse if they are invalid.
Before doing that though, it's worthwhile to debug a bit and try and get a sense of why this is resulting in the EOFException. On the server side, I recommend starting with the task inner class doExecute method at AbstractMessageHandler L296. That's where arbitrary uncaught exceptions are supposed to be handled. If that seems to be working ok, then perhaps there's a flaw in the client side.
> EOFException when address of a mgmt operation is of a bad data type
> -------------------------------------------------------------------
>
> Key: WFCORE-48
> URL: https://issues.jboss.org/browse/WFCORE-48
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Emmanuel Hugonnet
>
> (Hopefully this belongs to WildFly Core. If not, please move to WildFly.)
> I'm doing a programmatic invocation of a simple mgmt operation on the root mgmt resource, say e.g. {{:whoami}}. I'm doing this against a freshly built WildFly from master branch (commit {{e2b9ecfb}}) and on the client side, I'm depending on {{org.wildfly.core:wildfly-controller-client:1.0.0.Alpha4}}.
> The code looks like this:
> {code:java}
> ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);
> try {
> ModelNode op = new ModelNode();
> op.get(ClientConstants.OP).set("whoami");
> op.get(ClientConstants.OP_ADDR).set("");
> ModelNode result = client.execute(op);
> System.out.println(result);
> } finally {
> client.close();
> }
> {code}
> This fails with an exception like this:
> {code}
> Exception in thread "main" java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at cz.ladicek.wildfly.ErrorReproducer.main(ErrorReproducer.java:17)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Caused by: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 7 more
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:267)
> at org.jboss.as.protocol.mgmt.ProtocolUtils.expectHeader(ProtocolUtils.java:83)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$1.handleRequest(AbstractModelControllerClient.java:167)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:235)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:113)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:84)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:452)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> However, when I remove the line that sets {{address}} ({{op.get(ClientConstants.OP_ADDR).set("");}}), it works just fine.
> Fine, I made a mistake, but getting an {{EOFException}}? That's hardly an appropriate response. I should get a proper failure ({{"outcome" => "failed"}} etc.).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS edited comment on JGRP-1876 at 1/23/15 9:55 AM:
-------------------------------------------------------------
By Effects, I means consequences.
1/ Yes. But that temporary merge causes member lost, moreover, a coord.
2/ Not just an optimization.
At B's side: It lost its coord A in spite of being available and sending periodically a heartbeat.
In configuration, we added failure detection protocol (FD_ALL), configured "timeout = 3,5 * interval" and added VERIFY_SUSPSECT to be sure that a member is excluded only if it's real dead.
Recently you added to jgroups the ability to implement coord election to avoid coord change and bring more stability to a cluster ([JGRP-592|https://issues.jboss.org/browse/JGRP-592] and [MembershipChangePolicy|http://www.jgroups.org/manual/html/user-advanced.h...]). The case discussed here shows that merge process goes against that policy: coord lost and double coord changes.
was (Author: ammous):
By Effects, I means consequences.
1/ Yes. But that temporary merge causes member lost, moreover, a coord.
2/ Not just an optimization.
At B's side: It lost its coord A in spite of being available and sending periodically a heartbeat.
In configuration, we added failure detection protocol (FD_ALL), configured "timeout = 3,5 * interval" and added VERIFY_SUSPSECT to be sure that a member is excluded only if it's real dead.
Recently you added to jgroups the ability to implement coord election to avoid coord change and bring more stability to a cluster ([JGRP-592|https://issues.jboss.org/browse/JGRP-592] and [MembershipChangePolicy|http://www.jgroups.org/manual/html/user-advanced.h...]). The case discussed here shows that merge process goes counter that policy: coord lost and double coord changes.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS commented on JGRP-1876:
------------------------------------
By Effects, I means consequences.
1/ Yes. But that temporary merge causes member lost, moreover, a coord.
2/ Not just an optimization.
At B's side: It lost its coord A in spite of being available and sending periodically a heartbeat.
In configuration, we added failure detection protocol (FD_ALL), configured "timeout = 3,5 * interval" and added VERIFY_SUSPSECT to be sure that a member is excluded only if it's real dead.
Recently you added to jgroups the ability to implement coord election to avoid coord change and bring more stability to a cluster ([JGRP-592|https://issues.jboss.org/browse/JGRP-592] and [MembershipChangePolicy|http://www.jgroups.org/manual/html/user-advanced.h...]). The case discussed here shows that merge process goes counter that policy: coord lost and double coord changes.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-458) Operations to read attribute group information
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-458?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-458:
---------------------------------------
Assignee: Emmanuel Hugonnet
> Operations to read attribute group information
> ----------------------------------------------
>
> Key: WFCORE-458
> URL: https://issues.jboss.org/browse/WFCORE-458
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> See "Part III Other possible things to do" in http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html, and Heiko Braun's response thereto.
> 1) Add global operation "read-attribute-group(name=<name_of_group>) which functions similarly to read-resource, but only includes in the response those attributes defined as belonging to attribute group "name_of_group".
> Besides, the "name" parameter above, parameters and effect thereof should be consistent with "read-resource", except that any parameters dealing with inclusion of child resources should be excluded.
> 2) Add global operation "read-attribute-group-names()", which will return a ModelType.LIST whose elements are ModelType.STRING, each element being the name of an attribute-group with which an attribute is associated. Any name only appears once, no entry for the null group to which most attributes belong, response is an empty list if no attribute groups are defined.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFCORE-81:
--------------------------------------
Assignee: Emmanuel Hugonnet
Emmanuel,
Could you coordinate with Claudio on this; see if he still plans to work on it, and if not take it on? Thanks.
> Expose address of DC as runtime attributes on the HC
> ----------------------------------------------------
>
> Key: WFCORE-81
> URL: https://issues.jboss.org/browse/WFCORE-81
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Rupp
> Assignee: Emmanuel Hugonnet
> Labels: rhq
>
> Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime.
> 17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined
> [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute
> [17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http port of the DC
> [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well
> [17:04:51] <+bstansberry> yes please
> [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute
> 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address
> [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-499) System properties are broken in domain mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-499?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-499:
---------------------------------------
Assignee: Emmanuel Hugonnet (was: Brian Stansberry)
> System properties are broken in domain mode
> -------------------------------------------
>
> Key: WFCORE-499
> URL: https://issues.jboss.org/browse/WFCORE-499
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha15
> Reporter: Stuart Douglas
> Assignee: Emmanuel Hugonnet
>
> There seems to be some weirdness in how system properties are being propagated to domain mode servers, and in many cases they are not being applied.
> This appears to be an issue with the boot time handling of system properties.
> The only way I could get the property to be applied was to start the server first, then add the property using boot-time=false, although even in this case the property will disappear if the domain is restarted or the server is reloaded.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-519) Xalan Linkage error : TransformerConfigurationException
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-519?page=com.atlassian.jira.plugin... ]
David Lloyd resolved WFCORE-519.
--------------------------------
Fix Version/s: 1.0.0.Alpha16
Resolution: Done
Should be all fixed in the WildFly upstream.
> Xalan Linkage error : TransformerConfigurationException
> -------------------------------------------------------
>
> Key: WFCORE-519
> URL: https://issues.jboss.org/browse/WFCORE-519
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: Wildfly 8.1 & 8.2-Final
> JDK 1.7.0_45 & 1.7.0_71
> Windows & Linux
> Reporter: Stephen Kay
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 1.0.0.Alpha16
>
>
> Please note that this bug wasn't present on JBoss 7.1 / same WAR artifact
> This is full staktrace from our applicaion.
> 11:13:32,130 SEVERE ch.mitsa.credoc.ui.views.messages.MessagesTable (default task-9) Error getting message payload: : javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:765) rt.jar:1.7.0_71
> at _redirected.TransformerFactory.newTransformer(_TransformerFactory.java:132) jboss-modules.jar:1.3.3.Final
> at ch.mitsa.credoc.format.swift.impl.SwiftFormatter.getPrettyPrintedPayload(SwiftFormatter.java:196)
> at ch.mitsa.credoc.engine.service.OutputService.getPrettyPrintedMessage(OutputService.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) rt.jar:1.7.0_71
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) rt.jar:1.7.0_71
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) rt.jar:1.7.0_71
> at java.lang.reflect.Method.invoke(Method.java:606) rt.jar:1.7.0_71
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) wildfly-weld-8.2.0.Final.jar:8.2.0.Final
> (...)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months