Using LiveSite's Spring Framework?

em4444

Hello-
I'm entirely new to interwoven - just in the conceptual stages of a project that will be using it.
We had originally planned to use the spring framework and spring MVC until we learned that LiveSite serves your entire controller and view layers.
Now I see in the LiveSite Documentation that it uses spring framework behind-the-scenes, so we are reconsidering.
Is there any way to leverage the existing spring framework in LiveSite?

My specific use case would be -
when specifying content XML for a component, I see that you can make a callout to a method in a java class which dynamically returns the XML. Is there any way to call a method in a spring-managed bean here?

Thanks

Stokes

Great question. I don't think there's anything built in to do this, but it shouldn't be hard with a wrapper layer. The LiveSite framework creates a POJO (with no-arg constructor) and call the method, which has to have a certain signature.

But if that POJO is something generic that can get to your Spring ApplicationContext, I can imagine something like this:
  <Data>
    <External>
      <Parameters>
        <Datum Exposed="false" ID="SpringBeanName" Name="SpringBeanName" Type="String">MyBean</Datum>
        <Datum Exposed="false" ID="SpringBeanMethod" Name="SpringBeanMethod" Type="String">myMethod</Datum>
      </Parameters>
      <Object Scope="local">com.em4444.LiveSiteSpringAdapter</Object>
      <Method>handleRequest</Method>
    </External>
  </Data>

...where your LiveSiteSpringAdapter does this:
  public org.dom4j.Document handleRequest(com.interwoven.livesite.runtime.RequestContext context) {
    // get or create the spring application context
    ApplicationContext springContext = ...;
    // use the component parameters to determine which bean and method to call
    String beanName = context.getParameterString("SpringBeanName");
    String beanMethod = context.getParameterString("SpringBeanMethod");
    Object bean = springContext.getBean(beanName);
    try {
      // call the method
      ...
    }
    catch (Exception e) {
      // log/handle errors
      ...
    }
  }


That's kind of from-the-hip, but the point is that with an adapter like this you wouldn't need to tie in to the spring configuration used by livesite behind the scenes, you could have your own independent configuration file that you create a Spring context from.

The thing you'd be sharing, and it would be difficult not to share, is the Spring dependencies in the classpath. If you can live with whatever version of Spring that LiveSite already comes with--I'm not sure which version that is--and rely on those classes to already be in the classpath, then your life will be much easier.

One more thing, unrelated to the above approach, is that I know there are some cases where customers are encouraged to add their own Spring configuration in the livesite_customer tree somewhere. I've never done it and don't recall the use case for that, but I'm pretty sure it exists in the docs somewhere.

Stokes.