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

[Steven D. <ste...@gm...>]

Rod,

Did you have time to look into yet? I can create a JIRA issue if it's
ok for you.

Steven


On Sun, 02 Jan 2005 08:23:27 +0000, Rod Johnson <ro...@in...> wrote:
> 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
> ____________________________________________________
> 
> -------------------------------------------------------
> 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
> 
>