groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: GroovyDoc classloader issue
Date Mon, 25 Feb 2019 21:23:43 GMT
Hi Alexey, the attachment came through. I just haven't had time to test it
yet. Thanks!

Cheers, Paul.

On Tue, Feb 26, 2019 at 1:20 AM Alexey Belostotskiy <lexek-92@ya.ru> wrote:

> Hi, did you receive the last email (with test in attachment)? I'm not sure
> if it was sent properly.
>
> 20.02.2019, 17:34, "Alexey Belostotskiy" <lexek-92@ya.ru>:
>
> Hi, it's kind of messy, but I hope you'll get the idea.
>
> 19.02.2019, 23:48, "Paul King" <paulk@asert.com.au>:
>
> Our preference would be to have a standalone testcase that triggers your
> problem. Are you in a position to create such a test?
>
> On Wed, Feb 20, 2019 at 1:24 AM Alexey Belostotskiy <lexek-92@ya.ru>
> wrote:
>
> Hello,
>
> We're generating groovydocs in runtime in our app. We use groovydoc as a
> library, not standalone tool.
>
> It mostly works, but we're experiencing issues with some classes ending up
> unresolved. I found out that this happens because SimpleGroovyClassDoc is
> calling its getClass().getClassLoader() to get classloader for class
> resolution. But in our case, most of classes that we want to link should be
> loaded via different classloader.
>
> Basically, solution that would work for us, is to replace
> getClass().getClassLoader() calls in SimpleGroovyClassDoc with
> Thread.currentThread().getContextClassLoader(), but that might be a
> breaking change.
>
> I'm not sure what the process is for requesting such changes and whether
> it's something that Groovy team is willing to implement.
>
>

Mime
View raw message