Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CatalogsWithCleanIntegrationTest: Failing test on Windows #48

Open
dlmiles opened this issue Mar 25, 2023 · 1 comment
Open

CatalogsWithCleanIntegrationTest: Failing test on Windows #48

dlmiles opened this issue Mar 25, 2023 · 1 comment

Comments

@dlmiles
Copy link

dlmiles commented Mar 25, 2023

This IT serves to document the problem.

When building a project using this gradle plugin in an IDE on windows
it is necessary restart the gradle daemon process (causing it to
release open file handles) to allow a clean to occur after using
this feature (catalogs resolved with classpath:/maven: scheme).

The cause is suspected to be a lost InputStream inside XJC maybe from the
CatalogResolver#resolveEntity(String,String) implementation from
xml-resolver:xml-resolver:1.2 that isn't being closed. As XJC is built
more like a command line tool no one may have noticed.

Another commit will fix the URLClassLoader.close() use in this plugin
but that does not fix this issue.

Things already tried to resolve it with no luck so far, intercept
CatalogResolver#resolveEntity(String,String) inside this plugin at
ExtensibleCatalogResolver#resolveEntity(String?,String?): InputSource

Here it has been tried to force close all open InputStream's returned
and setByteStream(null). As maybe the API spec allows this to happen,
forcing the caller to open and manage their own InputStream.

Here it has been tried to collect all open InputStream's returned leaving
them open for the caller, collected into a static ConcurrentLinkedQueue.
Then at the exit point of the XJC plugin somewhere around the end of
AbstractXjcGeneratorWorkAction#doExecute(Options) call a static method
to enumerate and force close them. Did not fix problem.

Other options to try...

Build a ClassLoader the XJC main gets to use and monitor everything,
then cleanup after it. Like the ConcurrentLinkedQueue idea above
but with a more global view, not just the XML catalog usage.

Copy the JAR to a $TMPDIR location (outside of gradle $buildDir and
have URLClassLoader reference that. Security headache? The JARs end
up littered around not deleted.

These assume XJC is the cause and that use of ClassLoader has visiblity.

Link to commit IT 066478f

@dlmiles
Copy link
Author

dlmiles commented Mar 25, 2023

Link to commit to fix 95625b8

Ugly but effective :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant