BlazeDS and Grails/Hibernate

[Nick Collins-2]

Tomás Lin posted the following to his blog about a year ago regarding
his lessons learned using Grails as the back-end to a Flex
application:

========================================================

Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.

The Grails-Flex plugin. What a wonderful idea. I got giggles playing
with Marcel’s hello world example.

But then came trying to get it to work with non-toy data. Hibernate
breaks when trying to handle many-to-one relationships, something
about the connection being closed. Then you had to create new
Actionscript objects for each of your domain classes, replicating a
lot of the work. Then it was slow when you had a lot of objects, a
lesson we learned from the monster called Cairngorm.

Our solution, keep it light. We used simple REST services with Grail’s
content negotiation capabilities; and we didn’t run into those nasty
hibernate session exceptions anymore. We kept everything in a native
XML format and used e4x to bind this data into our components; and it
was beautiful, elegant and powerful. Both Grails/Groovy and
Flex/ActionScript have incredible XML support; exploit this.

========================================================

I was wondering if anything had been done to correct the Hibernate
issue he mentions, as I would much rather be able to use BlazeDS with
remoting and messaging than have to use REST with Flex.

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

    http://xircles.codehaus.org/manage_email

[Paul Bowler]

Nick,

We've recently launched an enterprise application using Flex and Grails and I can agree with a lot of what Tomas posted.

Fortunately we intentionally kept the server API small to minimise the Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from breaking. If I were to design and implement this again I'd probably go for a REST architecture too.

As far as I'm aware the issues have still not been respolved although I heard SpringSource and Adobe were working together to improve product inter-working. Can anyone confirm this?

Paul.

---

From: Nick Collins <[hidden email]>
To: [hidden email]
Sent: Fri, 11 December, 2009 17:06:38
Subject: [grails-user] BlazeDS and Grails/Hibernate

Tomás Lin posted the following to his blog about a year ago regarding
his lessons learned using Grails as the back-end to a Flex
application:

========================================================

Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.

The Grails-Flex plugin. What a wonderful idea. I got giggles playing
with Marcel’s hello world example.

But then came trying to get it to work with non-toy data. Hibernate
breaks when trying to handle many-to-one relationships, something
about the connection being closed. Then you had to create new
Actionscript objects for each of your domain classes, replicating a
lot of the work. Then it was slow when you had a lot of objects, a
lesson we learned from the monster called Cairngorm.

Our solution, keep it light. We used simple REST services with Grail’s
content negotiation capabilities; and we didn’t run into those nasty
hibernate session exceptions anymore. We kept everything in a native
XML format and used e4x to bind this data into our components; and it
was beautiful, elegant and powerful. Both Grails/Groovy and
Flex/ActionScript have incredible XML support; exploit this.

========================================================

I was wondering if anything had been done to correct the Hibernate
issue he mentions, as I would much rather be able to use BlazeDS with
remoting and messaging than have to use REST with Flex.

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

    http://xircles.codehaus.org/manage_email

[tomas lin]

Warning: this is a long ranting post.

The latest flex plugin in head has a RC of the Spring Flex integration.

I tried getting this to work by my London Groovy and Grails Exchange
presentation, but ran into a couple of issues. The talk will be posted
here in the next few days if you want to see how the Flex 4 tooling
works with SOAP services:
http://skillsmatter.com/podcast/ajax-ria/building-killer-rias-with-flex-and-grails

First, the Flex 4 API changes one of the methods used to get the
servlet, so this means that the Flex 3 plugin is incompatible with the
new version. This was easy to fix, but it meant that I had to go back
Marcel's 0.2 codebase. This also means Spring-Flex is not compatible
with Flex 4, due out early next year.

The more problematic issue here is that Flex 4 provides a lot of
really nice introspection tools but the BlazeDS/Groovy combination
does not support it yet. Adobe built a bunch of really nice bindings
in Flash Builder 4 for web services. This allows you to drag and drop
data types, create master-detail screens and basically have on-demand
scaffolding from your BlazeDS / SOAP / REST services. It's nice.

However, because the RDS has been written in a way that it only
introspects Java classes, this means that we need to add an additional
layer of tools to allow  our Groovy controllers and services to be
able to use this new tooling feature. To me, this is a deal breaker.

I used XFire (SOAP) for my demo and was able to get most of the new
Flex 4 features working without a hitch. XFire solves the circular
dependency and lazy loading issue elegantly by providing a
xmlTransients static method that you put in your domain classes. It
was easy and you can pull it off now with Grails.

To me, BlazeDS is almost written so that you would be stuck with Adobe
technologies and would eventually update to LCDS once your user base
becomes bigger. The pub/sub channelset really dies when you are
hitting large number of connections ( Yakov Fain claims this to be
about 800 ). Adobe also has a hibernate adaptor for LCDS, but won't
release this. So you're stuck trying to map your
lazyinitializationexceptions with tools like Gilead and dpHibernate,
adding much more pain to your configuration and deployment.

Add to that the fact that Spring-Flex does not handle java
instrospection properly, it means a long hard road for you to get
productive.

None of the other Flex-only server side tools seem to offer viable
solutions. GraniteDS is still hard to use and won't support the new
UI-level tooling. It doesn't provide caches properly and won't run
properly with Flash 10.

I think it depends on your use case. AMF channelsets use less
bandwidth and provide nice features like publisher and subscribe
channels. REST and SOAP are easy to set up within Grails and allow you
to use the new Flex 4 tools right away without waiting. They are also
compatible with non-flex APIs. If you are a bank with infinite
resources, build something in Java, bind it with BlazeDS or LCDS, and
you're done. That seems to be the target audience of that technology.

As a programmer, I think that right now, if I want to stay productive
and be able to use all the new Flash Builder model binding stuff right
away, I would choose SOAP services.

However, I find the new tooling for Flex fascinating, and would
probably end up spending a lot of time trying to get the BlazeDS
introspector and Flex modelling working with groovy only to find
myself at the wrong end of a DMCA takedown notice.

Hope that helps,

Tomas

On Fri, Dec 11, 2009 at 5:26 PM, Paul Bowler <[hidden email]> wrote:

> Nick,
>
> We've recently launched an enterprise application using Flex and Grails and
> I can agree with a lot of what Tomas posted.
>
> Fortunately we intentionally kept the server API small to minimise the
> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
> breaking. If I were to design and implement this again I'd probably go for a
> REST architecture too.
>
> As far as I'm aware the issues have still not been respolved although I
> heard SpringSource and Adobe were working together to improve product
> inter-working. Can anyone confirm this?
>
> Paul.
>
> ________________________________
> From: Nick Collins <[hidden email]>
> To: [hidden email]
> Sent: Fri, 11 December, 2009 17:06:38
> Subject: [grails-user] BlazeDS and Grails/Hibernate
>
> Tomás Lin posted the following to his blog about a year ago regarding
> his lessons learned using Grails as the back-end to a Flex
> application:
>
> ========================================================
>
> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>
> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
> with Marcel’s hello world example.
>
> But then came trying to get it to work with non-toy data. Hibernate
> breaks when trying to handle many-to-one relationships, something
> about the connection being closed. Then you had to create new
> Actionscript objects for each of your domain classes, replicating a
> lot of the work. Then it was slow when you had a lot of objects, a
> lesson we learned from the monster called Cairngorm.
>
> Our solution, keep it light. We used simple REST services with Grail’s
> content negotiation capabilities; and we didn’t run into those nasty
> hibernate session exceptions anymore. We kept everything in a native
> XML format and used e4x to bind this data into our components; and it
> was beautiful, elegant and powerful. Both Grails/Groovy and
> Flex/ActionScript have incredible XML support; exploit this.
>
> ========================================================
>
> I was wondering if anything had been done to correct the Hibernate
> issue he mentions, as I would much rather be able to use BlazeDS with
> remoting and messaging than have to use REST with Flex.
>
> ---------------------------------------------------------------------
> 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

[tomas lin]

Note : Graeme did mention better Flex integration as one of the goals
for next year.

On Fri, Dec 11, 2009 at 6:26 PM, Tomas Lin <[hidden email]> wrote:

> Warning: this is a long ranting post.
>
> The latest flex plugin in head has a RC of the Spring Flex integration.
>
> I tried getting this to work by my London Groovy and Grails Exchange
> presentation, but ran into a couple of issues. The talk will be posted
> here in the next few days if you want to see how the Flex 4 tooling
> works with SOAP services:
> http://skillsmatter.com/podcast/ajax-ria/building-killer-rias-with-flex-and-grails
>
> First, the Flex 4 API changes one of the methods used to get the
> servlet, so this means that the Flex 3 plugin is incompatible with the
> new version. This was easy to fix, but it meant that I had to go back
> Marcel's 0.2 codebase. This also means Spring-Flex is not compatible
> with Flex 4, due out early next year.
>
> The more problematic issue here is that Flex 4 provides a lot of
> really nice introspection tools but the BlazeDS/Groovy combination
> does not support it yet. Adobe built a bunch of really nice bindings
> in Flash Builder 4 for web services. This allows you to drag and drop
> data types, create master-detail screens and basically have on-demand
> scaffolding from your BlazeDS / SOAP / REST services. It's nice.
>
> However, because the RDS has been written in a way that it only
> introspects Java classes, this means that we need to add an additional
> layer of tools to allow  our Groovy controllers and services to be
> able to use this new tooling feature. To me, this is a deal breaker.
>
> I used XFire (SOAP) for my demo and was able to get most of the new
> Flex 4 features working without a hitch. XFire solves the circular
> dependency and lazy loading issue elegantly by providing a
> xmlTransients static method that you put in your domain classes. It
> was easy and you can pull it off now with Grails.
>
> To me, BlazeDS is almost written so that you would be stuck with Adobe
> technologies and would eventually update to LCDS once your user base
> becomes bigger. The pub/sub channelset really dies when you are
> hitting large number of connections ( Yakov Fain claims this to be
> about 800 ). Adobe also has a hibernate adaptor for LCDS, but won't
> release this. So you're stuck trying to map your
> lazyinitializationexceptions with tools like Gilead and dpHibernate,
> adding much more pain to your configuration and deployment.
>
> Add to that the fact that Spring-Flex does not handle java
> instrospection properly, it means a long hard road for you to get
> productive.
>
> None of the other Flex-only server side tools seem to offer viable
> solutions. GraniteDS is still hard to use and won't support the new
> UI-level tooling. It doesn't provide caches properly and won't run
> properly with Flash 10.
>
> I think it depends on your use case. AMF channelsets use less
> bandwidth and provide nice features like publisher and subscribe
> channels. REST and SOAP are easy to set up within Grails and allow you
> to use the new Flex 4 tools right away without waiting. They are also
> compatible with non-flex APIs. If you are a bank with infinite
> resources, build something in Java, bind it with BlazeDS or LCDS, and
> you're done. That seems to be the target audience of that technology.
>
> As a programmer, I think that right now, if I want to stay productive
> and be able to use all the new Flash Builder model binding stuff right
> away, I would choose SOAP services.
>
> However, I find the new tooling for Flex fascinating, and would
> probably end up spending a lot of time trying to get the BlazeDS
> introspector and Flex modelling working with groovy only to find
> myself at the wrong end of a DMCA takedown notice.
>
> Hope that helps,
>
> Tomas
>
> On Fri, Dec 11, 2009 at 5:26 PM, Paul Bowler <[hidden email]> wrote:
>> Nick,
>>
>> We've recently launched an enterprise application using Flex and Grails and
>> I can agree with a lot of what Tomas posted.
>>
>> Fortunately we intentionally kept the server API small to minimise the
>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>> breaking. If I were to design and implement this again I'd probably go for a
>> REST architecture too.
>>
>> As far as I'm aware the issues have still not been respolved although I
>> heard SpringSource and Adobe were working together to improve product
>> inter-working. Can anyone confirm this?
>>
>> Paul.
>>
>> ________________________________
>> From: Nick Collins <[hidden email]>
>> To: [hidden email]
>> Sent: Fri, 11 December, 2009 17:06:38
>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>
>> Tomás Lin posted the following to his blog about a year ago regarding
>> his lessons learned using Grails as the back-end to a Flex
>> application:
>>
>> ========================================================
>>
>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>
>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>> with Marcel’s hello world example.
>>
>> But then came trying to get it to work with non-toy data. Hibernate
>> breaks when trying to handle many-to-one relationships, something
>> about the connection being closed. Then you had to create new
>> Actionscript objects for each of your domain classes, replicating a
>> lot of the work. Then it was slow when you had a lot of objects, a
>> lesson we learned from the monster called Cairngorm.
>>
>> Our solution, keep it light. We used simple REST services with Grail’s
>> content negotiation capabilities; and we didn’t run into those nasty
>> hibernate session exceptions anymore. We kept everything in a native
>> XML format and used e4x to bind this data into our components; and it
>> was beautiful, elegant and powerful. Both Grails/Groovy and
>> Flex/ActionScript have incredible XML support; exploit this.
>>
>> ========================================================
>>
>> I was wondering if anything had been done to correct the Hibernate
>> issue he mentions, as I would much rather be able to use BlazeDS with
>> remoting and messaging than have to use REST with Flex.
>>
>> ---------------------------------------------------------------------
>> 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

[Nick Collins-2]

Part of what I don't like about using SOAP is that it is so verbose
and I like the idea of being able to pass real serialized objects
across the wire and let BlazeDS handle converting those to their Java
equivalents.

REST "support" in Flex still seems like to much of a "hack" to me, so
I kind of shudder at the thought of using it, though I know some have
used it quite successfully.

On Fri, Dec 11, 2009 at 12:26 PM, Tomas Lin <[hidden email]> wrote:

> Warning: this is a long ranting post.
>
> The latest flex plugin in head has a RC of the Spring Flex integration.
>
> I tried getting this to work by my London Groovy and Grails Exchange
> presentation, but ran into a couple of issues. The talk will be posted
> here in the next few days if you want to see how the Flex 4 tooling
> works with SOAP services:
> http://skillsmatter.com/podcast/ajax-ria/building-killer-rias-with-flex-and-grails
>
> First, the Flex 4 API changes one of the methods used to get the
> servlet, so this means that the Flex 3 plugin is incompatible with the
> new version. This was easy to fix, but it meant that I had to go back
> Marcel's 0.2 codebase. This also means Spring-Flex is not compatible
> with Flex 4, due out early next year.
>
> The more problematic issue here is that Flex 4 provides a lot of
> really nice introspection tools but the BlazeDS/Groovy combination
> does not support it yet. Adobe built a bunch of really nice bindings
> in Flash Builder 4 for web services. This allows you to drag and drop
> data types, create master-detail screens and basically have on-demand
> scaffolding from your BlazeDS / SOAP / REST services. It's nice.
>
> However, because the RDS has been written in a way that it only
> introspects Java classes, this means that we need to add an additional
> layer of tools to allow  our Groovy controllers and services to be
> able to use this new tooling feature. To me, this is a deal breaker.
>
> I used XFire (SOAP) for my demo and was able to get most of the new
> Flex 4 features working without a hitch. XFire solves the circular
> dependency and lazy loading issue elegantly by providing a
> xmlTransients static method that you put in your domain classes. It
> was easy and you can pull it off now with Grails.
>
> To me, BlazeDS is almost written so that you would be stuck with Adobe
> technologies and would eventually update to LCDS once your user base
> becomes bigger. The pub/sub channelset really dies when you are
> hitting large number of connections ( Yakov Fain claims this to be
> about 800 ). Adobe also has a hibernate adaptor for LCDS, but won't
> release this. So you're stuck trying to map your
> lazyinitializationexceptions with tools like Gilead and dpHibernate,
> adding much more pain to your configuration and deployment.
>
> Add to that the fact that Spring-Flex does not handle java
> instrospection properly, it means a long hard road for you to get
> productive.
>
> None of the other Flex-only server side tools seem to offer viable
> solutions. GraniteDS is still hard to use and won't support the new
> UI-level tooling. It doesn't provide caches properly and won't run
> properly with Flash 10.
>
> I think it depends on your use case. AMF channelsets use less
> bandwidth and provide nice features like publisher and subscribe
> channels. REST and SOAP are easy to set up within Grails and allow you
> to use the new Flex 4 tools right away without waiting. They are also
> compatible with non-flex APIs. If you are a bank with infinite
> resources, build something in Java, bind it with BlazeDS or LCDS, and
> you're done. That seems to be the target audience of that technology.
>
> As a programmer, I think that right now, if I want to stay productive
> and be able to use all the new Flash Builder model binding stuff right
> away, I would choose SOAP services.
>
> However, I find the new tooling for Flex fascinating, and would
> probably end up spending a lot of time trying to get the BlazeDS
> introspector and Flex modelling working with groovy only to find
> myself at the wrong end of a DMCA takedown notice.
>
> Hope that helps,
>
> Tomas
>
> On Fri, Dec 11, 2009 at 5:26 PM, Paul Bowler <[hidden email]> wrote:
>> Nick,
>>
>> We've recently launched an enterprise application using Flex and Grails and
>> I can agree with a lot of what Tomas posted.
>>
>> Fortunately we intentionally kept the server API small to minimise the
>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>> breaking. If I were to design and implement this again I'd probably go for a
>> REST architecture too.
>>
>> As far as I'm aware the issues have still not been respolved although I
>> heard SpringSource and Adobe were working together to improve product
>> inter-working. Can anyone confirm this?
>>
>> Paul.
>>
>> ________________________________
>> From: Nick Collins <[hidden email]>
>> To: [hidden email]
>> Sent: Fri, 11 December, 2009 17:06:38
>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>
>> Tomás Lin posted the following to his blog about a year ago regarding
>> his lessons learned using Grails as the back-end to a Flex
>> application:
>>
>> ========================================================
>>
>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>
>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>> with Marcel’s hello world example.
>>
>> But then came trying to get it to work with non-toy data. Hibernate
>> breaks when trying to handle many-to-one relationships, something
>> about the connection being closed. Then you had to create new
>> Actionscript objects for each of your domain classes, replicating a
>> lot of the work. Then it was slow when you had a lot of objects, a
>> lesson we learned from the monster called Cairngorm.
>>
>> Our solution, keep it light. We used simple REST services with Grail’s
>> content negotiation capabilities; and we didn’t run into those nasty
>> hibernate session exceptions anymore. We kept everything in a native
>> XML format and used e4x to bind this data into our components; and it
>> was beautiful, elegant and powerful. Both Grails/Groovy and
>> Flex/ActionScript have incredible XML support; exploit this.
>>
>> ========================================================
>>
>> I was wondering if anything had been done to correct the Hibernate
>> issue he mentions, as I would much rather be able to use BlazeDS with
>> remoting and messaging than have to use REST with Flex.
>>
>> ---------------------------------------------------------------------
>> 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

[Nick Collins-2]

