Re: grails in sailfin converged sip servlet container

> Services don't (or at least shouldn't) have anything to do with web requests.
> All you need is a hook into retrieving Spring beans. The docs suggest
> registering the "consumer" as a Spring bean to enable dependency injection
> but this is contrived and often impossible if Spring cannot manage the
> object's lifecycle, so you could instead pull the Spring beans using a helper
> class like this one:
>
> import org.codehaus.groovy.grails.web.context.ServletContextHolder;
> import org.springframework.context.ApplicationContext;
> import org.springframework.web.context.support.WebApplicationContextUtils;
>
> public class SpringUtils {
>
>   /**
>    * Get a spring bean by name.
>    */
>   @SuppressWarnings("unchecked")
>   public static <T> T getBean(final String name) {
>      ApplicationContext ctx =
> (ApplicationContext)ServletContextHolder.getServletContext().getAttribute(
>            GrailsApplicationAttributes.APPLICATION_CONTEXT);
>      return (T)ctx.getBean(name);
>   }
> }
>
> The generics bit is a minor hack that saves you from having to cast the bean
> to its type, so instead of having
>
>   MyService service = (MyService)SpringUtils.getBean("myService");
>
> you can just have
>
>   MyService service = SpringUtils.getBean("myService");
>
> This is entirely optional but pretty convenient.
>
> Burt
>
> On Tuesday 24 June 2008 11:05:12 pm Gregory Bond wrote:
>> i'm trying to do something different with Grails that will be great
>> for Grails and the SIP servlet community if it works out - but a few
>> words describing the problem context before i get to my problem:
>>
>> SIP is a protocol for voice-over IP and SailFin is an open source SIP
>> servlet container (https://sailfin.dev.java.net/) sponsored by Sun and
>> Ericsson - the SailFin container effectively combines a SIP servlet
>> container from Ericsson with Sun's open source GlassFish 2.2 HTTP
>> servlet container - SailFin is called a 'converged' container because
>> a deployed application (e.g. a war file) can contain *both* SIP
>> servlets and HTTP servlets
>>
>> because SailFin includes GlassFish, i've been able to run Grails 1.0.3
>> apps in the SailFin container with no problem but now i'm trying to
>> "attain convergence" by packaging a SIP servlet app and a Grails app
>> together in the same war file - what i want to do is have a doXXX()
>> method invocation in the *SIP servlet* access my Grails app's domain
>> model (either via a Grails service method or directly)
>>
>> what i'm trying to do appears to be a special case of Java (the SIP
>> servlet doXXX method) accessing Grails (a Grails service method) but
>> in this case the Grails app hasn't been invoked in response to an HTTP
>> request - instead, the SIP servlet is being invoked in response to a
>> SIP message - because there is no HTTP request involved in this
>> scenario it doesn't appear possible to use the Spring bean approach
>> described in section 8 of the Grails manual  ("the service layer"
>> http://grails.org/doc/1.0.x/guide/8.%20The%20Service%20Layer.html)
>>
>> so is there some way a service instance can be created outside of the
>> context of handling an HTTP request? if not, are there any other ways
>> that the Java code in the SIP servlet could access a Grails service
>> method or the domain model classes packaged in the same war file?
>>
>> i'm thinking that there must be a solution better than the
>> "stand-alone" GORM approach (http://grails.org/GORM+-+StandAlone+Gorm)
>> because the SIP servlet and the Grails app are packaged in the same
>> war file and therefore have access to each other's compiled code
>>
>> any help here would be greatly appreciated - this won't just help me -
>> solving this problem would be a big contribution to the burgeoning
>> telecom-over-IP community since combining Grails with SIP servlets
>> would enable developers to put together converged telecom applications
>> really quickly
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>