[
http://team.ops4j.org/browse/QI-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986#comment-17986
]
Paul Merlin commented on QI-329:
--------------------------------
Ok, one night sleeping on this and it's more clear for me.
The TypeToCompositeLookupTest is not disabled anymore and expose the current
behavior which is as follows.
*Objects, Transients and Values*
They have the very same behavior, here is the ValueComposite as an example:
{code:java}
interface Foo {}
interface FooValue extends Foo, ValueComposite {}
interface SomeFooValue extends FooValue {}
:
{
moduleAssembly.values( SomeFooValue.class );
:
module.newValueBuilder( SomeFooValue.class ); // Resolve to SomeFooValue
module.newValueBuilder( FooValue.class ); // Resolve to SomeFooValue
module.newValueBuilder( Foo.class ); // Resolve to SomeFooValue
}
:
{
moduleAssembly.values( SomeFooValue.class, FooValue.class );
:
module.newValueBuilder( SomeFooValue.class ); // Resolve to SomeFooValue
(exact type match)
module.newValueBuilder( FooValue.class ); // Resolve to FooValue (exact
type match)
module.newValueBuilder( Foo.class ); // Throws
AmbiguousTypeException!
}
{code}
*Entities*
Entities type lookup behave differently when it comes to
{code:java}
interface Foo {}
interface FooEntity extends Foo, EntityComposite {}
interface SomeFooEntity extends FooEntity {}
:
{
moduleAssembly.entities( SomeFooEntity.class );
:
uow.newEntityBuilder( SomeFooEntity.class ); // Resolve to SomeFooEntity
uow.newEntityBuilder( FooEntity.class ); // Resolve to SomeFooEntity
uow.newEntityBuilder( Foo.class ); // Resolve to SomeFooEntity
}
:
{
moduleAssembly.entities( SomeFooEntity.class, FooEntity.class );
:
uow.newEntityBuilder( SomeFooEntity.class ); // Resolve to SomeFooEntity
(exact type match)
uow.newEntityBuilder( FooEntity.class ); // Resolve to FooEntity (exact
type match)
uow.newEntityBuilder( Foo.class ); // Resolve to SomeFooEntity
(first declared matching type, assembly order)
}
{code}
*Services*
Services lookup never throw AmbiguousTypeException as there can be multiple
Services implementing a given type, by design. Like Entities it's the assembly
order of type declaration that dictate the order of Service type lookup.
I see one issue here: it's not the exact matching type that is found as first
but the first in assembly order.
See the TypeToCompositeLookupTest {{services()}} and
{{servicesPluralDeclaration()}} test methods for details.
----
So, one possible change would be to allow Objects, Values and Transients type
lookup to use first matching type in assembly order when there are several
matches. It would mean no more AmbiguousTypeException in this case and that
developers would have to keep in mind their assembly declaration order.
For all Composite types to behave the same, another change is needed in Service
type lookup to order first by matching type and then by assembly order.
We could also go further by speaking of closest type match instead of exact
type match.
----
I hope I made my point clear, not so easy with my frenchie english :)
Tell me what you think.
/Paul
> ValueBuilderFactory doesn't perform correct type-to-composite lookup
> --------------------------------------------------------------------
>
> Key: QI-329
> URL: http://team.ops4j.org/browse/QI-329
> Project: Qi4j
> Issue Type: Bug
> Components: Core Runtime
> Reporter: Niclas Hedhman
> Fix For: 2.0 - Reductionism
>
>
> When doing
> {code}
> ValueBuilder<DomainEvent> builder = vbf.newValueBuilder(DomainEvent.class)
> {code}
> Type-to-Composite lookup/search is not happening.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://team.ops4j.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
