December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6128) In domain mode after some CLI I was not able to restart a particular host until..

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/AS7-6128?page=com.atlassian.jira.plugin.s... ] Emanuel Muckenhuber commented on AS7-6128: ------------------------------------------ If this is happening with EAP 600 - then this might be fixed already. I assume the CLI appears to be hanging? In case you can reproduce this - can you grab a thread-dump? It might be related to some remote connection close issue we had. > In domain mode after some CLI I was not able to restart a particular host until.. > --------------------------------------------------------------------------------- > > Key: AS7-6128 > URL: https://issues.jboss.org/browse/AS7-6128 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management > Environment: Linux and EAP 6 > Reporter: Jim Tyrrell > Assignee: Brian Stansberry > > Running the examples in the JB348 Admin II class around the CLI section I uncovered an odd error, that I was not able to reproduce, and no one else seemed to have, but I thought I should log it here. > In the class last week I was doing the CLI activities per the guide on a domain instance. I fat fingered a bunch of things, and was getting errors. Once I was done making the changes with any errors I tried to restart host1 in the web console. This errored out without a good error message. After a few times of that I tried cntrl-cing in the console, only to have the server shutdown after about 5 minutes or so of hitting cntrl-c. I did not notice any error messages, but it makes me think some sort of racing, or locking condition exists in domain mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-6128) In domain mode after some CLI I was not able to restart a particular host until..

by Michael Harvey (JIRA)

