March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1442) ClientAgainstOldServerTestCase fails due to -XX:MaxMetaspaceSize=256m

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1442?page=com.atlassian.jira.plugi... ] Kabir Khan reassigned WFCORE-1442: ---------------------------------- Assignee: Kabir Khan > ClientAgainstOldServerTestCase fails due to -XX:MaxMetaspaceSize=256m > --------------------------------------------------------------------- > > Key: WFCORE-1442 > URL: https://issues.jboss.org/browse/WFCORE-1442 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > > The breaking change is https://github.com/wildfly/wildfly-core/commit/737106d7d6ea6d600f52630236... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1442) ClientAgainstOldServerTestCase fails due to -XX:MaxMetaspaceSize=256m

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1442?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1442: ------------------------------- Component/s: Domain Management > ClientAgainstOldServerTestCase fails due to -XX:MaxMetaspaceSize=256m > --------------------------------------------------------------------- > > Key: WFCORE-1442 > URL: https://issues.jboss.org/browse/WFCORE-1442 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > > The breaking change is https://github.com/wildfly/wildfly-core/commit/737106d7d6ea6d600f52630236... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1442) ClientAgainstOldServerTestCase fails due to -XX:MaxMetaspaceSize=256m

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1442?page=com.atlassian.jira.plugi... ] Kabir Khan moved JBEAP-3875 to WFCORE-1442: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1442 (was: JBEAP-3875) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Target Release: (was: 7.0.0.GA) > ClientAgainstOldServerTestCase fails due to -XX:MaxMetaspaceSize=256m > --------------------------------------------------------------------- > > Key: WFCORE-1442 > URL: https://issues.jboss.org/browse/WFCORE-1442 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Kabir Khan > > The breaking change is https://github.com/wildfly/wildfly-core/commit/737106d7d6ea6d600f52630236... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-6402: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1310908 Bugzilla Update: Perform > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-489) The "access-mechanism" field in the active-operation resources is always undefined

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-489?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-489: ------------------------------------------------ Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1202610|https://bugzilla.redhat.com/show_bug.cgi?id=1202610] from NEW to ASSIGNED > The "access-mechanism" field in the active-operation resources is always undefined > ---------------------------------------------------------------------------------- > > Key: WFCORE-489 > URL: https://issues.jboss.org/browse/WFCORE-489 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 1.0.0.Beta4 > > > The "access-mechanism" field in core-service=management/service=active-operations/active-operation=* is always undefined. The code that sets it is using the wrong var: > {code} > ModelNode accessMechanismNode = model.get(ACCESS_MECHANISM); > if (accessMechanism != null) { > accessMechanismNode.set(accessMechanismNode.toString()); > } > {code} > It should be accessMechanism.toString() -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-263: ------------------------------------------------ Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1202610|https://bugzilla.redhat.com/show_bug.cgi?id=1202610] from NEW to ASSIGNED > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha1 > > Attachments: unundeployable.zip > > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-393) Clone a profile

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-393: ------------------------------------------------ Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1125143|https://bugzilla.redhat.com/show_bug.cgi?id=1125143] from NEW to ASSIGNED > Clone a profile > --------------- > > Key: WFCORE-393 > URL: https://issues.jboss.org/browse/WFCORE-393 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 2.0.0.Alpha4 > > > Add the ability to clone a profile. > This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly. > Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6405) Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized

by Panos Grigoropoulos (JIRA)

