November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5648) Access log message fails to be written to recreated access log on Windows

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5648?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-5648: ------------------------------------ Assignee: Stuart Douglas (was: Tomaz Cerar) > Access log message fails to be written to recreated access log on Windows > ------------------------------------------------------------------------- > > Key: WFLY-5648 > URL: https://issues.jboss.org/browse/WFLY-5648 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR4 > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Fix For: 10.0.0.CR5 > > > Undertow fails to write to access-log when the access-log configuration was removed including the access-log file and then the configuration was recreated with [1]. Probably there remains some lock to old file preventing creation of the new one. > Steps to reproduce: > 1) deploy some simple web application > 2) define access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()}} > 3) reload server > 4) access the web application > 5) see that the access was logged to access-log > 6) remove the access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:remove()}} > 7) reload the server > 8) remove the access-log file > 9) define again the access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()}} > 10) access again the web application > 11) check both server logs and access-log > [1] > {noformat} > 05:49:51,448 ERROR [io.undertow] (default task-2) UT005016: Error writing access log: java.nio.file.AccessDeniedException: W:\workspace\eap-7x-undertow-integration-tests\d07ae7a0\manu-eap-1.1.13\out\UnzipEap_1\workspace\jboss-eap-7.0\standalone\log\access_log.log > at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230) > at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434) > at java.nio.file.Files.newOutputStream(Files.java:216) > at java.nio.file.Files.newBufferedWriter(Files.java:2860) > at io.undertow.server.handlers.accesslog.DefaultAccessLogReceiver.writeMessage(DefaultAccessLogReceiver.java:224) > at io.undertow.server.handlers.accesslog.DefaultAccessLogReceiver.run(DefaultAccessLogReceiver.java:180) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1161) Simplification of setCapabilityReference where resource only exposes a single capability.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1161?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1161: ------------------------------------------ https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... should do the trick. Two mildly doubtful things about it: https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... and a bit below. 2 CapabilityReferenceRecorder methods can no longer be supported. Probably best we didn't use them. I think I sense an "I told you so" coming from Tomaz. ;) 2) This requires that the address of the currently executing step be the same as that of the dependent resource. In practice when CapabilityReferenceRecorder is called that is the case, and I don't have any plan for something else, but my foresight isn't 20/20. I don't think either of these are that big of a deal, but I'm just barely uncomfortable enough that I won't send up a PR right now. It's PTO/holiday time anyway. > Simplification of setCapabilityReference where resource only exposes a single capability. > ----------------------------------------------------------------------------------------- > > Key: WFCORE-1161 > URL: https://issues.jboss.org/browse/WFCORE-1161 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > > Currently we need to use the following method to specify that one of our attributes is a reference to another capability: - > {code} > public BUILDER setCapabilityReference(String referencedCapability, String dependentCapability, boolean dynamicDependent) { > referenceRecorder = new CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder(referencedCapability, dependentCapability, dynamicDependent); > return (BUILDER) this; > } > {code} > However the resource has already indicated the capability it provides and indicated whether it is dynamic so the last two parameters duplicate this information. > This makes it much harder to re-use attribute definitions across different resources as even though they may reference the same time they now contain information about the resource they are used within. > As discussed previously there is still the case that a single resource could provide multiple capabilities and this additional information may be required to clarify which capability it is in relation to but in general if a resource only provides a single capability we should be able to detect that without the additional information on the attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-989) Saving/Restoring drools session prevents timer-related rules from firing

by David Weir (JIRA)

