grails in sailfin converged sip servlet container
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
grails in sailfin converged sip servlet container
by Gregory W. Bond
::
Rate this Message:
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 |
|
|
Re: grails in sailfin converged sip servlet container
by Burt Beckwith
::
Rate this Message:
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 |
|
|
Re: grails in sailfin converged sip servlet container
by Gregory W. Bond
::
Rate this Message:
thanks burt - i had a chance to try out your simple suggestion today
and it worked! i'm so pleased to be able to use grails with sailfin now On Tue, Jun 24, 2008 at 11:23 PM, Burt Beckwith <burt@...> wrote: > 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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: grails in sailfin converged sip servlet container
by glaforge
::
Rate this Message:
It's worth a little tutorial :-)
Or perhaps even a Grails plugin? This is a very interesting experiment. On Fri, Jun 27, 2008 at 4:16 AM, Gregory Bond <bond.gregory@...> wrote: > thanks burt - i had a chance to try out your simple suggestion today > and it worked! i'm so pleased to be able to use grails with sailfin > now > > On Tue, Jun 24, 2008 at 11:23 PM, Burt Beckwith <burt@...> wrote: >> 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 >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Guillaume Laforge Groovy Project Manager G2One, Inc. Vice-President Technology http://www.g2one.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: grails in sailfin converged sip servlet container
by Gregory W. Bond
::
Rate this Message:
i've put together a detailed tutorial and posted it here:
http://echarts.org/Blog/E4SS-Grails-and-SailFin.html special thanks to Burt for helping me out greg On Fri, Jun 27, 2008 at 3:29 AM, Guillaume Laforge <glaforge@...> wrote: > It's worth a little tutorial :-) > Or perhaps even a Grails plugin? > This is a very interesting experiment. > > On Fri, Jun 27, 2008 at 4:16 AM, Gregory Bond <bond.gregory@...> wrote: >> thanks burt - i had a chance to try out your simple suggestion today >> and it worked! i'm so pleased to be able to use grails with sailfin >> now >> >> On Tue, Jun 24, 2008 at 11:23 PM, Burt Beckwith <burt@...> wrote: >>> 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 >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > > -- > Guillaume Laforge > Groovy Project Manager > G2One, Inc. Vice-President Technology > http://www.g2one.com > > --------------------------------------------------------------------- > 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 |
|
|
Re: grails in sailfin converged sip servlet container
by glaforge
::
Rate this Message:
Nice!
Thanks for posting back! On Mon, Jul 14, 2008 at 6:08 PM, Gregory Bond <bond.gregory@...> wrote: > i've put together a detailed tutorial and posted it here: > http://echarts.org/Blog/E4SS-Grails-and-SailFin.html > > special thanks to Burt for helping me out > > greg > > On Fri, Jun 27, 2008 at 3:29 AM, Guillaume Laforge <glaforge@...> wrote: >> It's worth a little tutorial :-) >> Or perhaps even a Grails plugin? >> This is a very interesting experiment. >> >> On Fri, Jun 27, 2008 at 4:16 AM, Gregory Bond <bond.gregory@...> wrote: >>> thanks burt - i had a chance to try out your simple suggestion today >>> and it worked! i'm so pleased to be able to use grails with sailfin >>> now >>> >>> On Tue, Jun 24, 2008 at 11:23 PM, Burt Beckwith <burt@...> wrote: >>>> 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 >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >> >> >> >> -- >> Guillaume Laforge >> Groovy Project Manager >> G2One, Inc. Vice-President Technology >> http://www.g2one.com >> >> --------------------------------------------------------------------- >> 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 > > > -- Guillaume Laforge Groovy Project Manager G2One, Inc. Vice-President Technology http://www.g2one.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free embeddable forum powered by Nabble | Forum Help |
