March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBBUILD-728) Add proxy for Google GData repository

by Ramesh Reddy (JIRA)

Ramesh Reddy created JBBUILD-728: ------------------------------------ Summary: Add proxy for Google GData repository Key: JBBUILD-728 URL: https://issues.jboss.org/browse/JBBUILD-728 Project: JBoss Build System Issue Type: Bug Reporter: Ramesh Reddy Assignee: Paul Gier For Teiid community build purposes we need Google GData libraries, can please add http://code.google.com/p/mandubian-mvn/ to Third Party Proxied libraries. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6722) Quoted script parameters are not properly parsed in the bash script

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6722?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6722: ---------------------------------------------- James Perkins <jperkins(a)redhat.com> made a comment on [bug 918030|https://bugzilla.redhat.com/show_bug.cgi?id=918030] John, thoughts on the above? I've closed the PR until there is an okay to do this. > Quoted script parameters are not properly parsed in the bash script > ------------------------------------------------------------------- > > Key: AS7-6722 > URL: https://issues.jboss.org/browse/AS7-6722 > Project: Application Server 7 > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.0.0.Alpha1 > > > Quotes are added to parameters passed via the command line. When checking the parameters for the {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} properties quoted parameters are not found. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-129) Common Annotations for the JavaTM Platform 1.2 (JSR-250)

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-129?page=com.atlassian.jira.plugin.s... ] Shelly McGowan commented on JBEE-129: ------------------------------------- 1.0.0.Alpha1 released: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... > Common Annotations for the JavaTM Platform 1.2 (JSR-250) > -------------------------------------------------------- > > Key: JBEE-129 > URL: https://issues.jboss.org/browse/JBEE-129 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-javaee-specs > Reporter: Jozef Hartinger > Assignee: Shelly McGowan > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > http://jcp.org/aboutJava/communityprocess/maintenance/jsr250/jsr250change... -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1006) isSameRmOverride doesn't take effect

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1006?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated JBJCA-1006: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=922174 > isSameRmOverride doesn't take effect > ------------------------------------ > > Key: JBJCA-1006 > URL: https://issues.jboss.org/browse/JBJCA-1006 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-70) Allow for better scoping of dependencies

by James Perkins (JIRA)

James Perkins created LOGTOOL-70: ------------------------------------ Summary: Allow for better scoping of dependencies Key: LOGTOOL-70 URL: https://issues.jboss.org/browse/LOGTOOL-70 Project: Log Tool Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins The summary is a bit vague, but this is to track a few things for the tooling. Note two of these tasks aren't for the logging tooling directory, but for the maven-compiler-plugin. # Split out the annotations into a separate library # For the maven-compiler-plugin: non-dependency artifacts used only during compilation # For the maven-compiler-plugin: annotation processor dependencies AIUI 2 would add the ability to define artifacts on the maven-compiler-plugin configuration that are to be used during the compile process, e.g. the tooling annotations. 3 would define AP's that would be used, but not defined as a dependency in the tradition sense so that no inadvertent direct or transitive dependencies could be used in the source. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-1519) Simple Domain Management Role Based Permissions

by Joe Kemp (JIRA)