[ https://issues.jboss.org/browse/DROOLS-989?page=com.atlassian.jira.plugin... ] David Weir updated DROOLS-989: ------------------------------ Attachment: DroolsTimerTest.java Added the debug Agenda and RuleRuntime listeners to check the inserts/deletes and activations were occurring. > Saving/Restoring drools session prevents timer-related rules from firing > ------------------------------------------------------------------------ > > Key: DROOLS-989 > URL: https://issues.jboss.org/browse/DROOLS-989 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: David Weir > Assignee: Mario Fusco > Priority: Blocker > Attachments: DroolsTimerTest.java, DroolsTimerTest.java > > > Attached test case shows a timer-base rule firing. Then the session is saved and restored per the manual. When the trigger is inserted again, the rule does not fire. > This is killing my system whenever I have to restart and restore the current sessions. > The workaround is to create the session again from scratch -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-995) Add possibility to enable debug mode by setting environment variable in standalone scripts

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-995?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-995: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1241 (was: https://github.com/wildfly/wildfly-core/pull/1233) > Add possibility to enable debug mode by setting environment variable in standalone scripts > ------------------------------------------------------------------------------------------ > > Key: WFCORE-995 > URL: https://issues.jboss.org/browse/WFCORE-995 > Project: WildFly Core > Issue Type: Feature Request > Components: Scripts > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > It's common practice in Docker to control image run by configuring environment variables. > E.g. > {code:bash} > docker run -e POSTGRES_PASSWORD=mysecretpassword -d postgres > {code} > The Cloud Enablement team adds such a possibility to EAP docker images. They [replaces|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-d...] initial value of {{DEBUG_MODE}}: > {code:bash} > # Enhance standalone.sh to make remote JAVA debugging possible by specifying > # DEBUG=true environment variable > sed -i 's|DEBUG_MODE=false|DEBUG_MODE="${DEBUG:-false}"|' $JBOSS_HOME/bin/standalone.sh > {code} > It's not a clean solution. This change should be made in original scripts and not on a Dockerfile level. > Please allow configuring the {{DEBUG_MODE}} from environment variables (in similar as e.g. the {{JAVA_OPTS}} are handled. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-989) Saving/Restoring drools session prevents timer-related rules from firing

by David Weir (JIRA)

David Weir created DROOLS-989: --------------------------------- Summary: Saving/Restoring drools session prevents timer-related rules from firing Key: DROOLS-989 URL: https://issues.jboss.org/browse/DROOLS-989 Project: Drools Issue Type: Feature Request Components: core engine Affects Versions: 6.3.0.Final Reporter: David Weir Assignee: Mario Fusco Priority: Blocker Attachments: DroolsTimerTest.java Attached test case shows a timer-base rule firing. Then the session is saved and restored per the manual. When the trigger is inserted again, the rule does not fire. This is killing my system whenever I have to restart and restore the current sessions. The workaround is to create the session again from scratch -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1160: ------------------------------------------ [~dlofthouse] Is this not a use case for OperationContext.getCapabilityRuntimeApi() ? {code} public interace TheRuntimeAPI { /** Gets the ServiceName for a Service whose value type is SecurityFacotry<T> where * T is {@code outputType * @throw IllegalStateException if this capability does not support {@code outputType} */ ServiceName getSecurityFactoryServiceName(Class<?> outputType); } {code} When a RuntimeCapability is created and when a requiring capability uses the OperationContext, we don't have actual instances of SecurityFactory<T> to work with. (This isn't a case of casting.) All we have is instances of Class. Now we can try and come up with other parameters to add to RuntimeCapability.Builder and OperationContext.getCapabilityServiceName to try and do some other type of checking, but the capability author and the the requiror are going to have to have a mutual understanding of the relevant parameters. Which sounds like TheRuntimeAPI above. Maybe as a convenience the kernel can make it easy to check SecurityFactory<T>, but what if what's wanted is SecurityFactory<T, U>? > Definition of capabilities where the service return type is generic. > -------------------------------------------------------------------- > > Key: WFCORE-1160 > URL: https://issues.jboss.org/browse/WFCORE-1160 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > > Within Elytron we have the following interface: - > {code} > public interface SecurityFactory<T> {} > {code} > It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations. > As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1988) MessageDispatcher::sendMessageWithFuture with RequestOptions null

by matias sm (JIRA)

matias sm created JGRP-1988: ------------------------------- Summary: MessageDispatcher::sendMessageWithFuture with RequestOptions null Key: JGRP-1988 URL: https://issues.jboss.org/browse/JGRP-1988 Project: JGroups Issue Type: Enhancement Affects Versions: 3.6.6 Reporter: matias sm Assignee: Bela Ban Priority: Minor In MessageDispatcher::sendMessageWithFuture there are some validations to check the case of RequestOptions options being null. However, if one calls that method with a null RequestOptions argument, the execution ends in failure (with a NPE in the resulting future) [1]. The point is, either the validations are unnecessary and should exist a preconditions check at the beginning of the method, or it should set a (documented) default RequestOptions so the sending can be completed. [1] the source of the NPE is UnicastRequest::sendRequest when trying to access the RequestOptions's getMode method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1159) Add a runtime metric which shows filesystem usage and availability for known server locations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1159?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1159: ---------------------------------------- Assignee: ehsavoie Hugonnet (was: Brian Stansberry) [~ehugonnet] Once you have a look at this and clarify any requirements, please create a design wiki and post it to wildfly-dev. > Add a runtime metric which shows filesystem usage and availability for known server locations > --------------------------------------------------------------------------------------------- > > Key: WFCORE-1159 > URL: https://issues.jboss.org/browse/WFCORE-1159 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Server > Affects Versions: 2.0.2.Final > Reporter: Tristan Tarrant > Assignee: ehsavoie Hugonnet > > For management purposes it would be very useful to report runtime metrics for filesystem usage and availability for known server locations (data, tmp, logs, etc). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1160: ------------------------------------- Fix Version/s: (was: 3.0.0.Alpha1) > Definition of capabilities where the service return type is generic. > -------------------------------------------------------------------- > > Key: WFCORE-1160 > URL: https://issues.jboss.org/browse/WFCORE-1160 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > > Within Elytron we have the following interface: - > {code} > public interface SecurityFactory<T> {} > {code} > It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations. > As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1160: ------------------------------------------ Ok, thanks. It sounds like a good approach. > Definition of capabilities where the service return type is generic. > -------------------------------------------------------------------- > > Key: WFCORE-1160 > URL: https://issues.jboss.org/browse/WFCORE-1160 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha1 > > > Within Elytron we have the following interface: - > {code} > public interface SecurityFactory<T> {} > {code} > It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations. > As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2015