FYI, I happen to know that Adobe would be very interested in assisting
someone in developing a Grails plugin to work with LCDS, and I would
definitely be up for it, making it so you could also use a limited
portion of it with Blaze DS if you chose, if I knew that the Grails
side of it would behave properly.

My impression was that this hibernate issue was one that existed even
without Blaze DS, so I was hoping someone might have taken charge of
fixing it.

On Fri, Dec 11, 2009 at 12:26 PM, Tomas Lin <[hidden email]> wrote:

> Warning: this is a long ranting post.
>
> The latest flex plugin in head has a RC of the Spring Flex integration.
>
> I tried getting this to work by my London Groovy and Grails Exchange
> presentation, but ran into a couple of issues. The talk will be posted
> here in the next few days if you want to see how the Flex 4 tooling
> works with SOAP services:
> http://skillsmatter.com/podcast/ajax-ria/building-killer-rias-with-flex-and-grails
>
> First, the Flex 4 API changes one of the methods used to get the
> servlet, so this means that the Flex 3 plugin is incompatible with the
> new version. This was easy to fix, but it meant that I had to go back
> Marcel's 0.2 codebase. This also means Spring-Flex is not compatible
> with Flex 4, due out early next year.
>
> The more problematic issue here is that Flex 4 provides a lot of
> really nice introspection tools but the BlazeDS/Groovy combination
> does not support it yet. Adobe built a bunch of really nice bindings
> in Flash Builder 4 for web services. This allows you to drag and drop
> data types, create master-detail screens and basically have on-demand
> scaffolding from your BlazeDS / SOAP / REST services. It's nice.
>
> However, because the RDS has been written in a way that it only
> introspects Java classes, this means that we need to add an additional
> layer of tools to allow  our Groovy controllers and services to be
> able to use this new tooling feature. To me, this is a deal breaker.
>
> I used XFire (SOAP) for my demo and was able to get most of the new
> Flex 4 features working without a hitch. XFire solves the circular
> dependency and lazy loading issue elegantly by providing a
> xmlTransients static method that you put in your domain classes. It
> was easy and you can pull it off now with Grails.
>
> To me, BlazeDS is almost written so that you would be stuck with Adobe
> technologies and would eventually update to LCDS once your user base
> becomes bigger. The pub/sub channelset really dies when you are
> hitting large number of connections ( Yakov Fain claims this to be
> about 800 ). Adobe also has a hibernate adaptor for LCDS, but won't
> release this. So you're stuck trying to map your
> lazyinitializationexceptions with tools like Gilead and dpHibernate,
> adding much more pain to your configuration and deployment.
>
> Add to that the fact that Spring-Flex does not handle java
> instrospection properly, it means a long hard road for you to get
> productive.
>
> None of the other Flex-only server side tools seem to offer viable
> solutions. GraniteDS is still hard to use and won't support the new
> UI-level tooling. It doesn't provide caches properly and won't run
> properly with Flash 10.
>
> I think it depends on your use case. AMF channelsets use less
> bandwidth and provide nice features like publisher and subscribe
> channels. REST and SOAP are easy to set up within Grails and allow you
> to use the new Flex 4 tools right away without waiting. They are also
> compatible with non-flex APIs. If you are a bank with infinite
> resources, build something in Java, bind it with BlazeDS or LCDS, and
> you're done. That seems to be the target audience of that technology.
>
> As a programmer, I think that right now, if I want to stay productive
> and be able to use all the new Flash Builder model binding stuff right
> away, I would choose SOAP services.
>
> However, I find the new tooling for Flex fascinating, and would
> probably end up spending a lot of time trying to get the BlazeDS
> introspector and Flex modelling working with groovy only to find
> myself at the wrong end of a DMCA takedown notice.
>
> Hope that helps,
>
> Tomas
>
> On Fri, Dec 11, 2009 at 5:26 PM, Paul Bowler <[hidden email]> wrote:
>> Nick,
>>
>> We've recently launched an enterprise application using Flex and Grails and
>> I can agree with a lot of what Tomas posted.
>>
>> Fortunately we intentionally kept the server API small to minimise the
>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>> breaking. If I were to design and implement this again I'd probably go for a
>> REST architecture too.
>>
>> As far as I'm aware the issues have still not been respolved although I
>> heard SpringSource and Adobe were working together to improve product
>> inter-working. Can anyone confirm this?
>>
>> Paul.
>>
>> ________________________________
>> From: Nick Collins <[hidden email]>
>> To: [hidden email]
>> Sent: Fri, 11 December, 2009 17:06:38
>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>
>> Tomás Lin posted the following to his blog about a year ago regarding
>> his lessons learned using Grails as the back-end to a Flex
>> application:
>>
>> ========================================================
>>
>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>
>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>> with Marcel’s hello world example.
>>
>> But then came trying to get it to work with non-toy data. Hibernate
>> breaks when trying to handle many-to-one relationships, something
>> about the connection being closed. Then you had to create new
>> Actionscript objects for each of your domain classes, replicating a
>> lot of the work. Then it was slow when you had a lot of objects, a
>> lesson we learned from the monster called Cairngorm.
>>
>> Our solution, keep it light. We used simple REST services with Grail’s
>> content negotiation capabilities; and we didn’t run into those nasty
>> hibernate session exceptions anymore. We kept everything in a native
>> XML format and used e4x to bind this data into our components; and it
>> was beautiful, elegant and powerful. Both Grails/Groovy and
>> Flex/ActionScript have incredible XML support; exploit this.
>>
>> ========================================================
>>
>> I was wondering if anything had been done to correct the Hibernate
>> issue he mentions, as I would much rather be able to use BlazeDS with
>> remoting and messaging than have to use REST with Flex.
>>
>> ---------------------------------------------------------------------
>> 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

[Adam Evans]

I was looking into evaluating BlazeDS with grails a couple of weeks ago but with time constraints it didn't end up feasible.

One of the key reasons we was looking into this was the offline data synchronisation functionality available with flex / air apps. Reading between the lines (this is what I wanted to do a proof of concept on) is that you could develop a flex application and deploy it as a air app so it runs as a standard application. Adobe air has it's own SQLLite database and using BlazeDS you can bind data from a remote server, take the app offline, and then when the app comes back online you can synchronize data with the remote server and BlazeDS also handles conflicts.

I think if you had a flex application on the desktop backed by grails and able to work remotley without and synchronise data when you have a internet connection would be pretty bloody amazing... and from what i've read their shouldn't be a lot of work involved.

I think to do this you do need something such as BlaseDS rather than just a webservice?

[tomas lin]

Let me summarize my view,

If you want to use Flex 3 for Grails - use REST and e4x. This way you
can just use content negotiation in your controllers.

If you want to use Flex 4 and want use Grails now with the new tooling
support for services and scaffolding in Flash Builder 4 - use SOAP.
The tool creates wrappers around your XML objects so you get real
ActionScript value objects with all the validation you need. There is
no real advantage of using BlazeDS and Grails at this point, since you
actually lose this ability. This might change soon, but are you
willing to wait for this?

In Flex 3, your binding is done by hand. In Flex 4, the tool
autogenerates the services. If you are a masochist and still want to
do it by hand, rest is pain free.

On Fri, Dec 11, 2009 at 6:45 PM, Nick Collins <[hidden email]> wrote:

