September 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1971) Better base class for write-attribute handlers

by Brian Stansberry (JIRA)

Better base class for write-attribute handlers ---------------------------------------------- Key: AS7-1971 URL: https://issues.jboss.org/browse/AS7-1971 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.1.0.Beta1 ServerWriteAttributeOperationHandler isn't a very nice base for a write-attribute handler. 1) It does stuff in Stage.MODEL (validateResolvedValue()) that should be in Stage.RUNTIME. 2) It forces subclasses to register a Stage.RUNTIME handler, instead of providing that for them. 3) It doesn't provide very good support for handling rollbacks of runtime changes. 4) It's in the server module instead of controller. I'm going to add a new AbstractWriteAttributeHandler in controller, deprecate ServerWriteAttributeOperationHandler, and convert all existing uses of it in the AS code base. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (AS7-1554) Upgrade felix webconsole to remove dep 3.1.6.SP1

by Thomas Diesler (JIRA)

Upgrade felix webconsole to remove dep 3.1.6.SP1 ------------------------------------------------ Key: AS7-1554 URL: https://issues.jboss.org/browse/AS7-1554 Project: Application Server 7 Issue Type: Task Components: OSGi Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.1.0.CR1 > There is no version 3.1.6.SP1 of webconsole in SCM Its here https://github.com/tdiesler/org.apache.felix.webconsole/commits/3.1.6.SP1/ > And should we switch to 3.1.8 which appears to be the latest version? Not unless AS7 pulls in that version. A prerequisite would be that my patches made it upstream. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (AS7-1709) Client JNDI support for AS7

by Carlo de Wolf (JIRA)

Client JNDI support for AS7 --------------------------- Key: AS7-1709 URL: https://issues.jboss.org/browse/AS7-1709 Project: Application Server 7 Issue Type: Task Components: Naming Reporter: Carlo de Wolf Assignee: John Bailey Priority: Critical Fix For: 7.1.0.CR1 The following use case are applicable both to a remote/client VM and within AS7 itself. The configuration of the initial context is not specified in here, it'll be a resultant of this task and outlined in some documentation. Note that any {code}InitialContext ctx = new InitialContext();{code} might need {code}InitialContext ctx = new InitialContext(props);{code} where the actual contents of {{props}} is currently unspecified. h3. Calling AS7 It *must* be possible for a client to call AS7 via the following code: {code} InitialContext ctx = new InitialContext(); MyRemote bean = ctx.lookup("java:myserver1/myapp/myjar/myBean#MyRemote"); {code} h3. Calling different AS7 instances It *should* be possible for a client to call two different AS7 instances via the following code: {code} InitialContext ctx = new InitialContext(); MyRemote bean = ctx.lookup("java:myserver1/myapp/myJar/OtherBean#MyRemote"); OtherRemote bean2 = ctx.lookup("java:myserver2/otherapp/otherjar/OtherBean2#OtherRemote"); {code} Whether security and transaction propagation between the servers is available or possible is left beyond scope. h3. Calling different type/version of servers It *may* be possible for a client to call two different EAP versions via the following code: {code} InitialContext ctx = new InitialContext(); MyRemote bean = ctx.lookup("java:myEAP6/myapp/myJar/OtherBean#MyRemote"); OtherRemote bean2 = ctx.lookup("java:myEAP5/otherapp/otherjar/OtherBean2#OtherRemote"); {code} The last one would require a context to be associated with a certain module to load the proper client classes. See also http://wolf-71.blogspot.com/2010/02/et-phone-home.html Whether security and transaction propagation between the servers is available or possible is left beyond scope. Also the propagation of the current established tx/sec context might not be available. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1923) Rule order counts when adding inheriting rules

by Toni Rikkola (JIRA)

Rule order counts when adding inheriting rules ---------------------------------------------- Key: JBRULES-1923 URL: https://jira.jboss.org/jira/browse/JBRULES-1923 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: FUTURE Reporter: Toni Rikkola Assignee: Mark Proctor When inheriting rules, the order they are written to DRL counts. dward noticed this when using Guvnor. There is no way to control the order of the rules in Guvnor, so because of this inheritance doesn't always work. This works: rule A when ... then end rule B extends A when ... then end This doesn't work: rule B extends A when ... then end rule A when ... then end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
11
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1855) Failed fail-over doesn't trigger client's ExceptionListener

by Justin Bertram (JIRA)

Failed fail-over doesn't trigger client's ExceptionListener ----------------------------------------------------------- Key: JBMESSAGING-1855 URL: https://issues.jboss.org/browse/JBMESSAGING-1855 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3.CP09 Reporter: Justin Bertram Assignee: Yong Hao Gao If the cluster node to which a client is connected is dropped gracefully and the cluster is using FailoverOnNodeLeave = false then the client's connection will die and its exception listener will not be triggered so it may manually reconnect to another node of the cluster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
12
0 / 0

