[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[JBoss JIRA] (WFLY-3112) One can't change history and decay with DynamicLoadBalanceFactorProvider
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------
Radoslav Husar <rhusar(a)redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from NEW to ASSIGNED
> 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
10 years, 10 months
[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 moved MODCLUSTER-393 to WFLY-3112:
-------------------------------------------------
Project: WildFly (was: mod_cluster)
Key: WFLY-3112 (was: MODCLUSTER-393)
Affects Version/s: 8.0.0.Final
(was: 1.2.6.Final)
Security: Public
> 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)
> Affects Versions: 8.0.0.Final
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> 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
10 years, 10 months
[JBoss JIRA] (WFLY-3111) Accessing attribute message from class LoggingEvent always returns class String
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-3111:
-------------------------------------
The only way this will work currently is if you include your own version of log4j. I'm assuming of course you're including a log4j configuration file in your deployment. If you're attempting to use an appender as a custom-handler I don't think it will be possible to work. Have a look at https://docs.jboss.org/author/display/WFLY8/How+To#HowTo-HowdoIuselog4j.p... to see how to include your own version of log4j.
> Accessing attribute message from class LoggingEvent always returns class String
> -------------------------------------------------------------------------------
>
> Key: WFLY-3111
> URL: https://issues.jboss.org/browse/WFLY-3111
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.0.0.Final
> Environment: Windows 7, JDK 1.7.0_51
> Reporter: Jörg Brück
> Assignee: James Perkins
> Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
> public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
> this.fqnOfCategoryClass = fqnOfCategoryClass;
> this.logger = logger;
> this.level = level;
> logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
> public Object getMessage() {
> return logRecord.getMessage();
> }
> Here the implementation of getMessage of ExtLogRecord
> public String getMessage() {
> return message;
> }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
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, 10 months
[JBoss JIRA] (WFLY-3111) Accessing attribute message from class LoggingEvent always returns class String
by Jörg Brück (JIRA)
[ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.... ]
Jörg Brück updated WFLY-3111:
-----------------------------
Summary: Accessing attribute message from class LoggingEvent always returns class String (was: Accessing attribute message from class LogigngEvent always returns class String)
> Accessing attribute message from class LoggingEvent always returns class String
> -------------------------------------------------------------------------------
>
> Key: WFLY-3111
> URL: https://issues.jboss.org/browse/WFLY-3111
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.0.0.Final
> Environment: Windows 7, JDK 1.7.0_51
> Reporter: Jörg Brück
> Assignee: James Perkins
> Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
> public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
> this.fqnOfCategoryClass = fqnOfCategoryClass;
> this.logger = logger;
> this.level = level;
> logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
> public Object getMessage() {
> return logRecord.getMessage();
> }
> Here the implementation of getMessage of ExtLogRecord
> public String getMessage() {
> return message;
> }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
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, 10 months
[JBoss JIRA] (WFLY-3111) Accessing attribute message from class LogingEvent always returns class String
by Jörg Brück (JIRA)
Jörg Brück created WFLY-3111:
--------------------------------
Summary: Accessing attribute message from class LogingEvent always returns class String
Key: WFLY-3111
URL: https://issues.jboss.org/browse/WFLY-3111
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 8.0.0.Final
Environment: Windows 7, JDK 1.7.0_51
Reporter: Jörg Brück
Assignee: James Perkins
Priority: Minor
After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
have changed while accessing LoggingEvent in the function "append" of
class ApppenderSkeleton.
The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
this.fqnOfCategoryClass = fqnOfCategoryClass;
this.logger = logger;
this.level = level;
logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
The Object message is converted to string and saved in Class ExtLogRecord.
Here the implementation of getMessage:
public Object getMessage() {
return logRecord.getMessage();
}
Here the implementation of getMessage of ExtLogRecord
public String getMessage() {
return message;
}
Because of this String is always returned.
If I understand this code right you can transfer every object to log4j, but you can not access this objects
in an appender because of the LoggingEvent constructor where method toString is called.
What is the reason of this change in contrast to jboss 5.1.0?
Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
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, 10 months
[JBoss JIRA] (WFLY-3111) Accessing attribute message from class LogigngEvent always returns class String
by Jörg Brück (JIRA)
[ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.... ]
Jörg Brück updated WFLY-3111:
-----------------------------
Summary: Accessing attribute message from class LogigngEvent always returns class String (was: Accessing attribute message from class LogingEvent always returns class String)
> Accessing attribute message from class LogigngEvent always returns class String
> -------------------------------------------------------------------------------
>
> Key: WFLY-3111
> URL: https://issues.jboss.org/browse/WFLY-3111
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.0.0.Final
> Environment: Windows 7, JDK 1.7.0_51
> Reporter: Jörg Brück
> Assignee: James Perkins
> Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
> public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
> this.fqnOfCategoryClass = fqnOfCategoryClass;
> this.logger = logger;
> this.level = level;
> logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
> public Object getMessage() {
> return logRecord.getMessage();
> }
> Here the implementation of getMessage of ExtLogRecord
> public String getMessage() {
> return message;
> }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
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, 10 months