[jboss-jira] [JBoss JIRA] (JGRP-2000) Output of ProtocolStack.printProtocolSpecAsXML() cannot be used as a protocol stack without manual modifications
Jim Thomas (JIRA)
issues at jboss.org
Tue Jan 5 13:16:00 EST 2016
[ https://issues.jboss.org/browse/JGRP-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145165#comment-13145165 ]
Jim Thomas commented on JGRP-2000:
----------------------------------
I ended up switching to using property variables so I could use the same hand-built file on all members, so no big deal if you don't get to it any time soon (or at all). I probably should have figured that out a long time ago instead of going to programmatic in the first place.
I think you can use props.getClass().getName() instead of props.getName() and then strip off a leading "org.jgroups.protocols." if present to keep it looking clean. It will also add clarity if the user is using custom protocols. The other thing I noticed is that it wrote this under GMS:
membership_change_policy="org.jgroups.protocols.pbcast.GMS$DefaultMembershipPolicy at 47c89ac"
which might cause an error as well but I never got that far.
> Output of ProtocolStack.printProtocolSpecAsXML() cannot be used as a protocol stack without manual modifications
> ----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2000
> URL: https://issues.jboss.org/browse/JGRP-2000
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Reporter: Jim Thomas
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> The output of printProtocolSpecAsXML does not contain the pbcast package prefix for NACKACK2, GMS, STATE, etc. so the load fails due to class load failure.
> Suggest either add org.jgroups.protocols.pbcast to the protocol loading search or write protocol names with full classpath when printing the spec.
> Might it also make sense to skip writing out deprecated parameters?
> Reason: I'm generating my protocol stack programmatically because some of the parameter values are determined at run time. In order to facilitate some experimentation with timeouts/retries/etc. I decided to temporarily use an xml file which I first generate by writing out the stack to an xml file which we can tweak the settings for subsequent runs. Since every member has a unique protocol stack keeping the edits to a minimum is helpful. (Maybe using property variables would be a better approach for me?)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the jboss-jira
mailing list