[JBoss JIRA] Created: (JASSIST-92) ExprEditor: edit "throw new Exception"-Statements
by Hans-Joerg Adel (JIRA)
ExprEditor: edit "throw new Exception"-Statements
-------------------------------------------------
Key: JASSIST-92
URL: https://jira.jboss.org/jira/browse/JASSIST-92
Project: Javassist
Issue Type: Feature Request
Affects Versions: 3.11.0.GA
Environment: WIndows Vista Java 1.6
Reporter: Hans-Joerg Adel
Assignee: Shigeru Chiba
Priority: Minor
Hi!
At the moment I am using the ExprEditor. I miss an edit-Method to access throw statements like the follwing ones:
throw new RuntimeException();
try {
foobar(x);
} catch (IllegalArgumentException e) {
doSomething();
throw e; // this statement
}
I think of something like this:
public void edit(ThrowExpr t) {
t.getType(); // returns the CtClass of the thrown Exception
}
Cheers
Ruwen and Hans-Joerg
--
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
15 years, 9 months
[JBoss JIRA] Created: (JBRULES-2224) multi-restriction pattern throws UnsupportedOpEx
by Wolfgang Laun (JIRA)
multi-restriction pattern throws UnsupportedOpEx
------------------------------------------------
Key: JBRULES-2224
URL: https://jira.jboss.org/jira/browse/JBRULES-2224
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (expert)
Affects Versions: 5.0.1.FINAL
Reporter: Wolfgang Laun
Assignee: Mark Proctor
rule "same"
when
$m : ShGraphType( $x25No : x25No, $trans : trans )
GoType( x25No == $x25No || == ($x25No % 2000), trans != $trans ) #!!!#
$e : ShType( x25No == $x25No )
$v : View( elemSet contains $m )
then
Field x25No is an int.
The marked pattern is not flagged in Eclipse, passes the compiler without an error, but crashes at runtime during fact insertion with:
Exception in thread "main" java.lang.UnsupportedOperationException: does not support method call isAllowed(Object object, InternalWorkingMemory workingMemoiry)
at org.drools.rule.ReturnValueRestriction.isAllowedCachedRight(ReturnValueRestriction.java:252)
at org.drools.rule.OrCompositeRestriction.isAllowedCachedRight(OrCompositeRestriction.java:51)
at org.drools.rule.MultiRestrictionFieldConstraint.isAllowedCachedRight(MultiRestrictionFieldConstraint.java:115)
at org.drools.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:181)
at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:172)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:360)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:344)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:184)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:146)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1094)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1045)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:830)
at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:219)
at rss.checker.engine.impl.DroolsEngine.insert(DroolsEngine.java:61)
--
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
15 years, 9 months
[JBoss JIRA] Created: (JBAS-8352) Stacked login with subclassed Principal does not work.
by Craig Horrell (JIRA)
Stacked login with subclassed Principal does not work.
------------------------------------------------------
Key: JBAS-8352
URL: https://jira.jboss.org/browse/JBAS-8352
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.1.0.GA
Environment: Windows XP; Jboss 5.1.0.GA;
Reporter: Craig Horrell
Assignee: Anil Saldhana
The Principal is not propagated from login module to login module when using stacked logins. Instead, a new Principal is created, but only the first one survives.
Code references:
1. org.jboss.security.auth.spi.UsernamePasswordLoginModule: Method login():
Object username = sharedState.get("javax.security.auth.login.name");
if (username instanceof Principal) {
identity = (Principal) username;
} else {
String name = username.toString();
try {
identity = createIdentity(name);
} catch (Exception e) {
log.debug("Failed to create principal", e);
throw new LoginException("Failed to create principal: " + e.getMessage());
}
}
The code above checks to see if the Object stored in the shared state is a Principal. This code is correct.
2. Later in the same method:
if (getUseFirstPass() == true) { // Add the username and password to the shared state map
sharedState.put("javax.security.auth.login.name", username);
sharedState.put("javax.security.auth.login.password", credential);
}
This is part of the bug. It stores the name instead of the Object, which causes the second login module to create a new Principal.
3. org.jboss.security.auth.spi.AbstractServerLoginModule: Method: commit():
Principal identity = getIdentity();
principals.add(identity);
'principals' is a Set. The add will not replace an existing identity, so the one created by the second login module is ignored.
If the second login module got the object from the first, it could update it. As it is the second login module cannot do anything with the principal, as it is discarded.
Complications: Some thought would have to be given as to what would happen if two different principal classes were specified in the config. Perhaps disallow that ?
Our specific issue: We have a subclassed SimplePrincipal that holds context based security information for that user that is checked as part of the authorization in our web services. We stack a LDAP login module for the user-id and password, then a subclass of DatabaseServerLoginModule that gets the roles and other context based data from a database.
Work Around: in the subclassed DatabaseServerLoginModule's getRoleSets() method we do:
// To overcome stacked login bugs, we must replace the existing principal
// with a new one created here.
Principal pr = this.getIdentity();
log.trace("SlDbServerLoginModule: getRoleSets(): "
+ "Got Principal from parent: user: " + pr.getName());
SlIdentity slId = new SlIdentity(pr.getName());
slId.addClientList(getSlClientList(username, roleSet));
slId.addSiteList(getSlSiteList(username, roleSet));
Set<Principal> prs = this.subject.getPrincipals();
prs.remove(pr);
prs.add(slId);
log.trace("SlDbServerLoginModule: getRoleSets(): "
+ "Replaced Principal with SlIdentity: user: " + slId.getName());
return roleSets;
Thanks,
Craig.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months