> Part of what I don't like about using SOAP is that it is so verbose
> and I like the idea of being able to pass real serialized objects
> across the wire and let BlazeDS handle converting those to their Java
> equivalents.
>
> REST "support" in Flex still seems like to much of a "hack" to me, so
> I kind of shudder at the thought of using it, though I know some have
> used it quite successfully.
>
> On Fri, Dec 11, 2009 at 12:26 PM, Tomas Lin <[hidden email]> wrote:
>> Warning: this is a long ranting post.
>>
>> The latest flex plugin in head has a RC of the Spring Flex integration.
>>
>> I tried getting this to work by my London Groovy and Grails Exchange
>> presentation, but ran into a couple of issues. The talk will be posted
>> here in the next few days if you want to see how the Flex 4 tooling
>> works with SOAP services:
>> http://skillsmatter.com/podcast/ajax-ria/building-killer-rias-with-flex-and-grails
>>
>> First, the Flex 4 API changes one of the methods used to get the
>> servlet, so this means that the Flex 3 plugin is incompatible with the
>> new version. This was easy to fix, but it meant that I had to go back
>> Marcel's 0.2 codebase. This also means Spring-Flex is not compatible
>> with Flex 4, due out early next year.
>>
>> The more problematic issue here is that Flex 4 provides a lot of
>> really nice introspection tools but the BlazeDS/Groovy combination
>> does not support it yet. Adobe built a bunch of really nice bindings
>> in Flash Builder 4 for web services. This allows you to drag and drop
>> data types, create master-detail screens and basically have on-demand
>> scaffolding from your BlazeDS / SOAP / REST services. It's nice.
>>
>> However, because the RDS has been written in a way that it only
>> introspects Java classes, this means that we need to add an additional
>> layer of tools to allow  our Groovy controllers and services to be
>> able to use this new tooling feature. To me, this is a deal breaker.
>>
>> I used XFire (SOAP) for my demo and was able to get most of the new
>> Flex 4 features working without a hitch. XFire solves the circular
>> dependency and lazy loading issue elegantly by providing a
>> xmlTransients static method that you put in your domain classes. It
>> was easy and you can pull it off now with Grails.
>>
>> To me, BlazeDS is almost written so that you would be stuck with Adobe
>> technologies and would eventually update to LCDS once your user base
>> becomes bigger. The pub/sub channelset really dies when you are
>> hitting large number of connections ( Yakov Fain claims this to be
>> about 800 ). Adobe also has a hibernate adaptor for LCDS, but won't
>> release this. So you're stuck trying to map your
>> lazyinitializationexceptions with tools like Gilead and dpHibernate,
>> adding much more pain to your configuration and deployment.
>>
>> Add to that the fact that Spring-Flex does not handle java
>> instrospection properly, it means a long hard road for you to get
>> productive.
>>
>> None of the other Flex-only server side tools seem to offer viable
>> solutions. GraniteDS is still hard to use and won't support the new
>> UI-level tooling. It doesn't provide caches properly and won't run
>> properly with Flash 10.
>>
>> I think it depends on your use case. AMF channelsets use less
>> bandwidth and provide nice features like publisher and subscribe
>> channels. REST and SOAP are easy to set up within Grails and allow you
>> to use the new Flex 4 tools right away without waiting. They are also
>> compatible with non-flex APIs. If you are a bank with infinite
>> resources, build something in Java, bind it with BlazeDS or LCDS, and
>> you're done. That seems to be the target audience of that technology.
>>
>> As a programmer, I think that right now, if I want to stay productive
>> and be able to use all the new Flash Builder model binding stuff right
>> away, I would choose SOAP services.
>>
>> However, I find the new tooling for Flex fascinating, and would
>> probably end up spending a lot of time trying to get the BlazeDS
>> introspector and Flex modelling working with groovy only to find
>> myself at the wrong end of a DMCA takedown notice.
>>
>> Hope that helps,
>>
>> Tomas
>>
>> On Fri, Dec 11, 2009 at 5:26 PM, Paul Bowler <[hidden email]> wrote:
>>> Nick,
>>>
>>> We've recently launched an enterprise application using Flex and Grails and
>>> I can agree with a lot of what Tomas posted.
>>>
>>> Fortunately we intentionally kept the server API small to minimise the
>>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>>> breaking. If I were to design and implement this again I'd probably go for a
>>> REST architecture too.
>>>
>>> As far as I'm aware the issues have still not been respolved although I
>>> heard SpringSource and Adobe were working together to improve product
>>> inter-working. Can anyone confirm this?
>>>
>>> Paul.
>>>
>>> ________________________________
>>> From: Nick Collins <[hidden email]>
>>> To: [hidden email]
>>> Sent: Fri, 11 December, 2009 17:06:38
>>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>>
>>> Tomás Lin posted the following to his blog about a year ago regarding
>>> his lessons learned using Grails as the back-end to a Flex
>>> application:
>>>
>>> ========================================================
>>>
>>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>>
>>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>>> with Marcel’s hello world example.
>>>
>>> But then came trying to get it to work with non-toy data. Hibernate
>>> breaks when trying to handle many-to-one relationships, something
>>> about the connection being closed. Then you had to create new
>>> Actionscript objects for each of your domain classes, replicating a
>>> lot of the work. Then it was slow when you had a lot of objects, a
>>> lesson we learned from the monster called Cairngorm.
>>>
>>> Our solution, keep it light. We used simple REST services with Grail’s
>>> content negotiation capabilities; and we didn’t run into those nasty
>>> hibernate session exceptions anymore. We kept everything in a native
>>> XML format and used e4x to bind this data into our components; and it
>>> was beautiful, elegant and powerful. Both Grails/Groovy and
>>> Flex/ActionScript have incredible XML support; exploit this.
>>>
>>> ========================================================
>>>
>>> I was wondering if anything had been done to correct the Hibernate
>>> issue he mentions, as I would much rather be able to use BlazeDS with
>>> remoting and messaging than have to use REST with Flex.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[tomas lin]

There are two tools for this : dpHibernate and Gilead. However, Gilead
doesn't really solve this problem and forces you to do a lot more work
in your domain objects. DpHibernate works theoretically, but you have
to write the right wrapper code.

Again, Flex 4 automatically generates your service connection
ActionScript, gives you a nice drag and drop GUI. My suggestion here
is to try the web service support first since it if it doesn't work,
you can just throw it away. The only reason I suggest SOAP over REST
is that you can pass in a WSDL to the tool and it will create all the
data objects and services, but if you use REST, you have to manually
bind to the service calls. It depends on whether you want the bulk of
the work to be on your front-end guys or your backend guys.

The reason I suggest starting with services is that you can much
easily move from a SOAP approach to a REST approach to a BlazeDS
approach in Grails. But the opposite is not true.

On Fri, Dec 11, 2009 at 6:49 PM, Nick Collins <[hidden email]> wrote:

> FYI, I happen to know that Adobe would be very interested in assisting
> someone in developing a Grails plugin to work with LCDS, and I would
> definitely be up for it, making it so you could also use a limited
> portion of it with Blaze DS if you chose, if I knew that the Grails
> side of it would behave properly.
>
> My impression was that this hibernate issue was one that existed even
> without Blaze DS, so I was hoping someone might have taken charge of
> fixing it.
>
> On Fri, Dec 11, 2009 at 12:26 PM, Tomas Lin <[hidden email]> wrote:
>> Warning: this is a long ranting post.
>>
>> The latest flex plugin in head has a RC of the Spring Flex integration.
>>
>> I tried getting this to work by my London Groovy and Grails Exchange
>> presentation, but ran into a couple of issues. The talk will be posted
>> here in the next few days if you want to see how the Flex 4 tooling
>> works with SOAP services:
>> http://skillsmatter.com/podcast/ajax-ria/building-killer-rias-with-flex-and-grails
>>
>> First, the Flex 4 API changes one of the methods used to get the
>> servlet, so this means that the Flex 3 plugin is incompatible with the
>> new version. This was easy to fix, but it meant that I had to go back
>> Marcel's 0.2 codebase. This also means Spring-Flex is not compatible
>> with Flex 4, due out early next year.
>>
>> The more problematic issue here is that Flex 4 provides a lot of
>> really nice introspection tools but the BlazeDS/Groovy combination
>> does not support it yet. Adobe built a bunch of really nice bindings
>> in Flash Builder 4 for web services. This allows you to drag and drop
>> data types, create master-detail screens and basically have on-demand
>> scaffolding from your BlazeDS / SOAP / REST services. It's nice.
>>
>> However, because the RDS has been written in a way that it only
>> introspects Java classes, this means that we need to add an additional
>> layer of tools to allow  our Groovy controllers and services to be
>> able to use this new tooling feature. To me, this is a deal breaker.
>>
>> I used XFire (SOAP) for my demo and was able to get most of the new
>> Flex 4 features working without a hitch. XFire solves the circular
>> dependency and lazy loading issue elegantly by providing a
>> xmlTransients static method that you put in your domain classes. It
>> was easy and you can pull it off now with Grails.
>>
>> To me, BlazeDS is almost written so that you would be stuck with Adobe
>> technologies and would eventually update to LCDS once your user base
>> becomes bigger. The pub/sub channelset really dies when you are
>> hitting large number of connections ( Yakov Fain claims this to be
>> about 800 ). Adobe also has a hibernate adaptor for LCDS, but won't
>> release this. So you're stuck trying to map your
>> lazyinitializationexceptions with tools like Gilead and dpHibernate,
>> adding much more pain to your configuration and deployment.
>>
>> Add to that the fact that Spring-Flex does not handle java
>> instrospection properly, it means a long hard road for you to get
>> productive.
>>
>> None of the other Flex-only server side tools seem to offer viable
>> solutions. GraniteDS is still hard to use and won't support the new
>> UI-level tooling. It doesn't provide caches properly and won't run
>> properly with Flash 10.
>>
>> I think it depends on your use case. AMF channelsets use less
>> bandwidth and provide nice features like publisher and subscribe
>> channels. REST and SOAP are easy to set up within Grails and allow you
>> to use the new Flex 4 tools right away without waiting. They are also
>> compatible with non-flex APIs. If you are a bank with infinite
>> resources, build something in Java, bind it with BlazeDS or LCDS, and
>> you're done. That seems to be the target audience of that technology.
>>
>> As a programmer, I think that right now, if I want to stay productive
>> and be able to use all the new Flash Builder model binding stuff right
>> away, I would choose SOAP services.
>>
>> However, I find the new tooling for Flex fascinating, and would
>> probably end up spending a lot of time trying to get the BlazeDS
>> introspector and Flex modelling working with groovy only to find
>> myself at the wrong end of a DMCA takedown notice.
>>
>> Hope that helps,
>>
>> Tomas
>>
>> On Fri, Dec 11, 2009 at 5:26 PM, Paul Bowler <[hidden email]> wrote:
>>> Nick,
>>>
>>> We've recently launched an enterprise application using Flex and Grails and
>>> I can agree with a lot of what Tomas posted.
>>>
>>> Fortunately we intentionally kept the server API small to minimise the
>>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>>> breaking. If I were to design and implement this again I'd probably go for a
>>> REST architecture too.
>>>
>>> As far as I'm aware the issues have still not been respolved although I
>>> heard SpringSource and Adobe were working together to improve product
>>> inter-working. Can anyone confirm this?
>>>
>>> Paul.
>>>
>>> ________________________________
>>> From: Nick Collins <[hidden email]>
>>> To: [hidden email]
>>> Sent: Fri, 11 December, 2009 17:06:38
>>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>>
>>> Tomás Lin posted the following to his blog about a year ago regarding
>>> his lessons learned using Grails as the back-end to a Flex
>>> application:
>>>
>>> ========================================================
>>>
>>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>>
>>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>>> with Marcel’s hello world example.
>>>
>>> But then came trying to get it to work with non-toy data. Hibernate
>>> breaks when trying to handle many-to-one relationships, something
>>> about the connection being closed. Then you had to create new
>>> Actionscript objects for each of your domain classes, replicating a
>>> lot of the work. Then it was slow when you had a lot of objects, a
>>> lesson we learned from the monster called Cairngorm.
>>>
>>> Our solution, keep it light. We used simple REST services with Grail’s
>>> content negotiation capabilities; and we didn’t run into those nasty
>>> hibernate session exceptions anymore. We kept everything in a native
>>> XML format and used e4x to bind this data into our components; and it
>>> was beautiful, elegant and powerful. Both Grails/Groovy and
>>> Flex/ActionScript have incredible XML support; exploit this.
>>>
>>> ========================================================
>>>
>>> I was wondering if anything had been done to correct the Hibernate
>>> issue he mentions, as I would much rather be able to use BlazeDS with
>>> remoting and messaging than have to use REST with Flex.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[tomas lin]

