December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7721) Support module slots for foreign JMS bridges

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-7721?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-7721: ----------------------------------- [~robertjlee] I confirm that in wildfly master branch it is already possible to specify a modulename:slot in the jms-bridge's module attribute. I have updated the JMSBridgeTest to check this feature. > Support module slots for foreign JMS bridges > -------------------------------------------- > > Key: WFLY-7721 > URL: https://issues.jboss.org/browse/WFLY-7721 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Robert Lee > Assignee: Jeff Mesnil > Labels: artemis, bridge, jmsbridge, modules, slot > > It would be nice to specify the slot, along with the module, for a JMS bridge. > *Use case*: > When setting up a JMS bridge with a foreign JMS system, the "module" option can be used (as a CLI parameter or an XML attribute) to specify the library code for the foreign JMS system, as a JBoss Module. > We have a number of different versions of a legacy messaging API. We have previously set up modules for direct use within our deployed application code, using different slots for different versions of the foreign JMS system. > We are now trying to migrate away from our different messaging systems towards Wildfly/Artemis, and have tried to set up JMS bridges to connect with the different systems. > Unfortunately, it is not possible to use any module slot other than "main" with a JMS bridge. There is no "slot" attribute in the XML, and if we try to use "modulename:slot" notation, then we get an error saying that the module could not be loaded. Turning up debugging shows it is looking for "modulename\:slot:main". > This seems like an omission, and is causing us to have to rework code to avoid the use of slots for different versions of the same library, which seems like a step backwards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7727) Support module slots for foreign JMS bridges

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-7727: --------------------------------- Summary: Support module slots for foreign JMS bridges Key: WFLY-7727 URL: https://issues.jboss.org/browse/WFLY-7727 Project: WildFly Issue Type: Feature Request Components: JMS Affects Versions: 10.0.0.Final Reporter: Jeff Mesnil Assignee: Jeff Mesnil It would be nice to specify the slot, along with the module, for a JMS bridge. *Use case*: When setting up a JMS bridge with a foreign JMS system, the "module" option can be used (as a CLI parameter or an XML attribute) to specify the library code for the foreign JMS system, as a JBoss Module. We have a number of different versions of a legacy messaging API. We have previously set up modules for direct use within our deployed application code, using different slots for different versions of the foreign JMS system. We are now trying to migrate away from our different messaging systems towards Wildfly/Artemis, and have tried to set up JMS bridges to connect with the different systems. Unfortunately, it is not possible to use any module slot other than "main" with a JMS bridge. There is no "slot" attribute in the XML, and if we try to use "modulename:slot" notation, then we get an error saying that the module could not be loaded. Turning up debugging shows it is looking for "modulename\:slot:main". This seems like an omission, and is causing us to have to rework code to avoid the use of slots for different versions of the same library, which seems like a step backwards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to 100% and does not respond

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7275. ---------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done > Wildfly eats the CPU up to 100% and does not respond > ---------------------------------------------------- > > Key: WFLY-7275 > URL: https://issues.jboss.org/browse/WFLY-7275 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit > Reporter: Krisztian Kocsis > Assignee: Stuart Douglas > Fix For: 11.0.0.Alpha1 > > Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt > > > Hi! > > I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server. > It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile. > > I'v attached the stack trace but I unfortunately don't see anything according to my knowledge. > Please help me, I can provide more information if necessary. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7726) Expose @DataSourceDefiniton connections in the deployment model

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

