November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAOP-796) Creation of ClassAdvisor must use the AspectManager equivalent to the advised class' ClassLoader

by Flavia Rainone (JIRA)

Creation of ClassAdvisor must use the AspectManager equivalent to the advised class' ClassLoader ------------------------------------------------------------------------------------------------ Key: JBAOP-796 URL: https://jira.jboss.org/browse/JBAOP-796 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.9.Alpha1 Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 2.1.6 CP01, 2.1.9.GA, 2.2.1.GA Currently, an Advisor is created by calling AspectManager.instance().getAdvisor(). The correct is to create the advisor by calling AspectManager.instance(WovenClass.class).getAdvisor(WovenClass.class). Otherwise, the Advisor will be created as part of the AspectManager/Domain corresponding to the current context class loader: public static synchronized AspectManager instance() { return instance(Thread.currentThread().getContextClassLoader()); } In the JBoss AS environment, if the woven class is loaded during an archive deployment, this is equivalent to say that the Advisor will be erroneously created by the domain of the current deployment, instead of being created by the appropriate AspectManager/Domain instance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
10
0 / 0

[JBoss JIRA] (JBAOP-812) AspectManager.getAdvisors throws ConcurrentModificationException

by Flavia Rainone (JIRA)

Flavia Rainone created JBAOP-812: ------------------------------------ Summary: AspectManager.getAdvisors throws ConcurrentModificationException Key: JBAOP-812 URL: https://issues.jboss.org/browse/JBAOP-812 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.6.CP03 Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 2.1.6.CP04 The problem can be observed sometimes when running JBoss AS. The stack trace: ERROR [STDERR] (AOPListner:) java.util.ConcurrentModificationException ERROR [STDERR] (AOPListner:) at java.util.WeakHashMap$HashIterator.next(WeakHashMap.java:169) ERROR [STDERR] (AOPListner:) at org.jboss.aop.AspectManager.getAdvisors(AspectManager.java:543) ERROR [STDERR] (AOPListner:) at org.jboss.console.plugins.AOPLister$RefreshPoller.run(AOPLister.java:891) -- 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

13 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAOP-806) Using UnmodifiableLinkedHashMap constructor causes an UnsupportedOperationException exception to be thrown on IBM JDK

by Dustin Kut Moy Cheung (JIRA)

Using UnmodifiableLinkedHashMap constructor causes an UnsupportedOperationException exception to be thrown on IBM JDK --------------------------------------------------------------------------------------------------------------------- Key: JBAOP-806 URL: https://issues.jboss.org/browse/JBAOP-806 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Components: Aspect Library Environment: OS: Fedora 14 JDK: IBM JDK Reporter: Dustin Kut Moy Cheung Priority: Critical Read Summary. This error is caused because the IBM JDK LinkedHashMap invokes the putAll method on HashMap. Since the putAll method is overwridden in UnmodifiableLinkedHashMap.java, the UnmodifiableLinkedHashMap putAll method is called instead of the HashMap constructor and therefore throws that exception. The fix is to change the signature of the constructor being called (LinkedHashMap constructor) so that the putAll method is not called. Please see the patch that attempts to solve this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
6
0 / 0

[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

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

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