December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-718) Problems with creating CredentialStore from scratch when directory path doesn't exist.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-718?page=com.atlassian.jira.plugin.sy... ] Hynek Švábek updated ELY-718: ----------------------------- Priority: Critical (was: Major) > Problems with creating CredentialStore from scratch when directory path doesn't exist. > -------------------------------------------------------------------------------------- > > Key: ELY-718 > URL: https://issues.jboss.org/browse/ELY-718 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek Švábek > Assignee: Peter Skopek > Priority: Critical > > There are problems with creating CredentialStore from scratch when directory path doesn't exist. > *How to reproduce* > * /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/folderNotExist/keystorecs007.jceks?store.password=pass123;create.storage=true") > * /subsystem=elytron/credential-store=cs007/alias=newCs007:add(secret-value=Elytron) > *You can see this error message* > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot write storage file '/home/hsvabek/securityworkspace/AAA_prezentace/jboss-eap-7.1.0.DR7/standalone/data/folderNotExist/keystorecs007.jceks' for the store 'cs007''", > "rolled-back" => true > } > {code} > When you execute repeatedly last command /subsystem=elytron/credential-store=cs007/alias=newCs007:add(secret-value=Elytron) > you get information about duplicate resource. It's mean the entry is in Credential Store (in memory) but not in file... > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0212: Duplicate resource [ > (\"subsystem\" => \"elytron\"), > (\"credential-store\" => \"cs123\"), > (\"alias\" => \"newCs007\") > ]", > "rolled-back" => true > } > {code} > *My suggestion solutions of this two problems:* > * try to create directory path > * when fails creating of CredentialStore file then we remove entry from memory too. It can be confusing have entry only in memory. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

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

by Robert Lee (JIRA)

[ https://issues.jboss.org/browse/WFLY-7721?page=com.atlassian.jira.plugin.... ] Robert Lee commented on WFLY-7721: ---------------------------------- [~jmesnil] That's great news; thanks! > 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)

7 years, 5 months

1
0
0 / 0

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

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

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

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

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

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

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

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

7 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2016