[ https://issues.jboss.org/browse/AS7-1519?page=com.atlassian.jira.plugin.s... ] Joe Kemp commented on AS7-1519: ------------------------------- We are using standalone configurations but have similar concerns about multiple levels of security. At a minimum we would like to be able to secure the management interfaces (Administrative Console and JMX) with the following three levels: Read Only Operation - Deploy/Undeploy Enable/Disable Deployments. No configuration changes are permitted. Administrator - Full Access We use LDAP so ideally these levels could be tied to LDAP groups. > Simple Domain Management Role Based Permissions > ----------------------------------------------- > > Key: AS7-1519 > URL: https://issues.jboss.org/browse/AS7-1519 > Project: Application Server 7 > Issue Type: Sub-task > Components: Domain Management, Security > Affects Versions: 7.0.0.Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Authorization > Fix For: 8.0.0.Alpha1 > > > Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute. > Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-132) Update jboss-jta-api_spec to version 1.2

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-132?page=com.atlassian.jira.plugin.s... ] Shelly McGowan commented on JBEE-132: ------------------------------------- 1.0.0.Alpha1 version of the JTA 1.2 APIs have been released for [additional] testing and verification: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... > Update jboss-jta-api_spec to version 1.2 > ---------------------------------------- > > Key: JBEE-132 > URL: https://issues.jboss.org/browse/JBEE-132 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-javaee-specs > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > From the Change Log of JSR-970, the API additions are annotations for Transactional and TransactionScoped. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6367) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-6367?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-6367: ----------------------------------- A bit of background to this issue. Currently the EJB3 subsystem allows pointing to just one remoting connector (configured in the remoting subsystem): {code} <subsystem name="ejb3"...> <remote connector-ref="foo" thread-pool="default/> ... {code} The "foo" connector is in turn configured in the remoting subsystem. The foo connector is backed by a security-realm. Effectively, this means that all remote EJB communication that happens will happen via the foo connector and as a result will use *only* that single security-realm. The goal of this JIRA task was to allow the EJB3 subsystem to point to more than 1 remoting connectors configured in the remoting susbystem so that remote applications can then choose from these available remoting EJB connectors for EJB communication. This looked straightforward to implement when I initially started work on this. All I had to do was allow something like: {code} <subsystem name="ejb3"...> <connectors> <remote name="one" connector-ref="foo" thread-pool="default/> <remote name="two" connector-ref="another-one" thread-pool="default"/> ... </connectors> ... {code} instead of the previous configuration. But when I started implementing this I realized that it isn't straightforward keeping in mind the backward compatibility goals. It took a (long) while to get the transformers right for these configurations. As of today, I've the transformers functional and the above changes are working. However, while doing some manual testing around this, I've realized that our previous model/xml had a incorrect notion of configuring channel-creation-options for the remote EJB connector. It allowed something like: {code} <subsystem name="ejb3"...> <remote connector-ref="foo" thread-pool="default> <channel-creation-options> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> </channel-creation-options> </remote> ... {code} Those channel-creation-options were then used while registering a EJB channel handling service against the remoting Endpoint. Now with the changes were are proposing, this will no longer work out - i.e. each remote connector configuration in the EJB subsystem *cannot* be allowed to specify different channel-creation-options. In fact, it doesn't belong to the individual connector and instead it should be at the EJB subsystem level since that service should be registered just once. So this is going to require a lot more (re) work to implement this feature. I'm currently working on this one and have a different schema/model in mind. Something like: {code} <subsystem name="ejb3"...>  <remote>  <connectors>  <remoting-connector connector-ref="foo" thread-pool="default"/>  </connectors>  <channel-creation-options> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> </channel-creation-options> ... </remote> .... {code} This is going to take some work to get it functional. I'm working on this one in parallel with some other tasks. I'll update this JIRA once this gets done. > Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms > ------------------------------------------------------------------------------------------------------------ > > Key: AS7-6367 > URL: https://issues.jboss.org/browse/AS7-6367 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.3.Final (EAP) > Reporter: Derek Horton > Assignee: jaikiran pai > > My confusion is around the remoting/security-realm setup in the use case > where multiple EJBs are deployed that use different security-domains and > the EJBs will be invoked by remote standalone clients. For example, > ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to > be in the sec-domain-Y security-domain. > In this situation, the authentication checks are going to be handled by > the security-realm that is associated with the remote connector that is > configured to be used by the EJB subsystem. > It looks like the security-realm can either handle the authentication > checks directly (properties file, ldap, etc) or it can defer to the > jaas security-domain. In both of those situations, it seems that the > EJBs are limited to a single authentication point. The EJB > authentication is either going to be handled by a single security-realm > or the security-realm will defer to a single security-domain. > I could configure the security-domain to have multiple login modules. I > assume the same thing could be done with the security-realm. > Basically the problem that I am trying to solve boils down to this: the > authentication checks for remote EJBs appear to be checked by either a > single security-realm or a single security-domain. Is there a way to > change this? > One idea I had was to add another remote connector to the EJB subsystem. > Unfortunately, this does not appear to be possible. -- 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, 1 month

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: ---------------------------------- Thanks for the response and for posting that question on the Community list, Anil! I'll definitely look into the possibility of using a custom Tomcat Authenticator as well. > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6197) Add support nested URLs like webbundle:file://foo.jar

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6197?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-6197: -------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: EAP 6.1.0.Alpha (7.2.0.Final)) > Add support nested URLs like webbundle:file://foo.jar > ----------------------------------------------------- > > Key: AS7-6197 > URL: https://issues.jboss.org/browse/AS7-6197 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi, Web > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 8.0.0.Alpha1 > > > The webbundle URL may contain a nested URL that gives access to the bundle bytes. The TCK uses this method extensively instead of providing the input stream to the bundle bytes directly -- 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, 1 month

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 March 2013