Quantcast

Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Sebastien ARBOGAST
Hi everyone,

In a desperate attempt to make the existing Grails-BlazeDS plugin (1.0) work with Grails 1.3.4, and although I'm working in parallel on a rewriting of this plugin (which could take some time, see my previous message on this list), I did the following:
- Downloaded my test application there: http://sebastien-arbogast.com/wp-content/uploads/2010/05/todolist2.zip
- Downloaded Flex frontend for my test application there: http://sebastien-arbogast.com/wp-content/uploads/2010/05/todolist-web.zip
- Ran grails run-war on the test application
- Imported Flex frontend into Flash Builder 4
- Re-ran Data connectivity wizard to re-import echoService and todolistService
==> Result: everything works perfectly with test application in Grails 1.2.2

Then I did the following:
- Upgraded my test application to Grails 1.3.4
- Updated Flash Server settings in Flash Builder so that it looks for services-config.xml at the right place
- Re-ran data connectivity wizard
==> BOOM! Does not work anymore. echoService and todolistService cannot be seen anymore in Flash Builder

So obviously something has changed between 1.2.x and 1.3.x (the result is the same with all versions from 1.3.0).
But I don't know what and I don't know how to debug it.
Tomas Lin suggested that it could be linked to GRAILS-6521, so I added grails.spring.disable.aspectj.autoweaving=true to my config but it didn't change anything.

Anyone, help?

Best regards,
Sébastien Arbogast

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Sebastien ARBOGAST
As a follow-up on this issue, I've noticed that I had 2 different version of Spring BlazeDS library in my plugin, 1.0.3 and 1.5.0-CI638, so I removed 1.5.0, hoping that the problem came from a version conflict, but the problem is still there with just 1.0.3.
Then I tried to upgrade spring-flex by replacing 1.0.3 with 1.5.0-M1 but now when I try to start my application, I get the following exception:

java.lang.ClassNotFoundException: org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy

So I'm guessing spring-flex-1.5.0-M1 is not compatible with spring-security-2.0.4. Damn it!
I'll try to ask the question on SpringSource forums to see if someone can confirm compatibility issues.
In the meantime, if someone else has ideas, they are more than welcome.

Sébastien Arbogast



2010/8/22 Sebastien ARBOGAST <[hidden email]>
Hi everyone,

In a desperate attempt to make the existing Grails-BlazeDS plugin (1.0) work with Grails 1.3.4, and although I'm working in parallel on a rewriting of this plugin (which could take some time, see my previous message on this list), I did the following:
- Downloaded my test application there: http://sebastien-arbogast.com/wp-content/uploads/2010/05/todolist2.zip
- Downloaded Flex frontend for my test application there: http://sebastien-arbogast.com/wp-content/uploads/2010/05/todolist-web.zip
- Ran grails run-war on the test application
- Imported Flex frontend into Flash Builder 4
- Re-ran Data connectivity wizard to re-import echoService and todolistService
==> Result: everything works perfectly with test application in Grails 1.2.2

Then I did the following:
- Upgraded my test application to Grails 1.3.4
- Updated Flash Server settings in Flash Builder so that it looks for services-config.xml at the right place
- Re-ran data connectivity wizard
==> BOOM! Does not work anymore. echoService and todolistService cannot be seen anymore in Flash Builder

So obviously something has changed between 1.2.x and 1.3.x (the result is the same with all versions from 1.3.0).
But I don't know what and I don't know how to debug it.
Tomas Lin suggested that it could be linked to GRAILS-6521, so I added grails.spring.disable.aspectj.autoweaving=true to my config but it didn't change anything.

Anyone, help?

Best regards,
Sébastien Arbogast


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Oliver Wahlen
I have found a workaround to get the blazeds plugin to work with grails 1.3.x.
The problem seems to be that service classes written in groovy are not accepted by the spring-blazeds implementation.
It is however possible to expose a java class.

To demonstrate the workaround I have written the following simple grails service in grails-app/services/com/bts/DateService.groovy:
package com.bts
class DateService {
    static transactional = true
    String getDate() {
        Date date = new Date()
        return date.toString()
    }
}


Now I added a handler in src/java/com/bts/DateServiceHandler.java:
package com.bts;
import org.codehaus.groovy.grails.web.context.ServletContextHolder;
import org.springframework.flex.remoting.RemotingDestination;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;

@RemotingDestination
public class DateServiceHandler {
    public String getDate() {
        return getDateService().getDate();
    }

    private DateService getDateService() {
        WebApplicationContext ctx =
        WebApplicationContextUtils.getWebApplicationContext(ServletContextHolder.getServletContext());
        return (DateService) ctx.getBean("dateService");
    }
}


