[JBoss JIRA] (WFLY-3115) JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
by Thomas Kriechbaum (JIRA)
[ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.... ]
Thomas Kriechbaum updated WFLY-3115:
------------------------------------
Description:
When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
When defining JNDI-names (e.g. java:jboss/url/Configuration) instead of concrete URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952
was:
When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
When defining JNDI-names (e.g. java:app/url/Configuration) instead of convreate URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952
> JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3115
> URL: https://issues.jboss.org/browse/WFLY-3115
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Reporter: Thomas Kriechbaum
>
> When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
> When defining JNDI-names (e.g. java:jboss/url/Configuration) instead of concrete URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
> see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3115) JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
by Thomas Kriechbaum (JIRA)
[ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.... ]
Thomas Kriechbaum updated WFLY-3115:
------------------------------------
Summary: JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources (was: JNDI-Names should be supported in jboss-specific deployment descriptors for URL resurces)
> JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3115
> URL: https://issues.jboss.org/browse/WFLY-3115
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Reporter: Thomas Kriechbaum
> Priority: Critical
>
> When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
> When defining JNDI-names (e.g. java:app/url/Configuration) instead of convreate URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
> see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3115) JNDI-Names should be supported in jboss-specific deployment descriptors for URL resurces
by Thomas Kriechbaum (JIRA)
Thomas Kriechbaum created WFLY-3115:
---------------------------------------
Summary: JNDI-Names should be supported in jboss-specific deployment descriptors for URL resurces
Key: WFLY-3115
URL: https://issues.jboss.org/browse/WFLY-3115
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.Final
Reporter: Thomas Kriechbaum
Priority: Critical
When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
When defining JNDI-names (e.g. java:app/url/Configuration) instead of convreate URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3114) @Resource(lookup="java:...") causes an exception for URL resources
by Thomas Kriechbaum (JIRA)
Thomas Kriechbaum created WFLY-3114:
---------------------------------------
Summary: @Resource(lookup="java:...") causes an exception for URL resources
Key: WFLY-3114
URL: https://issues.jboss.org/browse/WFLY-3114
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.Final
Reporter: Thomas Kriechbaum
When referencing an URL resource via @Resource the lookup-property only supports a valid URLs (e.g. http://www.jboss.org). A JNDI-Name causes an exception (e.g. java:global/url/Configuration or java:app/url/Configuration)
Issue has been discussed in the user form.
Note:
@Resource(name="java:global/url/Configuration") works.
>From my point of view, the javadoc of @Resource is not very easy to understand.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3113) Websocket connection fails when connecting to protected URL (basic login)
by Alexandre Nikolov (JIRA)
Alexandre Nikolov created WFLY-3113:
---------------------------------------
Summary: Websocket connection fails when connecting to protected URL (basic login)
Key: WFLY-3113
URL: https://issues.jboss.org/browse/WFLY-3113
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.Final
Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux
Chrome, Firefox
Reporter: Alexandre Nikolov
Assignee: Stuart Douglas
In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.
When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.
But in a different application, using Atmosphere - both connections fails:
1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it because the reques.getPathInfo() returns the context root prepended to the path info.
For example if the context root is "jsr356test" and the protected path is /pubsub/protected, the path info returned is /jsr356test/pubsub/protected instead of /pubsub/protected
Here is the related discussion on the Atmosphere users group:
https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc
There is test WAR and source in the Atmosphere forum to reproduce the problem.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-2850) AJP connector with external authentication
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2850:
--------------------------------------
What did the security domain setup for this look like in AS7/EAP6? I have implemented an authenticator based on this in Undertow, but it would be helpful to know what the server side config used to look like.
> AJP connector with external authentication
> ------------------------------------------
>
> Key: WFLY-2850
> URL: https://issues.jboss.org/browse/WFLY-2850
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Reporter: Geert Coelmont
> Assignee: Stuart Douglas
> Priority: Critical
>
> Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
> A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
> For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3112) One can't change history and decay with DynamicLoadBalanceFactorProvider
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3112:
---------------------------------
Fix Version/s: 8.0.1.Final
Description:
I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
{code}
<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
<mod-cluster-config advertise-socket="modcluster" connector="ajp">
<dynamic-load-provider history="0">
<custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
<property name="capacity" value="1000"/>
<property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
<property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
</custom-load-metric>
</dynamic-load-provider>
</mod-cluster-config>
</subsystem>
{code}
The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent
that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called.
The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
The same IMHO holds for the decay attribute.
Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]:
{code}
// Historical value contribute an exponentially decayed factor
for (int i = 0; i < queue.size(); ++i) {
double decay = 1 / Math.pow(decayFactor, i);
totalDecay += decay;
this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
totalLoad += queue.get(i).doubleValue() * decay;
}
{code}
and
{code}
try {
// Normalize load with respect to capacity
this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
totalWeight += weight;
totalWeightedLoad += this.average(metricLoadHistory) * weight;
} catch (Exception e) {
this.log.error(e.getLocalizedMessage(), e);
}
{code}
with the following being the output: [^redacted_log].
So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
{noformat}
KTAG metricLoadHistory:[0.8]
{noformat}
to
{noformat}
KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
{noformat}
which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-)
WDYT?
was:
I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
{code}
<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
<mod-cluster-config advertise-socket="modcluster" connector="ajp">
<dynamic-load-provider history="0">
<custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
<property name="capacity" value="1000"/>
<property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
<property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
</custom-load-metric>
</dynamic-load-provider>
</mod-cluster-config>
</subsystem>
{code}
The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent
that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called.
The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
The same IMHO holds for the decay attribute.
Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]:
{code}
// Historical value contribute an exponentially decayed factor
for (int i = 0; i < queue.size(); ++i) {
double decay = 1 / Math.pow(decayFactor, i);
totalDecay += decay;
this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
totalLoad += queue.get(i).doubleValue() * decay;
}
{code}
and
{code}
try {
// Normalize load with respect to capacity
this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
totalWeight += weight;
totalWeightedLoad += this.average(metricLoadHistory) * weight;
} catch (Exception e) {
this.log.error(e.getLocalizedMessage(), e);
}
{code}
with the following being the output: [^redacted_log].
So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
{noformat}
KTAG metricLoadHistory:[0.8]
{noformat}
to
{noformat}
KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
{noformat}
which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-)
WDYT?
Component/s: Clustering
This is a WildFly bug, moved accordingly.
I have a fix ready in a branch.
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
> Key: WFLY-3112
> URL: https://issues.jboss.org/browse/WFLY-3112
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.1.Final
>
> Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider history="0">
> <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
> <property name="capacity" value="1000"/>
> <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
> <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
> </custom-load-metric>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
> double decay = 1 / Math.pow(decayFactor, i);
> totalDecay += decay;
> this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
> totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
> // Normalize load with respect to capacity
> this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
> this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
> totalWeight += weight;
> totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
> this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-)
> WDYT?
--
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
12 years, 1 month