November 2006 - jboss-jira - Jboss List Archives

by Inmobiliaria Rio Pangal

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3875) Support for virtual-host elements in a port-component element

by Michal Borowiecki (JIRA)

Support for virtual-host elements in a port-component element ------------------------------------------------------------- Key: JBAS-3875 URL: http://jira.jboss.com/jira/browse/JBAS-3875 Project: JBoss Application Server Issue Type: Patch Security Level: Public (Everyone can see) Components: Deployment services Reporter: Michal Borowiecki Assigned To: Dimitris Andreadis Support for virtual-host elements in a port-component element is required for JBWS-1325 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-114) Move (Esb)Email from common module to the services module

by Arvinder Singh (JIRA)

Move (Esb)Email from common module to the services module --------------------------------------------------------- Key: JBESB-114 URL: http://jira.jboss.com/jira/browse/JBESB-114 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: ESB Core Affects Versions: 4.0 Beta 1 Reporter: Arvinder Singh Assigned To: Arvinder Singh Priority: Minor Fix For: 4.0 (Esb)Email currently exists under the common module, this should be abstracted to the sevices module for the 4.0 GA release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBAOP-37) Before, After, After Throwing support

by Flavia Rainone (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-37?page=all ] Flavia Rainone updated JBAOP-37: -------------------------------- Description: This should be optimized as well. I've done a non-CVS-checked-in prototype of this. Feature Details: To use this feature, one should use the xml tags 'before', 'after' and 'throwing'. The signature of these advices should take any annotated arguments (annotation rules follow) and 'after' can return a value in order to overwrite/replace the intercepted join point returned value. Besides, to continue using the advice around, the user should just continue using the 'advice' xml tag. Around advices should either stick to the signature Object [advice_name](Invocation invocation) Or they can now use annotated parameters, as in 'before', 'after' and 'throwing' The parameters can be annotated with JoinPoint, Invocation, Return, Throwable, Arg, Args, Callee, Caller and Target. Parameter Annotation Rules: Except for around default signature, all parameters must be annotated with one of the annotations defined in package org.jboss.aop.advice. We have annotations that are allowed only for specific types of join points, and we have annotations that are allowed only for specific types of advices. These annotations are allowed depending on the advice type: - JoinPoint: Before, After, Throwing - Invocation: Around - Return: Around, After - Throwable: Throwing These annotations are allowed depending on the join point type: - Callee: call join points - Caller: call join points - Target: every non-static join point that is not a call Finally, we have the mutually exclusive annotations Arg and Args. Both can always be used (but not on the same advice method). The first one must annotate every advice parameter whose value is the value of a join point argument. The second one annotates parameters of type Object[] that must receive all join point arguments values. Advice Matching Rules Every Arg parameter is bound to a join point argument of the same type. If there is more than one join point argument with the requested type, then the Arg parameter will be bound to the first join point argument that has not been bound yet. When there are overloaded advice methods, JBoss AOP will use a priority order to pick the best match. The advice method with the most suitable type of the highest priority annotated parameter type is chosen. The increasing priority order of arguments is: Arg/Args, Return/Throwable, Target/Callee/Caller , JoinPoint/Invocation. was:This should be optimized as well. I've done a non-CVS-checked-in prototype of this. Added rule description to feature. > Before, After, After Throwing support > ------------------------------------- > > Key: JBAOP-37 > URL: http://jira.jboss.com/jira/browse/JBAOP-37 > Project: JBoss AOP > Issue Type: Feature Request > Affects Versions: 2.0.0.alpha1 > Reporter: Bill Burke > Assigned To: Flavia Rainone > Fix For: 2.0.0.alpha3 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > This should be optimized as well. I've done a non-CVS-checked-in prototype of this. > Feature Details: > To use this feature, one should use the xml tags 'before', 'after' and 'throwing'. > The signature of these advices should take any annotated arguments (annotation rules follow) and 'after' can return a value in order to overwrite/replace the intercepted join point returned value. > Besides, to continue using the advice around, the user should just continue using the 'advice' xml tag. > Around advices should either stick to the signature > Object [advice_name](Invocation invocation) > Or they can now use annotated parameters, as in 'before', 'after' and 'throwing' > The parameters can be annotated with JoinPoint, Invocation, Return, Throwable, Arg, Args, Callee, Caller and Target. > Parameter Annotation Rules: > Except for around default signature, all parameters must be annotated with one of the annotations defined in package org.jboss.aop.advice. We have annotations that are allowed only for specific types of join points, and we have annotations that are allowed only for specific types of advices. > These annotations are allowed depending on the advice type: > - JoinPoint: Before, After, Throwing > - Invocation: Around > - Return: Around, After > - Throwable: Throwing > These annotations are allowed depending on the join point type: > - Callee: call join points > - Caller: call join points > - Target: every non-static join point that is not a call > Finally, we have the mutually exclusive annotations Arg and Args. Both can always be used (but not on the same advice method). The first one must annotate every advice parameter whose value is the value of a join point argument. The second one annotates parameters of type Object[] that must receive all join point arguments values. > Advice Matching Rules > Every Arg parameter is bound to a join point argument of the same type. If there is more than one join point argument with the requested type, then the Arg parameter will be bound to the first join point argument that has not been bound yet. > When there are overloaded advice methods, JBoss AOP will use a priority order to pick the best match. The advice method with the most suitable type of the highest priority annotated parameter type is chosen. > The increasing priority order of arguments is: Arg/Args, Return/Throwable, Target/Callee/Caller , JoinPoint/Invocation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JASSIST-23) Java 2 Security ProtiectionDomain is not associated with new generated classes

