October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7400) JGroups channels should only use JMX if the associated capability is available.

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7400: ---------------------------------- Summary: JGroups channels should only use JMX if the associated capability is available. Key: WFLY-7400 URL: https://issues.jboss.org/browse/WFLY-7400 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-696) Elytron Client needs to support RealmCallback where realm not set in advance

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-696: ------------------------------------ Summary: Elytron Client needs to support RealmCallback where realm not set in advance Key: ELY-696 URL: https://issues.jboss.org/browse/ELY-696 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 1.1.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7399) Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated."

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7399: ------------------------------------ Summary: Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated." Key: WFLY-7399 URL: https://issues.jboss.org/browse/WFLY-7399 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Paul Ferraro Integrate MANUAL eviction strategy introduced in ISPN-6911. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7398) Tab completion causes NUL characters ('\0') to be injected...sometimes

by David Lloyd (JIRA)

David Lloyd created WFLY-7398: --------------------------------- Summary: Tab completion causes NUL characters ('\0') to be injected...sometimes Key: WFLY-7398 URL: https://issues.jboss.org/browse/WFLY-7398 Project: WildFly Issue Type: Bug Components: CLI Reporter: David Lloyd Assignee: Jason Greene Priority: Critical I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input. These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden. My "less" output of .jboss-cli-history looks something like this: {noformat} embed-server --std-out=echo cd subsystem=discovery ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}]) ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}]) {noformat} In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand. The "^@" are in inverse video in less, indicating a NUL character. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 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: ----------------------------- Component/s: Credential Store KeyStores > 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} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 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: ----------------------------- Steps to Reproduce: * firefly.keystore which is attached copy to eap_home/standalone/data/cs. * run EAP server ./bin/standalone.sh * run CLI ./bin/jboss-cli.sh -c if applicaple add Elytron extension and Elytron subsystem and reload server /extension=org.wildfly.extension.elytron:add() /subsystem=elytron:add() reload * /subsystem=elytron/credential-store=credStore:add(uri="cr-store://test/cs/scratchSC.jceks?create.storage=true;store.password=pass123" * /subsystem=elytron/credential-store=credStore/alias=ff:add(secret-value=Elytron) * /subsystem=elytron/key-store=firefly:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=credStore,alias=ff}) * /subsystem=elytron:remove() was: * firefly.keystore which is attached copy to eap_home/standalone/data/cs. * run EAP server ./bin/standalone.sh * run CLI ./bin/jboss-cli.sh -c if applicaple add Elytron extension and Elytron subsystem and reload server /extension=org.wildfly.extension.elytron:add() /subsystem=elytron:add() reload * /subsystem=elytron/credential-store=credStore:add(uri="cr-store://test/cs/scratchSC.jceks?create.storage=true;store.password=pass123" * /subsystem=elytron/credential-store=credStore/alias=ff:add(secret-value=Elytron) * /subsystem=elytron/key-store=firefly:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=credStore,alias=ff}) * /subsystem=elytron/credential-store=credStore:remove() > 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} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 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)

Hynek Švábek created ELY-695: -------------------------------- Summary: 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 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} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1902) Error messages from CLI batch should be more informative

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1902: ---------------------------------------------- Hi Marek, helping user to identify the source of an error is definitely helpful. I guess that you want to help user mainly when a batch is located inside script. - Adding the command (or operation) that was failing in addition to the step number could be helpful. This could be helpful both in interactive and inside a script. - Script line number. There is no support for script line number today. To match a script line to its output, you can use the --echo-command option. Every command will be printed prior to be executed. That should already help user with large scripts. Step line inside a script are not that easy to retrieve due to multi-line support. For example: batch :read-attribute(\ name=name) :read-attribute(\ name=nonsence) run-batch Line of failing run-batch is 6, what is the line of failing step-2? This could be implemented in the CLI today and/or in the CLI.next. I personally like the idea. I am surprised that no customer already required it. > Error messages from CLI batch should be more informative > -------------------------------------------------------- > > Key: WFCORE-1902 > URL: https://issues.jboss.org/browse/WFCORE-1902 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 3.0.0.Alpha10 > Reporter: Marek Kopecký > Assignee: Jean-Francois Denise > > *Description of problem:* > Error messages from CLI batch should be more informative > *Steps to Reproduce:* > {noformat} > cat <<EOF >a > batch > :read-attribute(name=product-version) > :read-attribute(name=product-name) > :read-attribute(name=nonsence) > :read-attribute(name=product-name) > run-batch > EOF > ./jboss-cli.sh -c --file=a > {noformat} > *Actual results:* > {noformat} > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}} > {noformat} > *Expected results:* > I can imagine content like following could be helpful for troubleshooting: > {noformat} > { > "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => { > "Operation step-3" => { > "line number" => 4 > "operation" => ":read-attribute(name=nonsence)" > "response" => "WFLYCTL0201: Unknown attribute 'nonsence'" > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SASL-78) Invalid manifest section in jboss-sasl JAR

by Björn Kautler (JIRA)

[ https://issues.jboss.org/browse/SASL-78?page=com.atlassian.jira.plugin.sy... ] Björn Kautler commented on SASL-78: ----------------------------------- Actually I did not have the problem with jboss-sasl as we don't use it in our WebStart application. I had the problem with other libs and then checked all libs that we have in our local Ivy repository for JARs with invalid manifest entries. If this project is EOL and replaced by a new project that does not have this problem, I guess it is fine and you can close the issue as wont-fix. :-) > Invalid manifest section in jboss-sasl JAR > ------------------------------------------ > > Key: SASL-78 > URL: https://issues.jboss.org/browse/SASL-78 > Project: SASL Provider > Issue Type: Bug > Components: Build > Affects Versions: 1.0.4.Final, 1.0.5.Final > Reporter: Björn Kautler > Assignee: Darran Lofthouse > > In the {{MANIFEST.MF}} of your {{jboss-sasl}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. (You are still using jboss-parent 7, if you upgrade to 8 or newer, the problem will be gone) > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7217) Adapt servlet-security example to use Elytron

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/WFLY-7217?page=com.atlassian.jira.plugin.... ] Sande Gilda reassigned WFLY-7217: --------------------------------- Assignee: Tomaz Cerar (was: Sande Gilda) > Adapt servlet-security example to use Elytron > --------------------------------------------- > > Key: WFLY-7217 > URL: https://issues.jboss.org/browse/WFLY-7217 > Project: WildFly > Issue Type: Bug > Components: Documentation > Reporter: Ingo Weiss > Assignee: Tomaz Cerar > Priority: Minor > Original Estimate: 2 hours > Time Spent: 2 hours > Remaining Estimate: 0 minutes > -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 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 October 2016