And finally in grails-app/conf/spring/resources.groovy:
beans = {
    dateServiceHandler(com.bts.DateServiceHandler) {}
}


If the grails application has the blazeds plugin installed the dateServiceHandler is visible to FlashBuilder and can be called from flex.

Note that it is not possible to let Spring inject the reference to the dateService from resources.groovy.
In this case FlashBuilder complains about properties beeing implemented that should not be implemented. Therefore I used the manual property injection of the dateService.

Note that it is also not possible to write the service in Groovy (i.e. in src/groovy/com/bts/DateServiceHandler.groovy) and then add this one in resources.groovy.
In this case the service is simply not shown in FlashBuilder.

It seems to me that the spring-blazeds framework has some issues interpreting Groovy services.
Maybe someone from the Spring team could check this...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

burtbeckwith
Cool stuff.

I've been working on the Flex plugin and along the way looking at the BlazeDS plugin, I'm not sure yet why the services aren't visible but I worked around this problem by explicitly looking for annotated services and registering them as remoting destinations using the same process as Spring-Flex.

I'm still working out a couple of other issues so it's not available yet but will be soon.

Burt

>
> I have found a workaround to get the blazeds plugin to work with grails
> 1.3.x.
> The problem seems to be that service classes written in groovy are not
> accepted by the spring-blazeds implementation.
> It is however possible to expose a java class.
>
> To demonstrate the workaround I have written the following simple grails
> service in grails-app/services/com/bts/DateService.groovy:
> package com.bts
> class DateService {
>     static transactional = true
>     String getDate() {
>         Date date = new Date()
>         return date.toString()
>     }
> }
>
> Now I added a handler in src/java/com/bts/DateServiceHandler.java:
> package com.bts;
> import org.codehaus.groovy.grails.web.context.ServletContextHolder;
> import org.springframework.flex.remoting.RemotingDestination;
> import org.springframework.web.context.WebApplicationContext;
> import org.springframework.web.context.support.WebApplicationContextUtils;
>
> @RemotingDestination
> public class DateServiceHandler {
>     public String getDate() {
>         return getDateService().getDate();
>     }
>
>     private DateService getDateService() {
>         WebApplicationContext ctx =
>        
> WebApplicationContextUtils.getWebApplicationContext(ServletContextHolder.getServletContext());
>         return (DateService) ctx.getBean("dateService");
>     }
> }
>
> And finally in grails-app/conf/spring/resources.groovy:
> beans = {
>     dateServiceHandler(com.bts.DateServiceHandler) {}
> }
>
>
> If the grails application has the blazeds plugin installed the
> dateServiceHandler is visible to FlashBuilder and can be called from flex.
>
> Note that it is not possible to let Spring inject the reference to the
> dateService from resources.groovy.
> In this case FlashBuilder complains about properties beeing implemented that
> should not be implemented. Therefore I used the manual property injection of
> the dateService.
>
> Note that it is also not possible to write the service in Groovy (i.e. in
> src/groovy/com/bts/DateServiceHandler.groovy) and then add this one in
> resources.groovy.
> In this case the service is simply not shown in FlashBuilder.
>
> It seems to me that the spring-blazeds framework has some issues
> interpreting Groovy services.
> Maybe someone from the Spring team could check this...
>
>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Oliver Wahlen
This sounds much more elegant compared to my solution.
Just to make sure I understand correctly what you are doing:
Similar to Spring Flex your approach is based on BlazedDS (Adobe).
However you bypass Spring's BlazeDS implementation.
Instead you itereate over the service artefacts and register them with BlazeDS as remoting destinations?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

burtbeckwith
There is currently a lot of overlap between the Flex and BlazeDS plugins since the Flex plugin uses BlazeDS but also supports Flex features like compiling mxml files, etc. So the current Flex plugin has been stripped way down and it depends on BlazeDS. This way you can use just BlazeDS or Flex+BlazeDS.

We're also looking at getting Grails applications to work more smoothly with Flash Builder so you can use 'grails run-app' instead of having to deploy a war file.

The BlazeDS plugin uses Spring Flex (it was based on 1.0 but is now based on 1.5) but since the services aren't visible I looked at the code that finds annotated classes and used the same approach in the BlazeDS plugin. But otherwise it uses Spring Flex to do most of the configuration.

You can still add destinations to remoting-config.xml and messaging-config.xml or use the <flex:remoting-destination> and <flex:message-destination> tags (or more likely the Spring bean DSL equivalents in resources.groovy) but as long as your exposed services are Grails services you can get by with just an annotation.

Burt

