[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1828 at 4/18/14 8:32 AM:
---------------------------------------------------------
Hmm, how do we do the actual parsing ?
XMLConfigurator does the parsing *for the entire XML config*, currently.
We'd have to provide hooks for a protocol do do part of this parsing on its own. E.g. after all attributes of a given protocol have been parsed, we look for children nodes. If there are any, we delegate parsing of this subtree to the protocol.
The FORK protocol already parses from an input stream, and we could simply add a second parse() method which accepts the DOM subtree (node). The default {{Protocol.parse(Element)}} method would be a no-op.
was (Author: belaban):
Hmm, how do we do the actual parsing ? XMLConfigurator does the parsing for the entire XML config, currently. We'd have to provide hooks for a protocol do do part of this parsing on its own. E.g if the default parse encounters an element it doesn't know, it could delagate parsing of this to the protocol.
The FORK protocol already parses from an input stream, and we could simply add a second parse() method which accepts a root DOM element. The default {{Protocol.parse(Element)}} method would be a no-op.
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1828:
--------------------------------
Hmm, how do we do the actual parsing ? XMLConfigurator does the parsing for the entire XML config, currently. We'd have to provide hooks for a protocol do do part of this parsing on its own. E.g if the default parse encounters an element it doesn't know, it could delagate parsing of this to the protocol.
The FORK protocol already parses from an input stream, and we could simply add a second parse() method which accepts a root DOM element. The default {{Protocol.parse(Element)}} method would be a no-op.
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1828 at 4/18/14 8:03 AM:
---------------------------------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
was (Author: belaban):
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1828 at 4/18/14 8:04 AM:
---------------------------------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code:xml}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code}
was (Author: belaban):
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1828 at 4/18/14 8:03 AM:
---------------------------------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
was (Author: belaban):
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1828:
--------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1828 at 4/18/14 8:01 AM:
---------------------------------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
was (Author: belaban):
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1827) Forked channel requires udp.xml file
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1827?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1827 at 4/18/14 7:21 AM:
---------------------------------------------------------
I'll take another look. Do you have a small sample program that shows the behavior ? I can't correlate your stack trace to the src as this is your port to Android to which I don't have the src code...
I'll also need the XML config plus the config of the fork stacks. I hope you don't still have the fork stack config inline...
was (Author: belaban):
I'll take another look. Do you have a small sample program that shows the behavior ? I can't correlate your stack trace to the src as this is your port to Android to which I don't have the src code...
> Forked channel requires udp.xml file
> ------------------------------------
>
> Key: JGRP-1827
> URL: https://issues.jboss.org/browse/JGRP-1827
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Environment: Android
> Reporter: Jim Thomas
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.4, 3.5
>
> Attachments: bla2.java, fork-stacks.xml, main.xml
>
>
> An exception is thrown when creating a fork channel if the stack file name is something other than udp.xml (in my case main.xml):
> final JChannel mainChannel = new JChannel("main.xml");
> final ForkChannel mbChannel = new ForkChannel(mainChannel,
> "main", "fork-mb");
> 4-09 17:33:38.270: W/System.err(5478): java.io.FileNotFoundException: JGRP000003: file "udp.xml" not found
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorFactory.java:211)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:102)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.JChannel.<init>(JChannel.java:172)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.JChannel.<init>(JChannel.java:123)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:75)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:118)
> 04-09 17:33:38.270: W/System.err(5478): at com.novawurks.jgroupstest.JGroupsTestActivity$JGroupsSetupThread.run(JGroupsTestActivity.java:119)
> If I have the stack named udp.xml then the exception is not thrown and everything works as expected. If I make a copy of main.xml named udp.xml (so both files are present) the exception is not thrown and everything works as expected.
> Contents of main.xml / udp.xml :
> {code:xml}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd" >
> <UDP
> enable_diagnostics="true"
> ip_mcast="true"
> ip_ttl="${jgroups.udp.ip_ttl:8}"
> loopback="true"
> max_bundle_size="1400"
> max_bundle_timeout="5"
> mcast_port="${jgroups.udp.mcast_port:45588}"
> mcast_recv_buf_size="200K"
> mcast_send_buf_size="200K"
> oob_thread_pool.enabled="true"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.min_threads="1"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="discard"
> thread_naming_pattern="cl"
> thread_pool.enabled="true"
> thread_pool.keep_alive_time="5000"
> thread_pool.max_threads="8"
> thread_pool.min_threads="2"
> thread_pool.queue_enabled="true"
> thread_pool.queue_max_size="10000"
> thread_pool.rejection_policy="discard"
> timer.keep_alive_time="3000"
> timer.max_threads="10"
> timer.min_threads="4"
> timer.queue_max_size="500"
> timer_type="new3"
> tos="8"
> ucast_recv_buf_size="200K"
> ucast_send_buf_size="200K" />
> <PING />
> <MERGE2
> max_interval="30000"
> min_interval="10000" />
> <FD_SOCK />
> <FD_ALL />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2
> discard_delivered_msgs="true"
> max_msg_batch_size="500"
> use_mcast_xmit="false"
> xmit_interval="500"
> xmit_table_max_compaction_time="30000"
> xmit_table_msgs_per_row="2000"
> xmit_table_num_rows="100" />
> <UNICAST3
> conn_expiry_timeout="0"
> max_msg_batch_size="500"
> xmit_interval="500"
> xmit_table_max_compaction_time="60000"
> xmit_table_msgs_per_row="2000"
> xmit_table_num_rows="100" />
> <pbcast.STABLE
> desired_avg_gossip="50000"
> max_bytes="4M"
> stability_delay="1000" />
> <pbcast.GMS
> join_timeout="3000"
> print_local_addr="true"
> view_bundling="true" />
> <UFC
> max_credits="2M"
> min_threshold="0.4" />
> <MFC
> max_credits="2M"
> min_threshold="0.4" />
> <FRAG frag_size="1000" />
> <pbcast.STATE_TRANSFER />
> <FORK>
> <fork-stack id="main" >
> <config>
> <CENTRAL_LOCK num_backups="2" />
> </config>
> </fork-stack>
> <fork-stack id="lock" >
> <config>
> <CENTRAL_LOCK num_backups="2" />
> <STATS />
> </config>
> </fork-stack>
> </FORK>
> </config>
> {code}
--
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
10 years, 5 months