October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7425) [GSS] (7.1.z) add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()

by Stephen Fikes (JIRA)

Stephen Fikes created WFLY-7425: ----------------------------------- Summary: [GSS] (7.1.z) add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader() Key: WFLY-7425 URL: https://issues.jboss.org/browse/WFLY-7425 Project: WildFly Issue Type: Enhancement Components: JPA / Hibernate Reporter: Stephen Fikes Assignee: Scott Marlow The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call. Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns. Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnit...] {quote} ClassLoader getNewTempClassLoader() Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call. Returns: temporary ClassLoader with same visibility as current loader {quote} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1911) Port DeploymentScannerTestCase to upstream

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugi... ] Peter Palaga commented on WFCORE-1911: -------------------------------------- > I moved this to WFCORE because WildFly Core is where tests like this belong. Even though it is an Arquillian integration test? > Port DeploymentScannerTestCase to upstream > ------------------------------------------ > > Key: WFCORE-1911 > URL: https://issues.jboss.org/browse/WFCORE-1911 > Project: WildFly Core > Issue Type: Task > Components: Deployment Scanner, Test Suite > Reporter: Peter Palaga > > The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1911) Port DeploymentScannerTestCase to upstream

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-7421 to WFCORE-1911: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1911 (was: WFLY-7421) Component/s: Deployment Scanner Test Suite (was: Test Suite) > Port DeploymentScannerTestCase to upstream > ------------------------------------------ > > Key: WFCORE-1911 > URL: https://issues.jboss.org/browse/WFCORE-1911 > Project: WildFly Core > Issue Type: Task > Components: Deployment Scanner, Test Suite > Reporter: Peter Palaga > > The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1911) Port DeploymentScannerTestCase to upstream

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1911: ------------------------------------------ I moved this to WFCORE because WildFly Core is where tests like this belong. > Port DeploymentScannerTestCase to upstream > ------------------------------------------ > > Key: WFCORE-1911 > URL: https://issues.jboss.org/browse/WFCORE-1911 > Project: WildFly Core > Issue Type: Task > Components: Deployment Scanner, Test Suite > Reporter: Peter Palaga > > The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7424) Singleton backup service cannot be overridden

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7424: ---------------------------------- Summary: Singleton backup service cannot be overridden Key: WFLY-7424 URL: https://issues.jboss.org/browse/WFLY-7424 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6841) Add backup service support for singleton services

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6841?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6841: ------------------------------- Issue Type: Bug (was: Feature Request) > Add backup service support for singleton services > ------------------------------------------------- > > Key: WFLY-6841 > URL: https://issues.jboss.org/browse/WFLY-6841 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6841) Singleton backup service cannot be overridden

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6841?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6841: ------------------------------- Summary: Singleton backup service cannot be overridden (was: Add backup service support for singleton services) > Singleton backup service cannot be overridden > --------------------------------------------- > > Key: WFLY-6841 > URL: https://issues.jboss.org/browse/WFLY-6841 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6841) Add backup service support for singleton services

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6841?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6841: ------------------------------------ Restating this jira as a bug, since apparently "Feature request" is too loaded. > Add backup service support for singleton services > ------------------------------------------------- > > Key: WFLY-6841 > URL: https://issues.jboss.org/browse/WFLY-6841 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7419) Add resteasy wadl as a module

by Frank Langelage (JIRA)

[ https://issues.jboss.org/browse/WFLY-7419?page=com.atlassian.jira.plugin.... ] Frank Langelage commented on WFLY-7419: --------------------------------------- This just adds the module. If you want to use it, in your REST application it's necessary to reference this module in your jboss-deployment-structure.xml: {code:xml} <sub-deployment name="rs-sales.war"> <dependencies> <module name="org.jboss.resteasy.resteasy-wadl"/> </dependencies> </sub-deployment> {code} and also add servlet mapping to your web.xml file: {code:xml} <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> <servlet> <servlet-name>WADL</servlet-name> <servlet-class>org.jboss.resteasy.wadl.ResteasyWadlServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>WADL</servlet-name> <url-pattern>/application.wadl</url-pattern> </servlet-mapping> </web-app> {code} > Add resteasy wadl as a module > ----------------------------- > > Key: WFLY-7419 > URL: https://issues.jboss.org/browse/WFLY-7419 > Project: WildFly > Issue Type: Enhancement > Components: REST > Affects Versions: 10.1.0.Final, 11.0.0.Alpha1 > Reporter: Frank Langelage > Assignee: Alessio Soldano > Fix For: 10.2.0.Final, 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-695) Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-695?page=com.atlassian.jira.plugin.sy... ] Hynek Švábek updated ELY-695: ----------------------------- Description: Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource. *Scenario:* * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore * I want to delete whole Elytron subsystem * I execute this CLI command */subsystem=elytron:remove()* and get error {code} { "outcome" => "failed", "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly", "rolled-back" => true } {code} *NOTES:* * When I perform CLI command */subsystem=elytron:remove()* again as it passes. * When I use for remove {allow-resource-service-restart=true} as /subsystem=elytron:remove(){allow-resource-service-restart=true} then result is successful. was: Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource. *Scenario:* * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore * I want to delete whole Elytron subsystem * I execute this CLI command */subsystem=elytron:remove()* and get error {code} { "outcome" => "failed", "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly", "rolled-back" => true } {code} > Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource. > ------------------------------------------------------------------------------------------------------- > > Key: ELY-695 > URL: https://issues.jboss.org/browse/ELY-695 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store, KeyStores > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource. > *Scenario:* > * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore > * I want to delete whole Elytron subsystem > * I execute this CLI command */subsystem=elytron:remove()* and get error > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly", > "rolled-back" => true > } > {code} > *NOTES:* > * When I perform CLI command */subsystem=elytron:remove()* again as it passes. > * When I use for remove {allow-resource-service-restart=true} as /subsystem=elytron:remove(){allow-resource-service-restart=true} then result is successful. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 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 October 2016