Re: [Springframework-developer] Dynamic language support in Spring

[Rod J. <ro...@in...>]

Steven

Have you checked out the Groovy support (and other scripting language support) in the sandbox?

I will take a closer look at the rest of your points next week (on holiday now), but just wanted to 
point you in that direction now...

I think some control over class loading is probably worthwhile, although it probably shouldn't be 
encouraged for application developers (rather than add-on frameworks) to manipulate class loaders.

Rgds
Rod

Steven Devijver wrote:
> Hi,
> 
> Right now Spring doesn't offer support for dynamic languages. This
> leads to at least one critical issue and a few minor others one that
> can be resolved.
> 
> The issues:
> 
> + De-serialization of dynamic classes (critical):
> 
> Say you have a setup with a client and server talking to each other.
> The client and server both share the same set of .groovy files
> containing a number of classes. These classes implement
> java.io.Serializable, have a serial version UID yet cannot be
> de-serialized. Http invoker uses java.io.ObjectInputStream which
> implements java de-serialization. ObjectInputStream uses it's own
> scheme to detect which class loader should be used to create a new
> instance from the serialized format and doesn't allow you to specify
> your own class loader. This means ObjectInputStream cannot resolve and
> http invoker cannot transport dynamic classes.
> 
> + Instantiation of dynamic classes in the bean factory (nice-to-have):
> 
> I've looked in the Spring sand box and I'm not sure if there's an
> implementation in there for creating dynamic classes from the bean
> factory. Currently you would be able to load for example Groovy
> classes using the bean factory if you would set a Groovy class loader
> as the context class loader before creating the Spring bean factory.
> This approach is not very usable as you would only be able to
> overwrite the context class loader in a simple java application while
> it would probably be (a lot) harder to do this in say a servlet
> container.
> 
> + Temporarily changing the context class loader (nice-to-have):
> 
> For some method calls you need to temporarily change the context class
> loader in order to let for example Hibernate load dynamic classes.
> Hibernate uses the context class loader to load classes. Temporarily
> changing the context class loader is required when you want to use
> dynamic classes as persistent objects. Restoring the original context
> class loader when the method exits - either on a normal exit or by
> throwing an exception - is required to not cause class loading
> problems elsewhere in the application (server). If we are talking
> about dao's we could easily do this using AOP. If we're talking about
> LocalSessionFactoryBean we need to do the context class loader switch
> only for the method afterPropertiesSet. We could also do this using
> AOP but that's a bit clumsy. Also, using AOP everyone would need to
> write the method interceptor that does the context class loader switch
> themselves.
> 
> The proposed solution:
> 
> Before I discuss the proposed solution I would like to mention that
> Groovy and Janino both offer a class loader while Jython and BeanShell
> (apparently) don't. I say apparently because I don't know Jython and
> BeanShell that well.
> 
> The first part of the proposed solution is to create factory beans for
> Groovy, Janino, ... that load scripts either from the file system or
> from a string. These factory bean would have as object type
> java.lang.ClassLoader and are there to declaratively load Groovy or
> Janino classes. Both the Groovy and Janino take a parent class loader.
> My experiments using Jetty show that the context class loader
> retrieved in the scope of the context loader listener can be safely
> used as a parent class loader while handing requests.
> 
> The second part of the proposed solution addresses the
> de-serialization issue. Subclassing ObjectInputStream allows you to
> overwrite the resolveClass method. This would allow you to use a
> custom class loader. If Spring would offer such a subclass it would be
> peanuts to subclass SimpleHttpInvokerRequestExecutor, add a
> classloader property and overwrite the readRemoteInvocationResult
> method.
> 
> The third part of the proposed solution addresses the instantiation of
> dynamic classes by the bean factory. By adding a classloader attribute
> to the xml bean definition one would be able to refer to the factories
> discussed above to specify which classloader Spring should use to load
> the defined class. I'm not sure how this should be implemented in
> Spring. In DefaultXmlBeanDefinitionParser the context class loader is
> passed to the bean definition so this looks like the hook. The custom
> class loader should be retrieved from the factory, I'm not sure how
> and where this should be implemented.
> 
> The fourth part of the proposed solution addresses the temporary
> switch of context class loaders. It would be nice if Spring would
> offer a method interceptor that implements this. It would also be nice
> if a classloader property could be added to a subclass of
> LocalSessionFactoryBean so that the context class loader could be
> switched in the afterPropertiesSet method.
> 
> If we can agree on the importance of dynamic language support in
> Spring I would be happy to implements parts 1, 2 and 4.
> 
> Steven
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

-- 

____________________________________________________
Rod Johnson
CEO, Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________