November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7554) Singleton: @AccessTimeout and @Lock on superclass method not

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7554?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7554. ---------------------------------- Resolution: Done If you want to use annotation for an external module you need to make sure you import annotation indexes. (annotations="true" in jboss-deployment-structure.xml) > Singleton: @AccessTimeout and @Lock on superclass method not > ------------------------------------------------------------- > > Key: WFLY-7554 > URL: https://issues.jboss.org/browse/WFLY-7554 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.2.Final, 10.1.0.Final > Environment: Win7_64, Oracle Java 8/102 > Reporter: Stefan Lindner > Assignee: Stuart Douglas > > {code:java} > @AccessTimeout(value=54321) > class MySuperclass { > @AccessTimeout(value=1200000000000L) > public void whileBlocked() {....} > } > @Singleton > @Startup > @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) > @DependsOn("BenutzerControllerImpl") > @AccessTimeout(value=54321) > @Lock(LockType.READ) > class MyClass extends MySuperclass { > @Lock(LockType.WRITE) > public void myBlocker() {....} > } > {code} > Calling method {code:java}whileBlocked{code} when another thread has called {code:java}myBlocker{code} leads to Exception > javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on MyClass - could not obtain lock within 5000MILLISECONDS > The standard says: > {quote}The AccessTimeout annotation can be specified on a business method or on a bean class (or superclass). > {quote} > In short: > # @AccessTimeout annotations on bean's class or method work as expected > # Annotations on superclass do not -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2020) Port default core configuration to latest Elytron AuthenticationConfiguration

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2020: ---------------------------------------- Summary: Port default core configuration to latest Elytron AuthenticationConfiguration Key: WFCORE-2020 URL: https://issues.jboss.org/browse/WFCORE-2020 Project: WildFly Core Issue Type: Task Components: CLI, Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2019) Upgrade to JBoss Remoting 5.0.0.Beta9

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2019: ---------------------------------------- Summary: Upgrade to JBoss Remoting 5.0.0.Beta9 Key: WFCORE-2019 URL: https://issues.jboss.org/browse/WFCORE-2019 Project: WildFly Core Issue Type: Component Upgrade Components: Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4163) Support infinispan batch job repository

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFLY-4163?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero commented on WFLY-4163: ---------------------------------------------------- Any news on this one? Would be a great addition for the HA profiles. > Support infinispan batch job repository > --------------------------------------- > > Key: WFLY-4163 > URL: https://issues.jboss.org/browse/WFLY-4163 > Project: WildFly > Issue Type: Feature Request > Components: Batch > Affects Versions: 9.0.0.Alpha1 > Reporter: Cheng Fang > Assignee: James Perkins > > Infinispan / JDG batch job repository is expected to be in the upcoming JBeret milestone release. WildFly batch subsystem will need to update the subsystem configuration to support the same, including updating batch subsystem schema. > WFLY-3139 (Add MongoDB support for a batch repository) involves similar changes. > In JBeret SE distrobution, those configurations are specified in jberet.properties file. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7633) Allow to define Infinispan job repository for Batch subsystem

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFLY-7633?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero closed WFLY-7633. ---------------------------------------------- Resolution: Duplicate Issue Duplicated from WFLY-4163 > Allow to define Infinispan job repository for Batch subsystem > ------------------------------------------------------------- > > Key: WFLY-7633 > URL: https://issues.jboss.org/browse/WFLY-7633 > Project: WildFly > Issue Type: Feature Request > Components: Batch, Clustering > Reporter: Guillermo González de Agüero > Assignee: Cheng Fang > > According to its documentation, JBeret supports Infinispan caches as job repositories (https://jberet.gitbooks.io/jberet-user-guide/content/set_up_jberet/). However, WildFly only allows in memory and JDBC repositories (https://wildscribe.github.io/Wildfly/10.0.0.Final/subsystem/batch-jberet/...). > IMHO, an Infinispan based one should be the default in HA profiles. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7633) Allow to define Infinispan job repository for Batch subsystem

