Useful filtered classloader for embedded tests; no sys resources leaking.
Add filtered classloader.
Why are these changes needed to SWCL? The stream returned is already Closeable and we don't need to return a filtered impl (by contract)...
Afais, if a stream is already closed -- as it should be, in any decent IO code,
it should be removed from openedStreams -- otherwise a 2nd call to close can happen,
which might not be ok, depending on the actual close impl.
If the Closeable doesn't support double-close without error, it's broken by contract:
" If the stream is already closed then invoking this method has no effect."
You're also leaking resource.
e.g. I close the stream manually, hence expecting it's a done-deal, but then profiler says it's not ;-)
I didn't see it, I'm just thinking out-loud and in theory. :-)
This commit represents a well-tested, simple filtered CL implementation which is likely to be useful in concert with SWCL.
A concern I have is that this is well out-of-scope for the SW project. What does this mean in terms of greater/easier configuration for the resources that get filtered in the CL? What about a switch to go to modular, or child-first delegation? This opens the doors to us providing ClassLoader implementations (in the API, no less) that are beyond what the SW project is intended to supply.
A more natural solution to me seems to have a slim CL thing build atop/delegate to/use the SWCL for loading of classes in a SW archive, and handle all other elements like the delegation model and filtering etc on its own. So what's preventing us from using something like JBCL or jboss-modules in Arquillian/Weld to wrap up the intentionally-simple SWCL?
Yeah, perhaps what we need it a new SW sub-project, which could handle diff classloading rules/notions;
e.g. as you mentioned, JBCL, Modules, OSGI, ...
Or this might be an over-kill, as you already have super-fast envs which use this CL systems,
hence we would just be re-inventing the wheel.
Where my FCL is a simple and good-enough solution to a real problem I just stumbled upon.
Embedded testing w/o such system CL filtering can hide actual CL problems,
making it pretty useless, unless you then also test the same stuff in real env.
Luckily this is the case with Weld
But we still use Embedded for quick&dirty tests, and knowing that the CL works as it should, is crucial.
e.g. that we don't slip in some bean class by mistake, etc
Ales, I'd like to close this PR as out-of-scope for ShrinkWrap. Any issues with my doing that, or would you like to open another project elsewhere to handle the types of CL work you suggest here?