Issue 1:
Friedrich Messner opened SPR-9453 and commented

We're using Spring's BeanWrapper to access a bean via reflection. For one bean's property

which has a generic type

which is read-only (no setter)

whose getter implements an interface

we're getting a org.springframework.beans.NotReadablePropertyException since Spring 3.1. I tracked it a little bit and found out that it is related to the ExtendedBeanInfo class introduced with Spring 3.1. The following example demonstrates this:

package org.springframework.beans;

import static org.junit.Assert.assertEquals;

import java.beans.BeanInfo;
import java.beans.IntrospectionException;
import java.beans.Introspector;

import org.junit.Test;

public class BeanInfoTest {

public interface Interface<T> {
T getProp();
}

public final class Bean implements Interface<Class<?>> {
private Class<?> prop;
public Class<?> getProp() { return prop; }
}

@Test
public void testWithPlainBeanInfo() throws IntrospectionException {
BeanInfo info = Introspector.getBeanInfo(Bean.class);
assertEquals(2, info.getPropertyDescriptors().length);
}

@Test
public void testWithExtendedBeanInfo() throws IntrospectionException {
ExtendedBeanInfo extendedInfo = new ExtendedBeanInfo(
Introspector.getBeanInfo(Bean.class));
assertEquals(2, extendedInfo.getPropertyDescriptors().length);
}
}

While the first test passes, the second fails on IBM JVM 1.6.

If we do any of

add a setter

remove the interface

change the type to non-generic (e.g. String)

run it under Sun JVM 1.6

it works.

It seems that ExtendedBeanInfo has a problem with the covariant return types coming from the bridge method for the generic property.

Affects: 3.1.1

Attachments:

introspect.tgz (1.74 kB)

Issue Links:

#14336 ExtendedBeanInfo exception - java.beans.IntrospectionException ("is duplicated by")

#14663 Overhaul non-void JavaBean write method support

Referenced from: commits b50bb50, 0ee1256, 30d0bd3, 4a8be69

1 votes, 5 watchers

Issue 2:
Casey Butterworth opened SPR-5192 and commented

I have recently started some work on an @LookupMethod annotation to be used in the following situation:

A prototype scoped bean needs to be used within a singleton

The singleton was created using component scanning

Currently the most obvious solution would be to forgo component scanning for the singleton and define the lookup-method in the ApplicationContext XML or using spring-java-config, e.g:

<!-- this could also be created using component scanning -->
<bean id="myPrototype" class="sample.MyPrototype" scope="prototype"/>

<bean id="mySingleton" class="sample.MySingleton">
<lookup-method name="createMyPrototype" bean="myPrototype"/>
</bean>

However, since I've been using component scanning with 2.5, it doesn't feel right defining the wiring outside of the components, and it would be ideal if we could do something like the following:

@Component
public abstract class MySingleton {
@LookupMethod(beanRef = "myPrototype")
protected abstract MyPrototype createMyPrototype();
}

@Component
public class MyPrototype {}

It would be even better if @LookupMethod could work in conjunction with autowiring (by type), but that can be a subsequent feature request.

I've started to implement a solution and will attach shortly.

Attachments:

LookupMethod.java (348 bytes)

LookupMethod.java (394 bytes)

lookup-method.zip (10.43 kB)

LookupMethodAnnotationBeanPostProcessor.java (2.14 kB)

Issue Links:

#12089 Passing lookup-method arguments to created bean constructor

#15860 BeanFactory lacks method for getting bean by type with specified constructor arguments

Referenced from: commits eb0ab84

37 votes, 33 watchers