[
http://issues.ops4j.org/browse/QI-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989#action_13989
]
Niclas Hedhman commented on QI-307:
-----------------------------------
I am not sure what we should do about this issue.
1. Should we introduce development mode system properties where these kind of
stuff are configured, and defaults to the best production level behavior?
2. What is exactly asked to be done?
> Better behaviour for complex generic usecases (related to QI-306)
> -----------------------------------------------------------------
>
> Key: QI-307
> URL: http://issues.ops4j.org/browse/QI-307
> Project: Qi4j
> Issue Type: Improvement
> Components: Core Runtime
> Affects Versions: 1.2
> Environment: Any.
> Reporter: Stanislav Muhametsin
> Fix For: 1.3
>
>
> Currently the exception thrown by Qi4j in scenario described in QI-306 makes
> user think there is a bug in Qi4j. To avoid duplicate issues, this could be
> fixed to produce more meaningful exception (warning about possibility of
> ambigous types later).
> Even more better way would be to have some kind of switch, which would allow
> the developer to take the risk and have the scenarios mentioned in QI-306. I
> for for one am using that kind of scenarios quite a lot in one of my
> projects, and the fix is really just one-line-change (at least in this case).
> I don't think it benefits to act too protectively in this case, but rather in
> "i will let you do it, if you really want" -manner. So if the switch is off,
> the exception is always thrown. If switch is on, then some kind of warning
> could be generated in log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/secure/Administrators.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