Offline DataSync is part of LCDS & LCDS Express. This is not supported
in BlazeDS.

http://www.adobe.com/products/livecycle/dataservices/compare.html

You can bake your own, given that AIR apps can query the network
connection state. But you would have to buy LCDS to do this.

On Fri, Dec 11, 2009 at 7:15 PM, AdamE <[hidden email]> wrote:

>
> I was looking into evaluating BlazeDS with grails a couple of weeks ago but
> with time constraints it didn't end up feasible.
>
> One of the key reasons we was looking into this was the offline data
> synchronisation functionality available with flex / air apps. Reading
> between the lines (this is what I wanted to do a proof of concept on) is
> that you could develop a flex application and deploy it as a air app so it
> runs as a standard application. Adobe air has it's own SQLLite database and
> using BlazeDS you can bind data from a remote server, take the app offline,
> and then when the app comes back online you can synchronize data with the
> remote server and BlazeDS also handles conflicts.
>
> I think if you had a flex application on the desktop backed by grails and
> able to work remotley without and synchronise data when you have a internet
> connection would be pretty bloody amazing... and from what i've read their
> shouldn't be a lot of work involved.
>
> I think to do this you do need something such as BlaseDS rather than just a
> webservice?
> --
> View this message in context: http://old.nabble.com/BlazeDS-and-Grails-Hibernate-tp26748007p26750041.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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Nick Collins-2]

FYI, LCDS Express is no more as of LCDS 3. They have not yet decided
what they are going to do to replace it.

On Fri, Dec 11, 2009 at 1:34 PM, Tomas Lin <[hidden email]> wrote:

> Offline DataSync is part of LCDS & LCDS Express. This is not supported
> in BlazeDS.
>
> http://www.adobe.com/products/livecycle/dataservices/compare.html
>
> You can bake your own, given that AIR apps can query the network
> connection state. But you would have to buy LCDS to do this.
>
> On Fri, Dec 11, 2009 at 7:15 PM, AdamE <[hidden email]> wrote:
>>
>> I was looking into evaluating BlazeDS with grails a couple of weeks ago but
>> with time constraints it didn't end up feasible.
>>
>> One of the key reasons we was looking into this was the offline data
>> synchronisation functionality available with flex / air apps. Reading
>> between the lines (this is what I wanted to do a proof of concept on) is
>> that you could develop a flex application and deploy it as a air app so it
>> runs as a standard application. Adobe air has it's own SQLLite database and
>> using BlazeDS you can bind data from a remote server, take the app offline,
>> and then when the app comes back online you can synchronize data with the
>> remote server and BlazeDS also handles conflicts.
>>
>> I think if you had a flex application on the desktop backed by grails and
>> able to work remotley without and synchronise data when you have a internet
>> connection would be pretty bloody amazing... and from what i've read their
>> shouldn't be a lot of work involved.
>>
>> I think to do this you do need something such as BlaseDS rather than just a
>> webservice?
>> --
>> View this message in context: http://old.nabble.com/BlazeDS-and-Grails-Hibernate-tp26748007p26750041.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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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

[Nick Collins-2]

Also, if you end up going the LCDS route, you're probably going to
want to use the new Adobe Application Modeling technology that allows
you to model your application in a pseudo-UML tool built around their
application modeling language and then Flash Builder/LCDS 3 will use
that to generate the back end service logic all ready for data
managment, offline data sync, etc. as well as using the same IDE
facilities to generate the front end service controller code.

On Fri, Dec 11, 2009 at 1:49 PM, Nick Collins <[hidden email]> wrote:

> FYI, LCDS Express is no more as of LCDS 3. They have not yet decided
> what they are going to do to replace it.
>
> On Fri, Dec 11, 2009 at 1:34 PM, Tomas Lin <[hidden email]> wrote:
>> Offline DataSync is part of LCDS & LCDS Express. This is not supported
>> in BlazeDS.
>>
>> http://www.adobe.com/products/livecycle/dataservices/compare.html
>>
>> You can bake your own, given that AIR apps can query the network
>> connection state. But you would have to buy LCDS to do this.
>>
>> On Fri, Dec 11, 2009 at 7:15 PM, AdamE <[hidden email]> wrote:
>>>
>>> I was looking into evaluating BlazeDS with grails a couple of weeks ago but
>>> with time constraints it didn't end up feasible.
>>>
>>> One of the key reasons we was looking into this was the offline data
>>> synchronisation functionality available with flex / air apps. Reading
>>> between the lines (this is what I wanted to do a proof of concept on) is
>>> that you could develop a flex application and deploy it as a air app so it
>>> runs as a standard application. Adobe air has it's own SQLLite database and
>>> using BlazeDS you can bind data from a remote server, take the app offline,
>>> and then when the app comes back online you can synchronize data with the
>>> remote server and BlazeDS also handles conflicts.
>>>
>>> I think if you had a flex application on the desktop backed by grails and
>>> able to work remotley without and synchronise data when you have a internet
>>> connection would be pretty bloody amazing... and from what i've read their
>>> shouldn't be a lot of work involved.
>>>
>>> I think to do this you do need something such as BlaseDS rather than just a
>>> webservice?
>>> --
>>> View this message in context: http://old.nabble.com/BlazeDS-and-Grails-Hibernate-tp26748007p26750041.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
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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

[Nick Collins-2]

I'm sorry to belabor the point, but could someone please expound on
what the issue is, exactly?

Is this a problem with Hibernate itself, or just it's implementation in Grails?

On Fri, Dec 11, 2009 at 11:26 AM, Paul Bowler <[hidden email]> wrote:

> Nick,
>
> We've recently launched an enterprise application using Flex and Grails and
> I can agree with a lot of what Tomas posted.
>
> Fortunately we intentionally kept the server API small to minimise the
> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
> breaking. If I were to design and implement this again I'd probably go for a
> REST architecture too.
>
> As far as I'm aware the issues have still not been respolved although I
> heard SpringSource and Adobe were working together to improve product
> inter-working. Can anyone confirm this?
>
> Paul.
>
> ________________________________
> From: Nick Collins <[hidden email]>
> To: [hidden email]
> Sent: Fri, 11 December, 2009 17:06:38
> Subject: [grails-user] BlazeDS and Grails/Hibernate
>
> Tomás Lin posted the following to his blog about a year ago regarding
> his lessons learned using Grails as the back-end to a Flex
> application:
>
> ========================================================
>
> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>
> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
> with Marcel’s hello world example.
>
> But then came trying to get it to work with non-toy data. Hibernate
> breaks when trying to handle many-to-one relationships, something
> about the connection being closed. Then you had to create new
> Actionscript objects for each of your domain classes, replicating a
> lot of the work. Then it was slow when you had a lot of objects, a
> lesson we learned from the monster called Cairngorm.
>
> Our solution, keep it light. We used simple REST services with Grail’s
> content negotiation capabilities; and we didn’t run into those nasty
> hibernate session exceptions anymore. We kept everything in a native
> XML format and used e4x to bind this data into our components; and it
> was beautiful, elegant and powerful. Both Grails/Groovy and
> Flex/ActionScript have incredible XML support; exploit this.
>
> ========================================================
>
> I was wondering if anything had been done to correct the Hibernate
> issue he mentions, as I would much rather be able to use BlazeDS with
> remoting and messaging than have to use REST with Flex.
>
> ---------------------------------------------------------------------
> 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

[Graeme Rocher-3]

The issue is with Hibernate itself. Hibernate create proxies for
associations and has special implementations of collections
(PersistentCollection, PersistentSet etc.) to lazy load associations

When you send this over the wire with BlazeDS it can lead to strange
exceptions. You can of course workaround these problems (by using
eager fetching for example), but expect bumps along the way.

Another alternative is to use the DTO plugin as is done with the GWT plugin

Cheers

On Wed, Dec 16, 2009 at 3:56 PM, Nick Collins <[hidden email]> wrote:

