[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-650?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-650:
----------------------------------
There already exists a property for providing a list of URLs, and it uses a round robin approach to distribute load.
The issue is that this property was not included in the documentation - so I'll change this jira to be a documentation issue. Using the switchyard registry is something that could be explored as a separate enhancement, perhaps if this approach is limiting in some way.
To test out the approach, specify a comma separated list of URLs in the overlord-rtgov.properties against a property called "SwitchYardServicesProvider.serverURLs".
> A Situation is always resubmitted to localhost:8080
> ---------------------------------------------------
>
> Key: RTGOV-650
> URL: https://issues.jboss.org/browse/RTGOV-650
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Reporter: Werner Müller
> Assignee: Gary Brown
> Fix For: 2.1.0.Beta2
>
>
> A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Brett Meyer edited comment on ARTIF-674 at 4/9/15 11:31 AM:
------------------------------------------------------------
However, I suppose the spec is vague enough that there's no reason that we couldn't take this approach:
Maintain conformance, but in a "separated" fashion (separate Atom binding, but the "core" binding becomes JSON, etc.). The new "core" binding is the main driving force behind all this. Every time I add a new feature that's outside of the spec requirements, I have to somehow get it to fit into the Atom binding so that the interfaces can use it. It almost always ends up being extremely hacky.
We'd also maintain the /ext model for ad-hoc support, but go ahead and add the new extension plugin architecture. As long as its all *additive*, maybe it'd be worthwhile.
was (Author: brmeyer):
However, I suppose the spec is vague enough that there's no reason that we couldn't take this approach:
Maintain conformance, but in a "separated" fashion (separate Atom binding, but the "core" binding becomes JSON, etc.). We'd also maintain the /ext model for ad-hoc support, but go ahead and add the new extension plugin architecture. As long as its all *additive*, maybe it'd be worthwhile.
> Separate from the S-RAMP spec
> -----------------------------
>
> Key: ARTIF-674
> URL: https://issues.jboss.org/browse/ARTIF-674
> Project: Artificer
> Issue Type: Task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 2.0
>
>
> For 2.0, we might consider separating from the S-RAMP spec. IMO, the spec should be largely considered dead and abandoned. RH seems to be the only entity still "using" it. Further, many pieces are starting to hold things back, in addition to adding needless complexity. Instead of focusing on conformance, use only "the good parts". Claim that the project is "loosely based on S-RAMP".
> Ideas:
> REMOVE
> - Atom binding: Instead, use pure JSON REST
> - The web UI services: With the server services using JSON REST, we'd no longer need an additional service layer specifically for the web UI.
> - All "s-ramp" namespaces
> KEEP
> - Model schemas and bindings.
> - Query core syntax
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on ARTIF-674:
----------------------------------
Comments overlapping :) +1 to additive changes.
> Separate from the S-RAMP spec
> -----------------------------
>
> Key: ARTIF-674
> URL: https://issues.jboss.org/browse/ARTIF-674
> Project: Artificer
> Issue Type: Task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 2.0
>
>
> For 2.0, we might consider separating from the S-RAMP spec. IMO, the spec should be largely considered dead and abandoned. RH seems to be the only entity still "using" it. Further, many pieces are starting to hold things back, in addition to adding needless complexity. Instead of focusing on conformance, use only "the good parts". Claim that the project is "loosely based on S-RAMP".
> Ideas:
> REMOVE
> - Atom binding: Instead, use pure JSON REST
> - The web UI services: With the server services using JSON REST, we'd no longer need an additional service layer specifically for the web UI.
> - All "s-ramp" namespaces
> KEEP
> - Model schemas and bindings.
> - Query core syntax
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months