[JBoss JIRA] Created: (AS7-1459) Add a commandline flag to the startup script to enable debugging
by Dan Allen (JIRA)
Add a commandline flag to the startup script to enable debugging
----------------------------------------------------------------
Key: AS7-1459
URL: https://issues.jboss.org/browse/AS7-1459
Project: Application Server 7
Issue Type: Feature Request
Components: CLI
Affects Versions: 7.0.0.Final
Reporter: Dan Allen
Assignee: Alexey Loubyansky
The startup script (standalone.sh & standalone.bat) should honor a commandline option that can be used to start the server with debugging enabled. Currently, the developer has to uncomment the JAVA_OPTS line in the standalone.conf file manually.
Proposal for starting the server with debugging enabled:
./bin/standalone.sh --debug
If necessary, the optional flag could accept the port as an optional argument.
./bin/standalone.sh --debug 8787
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBAS-8824) Cardinality constraints on children are not enforced after parsing
by Brian Stansberry (JIRA)
Cardinality constraints on children are not enforced after parsing
------------------------------------------------------------------
Key: JBAS-8824
URL: https://issues.jboss.org/browse/JBAS-8824
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 7.0.0.Alpha1
Reporter: Brian Stansberry
Priority: Critical
Fix For: 7.0.0.Beta1
The parsers enforce cardinality constraints on child elements in the model, but they aren't enforced thereafter. So, for example, a second "profile" or "socket-binding-group" could be added to a standalone server via a management operation.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JGRP-1317) STABLE: compress STABLE messages
by Bela Ban (JIRA)
STABLE: compress STABLE messages
--------------------------------
Key: JGRP-1317
URL: https://issues.jboss.org/browse/JGRP-1317
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12.2, 3.1
For large clusters, stable messages are quite large, and should be compressed.
E.g.:
- Don't send the entire view (with all members), but only the ViewId, then the indices of a digest array would point to the rank of a member within the referred-to ViewId
- A digest has 3 longs (low, highest_received and highest_delivered). Do we need all 3 every time ?
- Compress the 3 longs into 1 long and 2 shorts: the latter 2 are offsets from the first seqno
- Use a bit set (consisting of a variable number of ints) to set the 3 variables
- If we have a digest (0), 0, 0: send a special marker
- Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JGRP-1052) Ergonomics
by Bela Ban (JIRA)
Ergonomics
----------
Key: JGRP-1052
URL: https://jira.jboss.org/jira/browse/JGRP-1052
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.0
The goal is to (a) reduce the number of properties needed and (b) determine the values dynamically.
Examples:
- Determine the best min/max size of a thread pool
- Find out what the best timeout values are for retransmission, e.g. based on average retransmission times
- Determine the optimal number of credits in FC
This is similar to the JVM setting where, starting with 1.5, the initial values can be set, but over time, the JVM dynamically changes them.
In the best case, a config contains only a list of protocols without any properties, and JGroups will figure out the correct values.
--
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
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2438) loading multiple sheets of single Excel book by one change-set xml
by Toshiya Kobayashi (JIRA)
loading multiple sheets of single Excel book by one change-set xml
------------------------------------------------------------------
Key: JBRULES-2438
URL: https://jira.jboss.org/jira/browse/JBRULES-2438
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.0.1.FINAL
Reporter: Toshiya Kobayashi
Assignee: Mark Proctor
I'm trying to use rules via DecisionTable using change-set.
I wrote rules in multiple sheets of single Excel book.
Then I configured my change-set xml like:
...
<add>
<resource source='classpath:data/dtable.xls' type="DTABLE">
<decisiontable-conf input-type="XLS" worksheet-name="sheet1" />
</resource>
<resource source='classpath:data/dtable.xls' type="DTABLE">
<decisiontable-conf input-type="XLS" worksheet-name="sheet2" />
</resource>
</add>
...
But only rules of sheet1 were loaded.
As far as I observed source codes, KnowledgeAgentImpl.java puts resource into "Map<Resource, ResourceMapping> resources". But even if multiple resources are configured in change-set, it appears to me like those resources are considered as the same resource and eventually only one resource will be registered.
--
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
12 years, 2 months
[JBoss JIRA] Created: (JBMESSAGING-1490) BridgeService should be JAAS aware
by Nicholas Sayer (JIRA)
BridgeService should be JAAS aware
----------------------------------
Key: JBMESSAGING-1490
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1490
Project: JBoss Messaging
Issue Type: Feature Request
Affects Versions: 1.4.2.GA
Environment: n/a
Reporter: Nicholas Sayer
Assignee: Tim Fox
Priority: Optional
org.jboss.jms.server.bridge.BridgeService currently requires a username and password for the source and destination. It would be better if it could be configured with a JAAS login context name. This would allow username and password information to be set in, for example, a SecureIdentityLoginModule. For example:
<application-policy name = "JmsBridgeRealm">
<authentication>
<login-module code = "org.jboss.resource.security.SecureIdentityLoginModule" flag = "required">
<module-option name = "principal">${bridge.user}</module-option>
<module-option name = "userName">${bridge.user}</module-option>
<module-option name = "password">${bridge.encryptedPassword}</module-option>
<module-option name = "ignoreMissigingMCF">true</module-option>
<!-- it is a separate bug that you must set managedConnectionFactoryName to something regardless of setting ignoreMissingMCF to true -->
<module-option name = "managedConnectionFactoryName">jboss.nonexistent:service=NonExistent,name=NonExistent</module-option>
</login-module>
</authentication>
</application-policy>
There is undoubtedly a better way to accomplish this (probably to pass the JAAS context directly into the JMS connection factory used to vend connections for the bridge), but we're using this as a crude hack for now:
import java.util.Set;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import javax.security.auth.login.LoginException;
import javax.security.auth.login.CredentialNotFoundException;
import javax.resource.spi.security.PasswordCredential;
import org.jboss.jms.server.bridge.BridgeService;
public class JAASAwareBridgeService extends BridgeService {
private String sourceContext, targetContext;
public void setSourceLoginContext(String ctxName) { this.sourceContext = ctxName; }
public String getSourceLoginContext() { return this.sourceContext; }
public void setTargetLoginContext(String ctxName) { this.targetContext = ctxName; }
public String getTargetLoginContext() { return this.targetContext; }
public void start() throws Exception {
setupSourceCredentials();
setupTargetCredentials();
super.start();
}
private void setupSourceCredentials() throws LoginException {
PasswordCredential pc = getPasswordCredential(this.sourceContext);
super.setSourceUsername(pc.getUserName());
super.setSourcePassword(new String(pc.getPassword()));
}
private void setupTargetCredentials() throws LoginException {
PasswordCredential pc = getPasswordCredential(this.targetContext);
super.setTargetUsername(pc.getUserName());
super.setTargetPassword(new String(pc.getPassword()));
}
private static PasswordCredential getPasswordCredential(String contextName) throws LoginException {
LoginContext ctx = new LoginContext(contextName);
ctx.login();
Subject s = ctx.getSubject();
Set<PasswordCredential> creds = s.getPrivateCredentials(PasswordCredential.class);
if (creds.isEmpty())
throw new CredentialNotFoundException("Login context '" + contextName + "' subject has no PasswordCredential");
return creds.iterator().next(); // get 1st
}
}
--
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
12 years, 2 months