Add ability to inject properties in private classes

[michaelcouck]

Hi,

This is more a feature request than a bug ;)

With non-public classes, where the setters are either constructed manually or using a tool like lombok, the setter is not found. Perhaps a Class#methods() is the accessor for the setter methods, but presumably these are not visible. Perhaps a direct field setter option on the property annotation whereby the field is set directly, and not using a method?

Regards,
Michael

[fmbenhassine]

Hi Michael,

I'm really sorry for the late reply on this..

With non-public classes, where the setters are either constructed manually or using a tool like lombok, the setter is not found.

when you use lombok, setters are there and generated at compile time. Easy props acts at runtime, so these setters must be definitely there even if generated by lombok.

Perhaps a Class#methods() is the accessor for the setter methods, but presumably these are not visible. Perhaps a direct field setter option on the property annotation whereby the field is set directly, and not using a method?

Can you elaborate on this with an example please?
Easy props uses commons-beanutils which relies on setters to set the properties. If there is no setter, I'm not sure if easy propos can set the field. I need to test this case.

Kr,
Mahmoud

[fmbenhassine]

Hi Michael,

I think I understand now what you mean, but please correct me if I'm wrong. As of v2.0.1, Easy Props relies on Apache commons-beanutils to set properties on target objects. This requires the object class to be public and to provide a public setter for the target field. I believe this is because Apache commons-beanutils is targeted at JavaBeans (where a default constructor + public getters/setters are required).

The idea is to make this less restrictive and add the ability to inject properties in private classes, even those not providing a setter. Is that what you mean?

Here is a quick example:

import org.jeasy.props.annotations.SystemProperty;
import org.junit.Before;
import org.junit.Test;

import static org.assertj.core.api.Assertions.assertThat;
import static org.jeasy.props.PropertiesInjectorBuilder.aNewPropertiesInjector;

public class TestPropertyInjectionInNonPublicClass {

	@Before
	public void setUp() {
		System.setProperty("name", "foo");
	}

	@Test
	public void testPropertyInjectionInPrivateClassWithoutSetter() {
		// given
		MyBean myBean = new MyBean();

		//when
		aNewPropertiesInjector().injectProperties(myBean);

		// then
		assertThat(myBean.getName()).isEqualTo("foo");
	}
	
	private static class MyBean {

		@SystemProperty("name")
		private String name;

		public String getName() {
			return name;
		}
	}
}

This test fails today with v2.0.1 with java.lang.NoSuchMethodException: Property 'name' has no setter method in class 'class org.jeasy.props.TestPropertyInjectionInNonPublicClass$MyBean' (and passes if we make the class public and add a setter for name, which confirms the theory 😄 ).

I introduced a change (see b723efb) that uses the Java reflection API to set the value directly on the field without relying on apache commons beanutils and this test passes now.

I already deployed v3.0.0-SNSAPSHOT with this enhancement. I would be grateful if you could give it a try and let me know what you think. Many thanks upfront!

[michaelcouck]

Hi Mahmoud,

Looking at my comment from three years back it doesn't even seem familiar :) lol, I really can't remember what project that was for, or what the problem was. I do remember that we modified your tool a little and used it as is. I think I might have sent a pull request, also can't remember I am afraid. But somehow I seem to think that you are right, it had something to do with visibility, and setting the field directly would sort that out as you said.

Thanks for the great really easy tool :)

See ya,
Michael

[fmbenhassine]

Hi Michael,

No worries, I had the same feeling when reading my own comment a couple of years later 😄

The fix has been included in v3.0.0 which is now released.

Thank you for reporting this issue and for your contribution in #10!

Best regards,
Mahmoud