[JBoss JIRA] (WFLY-8655) TCPPING/TCPGOSSIP not configurable via outbound-socket-binding capability references
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8655?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-10586 to WFLY-8655:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8655 (was: JBEAP-10586)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR17)
> TCPPING/TCPGOSSIP not configurable via outbound-socket-binding capability references
> ------------------------------------------------------------------------------------
>
> Key: WFLY-8655
> URL: https://issues.jboss.org/browse/WFLY-8655
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> TCPPING and TCPGOSSIP are notoriously awkward to configure and manage. This can be addressed by using capability references to outbound-socket-bindings.
> e.g.
> <sockets-protocol type="TCPPING" outbound-socket-bindings="binding1 binding2"/>
> Additionally, TCPPING port_range can be auto-configured from the port_range specified by the transport.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8656) Bean discovery in deployment dependencies (modules) is always interpreted as "all"
by Yoann Rodière (JIRA)
Yoann Rodière created WFLY-8656:
-----------------------------------
Summary: Bean discovery in deployment dependencies (modules) is always interpreted as "all"
Key: WFLY-8656
URL: https://issues.jboss.org/browse/WFLY-8656
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 10.1.0.Final, 11.0.0.Beta1
Reporter: Yoann Rodière
Assignee: Stuart Douglas
The CDI spec specifies that the {{beans.xml}} file may set the "bean discovery mode" for a given bean archive: https://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive
Possible values include "all" (all classes should be considered as CDI beans) and "annotated" (only classes with class-level CDI annotations should b considered as CDI beans).
In Wildfly, this bean discovery mode is taken into account correctly for deployments, but not for the modules they depend on. For those modules, provided there is a {{beans.xml}}, and irrespective of the bean discovery mode set inside this file, every single class is considered as a bean and added to the CDI context.
----
This behavior is not related to the bean discovery mode defined in the "beans.xml" of the deployment. Actually, the code responsible for handling bean discovery in deployments and in their dependency is clearly separated. It seems that {{ExternalBeanArchiveProcessor}} is responsible for bean discovery in dependencies, and this class completely ignores the bean discovery mode defined in the {{bean.xml}} and always populate the archive with every single discovered class:
{code}
final BeansXml beansXml = parseBeansXml(url, parser, deploymentUnit);
final UrlScanner urlScanner = new UrlScanner();
final List<String> discoveredClasses = new ArrayList<String>();
if (!urlScanner.handleBeansXml(url, discoveredClasses)) {
continue;
}
discoveredClasses.removeAll(componentClassNames);
/*
* Below, the archive is populated with every discovered class,
* irrespective of beansXML.getBeanDiscoveryMode()
*/
final BeanDeploymentArchiveImpl bda = new BeanDeploymentArchiveImpl(new HashSet<String>(discoveredClasses), beansXml, dependency, beanArchiveIdPrefix + url.toExternalForm(), BeanArchiveType.EXTERNAL);
{code}
There seems to be hard-coded exceptions for {{jsf-impl-2.2}} and {{resteasy-cdi}}, so I suspect this problem has been noticed before, but I couldn't find any open ticket.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8654) mod_cluster stop/stop-context(waittime=..) attribute description is wrong
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8654?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-8654:
---------------------------------
Summary: mod_cluster stop/stop-context(waittime=..) attribute description is wrong (was: Improve mod_cluster stop/stop-context(waittime=..) attribute description)
> mod_cluster stop/stop-context(waittime=..) attribute description is wrong
> -------------------------------------------------------------------------
>
> Key: WFLY-8654
> URL: https://issues.jboss.org/browse/WFLY-8654
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> Cli operation description
> {noformat}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-operation-description(name=stop
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "stop",
> "description" => "Tell reverse proxies that all contexts on the node can't process requests.",
> "request-properties" => {"waittime" => {
> "type" => INT,
> "description" => "Timeout to wait for all contexts to stop.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => 10,
> "unit" => "SECONDS"
> }},
> "reply-properties" => {},
> "read-only" => false,
> "runtime-only" => true
> }
> }
> {noformat}
> Documentation
> {noformat}
> Stopping a context with waittime set to 0, meaning no timeout, instructs the balancer to stop routing any request to it immediately, which forces failover to another available context.
> If you set a timeout value using the waittime argument, no new sessions are created on this context, but existing sessions will continue to be directed to this node until they complete or the specified timeout has elapsed. The waittime argument defaults to 10 seconds.
> {noformat}
> There is difference, documentation basically says that till timeout is hit, node is disabled, cli description isn't that specific. Could you elaborate this?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (HAWKULARQE-71) Test Hawkular Java Agent
by Hayk Hovsepyan (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-71?page=com.atlassian.jira.plu... ]
Hayk Hovsepyan commented on HAWKULARQE-71:
------------------------------------------
Action Items:
* document on the JMAN4 requirements when we received theses
* include in ER1/ER2 test cycles
* if there are issues, BZ
> Test Hawkular Java Agent
> ------------------------
>
> Key: HAWKULARQE-71
> URL: https://issues.jboss.org/browse/HAWKULARQE-71
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Hayk Hovsepyan
> Assignee: Hayk Hovsepyan
> Priority: Minor
>
> There is a new Java Agent (HJA) that you can run in any JVM (including
> but not limited to EAP-based projects). You do so by passing in a
> "-javaagent" command line option to your JVM (e.g. java
> -javaagent=hawkular-javaagent.jar=config=config.yaml -jar my-app.jar
> ...yadda...). There are two additional properties you must set in
> standalone.conf if you want to run it inside an EAP JVM. The README will
> have the details.
> This new HJA is configured with a yaml file that largely mimics all the
> standalone.xml data that HWFA has. There is no ${x} support in the YAML
> file right now.
> This new HJA can talk to any EAP or WildFly server over the DMR management
> API. It can do deployments to your EAP/WildFly servers and monitoring of
> EAP/WildFly subsystems just like HWFA can.
> This new HJA can talk to any JMX server just like HWFA can (it will talk to
> the local MBeanServer or, if remotely monitoring a JMX server, it will talk
> to it over Jolokia/REST API).
> This new HJA can NOT run directly inside of a Host Controller due to
> https://issues.jboss.org/browse/WFCORE-2526 - however, you can run HJA
> externally in its own JVM (e.g. java -jar hawkular-javaagent.jar
> config=config.yaml) and have its config.yaml point to a remote Host
> Controller and you'll get the same functionality.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8642) rewrite handler handles references to contextual values incorrect
by Markus Stier (JIRA)
[ https://issues.jboss.org/browse/WFLY-8642?page=com.atlassian.jira.plugin.... ]
Markus Stier edited comment on WFLY-8642 at 4/27/17 8:18 AM:
-------------------------------------------------------------
I've tried your workaround, but it doesn't work. This is the error message from the log:
{code}
Cannot resolve expression 'regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=${1}¶m2=${2}'); done()'
{code}
I guess it won't be sufficient to add the ampersand as end token. Imagine a rewrite rule where one wants to compose a single value from two or more capture groups:
request: http://myhost.com/path/a/b/c
rewritten to: http://myhost/path?resource=a-b-c.xml
the rule would be: (... regex omitted.. ) -> rewrite ('/path'): set(attribute='%{QUERY_STRING}', value='resource=$1-$2-$3.xml').
I think you should try to get the curly braces to work.
was (Author: mrkstr):
I've tried your workaround, but it doesn't work. This is the error message from the log:
{code}
Cannot resolve expression 'regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=${1}¶m2=${2}'); done()'
{code}
I guess it won't be sufficient to add the quotation mark as end token. Imagine a rewrite rule where one wants to compose a single value from two capture groups:
request: http://myhost.com/path/a/b/c
rewritten to: http://myhost/path?resource=a-b-c.xml
the rule would be: (... regex omitted.. ) -> rewrite ('/path'): set(attribute='%{QUERY_STRING}', value='resource=$1-$2-$3.xml').
I think you should try to get the curly braces to work.
> rewrite handler handles references to contextual values incorrect
> -----------------------------------------------------------------
>
> Key: WFLY-8642
> URL: https://issues.jboss.org/browse/WFLY-8642
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: * Windows 10
> * Wildfly 10.1.0 Final
> * Undertow Subsystem 1.4.13
> Reporter: Markus Stier
> Assignee: Stuart Douglas
>
> Context:
> A URL in the form of "http://somehost.org/path/a/b" should be rewritten to "http://somehost.org/newpath?param1=a¶m2=b"
> The following filter should perform this rewrite:
> {code}
> <expression-filter name="rewrite-path" expression="regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=$1&param2=$2'); done()"/>
> {code}
> Problem:
> The output is (according to access-log);
> {code}
> somehost.org "GET /newpath?param1=b
> {code}
> * param1 is assigned to the value of $2
> * param2 is dropped completly
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8642) rewrite handler handles references to contextual values incorrect
by Markus Stier (JIRA)
[ https://issues.jboss.org/browse/WFLY-8642?page=com.atlassian.jira.plugin.... ]
Markus Stier edited comment on WFLY-8642 at 4/27/17 8:16 AM:
-------------------------------------------------------------
I've tried your workaround, but it doesn't work. This is the error message from the log:
{code}
Cannot resolve expression 'regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=${1}¶m2=${2}'); done()'
{code}
I guess it won't be sufficient to add the quotation mark as end token. Imagine a rewrite rule where one wants to compose a single value from two capture groups:
request: http://myhost.com/path/a/b/c
rewritten to: http://myhost/path?resource=a-b-c.xml
the rule would be: (... regex omitted.. ) -> rewrite ('/path'): set(attribute='%{QUERY_STRING}', value='resource=$1-$2-$3.xml').
I think you should try to get the curly braces to work.
was (Author: mrkstr):
I've tried your workaround, but it doesn't work. This is the error message from the log:
{code}
Cannot resolve expression 'regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=${1}¶m2=${2}'); done()'
{code}
> rewrite handler handles references to contextual values incorrect
> -----------------------------------------------------------------
>
> Key: WFLY-8642
> URL: https://issues.jboss.org/browse/WFLY-8642
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: * Windows 10
> * Wildfly 10.1.0 Final
> * Undertow Subsystem 1.4.13
> Reporter: Markus Stier
> Assignee: Stuart Douglas
>
> Context:
> A URL in the form of "http://somehost.org/path/a/b" should be rewritten to "http://somehost.org/newpath?param1=a¶m2=b"
> The following filter should perform this rewrite:
> {code}
> <expression-filter name="rewrite-path" expression="regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=$1&param2=$2'); done()"/>
> {code}
> Problem:
> The output is (according to access-log);
> {code}
> somehost.org "GET /newpath?param1=b
> {code}
> * param1 is assigned to the value of $2
> * param2 is dropped completly
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8642) rewrite handler handles references to contextual values incorrect
by Markus Stier (JIRA)
[ https://issues.jboss.org/browse/WFLY-8642?page=com.atlassian.jira.plugin.... ]
Markus Stier commented on WFLY-8642:
------------------------------------
I've tried your workaround, but it doesn't work. This is the error message from the log:
{code}
Cannot resolve expression 'regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=${1}¶m2=${2}'); done()'
{code}
> rewrite handler handles references to contextual values incorrect
> -----------------------------------------------------------------
>
> Key: WFLY-8642
> URL: https://issues.jboss.org/browse/WFLY-8642
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: * Windows 10
> * Wildfly 10.1.0 Final
> * Undertow Subsystem 1.4.13
> Reporter: Markus Stier
> Assignee: Stuart Douglas
>
> Context:
> A URL in the form of "http://somehost.org/path/a/b" should be rewritten to "http://somehost.org/newpath?param1=a¶m2=b"
> The following filter should perform this rewrite:
> {code}
> <expression-filter name="rewrite-path" expression="regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=$1&param2=$2'); done()"/>
> {code}
> Problem:
> The output is (according to access-log);
> {code}
> somehost.org "GET /newpath?param1=b
> {code}
> * param1 is assigned to the value of $2
> * param2 is dropped completly
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years