Unit tests fail when using Java 8 to build maven package about ognl HOT 8 CLOSED

I did a short test to see how the matching for java itself behaves:

    public static void main(String[] args) {
        Messages messages = new Messages(new HashMap<Object, Object>());
        System.out.println("messages.format('ShowAllCount', one) => \"foo\" == "+messages.format("ShowAllCount", 1 )); 
        System.out.println("messages.format('ShowAllCount', {one}) => \"foo\" == "+messages.format("ShowAllCount", new Object[] { 1 } )); 
        System.out.println("messages.format('ShowAllCount', {one, two}) => \"foo\" == "+messages.format("ShowAllCount", new Object[] { 1, 2 } )); 
        System.out.println("messages.format('ShowAllCount', one, two) => \"foo\" == "+messages.format("ShowAllCount", 1, 2 )); 
    }

The result is:

messages.format('ShowAllCount', one) => "foo" == first
messages.format('ShowAllCount', {one}) => "foo" == foo
messages.format('ShowAllCount', {one, two}) => "foo" == foo
messages.format('ShowAllCount', one, two) => "foo" == haha

And this is the same for both java versions (1.7 & 1.8). So this would be the ideal result ;)

from ognl.

Looks like the same issue as here https://issues.apache.org/jira/browse/OGNL-250

from ognl.

Hi @lukaszlenart ,
Thank you for this link. I havn't been aware that the OGNL project on apache is still alive ;)

Never the less I started digging a bit deeper into it (also in conjunction with #17 ) and it seems that there are two seperate implementations for finding out the appropiate method:
OgnlRuntime.getReadMethod() used by the compiler and OgnlRuntime.getAppropriateMethod() in other cases.

Might it make sense to centralize it to one implementation?

I also have seen that methods are actually called during the compile(). Are you aware of this? Dosn't it cause a lot of confusion in the backend?

And should wie transfer my tickets to Apache?

from ognl.

Yes, I mean, soon I want to switch all the efforts to Apache Commons OGNL and start preparing a new 4.0 release. I don't want to spend more time on extending/improving 3.x line - it's here just to keep support, fix bugs and so on.

from ognl.

So does it make sense to fix this regressin in 3.x or shall i just fix my issue in #17 and leave this as Task for OGNL 4?

from ognl.

Up to you but OGNL4 can differ in this area so maybe there is no such issue there.

from ognl.

one remark: releasing OGNL3 is under my command, with OGNL4 won't be that easy ;-)

from ognl.

Hi,

I started digging into that method matching and implemented an initial version.
It works with all current unit tests and also fixes #17.

Please have a look on the code and decide what to do. It could fix a lot things but also be dangerous...

And just some ideas i had while i was working in the depth of OGNL - could be interesting for OGNL4:

It might be better to have all the Matching and Conversion stuff done on "Java-Class" basis instead of Object basis. I think this is why methods are called during OGNL.compile() - to get the returning Object. When the method is not callable or failing the compiler starts struggling.
My Opinion is that the Object is not really required. I think looking taking Method.getReturnType() and working with the class would be better provides better matching capabilties - we even know what it is if the method fails or returns null.

And as further use case - it might be passible to implement autocompletion / code assist functionality based on this for OGNL ;)

Are there already some discissions on this?

from ognl.