[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