[jboss-jira] [JBoss JIRA] (JGRP-1613) FORK: cactus stacks
Bela Ban (JIRA)
jira-events at lists.jboss.org
Wed Aug 14 05:23:26 EDT 2013
[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796694#comment-12796694 ]
Bela Ban commented on JGRP-1613:
--------------------------------
I opted for configuring the fork-stacks by use of an external XML file (config=/home/bela/fork-stacks.xml) because:
* At the time of parsing the XML, FORK isn't yet created, so FORK won't be able to parse the XML
* We'd have to save the XML Element and pass it to FORK after it's been created, this is not nice IMO
* FORK would also have to provide the schema for the DOM element subtree
* Other systems consuming JGroups, e.g. Wildfly (AS8) would have to introduce a special fork element
> FORK: cactus stacks
> -------------------
>
> Key: JGRP-1613
> URL: https://issues.jboss.org/browse/JGRP-1613
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack.
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.
--
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
More information about the jboss-jira
mailing list