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