lazyducker/lambdaj

Lambdaj limitation with Dom4j

Opened this issue · 4 comments

What steps will reproduce the problem?
1. Inject some list of dom4j Attributes (e.g element.attributes()) into a test 
for the method listed below:

import static ch.lambdaj.Lambda.having;
import static ch.lambdaj.Lambda.selectFirst;
import static org.hamcrest.CoreMatchers.equalTo;

import java.util.List;

import org.dom4j.Attribute;
public class DocumentUtils {

    public static String getAttributeValueFromListByName(
            List<Attribute> list, String name) {

        Attribute requiredAttribute = selectFirst(list,
                having((Attribute.class).getName(), equalTo(name)));

        String value = requiredAttribute.getValue();

        return value;

    }
}


What is the expected output? What do you see instead?

I would expect the method to return the value of the specified (by 
name)attribute. Instead I get the following stacktrace:

ch.lambdaj.function.argument.ArgumentConversionException: Unable to convert the 
placeholder org.dom4j.Attribute in a valid argument at 
ch.lambdaj.function.argument.ArgumentsFactory.actualArgument(ArgumentsFactory.ja
va:92) at 
ch.lambdaj.function.matcher.HasArgumentWithValue.havingValue(HasArgumentWithValu
e.java:70) at ch.lambdaj.Lambda.having(Lambda.java:1204)


What version of the product are you using? On what operating system?

lambdaj2.4 on windows 7


Please provide any additional information below.

Dom4j 1.6, Junit 4.9


Original issue reported on code.google.com by declan.t...@gmail.com on 27 Mar 2012 at 11:20

Just making it clear that this effects all proxying of polymorphic classes, and 
not just this Dom4j scenario. Would love a fix!

Original comment by rmurf...@gmail.com on 15 May 2012 at 9:54

Am I wrong or are you missing to use the 'on' method like in:

Attribute requiredAttribute = selectFirst(list,
                having(ON(Attribute.class).getName(), equalTo(name)));

Original comment by mario.fu...@gmail.com on 8 Jul 2012 at 1:56

I've ran into exactly the same problem as the topic starter.
And yes, the on method as stated by Mario solves the problem.
I'm actually surprised to see that the original code compiles at all!

This issue can be closed as invalid.

Original comment by vadipp@gmail.com on 7 Nov 2013 at 5:57

Ah, the (Attribute.class).getName() code compiles because the Class object has 
a getName method. Easy as pie.

Original comment by vadipp@gmail.com on 7 Nov 2013 at 5:58