RSF Discussions Forum

Hello,

I'm back working with RSF again, this time on a personal project. I feel like a kid in a candy shop

Being a personal project, this is Sakai-less, although it sports a global spring context like Sakai, and a ComponentManager to abstract the Spring components similar to Sakai. I would like to run my webapps in RSF, and have spring components from my global spring context injectable transparently into my RSF components.

Skimming through the SakaiRSF work, it appears a "RSACStringBridge" (?) component has been extended, and maps it to a string "sakai-Context".

Can anyone clarify what this is doing, or if I'm in left field on my lead? Any examples that can provide that functionality would be greatly appreciated.

Cheers,

Branden

Hi - the purpose of these "bridge" classes are to enable Java immutable classes to appear in Spring contexts as proxies. Since it is impossible to "fake out" an immutable class in Java, the only way to create a Spring bean which may dynamically take on a variable role of one of these classes is via a one-line interface (OLI! http://rsf.fluidproject.org/wiki/Wiki.jsp?page=OLI) class which returns the type (in this case, String).

The purpose of the "sakai-Context" bean is to allow a point of resolution and injection of some String representing the "Sakai Context" (in old-style Sakai, a site string reference), without causing pollution by dependence on the Sakai APIs. RSACStringBridge is a generalised helper which allows bridging such a proxy from application to request context - since in general the value of this String will be different in each active request.

I hope this helps you somewhat, although hopefully it also conveys that this is not really anything that you would need to bother with yourself, especially in a project outside of Sakai, where you would be blissfully unbothered by the intrusion of undesirable dependencies.

Look out for "Fluid Kettle" - coming soon, an all-Javascript serverside embodiment of the RSF concepts delivered as a tiny minimal Java Servlet... an XML-less, Java-less dawn

- together with a super-lightweight all-Javascript IoC system.... "there are greater madmen even than I".

Thanks for your reply, Antranig. I see what the RSACStringBridge is for now, and proves that my theory on what it might be for was in fact way out in left field.

To my original question, then: How can I inject spring beans from my global context transparently into my RSF webapp's spring context? For example, in my RSF webapp:

Code:

 <bean class="my.web.producers.WelcomeProducer">
     <property name='myService' ref='my.api.MyService' />
 </bean id>

Where 'my.api.MyService' belongs to a spring context external from my RSF context.

Thanks again,

Branden

PS: Fluid Kettle sounds interesting, although giving JAX the boot sounds terrifying. I'll wait to see a demo

That's a matter of arranging the geometry of your application contexts. In Sakai this is what is done by the Sakai context listener - it registers the global Sakai Spring context as a parent of the webapp's context.

You can see one instance of the glorious code in action here:

https://source.sakaiproject.org/svn/component/branches/sakai_2-2-x/component-api/component/src/java/org/sakaiproject/component/impl/ContextLoader.java

The base class is documented here:

http://static.springsource.org/spring/docs/2.0.7/api/org/springframework/web/context/ContextLoader.html

You don't need to achieve this effect in this way - any other method of calling setParent on the new webapp's context will be effective -

http://static.springsource.org/spring/docs/2.0.7/api/org/springframework/context/ConfigurableApplicationContext.html#setParent(org.springframework.context.ApplicationContext)

Note that the method warns though that the parent should generally only be set during the constructor for an application context.

Where is your parent global context actually coming from?