December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7739) Enable SymlinkingUnitTestCase on Linux

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-7739?page=com.atlassian.jira.plugin.... ] Chao Wang updated WFLY-7739: ---------------------------- Labels: downstream_dependency (was: ) > Enable SymlinkingUnitTestCase on Linux > -------------------------------------- > > Key: WFLY-7739 > URL: https://issues.jboss.org/browse/WFLY-7739 > Project: WildFly > Issue Type: Task > Components: Test Suite > Affects Versions: 10.1.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-864) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/SECURITY-864?page=com.atlassian.jira.plug... ] Philippe Marschall commented on SECURITY-864: --------------------------------------------- [~mletenay] No, read only JNDI seems to be feature of the modular service container based runtimes (JBoss AS 7+). JNDI is only writable during deployment. Maybe your module gets called during deployment of the application so you don't notice. Or a {{WritableServiceBasedNamingStore#pushOwner}} is missing in our case. We use EJB remoting and our login module gets called after deployment when the first EJB call is made. Right now we look at implementing a custom JNDI object factory, we'll keep you posted. > NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-864 > URL: https://issues.jboss.org/browse/SECURITY-864 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Reporter: Chao Wang > Assignee: Stefan Guilhen > > "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level: > {noformat} > <logger category="org.jboss.as.security"> > <level name="TRACE"/> > </logger> > <logger category="org.jboss.security"> > <level name="TRACE"/> > </logger> > {noformat} > See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134] > I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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

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

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

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

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

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

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

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

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