March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3548) RMIAdaptorUnitTestCase testMBeanInfoMarshalling failures

by Matt Wringe (JIRA)

RMIAdaptorUnitTestCase testMBeanInfoMarshalling failures -------------------------------------------------------- Key: JBAS-3548 URL: http://jira.jboss.com/jira/browse/JBAS-3548 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.4.GA Environment: Sun 1.5.0_08 JVM RHEL 4, Linux Kernel 2.6.9 Reporter: Matt Wringe The org.jboss.test.jmx.test.RMIAdaptorUnitTestCase testMBeanInfoMarshalling test fails on the Sun 1.5.0 JVM. >From the test report: "Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)" -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Closed: (JBAS-52) Need view handlers for jmx-console custom types

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-52?page=all ] Scott M Stark closed JBAS-52. ----------------------------- Resolution: Won't Fix The new open source console will be where enhancements are made. > Need view handlers for jmx-console custom types > ----------------------------------------------- > > Key: JBAS-52 > URL: http://jira.jboss.com/jira/browse/JBAS-52 > Project: JBoss Application Server > Issue Type: Patch > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Scott M Stark > Assigned To: Scott M Stark > > The current PropertyEditor toString view is too limiting a display for the non-trivial types that can show up as mbean attribute types. A simple example is all of the ejb org.jboss.metadata types which should be exposed from the ejb and web containers. > A simple solution would be to have an HtmlEditor analog to the PropertyEditor view. This should ultimately integrate with our jsf/portal solution somehow. -- 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, 2 months

1
0
0 / 0

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

by Flavia Rainone (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-37?page=all ] Flavia Rainone closed JBAOP-37. ------------------------------- Resolution: Done Assignee: Flavia Rainone > 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.alpha4 > > 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, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-4178) RunAsListener uses unsupported implementation

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-4178?page=comments#action_12355037 ] Anil Saldhana commented on JBAS-4178: ------------------------------------- Remy has not suggested an alternative to the InstanceListener interface. Basically, we will need the patched tomcat jars for the various branches in question. > RunAsListener uses unsupported implementation > --------------------------------------------- > > Key: JBAS-4178 > URL: http://jira.jboss.com/jira/browse/JBAS-4178 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: JBossAS-4.0.5.GA > Reporter: Ryan Campbell > Assigned To: Anil Saldhana > Priority: Critical > Fix For: JBossAS-4.0.5.SP1 , JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta3 > > > Class org.jboss.web.tomcat.security.RunAsListener is an implementation of InstanceListener interface used for establishment of run-as role for servlet init/destroy events. According to tomcat developers, InstanceListener interface is meant for debugging purposes only and is causing some performace degradations. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-153) VirtualFile needs an exists method

by Scott M Stark (JIRA)

VirtualFile needs an exists method ---------------------------------- Key: JBMICROCONT-153 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-153 Project: JBoss MicroContainer Issue Type: Feature Request Components: VFS Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0 Beta3 We need to add a boolean exists() method to VirtualFile/VirtualFileHandler as its possible for the underlying file implementation to be deleted and there is no obvious api call to detect this. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-717) Drools 3.1.0-M1 dsl compatibility problems with 3.0.4

by Thomas Gonzalez (JIRA)

Drools 3.1.0-M1 dsl compatibility problems with 3.0.4 ----------------------------------------------------- Key: JBRULES-717 URL: http://jira.jboss.com/jira/browse/JBRULES-717 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.1-m1 Environment: windows 2k Reporter: Thomas Gonzalez Assigned To: Mark Proctor Priority: Critical Fix For: 3.1-m1 Tom - there was some MAJOR re-work for 3.1m1 - could you put this in a JIRA - that example, perhaps with the test code, but at least the example. Its probably some regex-foo stuffing up and choking on the \n, no doubt. That would be great. On 3/2/07, Tom Gonzalez <tomgon(a)nortel.com> wrote: We are in the process of converting from 3.0.4 to 3.1.0-M1 and having problems building rules with a dsl that built in 3.0.4 with no problems. We are getting rule compilation errors reporting: String literal is not properly closed by a double-quote The problem was isolated to the following, a dsl mapping that works in 3.0.4 [then]Log : {level} , {message}=logUtil.log ( {level} , "{message}\n" ); We had to change it to the following to get past the compile error. [then]Log : {level} , {message}=logUtil.log ( {level} , "{message}"); Tried to get the lf in various ways but no luck. Only way would be to modify every message and add a LF [then]Log : {level} , {message}=logUtil.log ( {level} , "{message}" + "\n"); -- no good got same error. This was not easy to find either. The error message above was not of much use. -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBAS-4178) RunAsListener uses unsupported implementation