> I'm sorry to belabor the point, but could someone please expound on
> what the issue is, exactly?
>
> Is this a problem with Hibernate itself, or just it's implementation in Grails?
>
> On Fri, Dec 11, 2009 at 11:26 AM, Paul Bowler <[hidden email]> wrote:
>> Nick,
>>
>> We've recently launched an enterprise application using Flex and Grails and
>> I can agree with a lot of what Tomas posted.
>>
>> Fortunately we intentionally kept the server API small to minimise the
>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>> breaking. If I were to design and implement this again I'd probably go for a
>> REST architecture too.
>>
>> As far as I'm aware the issues have still not been respolved although I
>> heard SpringSource and Adobe were working together to improve product
>> inter-working. Can anyone confirm this?
>>
>> Paul.
>>
>> ________________________________
>> From: Nick Collins <[hidden email]>
>> To: [hidden email]
>> Sent: Fri, 11 December, 2009 17:06:38
>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>
>> Tomás Lin posted the following to his blog about a year ago regarding
>> his lessons learned using Grails as the back-end to a Flex
>> application:
>>
>> ========================================================
>>
>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>
>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>> with Marcel’s hello world example.
>>
>> But then came trying to get it to work with non-toy data. Hibernate
>> breaks when trying to handle many-to-one relationships, something
>> about the connection being closed. Then you had to create new
>> Actionscript objects for each of your domain classes, replicating a
>> lot of the work. Then it was slow when you had a lot of objects, a
>> lesson we learned from the monster called Cairngorm.
>>
>> Our solution, keep it light. We used simple REST services with Grail’s
>> content negotiation capabilities; and we didn’t run into those nasty
>> hibernate session exceptions anymore. We kept everything in a native
>> XML format and used e4x to bind this data into our components; and it
>> was beautiful, elegant and powerful. Both Grails/Groovy and
>> Flex/ActionScript have incredible XML support; exploit this.
>>
>> ========================================================
>>
>> I was wondering if anything had been done to correct the Hibernate
>> issue he mentions, as I would much rather be able to use BlazeDS with
>> remoting and messaging than have to use REST with Flex.
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>

--
Graeme Rocher
Head of Grails Development
SpringSource - A Division of VMware
http://www.springsource.com

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

    http://xircles.codehaus.org/manage_email

[tomas lin]

To add a bit more info to this,

The Flex plugin right now does not support any kind of lazy loading.
So if your domain objects have any type of one-to-many relationships,
you'll run into a wonderful lazyloadingexception.

There is a google code project that you can use as a reference if you
want to integrate the dpHibernate library - which handles your
sessions for you, provided you change your actionscript valueobjects
according to their implementation -
http://code.google.com/p/flexongrails/

You might also consider the GraniteDS plugin ( which supports lazy
loading problems via its propitiatory Tide framework ). But GraniteDS
doesn't seem to want to play nice with Flash 10.

Alternatively, you can also explore using the Gilead library with the
DTO plugin - http://noon.gilead.free.fr/gilead/

On Wed, Dec 16, 2009 at 3:00 PM, Graeme Rocher
<[hidden email]> wrote:

> The issue is with Hibernate itself. Hibernate create proxies for
> associations and has special implementations of collections
> (PersistentCollection, PersistentSet etc.) to lazy load associations
>
> When you send this over the wire with BlazeDS it can lead to strange
> exceptions. You can of course workaround these problems (by using
> eager fetching for example), but expect bumps along the way.
>
> Another alternative is to use the DTO plugin as is done with the GWT plugin
>
> Cheers
>
> On Wed, Dec 16, 2009 at 3:56 PM, Nick Collins <[hidden email]> wrote:
>> I'm sorry to belabor the point, but could someone please expound on
>> what the issue is, exactly?
>>
>> Is this a problem with Hibernate itself, or just it's implementation in Grails?
>>
>> On Fri, Dec 11, 2009 at 11:26 AM, Paul Bowler <[hidden email]> wrote:
>>> Nick,
>>>
>>> We've recently launched an enterprise application using Flex and Grails and
>>> I can agree with a lot of what Tomas posted.
>>>
>>> Fortunately we intentionally kept the server API small to minimise the
>>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>>> breaking. If I were to design and implement this again I'd probably go for a
>>> REST architecture too.
>>>
>>> As far as I'm aware the issues have still not been respolved although I
>>> heard SpringSource and Adobe were working together to improve product
>>> inter-working. Can anyone confirm this?
>>>
>>> Paul.
>>>
>>> ________________________________
>>> From: Nick Collins <[hidden email]>
>>> To: [hidden email]
>>> Sent: Fri, 11 December, 2009 17:06:38
>>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>>
>>> Tomás Lin posted the following to his blog about a year ago regarding
>>> his lessons learned using Grails as the back-end to a Flex
>>> application:
>>>
>>> ========================================================
>>>
>>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>>
>>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>>> with Marcel’s hello world example.
>>>
>>> But then came trying to get it to work with non-toy data. Hibernate
>>> breaks when trying to handle many-to-one relationships, something
>>> about the connection being closed. Then you had to create new
>>> Actionscript objects for each of your domain classes, replicating a
>>> lot of the work. Then it was slow when you had a lot of objects, a
>>> lesson we learned from the monster called Cairngorm.
>>>
>>> Our solution, keep it light. We used simple REST services with Grail’s
>>> content negotiation capabilities; and we didn’t run into those nasty
>>> hibernate session exceptions anymore. We kept everything in a native
>>> XML format and used e4x to bind this data into our components; and it
>>> was beautiful, elegant and powerful. Both Grails/Groovy and
>>> Flex/ActionScript have incredible XML support; exploit this.
>>>
>>> ========================================================
>>>
>>> I was wondering if anything had been done to correct the Hibernate
>>> issue he mentions, as I would much rather be able to use BlazeDS with
>>> remoting and messaging than have to use REST with Flex.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
>
> --
> Graeme Rocher
> Head of Grails Development
> SpringSource - A Division of VMware
> http://www.springsource.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

[Nick Collins-2]

Thanks as always, Graeme.

I was just looking at the DTO plugin, and it looks like it might be a
good option.

I would assume that I would then use the DTO as my remote-class alias.
From what I saw then DTO doesn't have the id and version attributes,
though, so I could leave those out of my AS DTOs. Now, when I pass
those DTOs back to Grails, how does it link them to the Domain objects
to then be persisted back to the database?

Nick

On Wed, Dec 16, 2009 at 9:00 AM, Graeme Rocher
<[hidden email]> wrote:

> The issue is with Hibernate itself. Hibernate create proxies for
> associations and has special implementations of collections
> (PersistentCollection, PersistentSet etc.) to lazy load associations
>
> When you send this over the wire with BlazeDS it can lead to strange
> exceptions. You can of course workaround these problems (by using
> eager fetching for example), but expect bumps along the way.
>
> Another alternative is to use the DTO plugin as is done with the GWT plugin
>
> Cheers
>
> On Wed, Dec 16, 2009 at 3:56 PM, Nick Collins <[hidden email]> wrote:
>> I'm sorry to belabor the point, but could someone please expound on
>> what the issue is, exactly?
>>
>> Is this a problem with Hibernate itself, or just it's implementation in Grails?
>>
>> On Fri, Dec 11, 2009 at 11:26 AM, Paul Bowler <[hidden email]> wrote:
>>> Nick,
>>>
>>> We've recently launched an enterprise application using Flex and Grails and
>>> I can agree with a lot of what Tomas posted.
>>>
>>> Fortunately we intentionally kept the server API small to minimise the
>>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>>> breaking. If I were to design and implement this again I'd probably go for a
>>> REST architecture too.
>>>
>>> As far as I'm aware the issues have still not been respolved although I
>>> heard SpringSource and Adobe were working together to improve product
>>> inter-working. Can anyone confirm this?
>>>
>>> Paul.
>>>
>>> ________________________________
>>> From: Nick Collins <[hidden email]>
>>> To: [hidden email]
>>> Sent: Fri, 11 December, 2009 17:06:38
>>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>>
>>> Tomás Lin posted the following to his blog about a year ago regarding
>>> his lessons learned using Grails as the back-end to a Flex
>>> application:
>>>
>>> ========================================================
>>>
>>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>>
>>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>>> with Marcel’s hello world example.
>>>
>>> But then came trying to get it to work with non-toy data. Hibernate
>>> breaks when trying to handle many-to-one relationships, something
>>> about the connection being closed. Then you had to create new
>>> Actionscript objects for each of your domain classes, replicating a
>>> lot of the work. Then it was slow when you had a lot of objects, a
>>> lesson we learned from the monster called Cairngorm.
>>>
>>> Our solution, keep it light. We used simple REST services with Grail’s
>>> content negotiation capabilities; and we didn’t run into those nasty
>>> hibernate session exceptions anymore. We kept everything in a native
>>> XML format and used e4x to bind this data into our components; and it
>>> was beautiful, elegant and powerful. Both Grails/Groovy and
>>> Flex/ActionScript have incredible XML support; exploit this.
>>>
>>> ========================================================
>>>
>>> I was wondering if anything had been done to correct the Hibernate
>>> issue he mentions, as I would much rather be able to use BlazeDS with
>>> remoting and messaging than have to use REST with Flex.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
>
> --
> Graeme Rocher
> Head of Grails Development
> SpringSource - A Division of VMware
> http://www.springsource.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

[Nick Collins-2]

I may have to look into this further. I know the guys at Digital
Primates who developed this, so I may have to investigate how to best
integrate it into a Grails stack.

Thanks!

Nick

On Wed, Dec 16, 2009 at 9:17 AM, Tomas Lin <[hidden email]> wrote:

