Hi all,
A while back we had a thread discussing some issues with mod proxy cloning that appear to only manifest on osx, jdk 1.7. This issue basically makes it impossible to run GeoServer locally.
The problem manifests itself as a ClassNotFoundException resulting from calls to cloneMap and cloneCollection when the deepCopy argument is set to true. From what I can tell the problem is exactly the one described here:
https://jira.codehaus.org/browse/JRUBY-5142
The class loader being used by ObjectOutputStream sometimes ends up being the parent of the main application class loader, meaning it doesn’t have any of the geotools/geoserver/etc… .classes defined in it. So we end up getting a ClassNotFoundException whenever the map or collection contains an object not defined in the jre runtime class library.
So, how about taking the same approach as the JRuby folks and use a custom ObjectOutputStream that ensures we always use the app class loader?
-Justin
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive
On Thu, Jul 3, 2014 at 5:33 AM, Justin Deoliveira <jdeolive@anonymised.com
wrote:
Hi all,
A while back we had a thread discussing some issues with mod proxy cloning
that appear to only manifest on osx, jdk 1.7. This issue basically makes it
impossible to run GeoServer locally.
The problem manifests itself as a ClassNotFoundException resulting from
calls to cloneMap and cloneCollection when the deepCopy argument is set to
true. From what I can tell the problem is exactly the one described here:
https://jira.codehaus.org/browse/JRUBY-5142
The class loader being used by ObjectOutputStream sometimes ends up being
the parent of the main application class loader, meaning it doesn't have
any of the geotools/geoserver/etc.. .classes defined in it. So we end up
getting a ClassNotFoundException whenever the map or collection contains an
object not defined in the jre runtime class library.
So, how about taking the same approach as the JRuby folks and use a custom
ObjectOutputStream that ensures we always use the app class loader?
Yup, good idea
Cheers
Andrea
--
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
Cool. Pull request.
https://github.com/geoserver/geoserver/pull/634
···
On Thu, Jul 3, 2014 at 12:09 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive
On Thu, Jul 3, 2014 at 5:33 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
A while back we had a thread discussing some issues with mod proxy cloning that appear to only manifest on osx, jdk 1.7. This issue basically makes it impossible to run GeoServer locally.
The problem manifests itself as a ClassNotFoundException resulting from calls to cloneMap and cloneCollection when the deepCopy argument is set to true. From what I can tell the problem is exactly the one described here:
https://jira.codehaus.org/browse/JRUBY-5142
The class loader being used by ObjectOutputStream sometimes ends up being the parent of the main application class loader, meaning it doesn’t have any of the geotools/geoserver/etc… .classes defined in it. So we end up getting a ClassNotFoundException whenever the map or collection contains an object not defined in the jre runtime class library.
So, how about taking the same approach as the JRuby folks and use a custom ObjectOutputStream that ensures we always use the app class loader?
Yup, good idea
Cheers
Andrea
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it