by Ryan Campbell (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-4178?page=all ] Ryan Campbell updated JBAS-4178: -------------------------------- Fix Version/s: JBossAS-5.0.0.Beta3 JBossAS-4.2.0.GA JBossAS-4.0.5.SP1 JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=102744 Affects Version/s: JBossAS-4.0.5.GA Assignee: Anil Saldhana > RunAsListener uses unsupported implementation > --------------------------------------------- > > Key: JBAS-4178 > URL: http://jira.jboss.com/jira/browse/JBAS-4178 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: JBossAS-4.0.5.GA > Reporter: Ryan Campbell > Assigned To: Anil Saldhana > Priority: Critical > Fix For: JBossAS-4.0.5.SP1 , JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta3 > > > Class org.jboss.web.tomcat.security.RunAsListener is an implementation of InstanceListener interface used for establishment of run-as role for servlet init/destroy events. According to tomcat developers, InstanceListener interface is meant for debugging purposes only and is causing some performace degradations. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Moved: (JBAS-4178) RunAsListener uses unsupported implementation

by Ryan Campbell (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-4178?page=all ] Ryan Campbell moved JBPAPP-62 to JBAS-4178: ------------------------------------------- Project: JBoss Application Server (was: Jboss Enterprise Platform App Edition) Key: JBAS-4178 (was: JBPAPP-62) Component/s: Security (was: App Server) > RunAsListener uses unsupported implementation > --------------------------------------------- > > Key: JBAS-4178 > URL: http://jira.jboss.com/jira/browse/JBAS-4178 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Reporter: Ryan Campbell > Priority: Critical > > Class org.jboss.web.tomcat.security.RunAsListener is an implementation of InstanceListener interface used for establishment of run-as role for servlet init/destroy events. According to tomcat developers, InstanceListener interface is meant for debugging purposes only and is causing some performace degradations. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-999) Remove operations on ROOT cause problems with pessimistic locks and rollbacks

by Manik Surtani (JIRA)

Remove operations on ROOT cause problems with pessimistic locks and rollbacks ----------------------------------------------------------------------------- Key: JBCACHE-999 URL: http://jira.jboss.com/jira/browse/JBCACHE-999 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP2, 2.0.0.BETA1 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.BETA2, 2.0.0.GA, 1.4.1.SP3 Performing remove operations on Fqn.ROOT cause indeterminate behaviour when using pessimistic locking, due to hard-coded node removal semantics (see TreeCache.realRemove() in 1.4.x and CacheImpl.realRemove() in 2.x) and node re-addition on rollback (TreeCache/CacheImpl._addChild()) -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-426) Multiplexer: test concurrent processing

by Bela Ban (JIRA)

Multiplexer: test concurrent processing --------------------------------------- Key: JGRP-426 URL: http://jira.jboss.com/jira/browse/JGRP-426 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 4 unit tests: - Message M1 blocks for 10 seconds. Message M2 doesn't block and should get processed immediately #1 Sender A sends M1 to S1 and M2 to S1. M2 should wait until M1 is done #2 Sender A sends M1 to S1 and M2 to S2. M2 should get processed immediately and not have to wait for M1 to complete #3 Sender A sends M1 to S1 and sender B sends M2 to S1. M2 should get processed concurrently to M1 and should not have to wait for M1's completion #4 Sender A sends M1 to S1 and sender B sends M2 to S2. M1 and M2 should get processed concurrently -- 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, 2 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 March 2007