April 2015 - jboss-jira - Jboss List Archives

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

9 years, 8 months

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)

9 years, 8 months

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)

9 years, 8 months

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)

9 years, 8 months

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 updated DROOLS-775: ------------------------------------ Affects Version/s: (was: 6.3.0.Final) > 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)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4569) EntityBean instances are leaked from pool on certain exceptions

by Alexey Makhmutov (JIRA)

[ https://issues.jboss.org/browse/WFLY-4569?page=com.atlassian.jira.plugin.... ] Alexey Makhmutov updated WFLY-4569: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/7394 > EntityBean instances are leaked from pool on certain exceptions > --------------------------------------------------------------- > > Key: WFLY-4569 > URL: https://issues.jboss.org/browse/WFLY-4569 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final, 9.0.0.Beta2, 9.0.0.CR1 > Reporter: Alexey Makhmutov > > Entity beans instances may not be returned to the pool after certain exceptions, which may lead to pool exhaustion. > Currently, following two cases are discovered: > # If any exception is thrown from ejbCreate method (e.g. duplicate record was found in the database), then bean instance won’t be returned to the pool, as there are no try-finally statements around call to ejbCreate in EntityBeanEjbCreateMethodInterceptor/EntityBeanRemoteViewInstanceFactory classes for this call. > # If runtime exception (such as EJBException) is thrown from business method, then instance won’t be returned to the pool, as it will be marked as discarded by EntityBeanAssociatingInterceptor and both ReferenceCountingEntityCache/TransactionLocalEntityCache cache implementations just ignores discarded instance on release call. > These problems actually make impossible using of pooled instances with Entity beans, as number of used beans from pool will be steadily increasing in production until pool is exhausted and clients start getting ‘Failed to acquire permit’ exceptions. > Here is the set of integration tests, which examines the described behavior: https://github.com/Lerm/jboss-as/commit/f3eadd96d84dabc0a8b9c6c866ccfd5fe... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4569) EntityBean instances are leaked from pool on certain exceptions

by Alexey Makhmutov (JIRA)

Alexey Makhmutov created WFLY-4569: -------------------------------------- Summary: EntityBean instances are leaked from pool on certain exceptions Key: WFLY-4569 URL: https://issues.jboss.org/browse/WFLY-4569 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 9.0.0.Beta2, 8.2.0.Final, 9.0.0.CR1 Reporter: Alexey Makhmutov Entity beans instances may not be returned to the pool after certain exceptions, which may lead to pool exhaustion. Currently, following two cases are discovered: # If any exception is thrown from ejbCreate method (e.g. duplicate record was found in the database), then bean instance won’t be returned to the pool, as there are no try-finally statements around call to ejbCreate in EntityBeanEjbCreateMethodInterceptor/EntityBeanRemoteViewInstanceFactory classes for this call. # If runtime exception (such as EJBException) is thrown from business method, then instance won’t be returned to the pool, as it will be marked as discarded by EntityBeanAssociatingInterceptor and both ReferenceCountingEntityCache/TransactionLocalEntityCache cache implementations just ignores discarded instance on release call. These problems actually make impossible using of pooled instances with Entity beans, as number of used beans from pool will be steadily increasing in production until pool is exhausted and clients start getting ‘Failed to acquire permit’ exceptions. Here is the set of integration tests, which examines the described behavior: https://github.com/Lerm/jboss-as/commit/f3eadd96d84dabc0a8b9c6c866ccfd5fe... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4429) Refactor JCA subsystems

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-4429?page=com.atlassian.jira.plugin.... ] Jesper Pedersen updated WFLY-4429: ---------------------------------- Fix Version/s: 10.0.0.Alpha1 (was: 9.0.0.CR1) > Refactor JCA subsystems > ----------------------- > > Key: WFLY-4429 > URL: https://issues.jboss.org/browse/WFLY-4429 > Project: WildFly > Issue Type: Task > Components: JCA > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Priority: Critical > Fix For: 10.0.0.Alpha1 > > > Make use of PASSIVE services, and PersistentResource in :jca:, :datasources: and :resource-adapters: -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4430) Remove transport from DWM

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-4430?page=com.atlassian.jira.plugin.... ] Jesper Pedersen updated WFLY-4430: ---------------------------------- Fix Version/s: 10.0.0.Alpha1 (was: 9.0.0.CR1) > Remove transport from DWM > ------------------------- > > Key: WFLY-4430 > URL: https://issues.jboss.org/browse/WFLY-4430 > Project: WildFly > Issue Type: Task > Components: JCA > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Priority: Critical > Fix For: 10.0.0.Alpha1 > > > Remove 'transport' and 'transportType' from DWM. Use the unique name of the DWM for channel name -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4568) Remove support for jboss-as-resource-adapters_1_0.xsd

by Jesper Pedersen (JIRA)

Jesper Pedersen created WFLY-4568: ------------------------------------- Summary: Remove support for jboss-as-resource-adapters_1_0.xsd Key: WFLY-4568 URL: https://issues.jboss.org/browse/WFLY-4568 Project: WildFly Issue Type: Task Components: JCA Reporter: Jesper Pedersen Assignee: Stefano Maestri Fix For: 10.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015