December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7748) JBoss does not return exception with stack trace if the service address is not localhost or loopback ip

by Khoa Tran (JIRA)

[ https://issues.jboss.org/browse/WFLY-7748?page=com.atlassian.jira.plugin.... ] Khoa Tran commented on WFLY-7748: --------------------------------- Thank Tomaz, will try as advised. Just wonder if this is documented, maybe its just me but I couldn't find document about it. A little context, my GWT application (client side) depends on the exception having stack trace, so that base on the stack trace information it can generate appropriate message. When moving to JBOSS 7, without knowing this setting, all the exception lost information, thus result in my application behave incorrectly > JBoss does not return exception with stack trace if the service address is not localhost or loopback ip > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-7748 > URL: https://issues.jboss.org/browse/WFLY-7748 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Window OS: win 7 > JDK version: 1.8.0_112 > Reporter: Khoa Tran > Priority: Critical > Attachments: Replication.docx, WebException.zip, standalone.xml > > > For this JBOSS release 7.0.1.GA, exception return to client upon processing HTTP Request is not consistent. How the exception return surprisingly depends on the ipaddress (of the server). > What I mean is: > - Using 127.0.0.1 or localhost as part of address, exception is return fine, with proper stack trace > - Using PC domain name, or lan ip adrress, the exception return is just "Internal Server Error", no stack trace - this look like JBoss error to me. > Please view attach document for detail, also there is sample project and standalone xml included. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7748) JBoss does not return exception with stack trace if the service address is not localhost or loopback ip

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7748?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-7748. ----------------------------- Resolution: Rejected This is by design. By default stacktraces are only shown for local requests as that reflects development needs. You can change that by configuring servlet-conteiner in undertow subsystem differently {code:xml} <servlet-container name="default" stack-trace-on-error="all" >.. {code} to show stacktraces for all requests > JBoss does not return exception with stack trace if the service address is not localhost or loopback ip > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-7748 > URL: https://issues.jboss.org/browse/WFLY-7748 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Window OS: win 7 > JDK version: 1.8.0_112 > Reporter: Khoa Tran > Priority: Critical > Attachments: Replication.docx, WebException.zip, standalone.xml > > > For this JBOSS release 7.0.1.GA, exception return to client upon processing HTTP Request is not consistent. How the exception return surprisingly depends on the ipaddress (of the server). > What I mean is: > - Using 127.0.0.1 or localhost as part of address, exception is return fine, with proper stack trace > - Using PC domain name, or lan ip adrress, the exception return is just "Internal Server Error", no stack trace - this look like JBoss error to me. > Please view attach document for detail, also there is sample project and standalone xml included. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7748) JBoss does not return exception with stack trace if the service address is not localhost or loopback ip

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7748?page=com.atlassian.jira.plugin.... ] Tomaz Cerar moved JBWEB-315 to WFLY-7748: ----------------------------------------- Project: WildFly (was: JBoss Web) Key: WFLY-7748 (was: JBWEB-315) Workflow: GIT Pull Request workflow (was: classic default workflow) Affects Version/s: 10.1.0.Final (was: JBossWeb-7.0.1.GA ) > JBoss does not return exception with stack trace if the service address is not localhost or loopback ip > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-7748 > URL: https://issues.jboss.org/browse/WFLY-7748 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Environment: Window OS: win 7 > JDK version: 1.8.0_112 > Reporter: Khoa Tran > Assignee: Remy Maucherat > Priority: Critical > Attachments: Replication.docx, WebException.zip, standalone.xml > > > For this JBOSS release 7.0.1.GA, exception return to client upon processing HTTP Request is not consistent. How the exception return surprisingly depends on the ipaddress (of the server). > What I mean is: > - Using 127.0.0.1 or localhost as part of address, exception is return fine, with proper stack trace > - Using PC domain name, or lan ip adrress, the exception return is just "Internal Server Error", no stack trace - this look like JBoss error to me. > Please view attach document for detail, also there is sample project and standalone xml included. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7748) JBoss does not return exception with stack trace if the service address is not localhost or loopback ip

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7748?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-7748: --------------------------------- Assignee: (was: Remy Maucherat) > JBoss does not return exception with stack trace if the service address is not localhost or loopback ip > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-7748 > URL: https://issues.jboss.org/browse/WFLY-7748 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Environment: Window OS: win 7 > JDK version: 1.8.0_112 > Reporter: Khoa Tran > Priority: Critical > Attachments: Replication.docx, WebException.zip, standalone.xml > > > For this JBOSS release 7.0.1.GA, exception return to client upon processing HTTP Request is not consistent. How the exception return surprisingly depends on the ipaddress (of the server). > What I mean is: > - Using 127.0.0.1 or localhost as part of address, exception is return fine, with proper stack trace > - Using PC domain name, or lan ip adrress, the exception return is just "Internal Server Error", no stack trace - this look like JBoss error to me. > Please view attach document for detail, also there is sample project and standalone xml included. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7748) JBoss does not return exception with stack trace if the service address is not localhost or loopback ip

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7748?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-7748: ------------------------------ Component/s: Web (Undertow) > JBoss does not return exception with stack trace if the service address is not localhost or loopback ip > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-7748 > URL: https://issues.jboss.org/browse/WFLY-7748 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Window OS: win 7 > JDK version: 1.8.0_112 > Reporter: Khoa Tran > Priority: Critical > Attachments: Replication.docx, WebException.zip, standalone.xml > > > For this JBOSS release 7.0.1.GA, exception return to client upon processing HTTP Request is not consistent. How the exception return surprisingly depends on the ipaddress (of the server). > What I mean is: > - Using 127.0.0.1 or localhost as part of address, exception is return fine, with proper stack trace > - Using PC domain name, or lan ip adrress, the exception return is just "Internal Server Error", no stack trace - this look like JBoss error to me. > Please view attach document for detail, also there is sample project and standalone xml included. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2141) RingBuffer should implement BlockingQueue

