Null values passed to Injected constructor with multiple name-quailified injections

[LandonLunsford]

If you have a constructor with multiple name-qualified injection mappings the method will receive null values, except for the last one which is valid.

example:

injector.map(BitmapData, 'a').toType(bitmapClass_a);
injector.map(BitmapData, 'b').toType(bitmapClass_b);
injector.map(BitmapData, 'c').toType(bitmapClass_c);
injector.getInstance(Foo);

[Inject(name = "a", name="b", name="c")]
public class Foo {
public function Foo(a:BitmapData, b:BitmapData, c:BitmapData){
a.doSomething(); // throws null pointer exception
b.doSomething(); // throws null pointer exception
c.doSomething(); // behaves as expected
}
}

[tschneidereit]

Interesting. That looks like a bug in how argument values are collected
during injection.

Thanks for the report, I'll look into it.

[pmowrer]

Is this an open bug still? I'm having an issue that's exhibited in the same way, only I can't put my finger on what's triggering it (it's not name-qualified mappings in my case).

[LandonLunsford]

The issue is still live and well in my copy of Swiftsuspenders-v2.0.0rc1.swc

However I think I saw a pull request related to this that was merged somewhat recently.

Till, has this been resolved?

When I get a chance I will see if I cannot add a unit test to reproduce what I was experiencing.

[pmowrer]

It appears the issue I was experiencing is fixed in the master branch. :)

It is however present in the RC that shipped with RL 2.0. I'm surprised more people from the RL community haven't ran into it.

[tschneidereit]

Patrick, thanks for the confirmation that this is fixed in master. Sadly, I
have little to no time to invest in Swiftsuspenders these days, so please
accept my apologies for responding this slowly.

@darscan, maybe you can spin a new version and integrate that into
Robotlegs 2?

[darscan]

Hi @pmowrer

..fixed in the master branch .. however present in the RC that shipped with RL 2.0

They should be the same (unless I did the release incorrectly):

https://github.com/tschneidereit/SwiftSuspenders/commits/master
https://github.com/robotlegs/swiftsuspenders/commits/master

Will have a look when I get the chance.

[darscan]

So, there's a test that mostly covers this already (with 2 named constructor args), and it's passing on master. I wrote another test that verifies that 3 named constructor arguments are dealt with correctly, and they are, but I don't think it adds any value so I haven't submitted it.

To test that the version of Swiftsuspenders released with v2.0.0 works correctly I added an integration test to the robotlegs test suite. It passes there as well. I didn't commit it as it's already covered by the swiftsuspenders test suite in a way that I'm currently comfortable with.

However, while doing this I found an almost certainly unrelated bug in our RobotlegsInjector adapter which I fixed and added tests for.

This warrants a new Robotlegs release so once I do that could you please check again that you're still getting this error when using Robotlegs?

[pmowrer]

Sure thing!

I'm using a custom RL2 SWC with the master SwiftSuspenders branch right now to get around the constructor injection nulls. If I swap it for the official RL2 release SWC, the nulls resurface. Let me know when the new release is ready and I'll try it out.

The problem I'm seeing is not related to named constructor arguments. I wish I could provide a test for this but I never figured out what exactly triggers it.

[darscan]

Cool, I've released Robotlegs 2.1.0. I built it against Swiftsuspenders 2.0.0rc3:

https://github.com/robotlegs/swiftsuspenders/commits/master

Please let me know if you're still seeing the issue.

[darscan]

You can download RL 2.1.0 over at: http://www.robotlegs.org/

[pmowrer]

Just verified that the issue no longer occurs in RL 2.1.0, whereas it does in RL 2.0.0. Thanks @darscan!

[darscan]

Excellent, can this issue be closed?

[LandonLunsford]

Sounds like

On Sat, Jun 29, 2013 at 1:44 PM, Shaun Smith [email protected]:

Excellent, can this issue be closed?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/76#issuecomment-20236854
.