[ https://issues.jboss.org/browse/AS7-6128?page=com.atlassian.jira.plugin.s... ] Michael Harvey commented on AS7-6128: ------------------------------------- Jim, Can you elaborate more precisely on steps? "I was doing the CLI activities per the guide on a domain instance. I fat fingered a bunch of things, and was getting errors." Were you able to recover any logs with error messages directly after the server non-responding incident/potential race condition and prior to the restart? This is going to be very hard to get to the bottom of and debug given the limited nature of the report. > In domain mode after some CLI I was not able to restart a particular host until.. > --------------------------------------------------------------------------------- > > Key: AS7-6128 > URL: https://issues.jboss.org/browse/AS7-6128 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management > Environment: Linux and EAP 6 > Reporter: Jim Tyrrell > Assignee: Brian Stansberry > > Running the examples in the JB348 Admin II class around the CLI section I uncovered an odd error, that I was not able to reproduce, and no one else seemed to have, but I thought I should log it here. > In the class last week I was doing the CLI activities per the guide on a domain instance. I fat fingered a bunch of things, and was getting errors. Once I was done making the changes with any errors I tried to restart host1 in the web console. This errored out without a good error message. After a few times of that I tried cntrl-cing in the console, only to have the server shutdown after about 5 minutes or so of hitting cntrl-c. I did not notice any error messages, but it makes me think some sort of racing, or locking condition exists in domain mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-944) Not possible to get access to the underlying DataSource through WrapperDataSource

by Shay Matasaro (JIRA)

[ https://issues.jboss.org/browse/JBJCA-944?page=com.atlassian.jira.plugin.... ] Shay Matasaro commented on JBJCA-944: ------------------------------------- Hi Siamak, Jesper's suggestion is that start a thread in the forum regarding this item. Shay > Not possible to get access to the underlying DataSource through WrapperDataSource > --------------------------------------------------------------------------------- > > Key: JBJCA-944 > URL: https://issues.jboss.org/browse/JBJCA-944 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.0.11.Final > Reporter: Siamak Sadeghianfar > Assignee: Jesper Pedersen > Priority: Critical > > JNDI lookup for a datasource on EAP 6.0 returns an instance of WrapperDataSource [1] and since it doesn't override JBossWrapper.getWrappedObject() [2] which is in the super class, unwrap() always returns null. > WrapperDataSource should override getWrappedObject() as stated in the javadoc to return the underlying datasource. > With the current implementation, the following code always throws exception: > {code:java} > Context ctx = new InitialContext(); > DataSource ds = (DataSource)ctx.lookup("jboss/datasources/ExampleDS"); > OracleDataSource unwrapped = null; > > if (ds instanceof WrapperDataSource) { > WrapperDataSource wrapper = (WrapperDataSource) ds; > try { > unwrapped = wrapper.unwrap(OracleDataSource.class); > } catch (SQLException e) { > e.printStackTrace(); > } > } > {code} > {noformat} > 13:30:38,354 ERROR [stderr] (MSC service thread 1-2) java.sql.SQLException: Not a wrapper for: oracle.jdbc.pool.OracleDataSource > 13:30:38,354 ERROR [stderr] (MSC service thread 1-2) at org.jboss.jca.adapters.jdbc.JBossWrapper.unwrap(JBossWrapper.java:82) > {noformat} > [1] http://source.jboss.org/browse/IronJacamar/tags/IRONJACAMAR_1_0_11_FINAL/... > [2] http://source.jboss.org/browse/IronJacamar/tags/IRONJACAMAR_1_0_11_FINAL/... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-709) Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available

by Yi Chen (JIRA)

[ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plug... ] Yi Chen commented on SECURITY-709: ---------------------------------- Hi, Anil Thanks for looking into this. Here is my reasoning for reporting this: I believe the fundamental issue is that the authentication did *not* fail – it was not performed, because of a failure in the server. How the failure is diagnosed, by whom, and with what tools is beside the point. The description at the W3C’s website of the rfc2616 codes (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) is: 10.4.2 401 Unauthorized The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43]. An inability for JBoss to perform authentication because the LDAP server is down/unreachable/misconfigured is not an authentication problem. Instead, W3C says 10.5 Server Error 5xx Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method. I’m not wedded to this being a 500 – it could be 503 (service unavailable) or 504 (Gateway Timeout). The rationale here is that the authentication is being done on behalf of a client who is using what s/he believes to be the correct credentials. A 401, where credentials have been submitted, would suggest the credentials are in error – which leads to two behaviours: - Clients will stop auto-login attempts (e.g. when returning to a wireless network) because bad credentials aren’t going to get better by resubmitting them. - Users will be confused and angry because their valid credentials are apparently being submitted, and then denied – which in the absence of any other information suggests the (JBoss) service is non-deterministic (a.k.a. “broken”). By returning a 500-series code, we do not call into question the quality of the authentication tokens – we indicate to the client and to the end user that we are having difficulty in completing their request: i.e. the problem is at *this* end of the wire, not *their* end of the wire. Agreed the administrator needs to fix it – but we shouldn’t be misleading the end user on the way. Thanks, Yi > Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available > --------------------------------------------------------------------------------------- > > Key: SECURITY-709 > URL: https://issues.jboss.org/browse/SECURITY-709 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_v4_0_7 > Reporter: Yi Chen > Assignee: Anil Saldhana > > I am using the LdapLoginModule from PicketBox in JBoss AS 7.1.1 to enable authentication against our company's LDAP server. However, I always get a HTTP 401 back no matter what kind of problem caused the authentication failure. Tracing through the Picketbox and JBoss code, I found that the problem seems to be from the private method "proceedWithJaasLogin" in "JBossCachedAuthenticationManager". At the end of this method: > ... > catch (LoginException e) > { > // Don't log anonymous user failures unless trace level logging is on > if (principal != null && principal.getName() != null || trace) > log.error("Login failure", e); > authException = e; > } > // Set the security association thread context info exception > SubjectActions.setContextInfo("org.jboss.security.exception", authException); > return authenticated; > } > So basically, whatever exception that was sent up from the login modules is simply store in the thread context. The methods then simply returns true or false to indicate whether an authentication is successful or not. Whatever exception is store in the thread context doesn't appear to be used to generate a more appropriate error code to the client. > Steps to reproduce: > Just set up a LdapLoginModule and verify that it can be used to authenticate some users for a web application. Then shut down the LDAP server and try again. The client of the web application will always get back HTTP 401. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-5255) Deployed log4j.properties does not affect non log4j logging systems

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/AS7-5255?page=com.atlassian.jira.plugin.s... ] James Perkins commented on AS7-5255: ------------------------------------ Link to PR for log4j-jboss-logmanager https://github.com/jboss-logging/log4j-jboss-logmanager/pull/1 > Deployed log4j.properties does not affect non log4j logging systems > ------------------------------------------------------------------- > > Key: AS7-5255 > URL: https://issues.jboss.org/browse/AS7-5255 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.1.2.Final (EAP) > Reporter: Patrick Ruckstuhl > Assignee: James Perkins > Priority: Blocker > Fix For: 7.2.0.Alpha1 > > > If I create the file > my.ear/META-INF/log4j.properties > with > log4j.rootLogger=DEBUG, FA > log4j.appender.FA=org.apache.log4j.FileAppender > log4j.appender.FA.File=/tmp/my.log > log4j.appender.FA.layout=org.apache.log4j.PatternLayout > log4j.appender.FA.layout.ConversionPattern= %-4r [%t] %-5p %c %x - %m%n > this results in nothing in the server.log and an empty /tmp/my.log > but if I create a > my.ear/META-INF/logging.properties > this results in everything beeing logged to /tmp/my.log > We're using SLF4J in our application and also using a library that uses COMMONS-LOGGING > I also did a test with doing an additional log statement using the log4j api directly and this one (and only this one) did get logged to /tmp/my.log -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-6152) Content repository view broken?

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/AS7-6152?page=com.atlassian.jira.plugin.s... ] Heiko Braun commented on AS7-6152: ---------------------------------- upload jboss-as-login.war to an empty repository on a domain with two hosts > Content repository view broken? > ------------------------------- > > Key: AS7-6152 > URL: https://issues.jboss.org/browse/AS7-6152 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 7.2.0.CR1 > > > Might relate to the snapshot, but it doesn't display the contents -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-6152) Content repository view broken?

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/AS7-6152?page=com.atlassian.jira.plugin.s... ] Heiko Braun reassigned AS7-6152: -------------------------------- Assignee: Harald Pehl (was: Heiko Braun) > Content repository view broken? > ------------------------------- > > Key: AS7-6152 > URL: https://issues.jboss.org/browse/AS7-6152 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console > Reporter: Heiko Braun > Assignee: Harald Pehl > Fix For: 7.2.0.CR1 > > > Might relate to the snapshot, but it doesn't display the contents -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-6152) Content repository view broken?

by Heiko Braun (JIRA)

Heiko Braun created AS7-6152: -------------------------------- Summary: Content repository view broken? Key: AS7-6152 URL: https://issues.jboss.org/browse/AS7-6152 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Might relate to the snapshot, but it doesn't display the contents -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-6152) Content repository view broken?

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/AS7-6152?page=com.atlassian.jira.plugin.s... ] Heiko Braun updated AS7-6152: ----------------------------- Fix Version/s: 7.2.0.CR1 > Content repository view broken? > ------------------------------- > > Key: AS7-6152 > URL: https://issues.jboss.org/browse/AS7-6152 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 7.2.0.CR1 > > > Might relate to the snapshot, but it doesn't display the contents -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-6151) Topology lifecycle changes need to yield model events

by Heiko Braun (JIRA)

Heiko Braun created AS7-6151: -------------------------------- Summary: Topology lifecycle changes need to yield model events Key: AS7-6151 URL: https://issues.jboss.org/browse/AS7-6151 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.2.0.CR1 i.e. stopping a server doesn't update the server picker -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 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 2012