[JBoss JIRA] Created: (JGRP-1369) MuxRpcDispatcher may encapsulate infinitely RequestOption's filter with NoMuxHandlerRspFilter

by Benoit Leblanc (JIRA)

MuxRpcDispatcher may encapsulate infinitely RequestOption's filter with NoMuxHandlerRspFilter --------------------------------------------------------------------------------------------- Key: JGRP-1369 URL: https://issues.jboss.org/browse/JGRP-1369 Project: JGroups Issue Type: Bug Affects Versions: 2.12.1 Reporter: Benoit Leblanc Assignee: Bela Ban MuxRpcDispatcher alters RequestOption's filter by encapsulating it with a NoMuxHandlerRspFilter. Passing the same instance of RequestOptions to rpc calls leads to : java.lang.StackOverflowError at org.jgroups.blocks.mux.NoMuxHandlerRspFilter.isAcceptable(NoMuxHandlerRspFilter.java:24) at org.jgroups.blocks.mux.NoMuxHandlerRspFilter.isAcceptable(NoMuxHandlerRspFilter.java:24) ..... ..... Solutions : 1/ "Clone" RequestOption at each call like fix used in https://issues.jboss.org/browse/JGRP-1271. The drawback with this solution, is the performance concern : useless object creation if a RequestOption is reused. 2/ Don't encapsulate RequestOption is a NoMuxHandlerRspFilter is already setted. Modification concerns two classes : * NoMuxHandlerRspFilter private NoMuxHandlerRspFilter(RspFilter filter) { this.filter = filter; } public static RspFilter createInstance(RspFilter filter) { if (filter instanceof NoMuxHandlerRspFilter) { return filter; } return new NoMuxHandlerRspFilter(filter) ; } * MuxRpcDispatcher protected GroupRequest cast(Collection<Address> dests, Message msg, RequestOptions options, boolean blockForResults) { RspFilter filter = options.getRspFilter(); return super.cast(dests, msg, options.setRspFilter(NoMuxHandlerRspFilter.createInstance(filter)), blockForResults); } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-1336) GMS: if a member leaving takes a long time, it can get merged back into the cluster

by Bela Ban (JIRA)

GMS: if a member leaving takes a long time, it can get merged back into the cluster ----------------------------------------------------------------------------------- Key: JGRP-1336 URL: https://issues.jboss.org/browse/JGRP-1336 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.1 When JChannel.disconnect() is called, and the leave processing takes a long time (e.g. due to excessive CPU use and GC), then it can happen that the leaving node is merged back into the cluster. This occurred in the Infinispan testsuite which is run in parallel (high CPU contention). SOLUTION: after sending the LEAVE request, disable discovery, so MERGE2 won't discover us. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (AS7-1966) Add list-snapshots to operations available to GET requests on HTTP interface

by Darran Lofthouse (JIRA)

Add list-snapshots to operations available to GET requests on HTTP interface ---------------------------------------------------------------------------- Key: AS7-1966 URL: https://issues.jboss.org/browse/AS7-1966 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.0.Beta1 The operations allowed using GET are the read operations, list-snapshots is a read only operation so should be allowed over GET. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (AS7-1432) Adding director element to action-log in a virtual-host causes xml parse error

by dan ginsberg (JIRA)

Adding director element to action-log in a virtual-host causes xml parse error ------------------------------------------------------------------------------- Key: AS7-1432 URL: https://issues.jboss.org/browse/AS7-1432 Project: Application Server 7 Issue Type: Bug Components: Logging Affects Versions: 7.0.0.Final Environment: Linux x86_64 Reporter: dan ginsberg Assignee: David Lloyd In standalone.xml, in a virutal-server, 1) add an access-log element Find: server starts correctly and creates the access log 2) in the access-log element, add a directory element Find: server no longer starts correctly. you may see an xml parse error logged, or you may just find that subsequent xml is not correclty parsed -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
4
0 / 0

[JBoss JIRA] Created: (LOGMGR-32) NPE in Formatters

by Stuart Douglas (JIRA)

NPE in Formatters ----------------- Key: LOGMGR-32 URL: https://issues.jboss.org/browse/LOGMGR-32 Project: JBoss Log Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.2.0.GA Reporter: Stuart Douglas Assignee: David Lloyd In Formatters on line 452 there is a line: exceptionClass.getProtectionDomain().getCodeSource().getLocation() which can cause a NPE. This NPE then gets swallowed by: catch (Throwable t) { // ignore } This makes is extremely difficult to set a NPE breakpoint when debugging, as it keeps getting tripped by there spurious exceptions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
2
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 September 2011