December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-444) JAVA_OPTS environment variable not used for domain mode on Windows

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-444?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-444: ------------------------------------------------ Josef Cacek <jcacek(a)redhat.com> changed the Status of [bug 1170051|https://bugzilla.redhat.com/show_bug.cgi?id=1170051] from NEW to POST > JAVA_OPTS environment variable not used for domain mode on Windows > ------------------------------------------------------------------ > > Key: WFCORE-444 > URL: https://issues.jboss.org/browse/WFCORE-444 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Josef Cacek > Assignee: Josef Cacek > > When I use JAVA_OPTS as an environment variable (i.e. configured before starting the AS) it's not propagated when used in domain mode on windows (domain.bat). > For standalone mode (standalone.bat) it works. > For Linux/Unix it works in both cases (standalone.sh, domain.sh). > Steps to reproduce: > {code} > SET "JAVA_OPTS=...MyOwnJavaOptsConfig..." > domain.bat > {code} > Actual result: > The configured JAVA_OPTS are not used. > Expected result: > Provided JAVA_OPTS are used for the process controller and host controller processes. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3316) Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3316?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3316: ----------------------------------------------- Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1094380|https://bugzilla.redhat.com/show_bug.cgi?id=1094380] from NEW to ASSIGNED > Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed > ------------------------------------------------------------------------------------------------- > > Key: WFLY-3316 > URL: https://issues.jboss.org/browse/WFLY-3316 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > Labels: ejb, naming, remote-clients, remote-ejb-connection > Attachments: reproducer.zip > > > If a client run multi threads and each Thread use it's own InitialContext the behaviour is unexpected. > The behaviour is as followed: > if each invocation create it's own IC and lookup the EJB there is sometimes a EJBCLIENT000025 because one of the one thread has closed the IC until another thread try to invoke an EJB. > If the IC is reused the failure might happen only if the first Thread has finished the invocations and close the IC during other Threads are still running. > It looks that the underlying remote connection will be closed if the first IC is closed without respect that there are different IC's created and still in use. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3316) Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-3316?page=com.atlassian.jira.plugin.... ] Enrique González Martínez reassigned WFLY-3316: ----------------------------------------------- Assignee: Enrique González Martínez (was: Jason Greene) > Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed > ------------------------------------------------------------------------------------------------- > > Key: WFLY-3316 > URL: https://issues.jboss.org/browse/WFLY-3316 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Wolf-Dieter Fink > Assignee: Enrique González Martínez > Labels: ejb, naming, remote-clients, remote-ejb-connection > Attachments: reproducer.zip > > > If a client run multi threads and each Thread use it's own InitialContext the behaviour is unexpected. > The behaviour is as followed: > if each invocation create it's own IC and lookup the EJB there is sometimes a EJBCLIENT000025 because one of the one thread has closed the IC until another thread try to invoke an EJB. > If the IC is reused the failure might happen only if the first Thread has finished the invocations and close the IC during other Threads are still running. > It looks that the underlying remote connection will be closed if the first IC is closed without respect that there are different IC's created and still in use. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-444) JAVA_OPTS environment variable not used for domain mode on Windows

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-444?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-444: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1170051 > JAVA_OPTS environment variable not used for domain mode on Windows > ------------------------------------------------------------------ > > Key: WFCORE-444 > URL: https://issues.jboss.org/browse/WFCORE-444 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Josef Cacek > Assignee: Josef Cacek > > When I use JAVA_OPTS as an environment variable (i.e. configured before starting the AS) it's not propagated when used in domain mode on windows (domain.bat). > For standalone mode (standalone.bat) it works. > For Linux/Unix it works in both cases (standalone.sh, domain.sh). > Steps to reproduce: > {code} > SET "JAVA_OPTS=...MyOwnJavaOptsConfig..." > domain.bat > {code} > Actual result: > The configured JAVA_OPTS are not used. > Expected result: > Provided JAVA_OPTS are used for the process controller and host controller processes. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-444) JAVA_OPTS environment variable not used for domain mode on Windows

by Josef Cacek (JIRA)

Josef Cacek created WFCORE-444: ---------------------------------- Summary: JAVA_OPTS environment variable not used for domain mode on Windows Key: WFCORE-444 URL: https://issues.jboss.org/browse/WFCORE-444 Project: WildFly Core Issue Type: Bug Components: Scripts Reporter: Josef Cacek Assignee: Josef Cacek When I use JAVA_OPTS as an environment variable (i.e. configured before starting the AS) it's not propagated when used in domain mode on windows (domain.bat). For standalone mode (standalone.bat) it works. For Linux/Unix it works in both cases (standalone.sh, domain.sh). Steps to reproduce: {code} SET "JAVA_OPTS=...MyOwnJavaOptsConfig..." domain.bat {code} Actual result: The configured JAVA_OPTS are not used. Expected result: Provided JAVA_OPTS are used for the process controller and host controller processes. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3910) To be added AJP connector connectionTimeout parameter

by Angel Ivanov (JIRA)

[ https://issues.jboss.org/browse/WFLY-3910?page=com.atlassian.jira.plugin.... ] Angel Ivanov commented on WFLY-3910: ------------------------------------ Is there connectionTimeout configuration parameter in Wildfly? > To be added AJP connector connectionTimeout parameter > ----------------------------------------------------- > > Key: WFLY-3910 > URL: https://issues.jboss.org/browse/WFLY-3910 > Project: WildFly > Issue Type: Feature Request > Components: ConfigAdmin > Affects Versions: 8.1.0.Final > Reporter: Angel Ivanov > Assignee: Thomas Diesler > > Hi, > We need configuration parameter for Undertow to manage especially AJP connector connection timeout, because created threads staid alive forever. > In tomcat such kind of connector parameter was connectionTimeout. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4127) @TransactionAttribute ignored on SFSB PostConstruct lifecycle callback

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4127?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-4127: -------------------------------------- What exactly is the behaviour you are seeing? I added a quick test for this to our test suite and it passed: https://github.com/stuartwdouglas/wildfly/compare/WFLY-4127 > @TransactionAttribute ignored on SFSB PostConstruct lifecycle callback > ---------------------------------------------------------------------- > > Key: WFLY-4127 > URL: https://issues.jboss.org/browse/WFLY-4127 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Martin Kouba > Assignee: Stuart Douglas > > This is a regression introduced in this commit: > https://github.com/wildfly/wildfly/commit/456a624d98eaa5f5fc016ad75202901... > Most probably {{StatefulComponentDescription}} should not pass treatRequiredAsRequiresNew=false to {{org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.Factory}} constructor. > There is a CDI TCK test which can be used as a reproducer: > https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jb... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-379) Missing param-name in a web.xml causes NullPointerException during deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/JBMETA-379?page=com.atlassian.jira.plugin... ] Brian Stansberry updated JBMETA-379: ------------------------------------ Fix Version/s: 7.2.0.Final > Missing param-name in a web.xml causes NullPointerException during deployment > ------------------------------------------------------------------------------ > > Key: JBMETA-379 > URL: https://issues.jboss.org/browse/JBMETA-379 > Project: JBoss Metadata > Issue Type: Bug > Components: web > Affects Versions: 8.0.0.Final > Reporter: Jay Kumar SenSharma > Assignee: Jean-Frederic Clere > Fix For: 7.2.0.Final, 8.1.1.Final > > Attachments: ContextParamNullDemo.war > > > - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following: > {code} > 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war") > 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: java.lang.NullPointerException > at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > ... 5 more > 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\" > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-382) Support recursive and nested expressions

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/JBMETA-382?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on JBMETA-382: ----------------------------------------- Pull requests: https://github.com/jboss/metadata/pull/73 https://github.com/jboss/metadata/pull/74 > Support recursive and nested expressions > ---------------------------------------- > > Key: JBMETA-382 > URL: https://issues.jboss.org/browse/JBMETA-382 > Project: JBoss Metadata > Issue Type: Feature Request > Components: common > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > For management configuration, WildFly and EAP support recursive expression resolution (where if ${x} resolves to ${y}, then ${y] is resolved) and will support nested expression resolution as well. The JBoss Metadata PropertyReplacer stuff should do the same so users get a consistent experience regardless of where they place an expression. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-382) Support recursive and nested expressions

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/JBMETA-382?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved JBMETA-382. ------------------------------------- Fix Version/s: 7.2.0.Final 8.1.1.Final Resolution: Done > Support recursive and nested expressions > ---------------------------------------- > > Key: JBMETA-382 > URL: https://issues.jboss.org/browse/JBMETA-382 > Project: JBoss Metadata > Issue Type: Feature Request > Components: common > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 7.2.0.Final, 8.1.1.Final > > > For management configuration, WildFly and EAP support recursive expression resolution (where if ${x} resolves to ${y}, then ${y] is resolved) and will support nested expression resolution as well. The JBoss Metadata PropertyReplacer stuff should do the same so users get a consistent experience regardless of where they place an expression. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014