>
> This sounds much more elegant compared to my solution.
> Just to make sure I understand correctly what you are doing:
> Similar to Spring Flex your approach is based on BlazedDS (Adobe).
> However you bypass Spring's BlazeDS implementation.
> Instead you itereate over the service artefacts and register them with
> BlazeDS as remoting destinations?

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Sebastien ARBOGAST
That's also what I tried to do with the new version of the BlazeDS plugin, because annotations are not the "usual" way to deal with that sort of things. But I had issues with security at some point.
By the way, Burt, I think we can test a first version of your plugin without thinking about security yet. But it would be really awesome if the final version integrated smoothly with the new Spring Security plugins, don't you think?

Sébastien Arbogast



2010/9/27 Burt Beckwith <[hidden email]>
There is currently a lot of overlap between the Flex and BlazeDS plugins since the Flex plugin uses BlazeDS but also supports Flex features like compiling mxml files, etc. So the current Flex plugin has been stripped way down and it depends on BlazeDS. This way you can use just BlazeDS or Flex+BlazeDS.

We're also looking at getting Grails applications to work more smoothly with Flash Builder so you can use 'grails run-app' instead of having to deploy a war file.

The BlazeDS plugin uses Spring Flex (it was based on 1.0 but is now based on 1.5) but since the services aren't visible I looked at the code that finds annotated classes and used the same approach in the BlazeDS plugin. But otherwise it uses Spring Flex to do most of the configuration.

You can still add destinations to remoting-config.xml and messaging-config.xml or use the <flex:remoting-destination> and <flex:message-destination> tags (or more likely the Spring bean DSL equivalents in resources.groovy) but as long as your exposed services are Grails services you can get by with just an annotation.

Burt

>
> This sounds much more elegant compared to my solution.
> Just to make sure I understand correctly what you are doing:
> Similar to Spring Flex your approach is based on BlazedDS (Adobe).
> However you bypass Spring's BlazeDS implementation.
> Instead you itereate over the service artefacts and register them with
> BlazeDS as remoting destinations?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

burtbeckwith
I have security working. The spring-security-acl plugin adds support for annotated methods, and I've tested that it works with the BlazeDS plugin.

Burt

> That's also what I tried to do with the new version of the BlazeDS plugin,
> because annotations are not the "usual" way to deal with that sort of
> things. But I had issues with security at some point.
> By the way, Burt, I think we can test a first version of your plugin without
> thinking about security yet. But it would be really awesome if the final
> version integrated smoothly with the new Spring Security plugins, don't you
> think?
>
> Sébastien Arbogast
>
>
>
> 2010/9/27 Burt Beckwith <[hidden email]>
>
> > There is currently a lot of overlap between the Flex and BlazeDS plugins
> > since the Flex plugin uses BlazeDS but also supports Flex features like
> > compiling mxml files, etc. So the current Flex plugin has been stripped way
> > down and it depends on BlazeDS. This way you can use just BlazeDS or
> > Flex+BlazeDS.
> >
> > We're also looking at getting Grails applications to work more smoothly
> > with Flash Builder so you can use 'grails run-app' instead of having to
> > deploy a war file.
> >
> > The BlazeDS plugin uses Spring Flex (it was based on 1.0 but is now based
> > on 1.5) but since the services aren't visible I looked at the code that
> > finds annotated classes and used the same approach in the BlazeDS plugin.
> > But otherwise it uses Spring Flex to do most of the configuration.
> >
> > You can still add destinations to remoting-config.xml and
> > messaging-config.xml or use the <flex:remoting-destination> and
> > <flex:message-destination> tags (or more likely the Spring bean DSL
> > equivalents in resources.groovy) but as long as your exposed services are
> > Grails services you can get by with just an annotation.
> >
> > Burt
> >
> > >
> > > This sounds much more elegant compared to my solution.
> > > Just to make sure I understand correctly what you are doing:
> > > Similar to Spring Flex your approach is based on BlazedDS (Adobe).
> > > However you bypass Spring's BlazeDS implementation.
> > > Instead you itereate over the service artefacts and register them with
> > > BlazeDS as remoting destinations?
> >
>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Sebastien ARBOGAST
That's simply awesome. After so many months of tinkering and frustration, it looks like Grails will finally have proper Flex integration.

Sébastien Arbogast



2010/9/27 Burt Beckwith <[hidden email]>
I have security working. The spring-security-acl plugin adds support for annotated methods, and I've tested that it works with the BlazeDS plugin.

Burt

