December 2014 - jboss-jira - Jboss List Archives

[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)

11 years, 7 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)

11 years, 7 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)

11 years, 7 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)

11 years, 7 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)

11 years, 7 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)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4147) WildFly full feature pack references unresolved artifact

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4147?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-4147. ---------------------------------- Fix Version/s: 9.0.0.Alpha1 Resolution: Done > WildFly full feature pack references unresolved artifact > -------------------------------------------------------- > > Key: WFLY-4147 > URL: https://issues.jboss.org/browse/WFLY-4147 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 9.0.0.Alpha1 > Reporter: Stan Silvert > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > I have a server-provisioning.xml outside of the WildFly build. It looks like this: > {code:xml} > <server-provisioning xmlns="urn:wildfly:server-provisioning:1.0"> > <feature-packs> > <feature-pack groupId="org.wildfly" artifactId="wildfly-feature-pack" version="${project.version}"/> > </feature-packs> > </server-provisioning> > {code} > When I build, I get: > {noformat} > [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha6:build (server-provisioning) on project wildfly-build: Execution ser > ver-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha6:build failed: java.lang.RuntimeException: java.lang.RuntimeException: fai > led to resolve artifact org.wildfly:wildfly-client-all:jar:9.0.0.Alpha1: Failure to find org.wildfly:wildfly-client-all:jar:9.0.0.Alpha1 in http://repository.jboss.org/ne > xus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed o > r updates are forced -> [Help 1] > {noformat} > The problem is that wildfly-client-all is not pushed to the Maven repo. This will only work if wildfly-client-all is already in your local repo. > Looks like wildfly-client-all simply should not be referenced in the feature pack. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4147) WildFly full feature pack references unresolved artifact

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4147?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-4147: -------------------------------------- I have released the wildfly-client-all artefact. > WildFly full feature pack references unresolved artifact > -------------------------------------------------------- > > Key: WFLY-4147 > URL: https://issues.jboss.org/browse/WFLY-4147 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 9.0.0.Alpha1 > Reporter: Stan Silvert > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > I have a server-provisioning.xml outside of the WildFly build. It looks like this: > {code:xml} > <server-provisioning xmlns="urn:wildfly:server-provisioning:1.0"> > <feature-packs> > <feature-pack groupId="org.wildfly" artifactId="wildfly-feature-pack" version="${project.version}"/> > </feature-packs> > </server-provisioning> > {code} > When I build, I get: > {noformat} > [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha6:build (server-provisioning) on project wildfly-build: Execution ser > ver-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha6:build failed: java.lang.RuntimeException: java.lang.RuntimeException: fai > led to resolve artifact org.wildfly:wildfly-client-all:jar:9.0.0.Alpha1: Failure to find org.wildfly:wildfly-client-all:jar:9.0.0.Alpha1 in http://repository.jboss.org/ne > xus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed o > r updates are forced -> [Help 1] > {noformat} > The problem is that wildfly-client-all is not pushed to the Maven repo. This will only work if wildfly-client-all is already in your local repo. > Looks like wildfly-client-all simply should not be referenced in the feature pack. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4043) Cannot load custom login module

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4043?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-4043: ---------------------------------------- Have you asked about this on the forums? Setting up a security domain with a RealmDirect login-module and then having the security-realm use that JAAS security domain seems circular to me. I understand why there could be an issue here -- the quickstart counts on the fact that LoginContext will use the TCCL to load the login module class, and when the EJB call is made, the TCCL is the deployment's classloader, so the class is visible. It doesn't surprise me that the deployment classloader is not the TCCL when other call patterns are used. The basic solution to that would be to package the login module code in a module in the $WILDFLY_HOME/modules dir and use the "login-module" element's "module" attribute to specify the name of the module. But I'm not sure if you really want to package the login module class in the deployment, or if that's just something you're doing because the quickstart did it that way. > Cannot load custom login module > ------------------------------- > > Key: WFLY-4043 > URL: https://issues.jboss.org/browse/WFLY-4043 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.1.0.Final > Environment: Java 1.8.0_25 > Reporter: Rostyslav Smirnov > Assignee: Jason Greene > > When security realm authentication is configured to use JAAS domain, it is not possible to use custom login module, because there is no loader present for deployed classes. LoginContext attempts to load the login module class and fails with ClassNotFoundException. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1077) JDK ORB Subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ] Tomasz Adamski commented on WFLY-1077: -------------------------------------- Transaction testsuite integration tests: I have checked part of transaction testsuite which is responsible for checking transaction propagation and recovery: TxPropagationCrashRecoveryTestCase, JMSCrashRecoveryTestCase, JMSLrcoCrashRecoveryTestCase tests. I have run those test on narayana 5.0.3 branch with JBTM-2255 fix merged in the following configurations: wildfly<->wildfly eap<->wildfly wildfly<->eap In each of those cases all tests are passed. > JDK ORB Subsystem > ----------------- > > Key: WFLY-1077 > URL: https://issues.jboss.org/browse/WFLY-1077 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Dimitris Andreadis > Assignee: Tomasz Adamski > > Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem. > AFAIK, most/all JDK ORBs are based on the Sun ORB. > Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 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 December 2014