maybe we document the shortcoming for 1.0, have that clustering boolean and throw an exception if its true and people try to use groovy files?
Chris Turner wrote:
It's nothing to do with copying the byte code. What happens is that ServerA in the cluster serializes, say, a Groovy page from the session. Into the serialized stream it writes the name of the class (e.g. com.xyz.pages.SomePage) then serializes all the attributes. The serialized stream has no knowledge that the class was created by Groovy. At the other end, ServerB reads the stream and first reads the class name (com.xyz.pages.SomePage) it then uses the standard War class loader from the app server to try to load this class. Obviously the class isn't there because its the Wicket class resolver that deals with loading Groovy classes. You then get a ClassNotFoundException. Thinking about it, the same would happen when using session recovery on a single server as well. There is nothing you can do to get round this as session serialization/deserialization is entirely under control of the app server - Wicket has nothing to do with it.
The solution is pretty complex in terms of overriding the whole classloader and serialization mechanism so that whenever a groovy object is serialized we actually write a proxy class first. Then when the proxy class is deserialized the standard deserialization and class loading deals with the proxy and then the proxy takes over and uses the groovy class resolver to deserialize the groovy class. It's messy, complex and uses some pretty obscure features of the Java API.
I'm happy to do some experiments with this if you would like because I have done something similar before. However, I think it's a big enough piece of work that it would be unlikely to be something we could guarantee to get fully working before 1.0. The whole Java dynamic proxy support is a big learning curve on its own.
regards, Chris
Juergen Donnerstag wrote:
I'm not sure I understood everything in detail. What I haven't
understood so far:. with a cluster you deploy classes / jar on each
container and a classloader loads the classes required. You have to
make sure you deploy the same files on each node. The classes byte
codes don't get copied from one container to another. Isn't groovy
simply another means of class loading? Assuming users either have a
shared storage (db, etc. etc.) or accept that the groovy files are
out of sync while being replicated, why do we need to copy the groovy's byte code from container to another? Why doesn't the existing
groovy classloader mechanism do?
regards Juergen
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