by Bela Ban (JIRA)

Bela Ban created JGRP-2141: ------------------------------ Summary: RingBuffer should implement BlockingQueue Key: JGRP-2141 URL: https://issues.jboss.org/browse/JGRP-2141 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.1 Then we could use RingBuffer and queue in ThreadPoolExecutor -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2138) Request.viewChange() implementations should not use View.getMembers()

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2138?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2138: -------------------------------- OK, extending GenericList<Address> and implementing get(int index) did the job. Now getMembers() returns this and therefore we have _no_ copying at all... > Request.viewChange() implementations should not use View.getMembers() > --------------------------------------------------------------------- > > Key: JGRP-2138 > URL: https://issues.jboss.org/browse/JGRP-2138 > Project: JGroups > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.12, 4.0 > > > {{Request.viewChange()}} is called once for every request, and {{View.getMembers()}} allocates 2 (small) objects. Both {{UnicastRequest}} and {{GroupRequest}} could use {{View.containsMember()}} instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-820) CredentialStore is not able to create CS file which was deleted after server startup.

by Hynek Švábek (JIRA)

Hynek Švábek created ELY-820: -------------------------------- Summary: CredentialStore is not able to create CS file which was deleted after server startup. Key: ELY-820 URL: https://issues.jboss.org/browse/ELY-820 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek Švábek Assignee: Darran Lofthouse CredentialStore is not able to create CS file which was deleted after server startup. CS file is recreated only if create.storage is set to true. But this feature would work with create.storage too. What do you think about it? *How to reproduce:* these steps are for creating CS file /subsystem=elytron/credential-store=recreate001:add(uri="cr-store://test/recreate001.jceks?store.password=pass123;create.storage=true") /subsystem=elytron/credential-store=recreate001/alias=alias001:add(secret-value=Elytron) *Own reproducer:* * /subsystem=elytron/credential-store=recreateCS:add(uri="cr-store://test/recreate001.jceks?store.password=pass123;create.storage=false") * /subsystem=elytron/credential-store=recreateCS/alias=alias2:add(secret-value=Elytron123) * *NOW* delete recreate001.jceks from filesystem * /subsystem=elytron/credential-store=recreateCS/alias=alias3:add(secret-value=Elytron123) * FAIL {code} { "outcome" => "failed", "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot write storage file '/home/hsvabek/securityworkspace/VERIFICATION/CredentialStore_2016_09_14/jboss-eap-7.1.0.DR9/standalone/data/recreate001.jceks' for the store 'recreateCS''", "rolled-back" => true } {code} * https://github.com/wildfly-security/wildfly-elytron/blob/5f0ed115ea265240... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-820) CredentialStore is not able to create CS file which was deleted after server startup.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-820?page=com.atlassian.jira.plugin.sy... ] Hynek Švábek reassigned ELY-820: -------------------------------- Assignee: Peter Skopek (was: Darran Lofthouse) > CredentialStore is not able to create CS file which was deleted after server startup. > ------------------------------------------------------------------------------------- > > Key: ELY-820 > URL: https://issues.jboss.org/browse/ELY-820 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek Švábek > Assignee: Peter Skopek > > CredentialStore is not able to create CS file which was deleted after server startup. > CS file is recreated only if create.storage is set to true. But this feature would work with create.storage too. > What do you think about it? > *How to reproduce:* > these steps are for creating CS file > /subsystem=elytron/credential-store=recreate001:add(uri="cr-store://test/recreate001.jceks?store.password=pass123;create.storage=true") > /subsystem=elytron/credential-store=recreate001/alias=alias001:add(secret-value=Elytron) > *Own reproducer:* > * /subsystem=elytron/credential-store=recreateCS:add(uri="cr-store://test/recreate001.jceks?store.password=pass123;create.storage=false") > * /subsystem=elytron/credential-store=recreateCS/alias=alias2:add(secret-value=Elytron123) > * *NOW* delete recreate001.jceks from filesystem > * /subsystem=elytron/credential-store=recreateCS/alias=alias3:add(secret-value=Elytron123) > * FAIL > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot write storage file '/home/hsvabek/securityworkspace/VERIFICATION/CredentialStore_2016_09_14/jboss-eap-7.1.0.DR9/standalone/data/recreate001.jceks' for the store 'recreateCS''", > "rolled-back" => true > } > {code} > * https://github.com/wildfly-security/wildfly-elytron/blob/5f0ed115ea265240... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-669) Create "behavesAs" operator to support traiting

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-669?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-669: ------------------------------------------ Fix Version/s: 7.0.0.Beta5 (was: 7.0.0.Beta4) > Create "behavesAs" operator to support traiting > ----------------------------------------------- > > Key: DROOLS-669 > URL: https://issues.jboss.org/browse/DROOLS-669 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.2.0.CR3 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.Beta5 > > > Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation. -- 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