November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1374) Rename property version.wildfly.swarm to version.org.wildfly.swarm

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-1374: ---------------------------------------- Summary: Rename property version.wildfly.swarm to version.org.wildfly.swarm Key: DROOLS-1374 URL: https://issues.jboss.org/browse/DROOLS-1374 Project: Drools Issue Type: Task Components: build Reporter: Geoffrey De Smet Assignee: Michael Biarnes Kiefer in kie-parent it says {code} <version.wildfly.swarm>2016.9</version.wildfly.swarm> {code} that should be {code} <version.org.wildfly.swarm>2016.9</version.org.wildfly.swarm> {code} according to property guidelines. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7708) support specifying the runtime-name in the deployment descriptor

by Gregor Rosenauer (JIRA)

[ https://issues.jboss.org/browse/WFLY-7708?page=com.atlassian.jira.plugin.... ] Gregor Rosenauer updated WFLY-7708: ----------------------------------- Description: There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name. The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension. This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable. Sadly, Wildfly completely ignores the <earName> (was it?) attribute in the application.xml. Generally, there should be an option to strip versions of deployments so e.g. JNDI lookup is stable and not version dependent. I know there can be a scenario where this would make sense, but it's a 0.0001% use case imho. As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-) In the meantime, the best way for me was to configure the maven-ear-plugin to change the module names like suggested in http://stackoverflow.com/a/27442584/160799 and to override the finalName of the modules in the module POMs. was: There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name. The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension. This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable. As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-) > support specifying the runtime-name in the deployment descriptor > ---------------------------------------------------------------- > > Key: WFLY-7708 > URL: https://issues.jboss.org/browse/WFLY-7708 > Project: WildFly > Issue Type: Enhancement > Components: EE > Affects Versions: 9.0.2.Final > Environment: Java EE 7 > Reporter: Gregor Rosenauer > Priority: Minor > Labels: EE, deployment, descriptor > > There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name. > The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension. > This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable. > Sadly, Wildfly completely ignores the <earName> (was it?) attribute in the application.xml. > Generally, there should be an option to strip versions of deployments so e.g. JNDI lookup is stable and not version dependent. > I know there can be a scenario where this would make sense, but it's a 0.0001% use case imho. > As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-) > In the meantime, the best way for me was to configure the maven-ear-plugin to change the module names like suggested in http://stackoverflow.com/a/27442584/160799 and to override the finalName of the modules in the module POMs. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7709) standalone-minimalistic.xml config got left behind

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFLY-7709?page=com.atlassian.jira.plugin.... ] Alexey Loubyansky updated WFLY-7709: ------------------------------------ Description: Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations. These operations are executed when the minimalistic config is loaded: {code} /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990") /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}") /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE /socket-binding-group=standard-sockets:add(default-interface="public") {code} These operations are executed as part of the default core config: {code} /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false") /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop {code} was: Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations. These operations are executed when the minimalistic config is loaded: /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990") /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}") /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE /socket-binding-group=standard-sockets:add(default-interface="public") These operations are executed as part of the default core config: /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false") /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop > standalone-minimalistic.xml config got left behind > -------------------------------------------------- > > Key: WFLY-7709 > URL: https://issues.jboss.org/browse/WFLY-7709 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 10.1.0.Final > Reporter: Alexey Loubyansky > Assignee: Brian Stansberry > > Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations. > These operations are executed when the minimalistic config is loaded: > {code} > /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default > /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990") > /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}") > /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") > /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE > /socket-binding-group=standard-sockets:add(default-interface="public") > {code} > These operations are executed as part of the default core config: > {code} > /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false") > /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop > /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native > /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default > /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7709) standalone-minimalistic.xml config got left behind

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFLY-7709: --------------------------------------- Summary: standalone-minimalistic.xml config got left behind Key: WFLY-7709 URL: https://issues.jboss.org/browse/WFLY-7709 Project: WildFly Issue Type: Bug Components: Domain Management Affects Versions: 10.1.0.Final Reporter: Alexey Loubyansky Assignee: Brian Stansberry Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations. These operations are executed when the minimalistic config is loaded: /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990") /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}") /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE /socket-binding-group=standard-sockets:add(default-interface="public") These operations are executed as part of the default core config: /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false") /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7708) support specifying the runtime-name in the deployment descriptor

by Gregor Rosenauer (JIRA)

[ https://issues.jboss.org/browse/WFLY-7708?page=com.atlassian.jira.plugin.... ] Gregor Rosenauer updated WFLY-7708: ----------------------------------- Priority: Minor (was: Major) > support specifying the runtime-name in the deployment descriptor > ---------------------------------------------------------------- > > Key: WFLY-7708 > URL: https://issues.jboss.org/browse/WFLY-7708 > Project: WildFly > Issue Type: Enhancement > Components: EE > Affects Versions: 9.0.2.Final > Environment: Java EE 7 > Reporter: Gregor Rosenauer > Priority: Minor > Labels: EE, deployment, descriptor > > There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name. > The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension. > This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable. > As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7708) support specifying the runtime-name in the deployment descriptor

by Gregor Rosenauer (JIRA)

Gregor Rosenauer created WFLY-7708: -------------------------------------- Summary: support specifying the runtime-name in the deployment descriptor Key: WFLY-7708 URL: https://issues.jboss.org/browse/WFLY-7708 Project: WildFly Issue Type: Enhancement Components: EE Affects Versions: 9.0.2.Final Environment: Java EE 7 Reporter: Gregor Rosenauer There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name. The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension. This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable. As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7707) Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7707: ------------------------------------ Summary: Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller Key: WFLY-7707 URL: https://issues.jboss.org/browse/WFLY-7707 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 10.1.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Minor We have had to do quite a bit of bending over backwards and copy the classes for AdditionalInitialization so it would be great if we can get around this classloader setup problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7617) Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7617?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7617: --------------------------------- Priority: Minor (was: Major) > Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller > ---------------------------------------------------------------------------------------- > > Key: WFLY-7617 > URL: https://issues.jboss.org/browse/WFLY-7617 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > We have had to do quite a bit of bending over backwards and copy the classes for AdditionalInitialization so it would be great if we can get around this classloader setup problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7617) Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7617?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7617: --------------------------------- Description: We have had to do quite a bit of bending over backwards and copy the classes for AdditionalInitialization so it would be great if we can get around this classloader setup problem. > Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller > ---------------------------------------------------------------------------------------- > > Key: WFLY-7617 > URL: https://issues.jboss.org/browse/WFLY-7617 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > We have had to do quite a bit of bending over backwards and copy the classes for AdditionalInitialization so it would be great if we can get around this classloader setup problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7617) Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7617?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7617: --------------------------------- Summary: Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller (was: Remove workarounds for WFCORE-1941) > Remove workarounds for WFCORE-1941 passing AdditionalInitialization to legacy controller > ---------------------------------------------------------------------------------------- > > Key: WFLY-7617 > URL: https://issues.jboss.org/browse/WFLY-7617 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 2016