April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-382) Support for profile and socket binding group includes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-382?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-382: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Support for profile and socket binding group includes > ----------------------------------------------------- > > Key: WFCORE-382 > URL: https://issues.jboss.org/browse/WFCORE-382 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 2.0.0.Beta1 > > > Restore the ability to have a profile include another profile and for a socket-binding-group to include another socket-binding-group. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-384) Server does wrongly reference a list of socket binding groups

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-384?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-384: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Server does wrongly reference a list of socket binding groups > ------------------------------------------------------------- > > Key: WFCORE-384 > URL: https://issues.jboss.org/browse/WFCORE-384 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Braun > Assignee: luck3y > Fix For: 2.0.0.Beta1 > > > hbraun: i see that a server (host=foo/server=bar) can have a list of socket-binding-groups > [10:59am] hbraun: shouldn't that be a a single socket binding instead? > [11:00am] emuckenhuber: oh... yeah > [11:00am] hbraun: maybe it's just the description that's wrong > [11:00am] emuckenhuber: that sounds similar to the jvm thing we had -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-392) Stack trace improvements, summarize the things that broke to make them not so intimidating

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-392?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-392: ------------------------------------ Fix Version/s: (was: 1.0.0.CR1) > Stack trace improvements, summarize the things that broke to make them not so intimidating > ------------------------------------------------------------------------------------------ > > Key: WFCORE-392 > URL: https://issues.jboss.org/browse/WFCORE-392 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Jim Tyrrell > Assignee: Brian Stansberry > Priority: Critical > Labels: eap6-ux > Attachments: log.txt > > > See the typical attached stack dump: > It would be nice if the stack dump could include all of the information above as a summary as shown below, basically just the first lines of the errors w/o the whole stack dump: > 11:51:45,391 INFO [org.jboss.as.server.controller] (HttpManagementService-threads - 5) Deployment of "SpringWAR.war" was rolled back with failure message {"Failed services" => {"jboss.web.deployment.default-host./SpringWAR" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context"}} > 11:51:45,392 INFO [org.jboss.as.controller] (HttpManagementService-threads - 5) Service status report > Services which failed to start: > service jboss.web.deployment.default-host./SpringWAR: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context > 11:51:45,417 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment SpringWAR.war in 26ms > 11:51:45,417 Error Summary of Exceptions in deployment: > - [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B > - [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B > - [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart > - ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors > - [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext > - [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR: > ERROR Scroll up to see more info... > Or > 11:51:45,417 Error Summary of Exceptions in deployment: > [1] [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B > [2] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B > [3] [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart > [4] ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors > [5] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext > [6] [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR: > ERROR Scroll up to see more info... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola commented on DROOLS-775: ----------------------------------------- After further investigation (profiling) I found that if I stub the {{ClassObjectTypeConf#checkPropertyListenerSupport}} method (which uses reflection internally) I experience a noticeable performance increase. The field {{supportsPropertyListeners}} is not used anywhere else. There's something I'm missing? > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-393: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > 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.Beta1 > > > 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.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-401) Consider using a "describe" notion for providing the model to slaves on registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-401?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-401: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Consider using a "describe" notion for providing the model to slaves on registration > ------------------------------------------------------------------------------------ > > Key: WFCORE-401 > URL: https://issues.jboss.org/browse/WFCORE-401 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 2.0.0.Beta1 > > > When a slave HC registers, the master provides it a copy of the domain-wide model as a DMR tree. This has a weakness in that the Resource impl types that comprise that tree on the master side are not transmitted. If custom Resource impls are used, they may not be recreated on the slave. > Consider instead sending a list of mgmt ops, a la what we do with servers when starting from an HC. > This could potentially be limited to subsystems, with the core model sent as it is now. The core model is handled by core-AS code on the slave side, so we can reasonably ensure that code always uses the correct Resource type. There are places where we already do that. The bigger problem is subsystems. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-396: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: luck3y > Fix For: 2.0.0.Beta1 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-431) CLI should WARN about usage deprecated api

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-431?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-431: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > CLI should WARN about usage deprecated api > ------------------------------------------ > > Key: WFCORE-431 > URL: https://issues.jboss.org/browse/WFCORE-431 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Tomaz Cerar > Assignee: Alexey Loubyansky > Fix For: 2.0.0.Beta1 > > > We added support for deprecating resources/attributes/operations/parameters some time ago. > I would be a good thing that we would warn users if they are using deprecated API. > Every resource/attribute/operation/param that is deprecated has extra element "deprecated" in metadata > With sub elements > - "since", which tells in what version it was deprecated > - "reason", text description why it is deprecated. > Reason in most cases also tells what is new replacement. > This should be only displayed in case of interactive shell usage. > Unless there is also some special CLI log file, it could be part of that even for non-interactive usage -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-459) Account for attribute groups in CLI behavior

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-459: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Account for attribute groups in CLI behavior > -------------------------------------------- > > Key: WFCORE-459 > URL: https://issues.jboss.org/browse/WFCORE-459 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > Fix For: 2.0.0.Beta1 > > > See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html > This JIRA is for reflecting the attribute group notion in CLI behavior. > I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-553) Allow for alternative access control providers to be plugged into management.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-553?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved WFLY-553. ----------------------------------- Fix Version/s: (was: 10.0.0.Alpha1) Resolution: Done I'm closing this as a presumed duplicate. > Allow for alternative access control providers to be plugged into management. > ----------------------------------------------------------------------------- > > Key: WFLY-553 > URL: https://issues.jboss.org/browse/WFLY-553 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Authorization, Realm_Management > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

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 April 2015