December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6150) Upgrade JSF based on Mojarra 2.1.16

by Stan Silvert (JIRA)

Stan Silvert created AS7-6150: --------------------------------- Summary: Upgrade JSF based on Mojarra 2.1.16 Key: AS7-6150 URL: https://issues.jboss.org/browse/AS7-6150 Project: Application Server 7 Issue Type: Feature Request Components: JSF Affects Versions: 7.1.3.Final (EAP), 7.1.1.Final Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) Upgrade JSF API and JSF IMPL based on Mojarra 2.1.16 -- 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 Anil Saldhana (JIRA)

[ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plug... ] Anil Saldhana commented on SECURITY-709: ---------------------------------------- I do not think the non-availability of ldap server should be represented as HTTP/500. It is a server administrator issue. He can easily look in the logs that the ldap server is down. > 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] (JBJCA-945) XA recovery not enabled for JCA 1.0 deployments

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-945?page=com.atlassian.jira.plugin.... ] Jesper Pedersen resolved JBJCA-945. ----------------------------------- Resolution: Done > XA recovery not enabled for JCA 1.0 deployments > ----------------------------------------------- > > Key: JBJCA-945 > URL: https://issues.jboss.org/browse/JBJCA-945 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Affects Versions: 1.0.13.Final, 1.1.0.Beta3 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.14.Final, 1.1.0.Beta4 > > -- 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-945) XA recovery not enabled for JCA 1.0 deployments

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-945: ------------------------------------- Summary: XA recovery not enabled for JCA 1.0 deployments Key: JBJCA-945 URL: https://issues.jboss.org/browse/JBJCA-945 Project: IronJacamar Issue Type: Bug Components: Deployer Affects Versions: 1.1.0.Beta3, 1.0.13.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Priority: Critical Fix For: 1.0.14.Final, 1.1.0.Beta4 -- 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-6149) Add console support for logging-profiles

by James Perkins (JIRA)

James Perkins created AS7-6149: ---------------------------------- Summary: Add console support for logging-profiles Key: AS7-6149 URL: https://issues.jboss.org/browse/AS7-6149 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: James Perkins Assignee: Heiko Braun Add support to add logging-profiles to the logging subsystem. The profile resource address is {{subsystem=logging/logging-profile=$PROFILE_NAME}}. Each profile has the same child resources as the base logging subsystem minus the logging-profile resource. -- 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-5182) properly transform/resolve expression values

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5182?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-5182: --------------------------------------- If a user says ${exp:default} it's an indication that they expect full expression resolution. Not doing that and just using the default is a violation of that contract. I don't see how this can be done. At best we could have the master send a request to the slave asking it to resolve the expression against the HC process' system props/env props/vault. But, the system props and env props can vary between servers that slave HC manages. And the master can only send a single value; making it be something that varies by server means... sending an expression. Which isn't supported by those processes. I believe this should be resolved as Won't Fix. If people want to use new features, they need to upgrade to versions that support those features. > properly transform/resolve expression values > -------------------------------------------- > > Key: AS7-5182 > URL: https://issues.jboss.org/browse/AS7-5182 > Project: Application Server 7 > Issue Type: Sub-task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Priority: Optional > Fix For: 7.3.0.Alpha1 > > > We need to be able to properly handle values which are getting changed to allow expressions. > The problem is that older HCs won't understand the expression value, therefore they need be resolved before sending the initial model. At this point this can only be done against domain/host specific system properties. Server-group and server level overrides would be lost when starting a managed server. -- 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-5639) Run OSGi CT with AS7

by David Bosschaert (JIRA)

[ https://issues.jboss.org/browse/AS7-5639?page=com.atlassian.jira.plugin.s... ] David Bosschaert updated AS7-5639: ---------------------------------- Git Pull Request: https://github.com/jbossas/jboss-as/pull/3427, https://github.com/jbossas/jboss-as/pull/3490, https://github.com/jbossas/jboss-as/pull/3638 (was: https://github.com/jbossas/jboss-as/pull/3427, https://github.com/jbossas/jboss-as/pull/3490) > Run OSGi CT with AS7 > -------------------- > > Key: AS7-5639 > URL: https://issues.jboss.org/browse/AS7-5639 > Project: Application Server 7 > Issue Type: Task > Components: OSGi > Reporter: David Bosschaert > Assignee: David Bosschaert > > The OSGi CT is currently run with the JBoss OSGi framework standalone. It should also be possible to run the CT with the AS7 integration. -- 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 RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-944?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBJCA-944: ----------------------------------------------- Shay Matasaro <smatasar(a)redhat.com> changed the Status of [bug 886594|https://bugzilla.redhat.com/show_bug.cgi?id=886594] from NEW to CLOSED > 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] (JBJCA-944) Not possible to get access to the underlying DataSource through WrapperDataSource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-944?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBJCA-944: ----------------------------------------------- Shay Matasaro <smatasar(a)redhat.com> made a comment on [bug 886594|https://bugzilla.redhat.com/show_bug.cgi?id=886594] looks like we are still using jira ill close this one > 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] (AS7-6148) CLI command to list/view AS modules

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6148?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6148: --------------------------------------- This needs dev list discussion before implementation. The existing module related commands need rework as well; the CLI should not be directly updating the filesystem, it should be delegating to the server for that. Any further work in the area of manipulating modules needs to be done in the context of a clear contract as to where modules are to be stored. The current contract is insufficient for a general purpose feature. > CLI command to list/view AS modules > ----------------------------------- > > Key: AS7-6148 > URL: https://issues.jboss.org/browse/AS7-6148 > Project: Application Server 7 > Issue Type: Feature Request > Components: CLI > Affects Versions: 7.1.2.Final (EAP) > Reporter: Akram Ben Aissi > Assignee: Alexey Loubyansky > > For the same reason as AS7-4265, it would be useful to have command to list and view modules and their configuration. > For example: > modules list --name=org.jboss.* > or simply > modules list > will display a list of all available/installed modules in the AS. > The same way, > modules view --name=org.jboss.as.security --slot=name > will display details for the specified module, include its related resources and classes, and so on -- 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