[JBoss JIRA] Created: (JBRULES-2079) ruleBase.addPackage(packageBuilder.getPackage()); should fail-fast with a clear error message if the packageBuilder has any errors
by Geoffrey De Smet (JIRA)
ruleBase.addPackage(packageBuilder.getPackage()); should fail-fast with a clear error message if the packageBuilder has any errors
----------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2079
URL: https://jira.jboss.org/jira/browse/JBRULES-2079
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.0.0.CR1
Reporter: Geoffrey De Smet
Assignee: Mark Proctor
Priority: Minor
Fix For: 5.1.0.M1
After you 've build your package with packageBuilder,
you've either called the hasErrors() method and done something about it
or you didn't check the hasErrors() method because you didn't know (or want to know) it existed and you expect it to throw an exception because hasErrors() returns true.
The principle of least surpise. You don't expect that it continues like everything is cool (while it's not) and crashes the moment you fire your first rules.
The exception should be a runtime exception and the message should at least mention the first of the errors.
The exception should probably contain a list of all errors of course too as a property.
See InvalidStateException in hibernate-validator.
--
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
10 years, 5 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
10 years, 5 months
[JBoss JIRA] Created: (JBMESSAGING-1478) inconsistent test suite performance
by Aleksandar Kostadinov (JIRA)
inconsistent test suite performance
-----------------------------------
Key: JBMESSAGING-1478
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1478
Project: JBoss Messaging
Issue Type: Bug
Components: Tests and Performance
Affects Versions: 1.4.0.SP3.CP04
Reporter: Aleksandar Kostadinov
Assignee: Tim Fox
I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
The mysql database is shared but I doubt it is the culprit.
I run the test suite with the following options:
property( name: "functional.tests.database", value: dbname )
property( name: "stress.tests.database", value: dbname )
property( name: "clustering.tests.database", value: dbname )
property( name: "test.target", value: "report" )
property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])
property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
Are there any other options I can add to increase isolation from other processes in the same LAN?
Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/
--
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
10 years, 5 months