> To add a bit more info to this,
>
> The Flex plugin right now does not support any kind of lazy loading.
> So if your domain objects have any type of one-to-many relationships,
> you'll run into a wonderful lazyloadingexception.
>
> There is a google code project that you can use as a reference if you
> want to integrate the dpHibernate library - which handles your
> sessions for you, provided you change your actionscript valueobjects
> according to their implementation -
> http://code.google.com/p/flexongrails/
>
> You might also consider the GraniteDS plugin ( which supports lazy
> loading problems via its propitiatory Tide framework ). But GraniteDS
> doesn't seem to want to play nice with Flash 10.
>
> Alternatively, you can also explore using the Gilead library with the
> DTO plugin - http://noon.gilead.free.fr/gilead/
>
> On Wed, Dec 16, 2009 at 3:00 PM, Graeme Rocher
> <[hidden email]> wrote:
>> The issue is with Hibernate itself. Hibernate create proxies for
>> associations and has special implementations of collections
>> (PersistentCollection, PersistentSet etc.) to lazy load associations
>>
>> When you send this over the wire with BlazeDS it can lead to strange
>> exceptions. You can of course workaround these problems (by using
>> eager fetching for example), but expect bumps along the way.
>>
>> Another alternative is to use the DTO plugin as is done with the GWT plugin
>>
>> Cheers
>>
>> On Wed, Dec 16, 2009 at 3:56 PM, Nick Collins <[hidden email]> wrote:
>>> I'm sorry to belabor the point, but could someone please expound on
>>> what the issue is, exactly?
>>>
>>> Is this a problem with Hibernate itself, or just it's implementation in Grails?
>>>
>>> On Fri, Dec 11, 2009 at 11:26 AM, Paul Bowler <[hidden email]> wrote:
>>>> Nick,
>>>>
>>>> We've recently launched an enterprise application using Flex and Grails and
>>>> I can agree with a lot of what Tomas posted.
>>>>
>>>> Fortunately we intentionally kept the server API small to minimise the
>>>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>>>> breaking. If I were to design and implement this again I'd probably go for a
>>>> REST architecture too.
>>>>
>>>> As far as I'm aware the issues have still not been respolved although I
>>>> heard SpringSource and Adobe were working together to improve product
>>>> inter-working. Can anyone confirm this?
>>>>
>>>> Paul.
>>>>
>>>> ________________________________
>>>> From: Nick Collins <[hidden email]>
>>>> To: [hidden email]
>>>> Sent: Fri, 11 December, 2009 17:06:38
>>>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>>>
>>>> Tomás Lin posted the following to his blog about a year ago regarding
>>>> his lessons learned using Grails as the back-end to a Flex
>>>> application:
>>>>
>>>> ========================================================
>>>>
>>>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>>>
>>>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>>>> with Marcel’s hello world example.
>>>>
>>>> But then came trying to get it to work with non-toy data. Hibernate
>>>> breaks when trying to handle many-to-one relationships, something
>>>> about the connection being closed. Then you had to create new
>>>> Actionscript objects for each of your domain classes, replicating a
>>>> lot of the work. Then it was slow when you had a lot of objects, a
>>>> lesson we learned from the monster called Cairngorm.
>>>>
>>>> Our solution, keep it light. We used simple REST services with Grail’s
>>>> content negotiation capabilities; and we didn’t run into those nasty
>>>> hibernate session exceptions anymore. We kept everything in a native
>>>> XML format and used e4x to bind this data into our components; and it
>>>> was beautiful, elegant and powerful. Both Grails/Groovy and
>>>> Flex/ActionScript have incredible XML support; exploit this.
>>>>
>>>> ========================================================
>>>>
>>>> I was wondering if anything had been done to correct the Hibernate
>>>> issue he mentions, as I would much rather be able to use BlazeDS with
>>>> remoting and messaging than have to use REST with Flex.
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>>
>> --
>> Graeme Rocher
>> Head of Grails Development
>> SpringSource - A Division of VMware
>> http://www.springsource.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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[tomas lin]

Forgot to mention that the Spring-Flex project has a reference
integration of dpHibernate that you would find very useful if you go
this route.

http://static.springsource.org/spring-flex/ ( dpHibernate-test.zip )

Given that Grails Flex plugin 0.4 in svn contains the spring-flex
integration, all you have to do is implement the right
opensessioninview filter, which is probably easier said than done.


On Wed, Dec 16, 2009 at 3:20 PM, Nick Collins <[hidden email]> wrote:

> I may have to look into this further. I know the guys at Digital
> Primates who developed this, so I may have to investigate how to best
> integrate it into a Grails stack.
>
> Thanks!
>
> Nick
>
> On Wed, Dec 16, 2009 at 9:17 AM, Tomas Lin <[hidden email]> wrote:
>> To add a bit more info to this,
>>
>> The Flex plugin right now does not support any kind of lazy loading.
>> So if your domain objects have any type of one-to-many relationships,
>> you'll run into a wonderful lazyloadingexception.
>>
>> There is a google code project that you can use as a reference if you
>> want to integrate the dpHibernate library - which handles your
>> sessions for you, provided you change your actionscript valueobjects
>> according to their implementation -
>> http://code.google.com/p/flexongrails/
>>
>> You might also consider the GraniteDS plugin ( which supports lazy
>> loading problems via its propitiatory Tide framework ). But GraniteDS
>> doesn't seem to want to play nice with Flash 10.
>>
>> Alternatively, you can also explore using the Gilead library with the
>> DTO plugin - http://noon.gilead.free.fr/gilead/
>>
>> On Wed, Dec 16, 2009 at 3:00 PM, Graeme Rocher
>> <[hidden email]> wrote:
>>> The issue is with Hibernate itself. Hibernate create proxies for
>>> associations and has special implementations of collections
>>> (PersistentCollection, PersistentSet etc.) to lazy load associations
>>>
>>> When you send this over the wire with BlazeDS it can lead to strange
>>> exceptions. You can of course workaround these problems (by using
>>> eager fetching for example), but expect bumps along the way.
>>>
>>> Another alternative is to use the DTO plugin as is done with the GWT plugin
>>>
>>> Cheers
>>>
>>> On Wed, Dec 16, 2009 at 3:56 PM, Nick Collins <[hidden email]> wrote:
>>>> I'm sorry to belabor the point, but could someone please expound on
>>>> what the issue is, exactly?
>>>>
>>>> Is this a problem with Hibernate itself, or just it's implementation in Grails?
>>>>
>>>> On Fri, Dec 11, 2009 at 11:26 AM, Paul Bowler <[hidden email]> wrote:
>>>>> Nick,
>>>>>
>>>>> We've recently launched an enterprise application using Flex and Grails and
>>>>> I can agree with a lot of what Tomas posted.
>>>>>
>>>>> Fortunately we intentionally kept the server API small to minimise the
>>>>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>>>>> breaking. If I were to design and implement this again I'd probably go for a
>>>>> REST architecture too.
>>>>>
>>>>> As far as I'm aware the issues have still not been respolved although I
>>>>> heard SpringSource and Adobe were working together to improve product
>>>>> inter-working. Can anyone confirm this?
>>>>>
>>>>> Paul.
>>>>>
>>>>> ________________________________
>>>>> From: Nick Collins <[hidden email]>
>>>>> To: [hidden email]
>>>>> Sent: Fri, 11 December, 2009 17:06:38
>>>>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>>>>
>>>>> Tomás Lin posted the following to his blog about a year ago regarding
>>>>> his lessons learned using Grails as the back-end to a Flex
>>>>> application:
>>>>>
>>>>> ========================================================
>>>>>
>>>>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>>>>
>>>>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>>>>> with Marcel’s hello world example.
>>>>>
>>>>> But then came trying to get it to work with non-toy data. Hibernate
>>>>> breaks when trying to handle many-to-one relationships, something
>>>>> about the connection being closed. Then you had to create new
>>>>> Actionscript objects for each of your domain classes, replicating a
>>>>> lot of the work. Then it was slow when you had a lot of objects, a
>>>>> lesson we learned from the monster called Cairngorm.
>>>>>
>>>>> Our solution, keep it light. We used simple REST services with Grail’s
>>>>> content negotiation capabilities; and we didn’t run into those nasty
>>>>> hibernate session exceptions anymore. We kept everything in a native
>>>>> XML format and used e4x to bind this data into our components; and it
>>>>> was beautiful, elegant and powerful. Both Grails/Groovy and
>>>>> Flex/ActionScript have incredible XML support; exploit this.
>>>>>
>>>>> ========================================================
>>>>>
>>>>> I was wondering if anything had been done to correct the Hibernate
>>>>> issue he mentions, as I would much rather be able to use BlazeDS with
>>>>> remoting and messaging than have to use REST with Flex.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Graeme Rocher
>>> Head of Grails Development
>>> SpringSource - A Division of VMware
>>> http://www.springsource.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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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

[Paul Bowler]

Nick,

I'd really recommend looking at using REST rather than BlazeDS+Flex Plugin.

With the latter you'll have to create create ActionScript representations of your domain classes and wrap them on the server as DTO's. This is a lot of duplication and overhead unless you keep your domains objects simple and few. Integration testing can also become a nightmare with this setup.

With REST you can simply expose your domain objects as XML (one line of Groovy) and use the powerful XML parsing features of Flex. Simple, scalable and testable.

Regards,

Paul.

 

---

From: Nick Collins <[hidden email]>
To: [hidden email]
Sent: Wed, 16 December, 2009 15:20:27
Subject: Re: [grails-user] BlazeDS and Grails/Hibernate

I may have to look into this further. I know the guys at Digital
Primates who developed this, so I may have to investigate how to best
integrate it into a Grails stack.

Thanks!

Nick

On Wed, Dec 16, 2009 at 9:17 AM, Tomas Lin <[hidden email]> wrote:

