You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: