November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6059) Update JBoss Transactions to 4.17.3.Final

by Tom Jenkinson (JIRA)

Tom Jenkinson created AS7-6059: ---------------------------------- Summary: Update JBoss Transactions to 4.17.3.Final Key: AS7-6059 URL: https://issues.jboss.org/browse/AS7-6059 Project: Application Server 7 Issue Type: Feature Request Components: Transactions Reporter: Tom Jenkinson Assignee: Jason Greene Fix For: 7.2.0.Alpha1 -- 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

12 years

1
1
0 / 0

[JBoss JIRA] (AS7-5960) Filter for CLI/GUI

by Pete Forsberg (JIRA)

Pete Forsberg created AS7-5960: ---------------------------------- Summary: Filter for CLI/GUI Key: AS7-5960 URL: https://issues.jboss.org/browse/AS7-5960 Project: Application Server 7 Issue Type: Feature Request Components: CLI Affects Versions: 7.1.2.Final (EAP) Reporter: Pete Forsberg Assignee: Alexey Loubyansky Priority: Minor Since the children of a given node in the CLI gui can be very long, a filter like that in Eclipse would be nice. -- 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

12 years

3
13
0 / 0

[JBoss JIRA] (AS7-6022) Provide a way to to customize Default stack of Interceptors

by Fernando Rubbo (JIRA)

Fernando Rubbo created AS7-6022: ----------------------------------- Summary: Provide a way to to customize Default stack of Interceptors Key: AS7-6022 URL: https://issues.jboss.org/browse/AS7-6022 Project: Application Server 7 Issue Type: Feature Request Reporter: Fernando Rubbo We know it is not a good practice to change the Jboss interceptor stack, but there are some requirements that are not possible to solve (at least as far as we know) without modifying the default stack. Please, take a look in https://community.jboss.org/thread/213749?tstart=0 Thanks in advance, Fernando Rubbo -- 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

12 years

1
1
0 / 0

[JBoss JIRA] (AS7-5897) Allow user applications to introduce server side non-EE interceptors for EE invocations

by jaikiran pai (JIRA)

jaikiran pai created AS7-5897: --------------------------------- Summary: Allow user applications to introduce server side non-EE interceptors for EE invocations Key: AS7-5897 URL: https://issues.jboss.org/browse/AS7-5897 Project: Application Server 7 Issue Type: Feature Request Components: EE, EJB Affects Versions: 7.1.3.Final (EAP) Reporter: jaikiran pai Assignee: jaikiran pai One of the topics that we discussed in the AS meeting was the use case where users have been demanding for a way to run their application specific interceptors before some of the server side app server specific interceptors and user application specific EE interceptors are run. This will allow for the user applications to have a way to pass in additional information (like security related info) to the server side interceptors (like the security interceptor) so that the information can then be made use for deciding whether or not the call should be allowed to happen or not. We used to allow to do this in previous versions of a AS via AOP but there's no current way to do it in AS7. The EE interceptors come into picture too late. Some approaches have been discussed around this, during the meeting, with the goal that whatever approach we introduce should be something that we should be able to "support" for a long time without having to ask the users to migrate to a newer way of doing this, in every other major release: 1) Allow the interceptors to use jboss-invocation library to use the interceptor API and implement their interceptors. The advantage of this approach as compared with the other approaches below, is that the semantics of this interceptor interface is something that "we" can decide and wouldn't matter if it conflicts with the semantics of the EE specific interceptors (for ex: EE specific interceptors have a invocationCtx.getTarget() which won't make sense for server side interceptors which are being invoked *before* the application component has been created) 2) Allow the user applications to just use the EE interceptor API for these intereceptors and we explicitly state that certain APIs like invocationCtx.getTarget() will have different semantics when run as a "system interceptor" 3) Introduce a very small/tiny API (EarlyEEInvocationContext as David calls it :)) which exposes limited semantics that the interceptors can rely on. We are leaning more towards #2 since that wouldn't need any new library or API for these interceptors, but would only require an explicit documentation of what's allowed and what's not in such interceptors. -- 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

12 years

3
3
0 / 0

[JBoss JIRA] (JGRP-1546) AUTH: enable the plugins to send / receive messages

by Bela Ban (JIRA)

Bela Ban created JGRP-1546: ------------------------------ Summary: AUTH: enable the plugins to send / receive messages Key: JGRP-1546 URL: https://issues.jboss.org/browse/JGRP-1546 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.3 Some plugins, e.g. X509 may require communication to perform authentication/authorization [1]. Add the ability for plugins to pick an ID, send messages with an AuthHeader including the ID and receive all messages with AuthHeaders containing the same ID. [1] https://issues.jboss.org/browse/JGRP-1487 -- 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

12 years

1
2
0 / 0

[JBoss JIRA] (AS7-5448) expose thread pool queue size through jmx

by Mathieu Lachance (JIRA)

Mathieu Lachance created AS7-5448: ------------------------------------- Summary: expose thread pool queue size through jmx Key: AS7-5448 URL: https://issues.jboss.org/browse/AS7-5448 Project: Application Server 7 Issue Type: Feature Request Components: JMX Affects Versions: 7.1.2.Final (EAP) Reporter: Mathieu Lachance Assignee: Stuart Douglas issue https://issues.jboss.org/browse/AS7-793 is not completed. thread pool exposed in jmx is still missing the queue size which is an essential metric to evaluate the system load. -- 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

12 years

4
19
0 / 0

[JBoss JIRA] (AS7-2476) Allow to choose CXF as jax-rs provider instead of Resteasy

by Luciano Blasetti (Created) (JIRA)

Allow to choose CXF as jax-rs provider instead of Resteasy ---------------------------------------------------------- Key: AS7-2476 URL: https://issues.jboss.org/browse/AS7-2476 Project: Application Server 7 Issue Type: Feature Request Components: REST, Web Services Affects Versions: 7.0.2.Final Reporter: Luciano Blasetti Assignee: Stuart Douglas Since Apache CXF provides a very good support for jax-rs and it is the mechanism for providing jax-ws in AS7, it does make sense to adopt it also for jax-rs services (it would be a more homogeneous solution), at least giving the chance to choice between the resteasy and cxf implementation through a configuration option. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

8
7
0 / 0

[JBoss JIRA] (JBRULES-3699) Large memory allocation per request in drools-camel-server

by Toshiya Kobayashi (JIRA)

Toshiya Kobayashi created JBRULES-3699: ------------------------------------------ Summary: Large memory allocation per request in drools-camel-server Key: JBRULES-3699 URL: https://issues.jboss.org/browse/JBRULES-3699 Project: Drools Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: drools-camel Affects Versions: 5.4.0.Final Reporter: Toshiya Kobayashi Assignee: Mark Proctor In drools-camel-server, memory allocation during request/response message handling is quite larger than actual request/response size. For example, with attached numbers.drl and JBoss_Benchmark_Request.xml, one SOAP request results in 45MB+ object allocation while the actual request size is 200KB and the response size is 650KB. They are short-lived objects so wouldn't be a memory leak but affect performance especially under high load. -- 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

12 years

2
3
0 / 0

[JBoss JIRA] (JBRULES-3676) drl

by hongkun an (JIRA)

hongkun an created JBRULES-3676: ----------------------------------- Summary: drl Key: JBRULES-3676 URL: https://issues.jboss.org/browse/JBRULES-3676 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: hongkun an Assignee: Mark Proctor -- 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

12 years

3
4
0 / 0

[JBoss JIRA] (SECURITY-707) Variable expansion is not supported in the module-option

by guillaume cornet (JIRA)

guillaume cornet created SECURITY-707: ----------------------------------------- Summary: Variable expansion is not supported in the module-option Key: SECURITY-707 URL: https://issues.jboss.org/browse/SECURITY-707 Project: PicketBox Issue Type: Bug Security Level: Public (Everyone can see) Reporter: guillaume cornet Assignee: Anil Saldhana Priority: Minor This configuration is not valid : <security-domain name="host" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="HTTP/ip-192-168-122-4.cloud.local"/> <module-option name="keyTab" value="${jboss.server.config.dir}/krb5.keytab"/> <module-option name="doNotPrompt" value="false"/> <module-option name="debug" value="true"/> </login-module> </authentication> </security-domain> It fails with the following exception : 10:28:52,710 INFO [stdout] (http-/0.0.0.0:8080-1) Key for the principal HTTP/ip-192-168-122-4.cloud.local(a)CLOUD.LOCAL not available in ${jboss.server.config.dir}/krb5.keytab 10:28:52,711 INFO [stdout] (http-/0.0.0.0:8080-1) [Krb5LoginModule] authentication failed => the variable "${jboss.server.config.dir}" is not expanded. -- 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

12 years

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 November 2012