> To add a bit more info to this,
>
> The Flex plugin right now does not support any kind of lazy loading.
> So if your domain objects have any type of one-to-many relationships,
> you'll run into a wonderful lazyloadingexception.
>
> There is a google code project that you can use as a reference if you
> want to integrate the dpHibernate library - which handles your
> sessions for you, provided you change your actionscript valueobjects
> according to their implementation -
> http://code.google.com/p/flexongrails/
>
> You might also consider the GraniteDS plugin ( which supports lazy
> loading problems via its propitiatory Tide framework ). But GraniteDS
> doesn't seem to want to play nice with Flash 10.
>
> Alternatively, you can also explore using the Gilead library with the
> DTO plugin - http://noon.gilead.free.fr/gilead/
>
> On Wed, Dec 16, 2009 at 3:00 PM, Graeme Rocher
> <[hidden email]> wrote:
>> The issue is with Hibernate itself. Hibernate create proxies for
>> associations and has special implementations of collections
>> (PersistentCollection, PersistentSet etc.) to lazy load associations
>>
>> When you send this over the wire with BlazeDS it can lead to strange
>> exceptions. You can of course workaround these problems (by using
>> eager fetching for example), but expect bumps along the way.
>>
>> Another alternative is to use the DTO plugin as is done with the GWT plugin
>>
>> Cheers
>>
>> On Wed, Dec 16, 2009 at 3:56 PM, Nick Collins <[hidden email]> wrote:
>>> I'm sorry to belabor the point, but could someone please expound on
>>> what the issue is, exactly?
>>>
>>> Is this a problem with Hibernate itself, or just it's implementation in Grails?
>>>
>>> On Fri, Dec 11, 2009 at 11:26 AM, Paul Bowler <[hidden email]> wrote:
>>>> Nick,
>>>>
>>>> We've recently launched an enterprise application using Flex and Grails and
>>>> I can agree with a lot of what Tomas posted.
>>>>
>>>> Fortunately we intentionally kept the server API small to minimise the
>>>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>>>> breaking. If I were to design and implement this again I'd probably go for a
>>>> REST architecture too.
>>>>
>>>> As far as I'm aware the issues have still not been respolved although I
>>>> heard SpringSource and Adobe were working together to improve product
>>>> inter-working. Can anyone confirm this?
>>>>
>>>> Paul.
>>>>
>>>> ________________________________
>>>> From: Nick Collins <[hidden email]>
>>>> To: [hidden email]
>>>> Sent: Fri, 11 December, 2009 17:06:38
>>>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>>>
>>>> Tomás Lin posted the following to his blog about a year ago regarding
>>>> his lessons learned using Grails as the back-end to a Flex
>>>> application:
>>>>
>>>> ========================================================
>>>>
>>>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>>>
>>>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>>>> with Marcel’s hello world example.
>>>>
>>>> But then came trying to get it to work with non-toy data. Hibernate
>>>> breaks when trying to handle many-to-one relationships, something
>>>> about the connection being closed. Then you had to create new
>>>> Actionscript objects for each of your domain classes, replicating a
>>>> lot of the work. Then it was slow when you had a lot of objects, a
>>>> lesson we learned from the monster called Cairngorm.
>>>>
>>>> Our solution, keep it light. We used simple REST services with Grail’s
>>>> content negotiation capabilities; and we didn’t run into those nasty
>>>> hibernate session exceptions anymore. We kept everything in a native
>>>> XML format and used e4x to bind this data into our components; and it
>>>> was beautiful, elegant and powerful. Both Grails/Groovy and
>>>> Flex/ActionScript have incredible XML support; exploit this.
>>>>
>>>> ========================================================
>>>>
>>>> I was wondering if anything had been done to correct the Hibernate
>>>> issue he mentions, as I would much rather be able to use BlazeDS with
>>>> remoting and messaging than have to use REST with Flex.
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>>
>> --
>> Graeme Rocher
>> Head of Grails Development
>> SpringSource - A Division of VMware
>> http://www.springsource.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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Nick Collins-2]

I guess my concern with REST is 1) the overhead of how verbose XML data is over the wire and 2) The HTTP header limitations inside the Flash Player that prevent fully utilizing REST.

Assuming after some testing that the performance is reasonable and we can rule out number 1, how do you get around #2?

Every method I've seen strikes me as a terrible hack, like adding some additional data to the POST requests and parsing it on the server side to figure out what the header is really supposed to be.

Nick

On Wed, Dec 16, 2009 at 10:35 AM, Paul Bowler <[hidden email]> wrote:

Nick,

I'd really recommend looking at using REST rather than BlazeDS+Flex Plugin.

With the latter you'll have to create create ActionScript representations of your domain classes and wrap them on the server as DTO's. This is a lot of duplication and overhead unless you keep your domains objects simple and few. Integration testing can also become a nightmare with this setup.

With REST you can simply expose your domain objects as XML (one line of Groovy) and use the powerful XML parsing features of Flex. Simple, scalable and testable.

Regards,

Paul.

 

---

From: Nick Collins <[hidden email]>
To: [hidden email]

Sent: Wed, 16 December, 2009 15:20:27
Subject: Re: [grails-user] BlazeDS and Grails/Hibernate

I may have to look into this further. I know the guys at Digital
Primates who developed this, so I may have to investigate how to best
integrate it into a Grails stack.

Thanks!

Nick

On Wed, Dec 16, 2009 at 9:17 AM, Tomas Lin <[hidden email]> wrote:
> To add a bit more info to this,
>
> The Flex plugin right now does not support any kind of lazy loading.
> So if your domain objects have any type of one-to-many relationships,
> you'll run into a wonderful lazyloadingexception.
>
> There is a google code project that you can use as a reference if you
> want to integrate the dpHibernate library - which handles your
> sessions for you, provided you change your actionscript valueobjects
> according to their implementation -
> http://code.google.com/p/flexongrails/
>
> You might also consider the GraniteDS plugin ( which supports lazy
> loading problems via its propitiatory Tide framework ). But GraniteDS
> doesn't seem to want to play nice with Flash 10.
>
> Alternatively, you can also explore using the Gilead library with the
> DTO plugin - http://noon.gilead.free.fr/gilead/
>
> On Wed, Dec 16, 2009 at 3:00 PM, Graeme Rocher
> <[hidden email]> wrote:
>> The issue is with Hibernate itself. Hibernate create proxies for
>> associations and has special implementations of collections
>> (PersistentCollection, PersistentSet etc.) to lazy load associations
>>
>> When you send this over the wire with BlazeDS it can lead to strange
>> exceptions. You can of course workaround these problems (by using
>> eager fetching for example), but expect bumps along the way.
>>
>> Another alternative is to use the DTO plugin as is done with the GWT plugin
>>
>> Cheers
>>
>> On Wed, Dec 16, 2009 at 3:56 PM, Nick Collins <[hidden email]> wrote:
>>> I'm sorry to belabor the point, but could someone please expound on
>>> what the issue is, exactly?
>>>
>>> Is this a problem with Hibernate itself, or just it's implementation in Grails?
>>>
>>> On Fri, Dec 11, 2009 at 11:26 AM, Paul Bowler <[hidden email]> wrote:
>>>> Nick,
>>>>
>>>> We've recently launched an enterprise application using Flex and Grails and
>>>> I can agree with a lot of what Tomas posted.
>>>>
>>>> Fortunately we intentionally kept the server API small to minimise the
>>>> Flex/BlazeDS overhead but still had to use DTO's to stop Hibernate/GORM from
>>>> breaking. If I were to design and implement this again I'd probably go for a
>>>> REST architecture too.
>>>>
>>>> As far as I'm aware the issues have still not been respolved although I
>>>> heard SpringSource and Adobe were working together to improve product
>>>> inter-working. Can anyone confirm this?
>>>>
>>>> Paul.
>>>>
>>>> ________________________________
>>>> From: Nick Collins <[hidden email]>
>>>> To: [hidden email]
>>>> Sent: Fri, 11 December, 2009 17:06:38
>>>> Subject: [grails-user] BlazeDS and Grails/Hibernate
>>>>
>>>> Tomás Lin posted the following to his blog about a year ago regarding
>>>> his lessons learned using Grails as the back-end to a Flex
>>>> application:
>>>>
>>>> ========================================================
>>>>
>>>> Lesson 2: Grails REST services beats BlazeDS. To a bloody pulp.
>>>>
>>>> The Grails-Flex plugin. What a wonderful idea. I got giggles playing
>>>> with Marcel’s hello world example.
>>>>
>>>> But then came trying to get it to work with non-toy data. Hibernate
>>>> breaks when trying to handle many-to-one relationships, something
>>>> about the connection being closed. Then you had to create new
>>>> Actionscript objects for each of your domain classes, replicating a
>>>> lot of the work. Then it was slow when you had a lot of objects, a
>>>> lesson we learned from the monster called Cairngorm.
>>>>
>>>> Our solution, keep it light. We used simple REST services with Grail’s
>>>> content negotiation capabilities; and we didn’t run into those nasty
>>>> hibernate session exceptions anymore. We kept everything in a native
>>>> XML format and used e4x to bind this data into our components; and it
>>>> was beautiful, elegant and powerful. Both Grails/Groovy and
>>>> Flex/ActionScript have incredible XML support; exploit this.
>>>>
>>>> ========================================================
>>>>
>>>> I was wondering if anything had been done to correct the Hibernate
>>>> issue he mentions, as I would much rather be able to use BlazeDS with
>>>> remoting and messaging than have to use REST with Flex.
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>>
>> --
>> Graeme Rocher
>> Head of Grails Development
>> SpringSource - A Division of VMware
>> http://www.springsource.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
>
>
>

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

    http://xircles.codehaus.org/manage_email