by Renat Zubairov (JIRA)

Java 2 Security ProtiectionDomain is not associated with new generated classes ------------------------------------------------------------------------------ Key: JASSIST-23 URL: http://jira.jboss.com/jira/browse/JASSIST-23 Project: Javassist Issue Type: Bug Environment: IBM WebSphere 5.1 with J2EE Security ON, Javassist 3.0, Tapestry 4.1, HiveMind 1.1.1 Reporter: Renat Zubairov Assigned To: Shigeru Chiba Priority: Blocker Attachments: exception.txt Classes that are generated using Javassist have no associated protection domain therefore it is not possible for JVM to assign permissions based on the static JAR files names, this is severe problem because it is not possible to grant permissions, hence all permissions are vorbidden, since that nothing works. Javassist is used by HiveMind to generate proxy classes for it's services, an see the stack trace (in attachment) the generated classes can't be associated with any ProtectionDomain, therefore _any Javassist supported application is impossble to start under strict security in Java_. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

4
15
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-275) Move Selector processing IN the Channel

by Ryan Campbell (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-275?page=all ] Ryan Campbell updated JBMESSAGING-275: -------------------------------------- Comment: was deleted > Move Selector processing IN the Channel > --------------------------------------- > > Key: JBMESSAGING-275 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-275 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Fix For: 1.2.0.CR1 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Currently, a consumer "arrests" a message that is being handled to it and doesn't match the Selector. That means it returns an active Delivery for it, but it doesn't forward the message to the client. This is because the consumer needs to be able to receiver further messages coming after the non-matching message, and that may potentially match the selector. > This is a poor solution that doesn't scale. We may end up with lots of non-matching messages being "arrested" by a consumer, while they could just be simply returned to the channel and forwarded to other potential consumers. > A possible (right) approach is to move selector processing in the Channel, so the message is not even handled to the non-accepting cosumer. Review this and refactor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-325) Message selectors and subscriptions

by Ryan Campbell (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-325?page=all ] Ryan Campbell updated JBMESSAGING-325: -------------------------------------- Comment: was deleted > Message selectors and subscriptions > ----------------------------------- > > Key: JBMESSAGING-325 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-325 > Project: JBoss Messaging > Issue Type: Bug > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.0.1.CR1 > > > If a subscription is created with a message selector, then all messages regardless of whether they match the selector go to the subscription, but only those that actually match get sent to the consumer. This means the other build up as deliveries in the serverconsumerendpoint and never get cleared down. > Fix is to make sure subscription only accepts message reference if it matches selector for subscription. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-60) Partitioned Cache

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-60?page=all ] Manik Surtani reopened JBCACHE-60: ---------------------------------- Reopening, this is something to revisit later. > Partitioned Cache > ----------------- > > Key: JBCACHE-60 > URL: http://jira.jboss.com/jira/browse/JBCACHE-60 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.3.0.GA > > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - Distributed load across multiple nodes in a cluster > - No replication/redundancy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-60) Partitioned Cache

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-60?page=all ] Manik Surtani updated JBCACHE-60: --------------------------------- Fix Version/s: 2.3.0.GA (was: 2.0.0.GA) > Partitioned Cache > ----------------- > > Key: JBCACHE-60 > URL: http://jira.jboss.com/jira/browse/JBCACHE-60 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.3.0.GA > > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - Distributed load across multiple nodes in a cluster > - No replication/redundancy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-868) Renamed PojoCache annotation

by Ben Wang (JIRA)

Renamed PojoCache annotation ---------------------------- Key: JBCACHE-868 URL: http://jira.jboss.com/jira/browse/JBCACHE-868 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.ALPHA2 There is currently a proposal to rename the annotation: PojoCacheable and InstanceOfPojoCacheable to just @Replicatable with the intention that it will be inheritance as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
3
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 2006