> That's also what I tried to do with the new version of the BlazeDS plugin,
> because annotations are not the "usual" way to deal with that sort of
> things. But I had issues with security at some point.
> By the way, Burt, I think we can test a first version of your plugin without
> thinking about security yet. But it would be really awesome if the final
> version integrated smoothly with the new Spring Security plugins, don't you
> think?
>
> Sébastien Arbogast
>
>
>
> 2010/9/27 Burt Beckwith <[hidden email]>
>
> > There is currently a lot of overlap between the Flex and BlazeDS plugins
> > since the Flex plugin uses BlazeDS but also supports Flex features like
> > compiling mxml files, etc. So the current Flex plugin has been stripped way
> > down and it depends on BlazeDS. This way you can use just BlazeDS or
> > Flex+BlazeDS.
> >
> > We're also looking at getting Grails applications to work more smoothly
> > with Flash Builder so you can use 'grails run-app' instead of having to
> > deploy a war file.
> >
> > The BlazeDS plugin uses Spring Flex (it was based on 1.0 but is now based
> > on 1.5) but since the services aren't visible I looked at the code that
> > finds annotated classes and used the same approach in the BlazeDS plugin.
> > But otherwise it uses Spring Flex to do most of the configuration.
> >
> > You can still add destinations to remoting-config.xml and
> > messaging-config.xml or use the <flex:remoting-destination> and
> > <flex:message-destination> tags (or more likely the Spring bean DSL
> > equivalents in resources.groovy) but as long as your exposed services are
> > Grails services you can get by with just an annotation.
> >
> > Burt
> >
> > >
> > > This sounds much more elegant compared to my solution.
> > > Just to make sure I understand correctly what you are doing:
> > > Similar to Spring Flex your approach is based on BlazedDS (Adobe).
> > > However you bypass Spring's BlazeDS implementation.
> > > Instead you itereate over the service artefacts and register them with
> > > BlazeDS as remoting destinations?
> >
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Oliver Wahlen
In reply to this post by burtbeckwith
This is really great news!
When do you think you will come up with a first version of this new flex plugin?
I would really be interested to test it and look at the code.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

burtbeckwith
It's pretty close, but SpringOne/2GX might get in the way.

Burt

>
> This is really great news!
> When do you think you will come up with a first version of this new flex
> plugin?
> I would really be interested to test it and look at the code.
>
>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

John David von Oertzen
Hi,

how is it going, i am really interested in a working solution.

Thanks,
John David
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Oliver Wahlen
In reply to this post by burtbeckwith
Hello Burt,
I just had a look at
https://github.com/grails-plugins/grails-flex/blob/master/application.properties.

Do you want to base your flex plugin on the blazeds plugin in the end?
I thought that you plugin would be more a replacement for blazeds, no?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Sebastien ARBOGAST
What I suggested Burt was to have more of a modular approach and split Flex support into 3 different plugins to allow people to use just what they need:
- blazeds will contain all the remoting logic and you will be able to use that without the flex plugin if you want to have all your flex code in a separate project, which I think is much better practice for any project of a certain size, and is crucial to allow good Flash Builder support
- the flex plugin will allow you to have your flex sources inside of your Grails project, compiled with the Flex compiler servlet
- and then there might be a flex-scaffolding plugin

That's why the flex plugin now depends on the blazeds one

Sébastien Arbogast



2010/11/7 Oliver Wahlen <[hidden email]>

Hello Burt,
I just had a look at
https://github.com/grails-plugins/grails-flex/blob/master/application.properties
https://github.com/grails-plugins/grails-flex/blob/master/application.properties
.

Do you want to base your flex plugin on the blazeds plugin in the end?
I thought that you plugin would be more a replacement for blazeds, no?

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-BlazeDS-plugin-1-0-and-Grails-1-3-x-tp2334411p3030780.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Oliver Wahlen
Hello Sébastien,
yes, this really sounds like a modular and good idea.
Will there be a new version of the blazeds plugin that works under grails 1.3.x and that supports "grails run-app"?
My understanding is that Burt has created something like this (see above).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

burtbeckwith
Yes, it's been updated for Grails 1.3 (but still works in 1.2), Spring Flex 1.5, Spring Security 3, etc. run-app is supported in Flash Builder by using a new integrate-with-flash-builder script that adds Flash Builder support to a Grails application and allows the app to work in both environments.

The scaffolding plugin (GFS, http://grails.org/plugin/flex-scaffold) has also been updated to use the other two plugins. All three are still being tested but should hopefully be able to be released as soon as this week (probably a little longer for GFS though).

So as Sebastian said, you'll have the flexibility to choose which plugins to install - just BlazeDS, or BlazeDS + Flex, or BlazeDS + Flex + Scaffolding.

Burt

>
> Hello Sébastien,
> yes, this really sounds like a modular and good idea.
> Will there be a new version of the blazeds plugin that works under grails
> 1.3.x and that supports "grails run-app"?
> My understanding is that Burt has created something like this (see above).
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-BlazeDS plugin 1.0 and Grails 1.3.x

Oliver Wahlen
Hello Burt,
so you have not only fixed the blazeds problems but also cleaned up the whole grails flex plugin family :-)
I am really looking forward to test the new plugins.

keep up the good work!
Oliver
Loading...