Panos Grigoropoulos created WFLY-6405: ----------------------------------------- Summary: Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized Key: WFLY-6405 URL: https://issues.jboss.org/browse/WFLY-6405 Project: WildFly Issue Type: Bug Components: CDI / Weld, Class Loading Affects Versions: 10.0.0.Final Reporter: Panos Grigoropoulos Assignee: Stuart Douglas (Wildfly 10.0.0.FINAL) During the performance test of my app (50 concurrent users with jmeter) I am running into the following issue: There are locked threads in the method WeldDeployment.getBeanDeploymentArchive(). Looking the code, this method is synchronized, so it makes sense. The question is, is this the expected behavior or this is a bug. In both cases is there any workaround to overcome this limitation? STACK TRACE: .... org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():73 org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():93 org.jboss.as.weld.deployment.WeldDeployment.getBeanDeploymentArchive():226 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6375) Identify colliding JBoss modules WRT JEP 200, section 6

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFLY-6375?page=com.atlassian.jira.plugin.... ] Richard Opalka edited comment on WFLY-6375 at 3/17/16 5:00 PM: --------------------------------------------------------------- After detailed analysis I identified the following jars colliding with JEP 200, section 6: {code} JDK9 Module -> Colliding JBoss Module (see http://openjdk.java.net/jeps/200, section 6) ------------------------------------------------------------------------------------------------------ [java.transaction] -> javax/transaction/api/main/jboss-transaction-api_1.2_spec-1.0.0.Final.jar [java.annotations.common] -> javax/annotation/api/main/jboss-annotations-api_1.2_spec-1.0.0.Final.jar [java.activation] -> javax/activation/api/main/activation-1.1.1.jar [java.xml.bind] -> javax/xml/bind/api/main/jboss-jaxb-api_2.2_spec-1.0.4.Final.jar [java.xml.ws] -> javax/xml/soap/api/main/jboss-saaj-api_1.3_spec-1.0.3.Final.jar [java.xml.ws] -> javax/xml/ws/api/main/jboss-jaxws-api_2.2_spec-2.0.2.Final.jar [java.xml.ws] -> javax/jws/api/main/jsr181-api-1.0-MR1.jar [java.corba] -> javax/orb/api/main/openjdk-orb-8.0.5.Final.jar {code} was (Author: ropalka): After detailed analysis I identified the following jars colliding with JEP 200, section 6: {code} JDK9 Module -> Colliding JBoss Module (see http://openjdk.java.net/jeps/200, section 6) ------------------------------------------------------------------------------------------------------ [java.transaction] -> javax/transaction/api/main/jboss-transaction-api_1.2_spec-1.0.0.Final.jar [java.annotations.common] -> javax/annotation/api/main/jboss-annotations-api_1.2_spec-1.0.0.Final.jar [java.activation] -> javax/activation/api/main/activation-1.1.1.jar [java.xml.bind] -> javax/xml/bind/api/main/jboss-jaxb-api_2.2_spec-1.0.4.Final.jar [java.xml.ws] -> javax/xml/soap/api/main/jboss-saaj-api_1.3_spec-1.0.3.Final.jar [java.xml.ws] -> javax/xml/ws/api/main/jboss-jaxws-api_2.2_spec-2.0.2.Final.jar [java.xml.ws] -> javax/jws/api/main/jsr181-api-1.0-MR1.jar [java.corba] -> javax/orb/api/main/openjdk-orb-8.0.5.Final.jar [java.corba] -> javax/orb/api/main/openjdk-orb-8.0.5.Final.jar [java.corba] -> javax/orb/api/main/openjdk-orb-8.0.5.Final.jar {code} > Identify colliding JBoss modules WRT JEP 200, section 6 > ------------------------------------------------------- > > Key: WFLY-6375 > URL: https://issues.jboss.org/browse/WFLY-6375 > Project: WildFly > Issue Type: Sub-task > Affects Versions: 10.0.0.Final > Reporter: Richard Opalka > Assignee: Richard Opalka > > JKD9 with jigsaw throws ClassNotFound exception if we're trying to 'override/enrich' JDK9 exported packages. This is collision with JEP 200, section 6: *A non-standard module must not export any standard API packages. A non-standard module may grant implied readability to a standard module.* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6404) Upgrade JBossWS from 5.1.3.SP1 to 5.1.4.Final

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-6404: ------------------------------------- Summary: Upgrade JBossWS from 5.1.3.SP1 to 5.1.4.Final Key: WFLY-6404 URL: https://issues.jboss.org/browse/WFLY-6404 Project: WildFly Issue Type: Component Upgrade Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 10.1.0.Final Upgrade to JBossWS 5.1.4.Final, including move to Apache CXF 3.1.5. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 March 2016