by Guillermo González de Agüero (JIRA)

Guillermo González de Agüero created WFLY-7633: -------------------------------------------------- Summary: Allow to define Infinispan job repository for Batch subsystem Key: WFLY-7633 URL: https://issues.jboss.org/browse/WFLY-7633 Project: WildFly Issue Type: Feature Request Components: Batch, Clustering Reporter: Guillermo González de Agüero Assignee: Cheng Fang According to its documentation, JBeret supports Infinispan caches as job repositories (https://jberet.gitbooks.io/jberet-user-guide/content/set_up_jberet/). However, WildFly only allows in memory and JDBC repositories (https://wildscribe.github.io/Wildfly/10.0.0.Final/subsystem/batch-jberet/...). IMHO, an Infinispan based one should be the default in HA profiles. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-368) Add optional Supplier<Provider[]> to realm implementations.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-368?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-368: -------------------------------------- Where realms create Credential instances they may also need to pass the Provider Supplier to the Credential so it can use it for subsequent Evidence verification. > Add optional Supplier<Provider[]> to realm implementations. > ----------------------------------------------------------- > > Key: ELY-368 > URL: https://issues.jboss.org/browse/ELY-368 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta15 > > > Realms use key factories, certificate factories, password factories, etc. Most of the time they just use the default installed providers. Enhance the realms to accept an optional {{Supplier<Provider[]>}} which will be used to load these kinds of things. The default supplier should be {{Security::getProviders()}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1364) InMemorySessionFactory has apparent memory leak

by Eli Israel (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1364?page=com.atlassian.jira.plugi... ] Eli Israel commented on DROOLS-1364: ------------------------------------ So, a quick correction: the SessionCache actually does NOT police its size, which means that fast-moving code can absolutely fill the cache up with many, many unused sessions, wreaking havoc on garbage collection as well. > InMemorySessionFactory has apparent memory leak > ----------------------------------------------- > > Key: DROOLS-1364 > URL: https://issues.jboss.org/browse/DROOLS-1364 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Eli Israel > Assignee: Mario Fusco > > I'm running drools with a runtime manager creating using PerRequest strategy and SessionCache turned on. (I process a LOT of requests but I want each one to be isolated) > The SessionCache properly gets rid of sessions that have hung around too long, which is great. > But the InMemorySessionFactory keeps a copy of every session it ever created, which -- it seems to me -- impedes garbage collection of unneeded, old sessions. > It's possible I'm just reading this wrong, but examinations of running code using VisualVM show a LOT of RightTuple objects hanging around, attached to sessions and their GC root appears to be the InMemorySessionFactory. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-128) Eliminate manually registering WildFlyElytronProvider for tests.

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-128: --------------------------------------- Summary: Eliminate manually registering WildFlyElytronProvider for tests. Key: REMJMX-128 URL: https://issues.jboss.org/browse/REMJMX-128 Project: Remoting JMX Issue Type: Task Components: Security, Tests Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha5 We should not be dependent on WildFlyElytronProvider registration especially in client side code as this library could be used in various environments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-775) Module free ServiceLoader discovery for Providers and Mechanism Factories

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-775: ------------------------------------ Summary: Module free ServiceLoader discovery for Providers and Mechanism Factories Key: ELY-775 URL: https://issues.jboss.org/browse/ELY-775 Project: WildFly Elytron Issue Type: Task Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta15 We still want ServiceLoader based discovery to work in non-modular environments, rather than adding a new element I think we rename the following: - {code:xml} <xsd:element name="use-module-providers" type="module-ref-type"/> <xsd:element name="use-module-sasl-factory" type="module-ref-type" /> {code} To use-service-loader-* Then make the attributes of module-ref-type optional and use the ClassLoader of the parser. I think in 99% of cases we will be looking for Elytron implementations so as the ClassLoader was able to load the parser it should have the rest of the Elytron service loader services.. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 November 2016