[
https://issues.jboss.org/browse/FORGE-1206?page=com.atlassian.jira.plugin...
]
Lincoln Baxter III commented on FORGE-1206:
-------------------------------------------
We have decided to remove the @Exported annotation and perform service lookup implicitly
based on calculated classloader boundaries. This effectively means that the AddonRegistry
getImported() queries will provide whatever the aggregate ServiceRegistry instances are
willing to produce. Essentially, what is a service and what is not is now solely up to the
implementing ServiceRegistry.
This resolves consistency issues with attempting to @Inject a Type vs getImported() vs
Imported.get(). They now all behave the same, and now all resolve anything in the
ServiceRegistries.
Imported<?>.get() has a different behavior compared to
iterator()
-----------------------------------------------------------------
Key: FORGE-1206
URL:
https://issues.jboss.org/browse/FORGE-1206
Project: Forge
Issue Type: Bug
Components: Furnace (Container)
Affects Versions: 2.0.0.Alpha12
Reporter: George Gastaldi
Fix For: 2.x Future
Given:
{code:java}
public interface MyInterface {}
{code}
and
{code:java}
public class Foo implements MyInterface {}
{code}
Trying to retrieve it from the Imported object from AddonRegistry:
{code:java}
Imported<MyInterface> imported = addonRegistry.getServices(MyInterface.class);
{code}
The following statements are observed:
# imported.get() returns instance of Foo
# imported.iterator().hasNext() returns false.
Since no {{@Exported}} is placed in {{MyInterface}}, I believe the first statement is a
bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira