ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (IVY-696) StackOverflowError when configuration extends itself
Date Tue, 04 Mar 2008 17:53:41 GMT

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

Xavier Hanin resolved IVY-696.
------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 2.0)
                   2.0-RC1

I've fixed this by checking configurations cycles at parse time. Consequently the StackOverflowError
is still technically feasible if you use a custom parser, with a custom ModuleDescriptor implementation
in which you don't check the cycles. But we can consider this is part of the ModuleDescriptor
contract to be valid.

> StackOverflowError when configuration extends itself
> ----------------------------------------------------
>
>                 Key: IVY-696
>                 URL: https://issues.apache.org/jira/browse/IVY-696
>             Project: Ivy
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.0-beta-1
>            Reporter: Johannes Rudolph
>            Assignee: Xavier Hanin
>            Priority: Minor
>             Fix For: 2.0-RC1
>
>
> I filed this as a bug though it is a clear usage error. But since this might happen more
often I think it should be handled more gracefully and informatively:
> If a configuration is specified to extend itself like in here:
> {quote}
>  <configurations>
>                 <conf name="compile" visibility="public" extends="compile"/>
>                 <conf name="runtime"/>
>  </configurations>
> {quote}
> Ivy doesn't complain but fails with a StackOverflowError:
> {quote}
> --- Nested Exception ---
> java.lang.StackOverflowError
>         at java.util.HashMap.getEntry(HashMap.java:344)
>         at java.util.LinkedHashMap.get(LinkedHashMap.java:280)
>         at org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor.getConfiguration(DefaultModuleDescriptor.java:368)
>         at org.apache.ivy.core.resolve.IvyNode.addRootModuleConfigurations(IvyNode.java:596)
>         at org.apache.ivy.core.resolve.IvyNode.addRootModuleConfigurations(IvyNode.java:599)
>         at org.apache.ivy.core.resolve.IvyNode.addRootModuleConfigurations(IvyNode.java:599)
>         at org.apache.ivy.core.resolve.IvyNode.addRootModuleConfigurations(IvyNode.java:599)
> {quote}
> This might as well be valid for arbitrary configuration inheritance cycles, but I didn't
tested this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message