[JBoss JIRA] Created: (JBMESSAGING-1870) ClientSocketWrapper constructors have a redundant call to createStreams()
by Ron Sigal (JIRA)
ClientSocketWrapper constructors have a redundant call to createStreams()
-------------------------------------------------------------------------
Key: JBMESSAGING-1870
URL: https://issues.jboss.org/browse/JBMESSAGING-1870
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.8.GA, 1.4.0.SP3.CP12
Reporter: Ron Sigal
Priority: Minor
org.jboss.jms.client.remoting.ClientSocketWrapper is derived from org.jboss.remoting.transport.socket.ClientSocketWrapper. The constructors of the former look like
public ClientSocketWrapper(Socket socket) throws IOException
{
super(socket);
createStreams(socket, null);
}
public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception
{
super(socket, metadata, timeout);
createStreams(socket, metadata);
}
and the constructors of the latter look like
public ClientSocketWrapper(Socket socket) throws IOException
{
super(socket);
createStreams(socket, null);
}
public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception
{
super(socket, timeout);
createStreams(socket, metadata);
}
The calls to createStreams() in the JBossMessaging versions of ClientSocketWrapper is redundant.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBMESSAGING-1866) Adapt JBM tests to new failover model
by Yong Hao Gao (JIRA)
Adapt JBM tests to new failover model
-------------------------------------
Key: JBMESSAGING-1866
URL: https://issues.jboss.org/browse/JBMESSAGING-1866
Project: JBoss Messaging
Issue Type: Task
Components: Tests and Performance
Affects Versions: 1.4.8.GA, 1.4.0.SP3.CP12
Reporter: Yong Hao Gao
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP13, 1.4.8.SP1
In jbm test suite some tests will fail if the 'keepOldFailoverModel' is set to false. This is because with new model, the failover for a dead node doesn't happen immediately. This affects all tests which expect a failover to happen after a certain timeout.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (AS7-1440) allow default persistence provider to be configured
by Scott Marlow (JIRA)
allow default persistence provider to be configured
---------------------------------------------------
Key: AS7-1440
URL: https://issues.jboss.org/browse/AS7-1440
Project: Application Server 7
Issue Type: Feature Request
Components: JPA / Hibernate
Reporter: Scott Marlow
Fix For: 7.1.0.Alpha1
Allow default persistence provider to be configured, so that a different provider could be used by default. This helps improve our JPA plugability (users preferred persistence provider can become the default).
Without this feature, the user could instead make application changes to the persistence.xml to accomplish the same (not always possible if user cannot make app changes).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-4091) Opimize organization and management of the JGroups subsystem
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created AS7-4091:
----------------------------------------
Summary: Opimize organization and management of the JGroups subsystem
Key: AS7-4091
URL: https://issues.jboss.org/browse/AS7-4091
Project: Application Server 7
Issue Type: Task
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 7.1.2.Final
There are a number of areas where the Infinispan subsystem is organizationally deficient:
- does not make use of ResourceDefinitions to (i) simplify the generation of DescriptionProviders and (ii) localize the definition of AttributeDefinitions
- handlers are in some cases written from scratch rather than subclassing helper handlers such as AbstractWriteAttributeHandler, AbstractAddStepHandler, AbstractRemoveStepHandler, etc.
- collections of services are defined monolithically, rather than in distinct units which makes stopping/restarting them error prone (c.f. CacheContainerAdd, CacheAdd install three or four services each with complex processing - stopping and restarting this in another handler is next to impossible)
- ServiceNames are not always easy to reconstruct
These issues make maintenance of the subsystem hard. These matters can be helped by:
- making use of ResourceDefinitions
- defining for each service X a static method installX(context, operation, model) and removeX(context, operation, model) which can be made use of in installServices(context, operation, model) and removeServices(operation, context, model)
- define the static method populate(), used to populate a model from an operation, which can be reused in populateModel(), creating describe operations, as well as other contexts
- define a static method installServices(context, operation, model) which can be used in performRuntime(), and in contexts where all services for a resource need to be stopped and restarted; similarly define removeServices(context, operation, model)
- make sure each ServiceName can be regenerated easily (c.f. regenerating JNDI names can involve model processing)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months