[jira] [Resolved] (ARIES-1248) Unable to create bean when passing subclass of BlockingQueue where argument is of type BlockingQueue and takes generics.

["Guillaume Nodet (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARIES-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Nodet resolved ARIES-1248.
------------------------------------
       Resolution: Fixed
         Assignee: Guillaume Nodet
    Fix Version/s: blueprint-core-1.9.0

Committing to https://svn.apache.org/repos/asf/aries/trunk ...
	A	blueprint/blueprint-core/src/test/resources/test-threadpool.xml
	M	blueprint/blueprint-core/src/test/java/org/apache/aries/blueprint/WiringTest.java
Committed r1822717


> Unable to create bean when passing subclass of BlockingQueue where argument is of type BlockingQueue and takes generics.
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-1248
>                 URL: https://issues.apache.org/jira/browse/ARIES-1248
>             Project: Aries
>          Issue Type: Bug
>          Components: Blueprint
>            Reporter: Andrew
>            Assignee: Guillaume Nodet
>            Priority: Major
>             Fix For: blueprint-core-1.9.0
>
>
> Here's a damn silly problem. Given the following code:
> {code:xml}
> <bean id="executorService" class="java.util.concurrent.ThreadPoolExecutor">
> 		<argument>
> 			<value>10</value>
> 		</argument>
> 		<argument>
> 			<value>10</value>
> 		</argument>
> 		<argument>
> 			<value>10</value>
> 		</argument>
> 		<argument value="SECONDS" />
> 		<argument>
> 			<bean class="java.util.concurrent.LinkedBlockingQueue" />
> 		</argument>
> 	</bean>
> {code}
> I get the following exception (in part):
> {code}
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_67]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_67]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_67]
> 	at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_67]
> 	at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
> 	at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
> 	at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:313)
> {code}
> Why? Because it's trying to pass a {{LinkedList}} to the method! Given a signature of
> {code:java}
> public ThreadPoolExecutor(int corePoolSize,
>                               int maximumPoolSize,
>                               long keepAliveTime,
>                               TimeUnit unit,
>                               BlockingQueue<Runnable> workQueue)
> {code}
> That obviously won't work.
> It appears that this is showing up in {{org.apache.aries.blueprint.container.AggregateConverter#convertToCollection}} - line 326, where it creates a *new* collection, rather than using the one I've passed in. Ruh-roh - I've configured a few things on this collection that I don't want to lose, like the maximum size of the queue.
> At a minimum, a few more cases need to be added to CollectionRecipe, plus it needs to accommodate Concurrent collections more - they have a lot of initial configuration, potentially, that needs to be kept. If I specify a maximum queue size of 10 as an argument to LinkedBlockingQueue, but you return a brand-new LinkedBlockingQueue, that will be unbounded - not what I want!
> I can see why you're doing it this way, but it seems like a very, very bad idea. Could it not be modified to return the original collection if it's empty, say?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)