[
https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889820#comment-15889820
]
Karl Pauls commented on FELIX-5573:
-----------------------------------
Right, throwing some kind of CNFE might be one solution to it but first things
first - right now, we don't expect to return null in the first place. This is a
special case that makes that happen but we "explicitly" assume it will not. The
relevant comment is:
// If a cycle is detected, we should return null to break the
// cycle. This should only ever be return to internal class
// loading code and not to the actual instigator of the class load.
It sounds like this assumption doesn't hold in the case of a class load of a
class that requires to be woven "by itself". In other words, we use null as a
result to signal to _internal_ code that this was a cycle and needs to be dealt
with accordingly. In this case our _internal_ code doesn't deal with it (or so
it appears) and if that is true it needs to be addressed so that it does. That
is when the question of how comes up.
Whether the fix is to throw an exception or to ignore the cycle in this case
and allow the class load to succeed unwoven we have to see. Regardless, it
should be because we understand that this is going on and not an accident.
> Detect recursive class loads while invoking weaving hooks
> ---------------------------------------------------------
>
> Key: FELIX-5573
> URL: https://issues.apache.org/jira/browse/FELIX-5573
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-5.6.2
> Reporter: Karl Pauls
> Assignee: Karl Pauls
> Fix For: framework-5.6.4
>
>
> We need to detect recursive class loads while invoking weaving hooks, if
> recursion is detected for a class name then we want to simply ignore all
> weave hooks for the recursive class load and allow it to proceed to define
> class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
