[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
[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
[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
[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
[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
[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