Closed GoogleCodeExporter closed 8 years ago
I've haven't worked with any OSGi based environment, so forgive my ignorance if
I'm not asking the right questions...
1. Would calling Thread.setContextClassLoader(...) be sufficient if BeanIO
honored the setting throughout?
2. If no for #1, which objects would require instantiation by the overridden
classloader? A bean object read from a stream seems obvious, but what about
type handlers, record reader/writer implementations, and the StreamFactory
itself?
3. At what "level" should a classloader be allowed to be overridden? I'm
guessing per stream would be overkill, but is allowing it to overridden only
once for the entire framework too little (i.e.
StreamFactory.setClassloader(...))?
Going with #1 or keeping it as simple as StreamFactory.setClassloader() could
be fairly straightforward, but other implementations may be more difficult...
Thanks,
Kevin
Original comment by kevin.s...@gmail.com
on 8 Nov 2011 at 10:28
As of release 1.2.2, BeanIO will honor a thread's context class loader in all
cases. Also note that all class loading is done when a mapping file is loaded.
A more direct interface for setting a class loader per StreamFactory will be
provided in a future release.
Original comment by kevin.s...@gmail.com
on 8 Jan 2012 at 9:31
Release 2.0 will allow users to specify a ClassLoader instance when creating a
StreamFactory. The ClassLoader will be used to resolve all classpath resources
and user defined bean classes.
Original comment by kevin.s...@gmail.com
on 8 Feb 2012 at 4:00
Original comment by kevin.s...@gmail.com
on 8 Feb 2012 at 4:00
Fixed as of release 2.0.0.M1.
Original comment by kevin.s...@gmail.com
on 3 Mar 2012 at 10:39
Original issue reported on code.google.com by
Leipol...@gmail.com
on 8 Nov 2011 at 3:25