[ https://issues.jboss.org/browse/WFLY-7726?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero updated WFLY-7726: ----------------------------------------------- Description: When a Datasource is defined either using @DatasourceDefinition or via web.xml, it isn't registered in the deployment model at /deployment=xx.war/subsystem=datasources. It works as expected when deploying the datasource via the deprecated *-ds.xml way. Looking at the code, it seems that DataSourceDefinitionAnnotationProcessor and DataSourceDefinitionDescriptorProcessor just need to add the resource to the org.jboss.as.server.deployment.Attachments.DEPLOYMENT_RESOURCE_SUPPORT as DsXmlDeploymentInstallProcessor does. was: When a Datasource is defined either using @DatasourceDefinition or via web.xml, it isn't registered in the deployment model at /deployment=xx.war/subsystem=datasources. It works as expected when deploying the datasource via the deprecated *-ds.xml way. > Expose @DataSourceDefiniton connections in the deployment model > --------------------------------------------------------------- > > Key: WFLY-7726 > URL: https://issues.jboss.org/browse/WFLY-7726 > Project: WildFly > Issue Type: Enhancement > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Stefano Maestri > > When a Datasource is defined either using @DatasourceDefinition or via web.xml, it isn't registered in the deployment model at /deployment=xx.war/subsystem=datasources. > It works as expected when deploying the datasource via the deprecated *-ds.xml way. > Looking at the code, it seems that DataSourceDefinitionAnnotationProcessor and DataSourceDefinitionDescriptorProcessor just need to add the resource to the org.jboss.as.server.deployment.Attachments.DEPLOYMENT_RESOURCE_SUPPORT as DsXmlDeploymentInstallProcessor does. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7726) Expose @DataSourceDefiniton connections in the deployment model

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

[ https://issues.jboss.org/browse/WFLY-7726?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero updated WFLY-7726: ----------------------------------------------- Description: When a Datasource is defined either using @DatasourceDefinition or via web.xml, it isn't registered in the deployment model at /deployment=xx.war/subsystem=datasources. It works as expected when deploying the datasource via the deprecated *-ds.xml way. was: When a Datasource is defined either using @DatasourceDefinition or via web.xml, it isn't visible from the deployment model at /deployment=xx.war/subsystem=datasources. It works as expected when deploying the datasource via the deprecated *-ds.xml way. > Expose @DataSourceDefiniton connections in the deployment model > --------------------------------------------------------------- > > Key: WFLY-7726 > URL: https://issues.jboss.org/browse/WFLY-7726 > Project: WildFly > Issue Type: Enhancement > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Stefano Maestri > > When a Datasource is defined either using @DatasourceDefinition or via web.xml, it isn't registered in the deployment model at /deployment=xx.war/subsystem=datasources. > It works as expected when deploying the datasource via the deprecated *-ds.xml way. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7726) Expose @DataSourceDefiniton connections in the deployment model

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

Guillermo González de Agüero created WFLY-7726: -------------------------------------------------- Summary: Expose @DataSourceDefiniton connections in the deployment model Key: WFLY-7726 URL: https://issues.jboss.org/browse/WFLY-7726 Project: WildFly Issue Type: Enhancement Components: JCA Affects Versions: 10.1.0.Final Reporter: Guillermo González de Agüero Assignee: Stefano Maestri When a Datasource is defined either using @DatasourceDefinition or via web.xml, it isn't visible from the deployment model at /deployment=xx.war/subsystem=datasources. It works as expected when deploying the datasource via the deprecated *-ds.xml way. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-812) JAR command action: list and access credential store contents

by David Lloyd (JIRA)

David Lloyd created ELY-812: ------------------------------- Summary: JAR command action: list and access credential store contents Key: ELY-812 URL: https://issues.jboss.org/browse/ELY-812 Project: WildFly Elytron Issue Type: Task Components: Command-Line Tool Reporter: David Lloyd It should be possible using the standalone Elytron JAR to access and list the contents of a credential store, of any format, including vault. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7219) Wrong description of missing target-name in simple-permission-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7219?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7219: ---------------------------------- Ok, I has try it, but as [~dmlloyd] noticed, there is not guaranteed that Permission define constructor for all allowed combinations - the null can be allowed in arguments... I can catch the exception (or just InvalidArgumentException), but there is not guaranteed that the exception was caused by given argument... I think we will have to close this as impossible in general. > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: WFLY-7219 > URL: https://issues.jboss.org/browse/WFLY-7219 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Labels: user_experience > Fix For: 11.0.0.Alpha1 > > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-811) Only AlgorithmCredentials should have parameters

by David Lloyd (JIRA)

David Lloyd created ELY-811: ------------------------------- Summary: Only AlgorithmCredentials should have parameters Key: ELY-811 URL: https://issues.jboss.org/browse/ELY-811 Project: WildFly Elytron Issue Type: Bug Components: Credentials Reporter: David Lloyd Only credentials which have algorithms should have parameters. If a credential needs parameters, it probably needs an algorithm. You need an algorithm name in order to acquire an AlgorithmParameters object, which is the only thing that can encode/decode algorithm parameters. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-810) Unify CredentialStore around CredentialSource style storage capability

by David Lloyd (JIRA)

David Lloyd created ELY-810: ------------------------------- Summary: Unify CredentialStore around CredentialSource style storage capability Key: ELY-810 URL: https://issues.jboss.org/browse/ELY-810 Project: WildFly Elytron Issue Type: Task Components: Credential Store Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta17 The following needs to be done: * Move the PB masked password format to a proper password type * Introduce protection parameters for credential stores and entries * Drop the admin_key concept in favor of credential store protection parameters * Introduce a proper vault-compatible credential store * Introduce a mechanism to pull protection parameters for stores from the client configuration * Use a credential store which can store (nearly) any credential type * Update XML accordingly * Remove dangerous command execution patterns from credential store, make them safe and make them CredentialSources instead * Clean up exception hierarchy of credential stores * Introduce simple map-backed credential store Additionally, the above implies: * Introduce AlgorithmParameterSpi for password parameter types * Introduce hashing ability for parameters * Add missing parameter types for PBE * Introduce serialization trickery to support picketbox class names for vault files * Atomic file output stream * Update tests as needed -- 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 December 2016