[JBoss JIRA] Created: (GTNWSRP-218) Force use of JBoss EL on AS 6
by Chris Laprun (JIRA)
Force use of JBoss EL on AS 6
-----------------------------
Key: GTNWSRP-218
URL: https://issues.jboss.org/browse/GTNWSRP-218
Project: GateIn WSRP
Issue Type: Sub-task
Components: Admin GUI
Affects Versions: 2.1.0-Beta01
Reporter: Chris Laprun
Assignee: Chris Laprun
Fix For: 2.1.0-Beta02
The EL evaluation engine seems to have changed between AS 5 and AS 6 and results in improper evaluations of expressions leading to calls being made on objects that are not ready to respond to them.
More specifically line 77 in /jsf/consumers/consumer.xhtml: rendered=#{!cons.refreshNeeded and cons.active and cons.producerInfo.registrationRequired}
Basically, it doesn't seem like the EL expression: !cons.refreshNeeded and cons.active and cons.producerInfo.registrationRequired is properly interpreted (or at the very least, not interpreted like it was on AS 5).
When the exception which causes the portlet to fail is thrown, the state is so that the expression should not be completely evaluated:
cons.refreshNeeded is true so !cons.refreshNeeded is false, the evaluation of the expression should stop because the result is already known to be false before looking at the rest of the expression (which is the Java behavior, foo && bar results in bar never being evaluated if foo is false).
Moreover, cons.active is also false (even though it should never be evaluated).
The exception is thrown because, despite the appropriate guards (the first two expressions !cons.refreshNeeded and cons.active), the EL engine still evaluates the last clause when the state of the underlying objects is not ready for such an evaluation as the root exception clearly states (java.lang.IllegalStateException: Registration status not yet known: call refresh first!). For me, this is a bug in the EL evaluation engine. At the very least, this is a huge change in behavior which should be documented somewhere i.e. the fact that you cannot rely on lazy evaluation of expressions in "and" clauses but this seems to be too big a behavioral change (which would also go against how Java works) for it to be proper behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Assigned: (GTNWSRP-132) Provide security authentication per wsrp producer in the consumer
by Chris Laprun (JIRA)
[ https://issues.jboss.org/browse/GTNWSRP-132?page=com.atlassian.jira.plugi... ]
Chris Laprun reassigned GTNWSRP-132:
------------------------------------
Assignee: Matt Wringe (was: Chris Laprun)
> Provide security authentication per wsrp producer in the consumer
> -----------------------------------------------------------------
>
> Key: GTNWSRP-132
> URL: https://issues.jboss.org/browse/GTNWSRP-132
> Project: GateIn WSRP
> Issue Type: Feature Request
> Reporter: Julien Viet
> Assignee: Matt Wringe
> Fix For: 2.1.0
>
>
> Security based on SOAP/HTTP security which allow basic/digest authentication.
> Usually the stub can be configured using smth like :
> Stub stub = // ... get the Stub;
> stub._setProperty ("javax.xml.rpc.security.auth.username", "juliet");
> stub._setProperty ("javax.xml.rpc.security.auth.password", "mypassword");
> We need to support several kind of username/password style, so we should have
> 1/ a global username/password for the whole producer, smth like
> <wsrp-producer>
> <producer-id>blah</producer-id>
> ...
> <auth-config>
> <username>blah username</username>
> <password>blah password</password>
> </auth-config>
> </wsrp-producer>
> 2/ a generic mechanism that would allow more fine grained username/password that can allow to make identity propagation (for sso)
> <wsrp-producer>
> <producer-id>blah</producer-id>
> ...
> <auth-config>
> <credential-factory>org.client.BlahCredentialFactory</credential-factory>
> </auth-config>
> </wsrp-producer>
> with an interface which allows to retrieve credentials. Usually the factory implementations leverage thread local mechanisms to integrate the user identity with a username/password storage like :
> String userId = UserId.getCurrentUserId();
> String password = passwordStore.getPassword(userId);
> return new WSRPCredential(userId, password);
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months