activationConditionRef problem

Rod Widdowson rdw at steadingsoftware.com
Sun Jul 12 10:56:10 EDT 2015


> As an example, see if you can
> get a simple String bean built with a constructor set by name. I don't
think I
> managed it.

I walked the code.  This appears to be a bug in the bytecode interpreter
(yes) inside Spring which doesn't find any parameters being looked at,
presumably because this is mostly a native class 

> In this particular case it's probably ok to circumvent the ability to
specify "true" and "false" because
> hardwiring that into a condition like this probably doesn't serve much
purpose, but once in a while 
> for debugging you might want to temporarily hardwire a condition to true
or false, so that's why 
> I was a little hesitant to break that.

I don't think you'd be breaking it, just making it less accessible.  After
all you can always say 
  
   <bean id="FalseBean" class="com.google.common.base.Predicates"
factory-method="alwaysFalse"/>
   <bean id="ExampleOrgPredicate"
parent="shibboleth.Conditions.RelyingPartyId" c:pred-ref="FalseBean "/>

Or some such....

R



More information about the dev mailing list