Grails Adoption Hell: My Point of View

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Grails Adoption Hell: My Point of View

Jonathan Rosenberg
I've been reading the thread on Grails adoption with great interest,
as I am considering adopting it for my own needs.  I'd like to give my
own hands-on point of view & also ask for some help/advice.

My background in a nutshell:
- CS background (CS PhD in 1987)
- programmed in many, many languages
- lots of Unix/Linux experience, sm amount Win experience
- lots of web programming experience (since 1995)
- been using PHP for 5 years or so
- small amount of Groovy experience, smaller anmount of Java experience
- no Tomcat (etc.) experience
- I run a non-profit.  I am the IT shop.  I only have to convince myself.

I have been working with Grails (on Tomcat) for about 2 months now.
Frankly, it's been hell, but the promise is so great that I have
persevered.  But I feel like I've now reached the breaking point & am
seriously considering bailing & looking for another framework.

There have been, of course, the usual learning curve problems (Tomcat,
Java, Groovy), which I expected.  The problems that are causing me
such distress are two-fold:

1) debugging
2) Instability

Debugging is painful for several reasons:
- turnaround time is way too long (compile, package, deploy, restart
Tomcat [sometimes])
- largely-meaningless stack traces.  Ok, some of this is my
inexperience, but I'm sure anyone would admit that the exceptions are
often very obscure, given the behind-the-scenes Grails magic)
- I have got debugging in Eclipse working, but it's pretty much
useless because of all the overhead imposed by Grails.  I spent 1/2
hour looking for a variable value & finally gave up).

As far as instability goes, I have not yet been able to get a stable
development environment set up.  I have environments on a Linux box
(testing, sometimes dev) & two PCs (development).  I often have to
restart Tomcat & sometimes have to redeploy the WAR.

Small changes in code seem to cause large changes in deployment,
reloading, etc.  For example, I recently made a small change to the
templates I use to render a page & I now find that I have to restart
Tomcat now when I deploy (something about "BeanFactory not
initialized...").

So, enough ranting, I have some questions for the crowd:

1) Is there any way to significantly minimize turnaround time? Or is
this just a fact of life in this environment?
2) Is there a good guide for setting up useful debugging available?
Or is this also just going to be painful?

Any help appreciated.  I really want to use Grails, but I'm spending
way too much time on non-programmatic issues.

Thanks for listening.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

scryan
Why are you redeploying etc. If you just use grails run-app you can do your development and the application will interpret the changes and they will be immediately visible without any build and deploy.  Tomcat is built into the framework so running grails run-app will start your application inside tomcat.  it seems like you are experiencing what a lot of us in the J2EE arena experienced years ago and that is why grails is such a productivity win.   The stacktraces are a little verbose but experience in java and groovy will make that more bearable.  What IDE do you use for your development?  If you use Intellij or Spring STS the debugger is very easy to use.  I am sorry you had such a bad experience so far but it sounds like for some reason you were pointed down a bad path to begin with.  i hope you will keep with it and use this list and other tutorials to help make your experience a much better one.

Scott Ryan
On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:

> I've been reading the thread on Grails adoption with great interest,
> as I am considering adopting it for my own needs.  I'd like to give my
> own hands-on point of view & also ask for some help/advice.
>
> My background in a nutshell:
> - CS background (CS PhD in 1987)
> - programmed in many, many languages
> - lots of Unix/Linux experience, sm amount Win experience
> - lots of web programming experience (since 1995)
> - been using PHP for 5 years or so
> - small amount of Groovy experience, smaller anmount of Java experience
> - no Tomcat (etc.) experience
> - I run a non-profit.  I am the IT shop.  I only have to convince myself.
>
> I have been working with Grails (on Tomcat) for about 2 months now.
> Frankly, it's been hell, but the promise is so great that I have
> persevered.  But I feel like I've now reached the breaking point & am
> seriously considering bailing & looking for another framework.
>
> There have been, of course, the usual learning curve problems (Tomcat,
> Java, Groovy), which I expected.  The problems that are causing me
> such distress are two-fold:
>
> 1) debugging
> 2) Instability
>
> Debugging is painful for several reasons:
> - turnaround time is way too long (compile, package, deploy, restart
> Tomcat [sometimes])
> - largely-meaningless stack traces.  Ok, some of this is my
> inexperience, but I'm sure anyone would admit that the exceptions are
> often very obscure, given the behind-the-scenes Grails magic)
> - I have got debugging in Eclipse working, but it's pretty much
> useless because of all the overhead imposed by Grails.  I spent 1/2
> hour looking for a variable value & finally gave up).
>
> As far as instability goes, I have not yet been able to get a stable
> development environment set up.  I have environments on a Linux box
> (testing, sometimes dev) & two PCs (development).  I often have to
> restart Tomcat & sometimes have to redeploy the WAR.
>
> Small changes in code seem to cause large changes in deployment,
> reloading, etc.  For example, I recently made a small change to the
> templates I use to render a page & I now find that I have to restart
> Tomcat now when I deploy (something about "BeanFactory not
> initialized...").
>
> So, enough ranting, I have some questions for the crowd:
>
> 1) Is there any way to significantly minimize turnaround time? Or is
> this just a fact of life in this environment?
> 2) Is there a good guide for setting up useful debugging available?
> Or is this also just going to be painful?
>
> Any help appreciated.  I really want to use Grails, but I'm spending
> way too much time on non-programmatic issues.
>
> Thanks for listening.
>
> --
> Jonathan Rosenberg
> Founder & Executive Director
> Tabby's Place, a Cat Sanctuary
> http://www.tabbysplace.org/
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Joshua Kehn
In reply to this post by Jonathan Rosenberg
I'm not sure what you're doing wrong, but I haven't ever had to restart the container because of a deployment. If anything I much prefer using Tomcat and WAR's for deployment compared to PHP because everything is packaged up and deployable. 

Debugging time can be minimized using strategic testing. I won't claim the stacktraces are pretty - they never are. I traditionally use TextMate and/or VIM for coding, no IDE support here. Have you considered a different approach to debugging? I have never found myself needing to use a dedicated debugger.

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:04 PM, Jonathan Rosenberg wrote:

I've been reading the thread on Grails adoption with great interest,
as I am considering adopting it for my own needs.  I'd like to give my
own hands-on point of view & also ask for some help/advice.

My background in a nutshell:
- CS background (CS PhD in 1987)
- programmed in many, many languages
- lots of Unix/Linux experience, sm amount Win experience
- lots of web programming experience (since 1995)
- been using PHP for 5 years or so
- small amount of Groovy experience, smaller anmount of Java experience
- no Tomcat (etc.) experience
- I run a non-profit.  I am the IT shop.  I only have to convince myself.

I have been working with Grails (on Tomcat) for about 2 months now.
Frankly, it's been hell, but the promise is so great that I have
persevered.  But I feel like I've now reached the breaking point & am
seriously considering bailing & looking for another framework.

There have been, of course, the usual learning curve problems (Tomcat,
Java, Groovy), which I expected.  The problems that are causing me
such distress are two-fold:

1) debugging
2) Instability

Debugging is painful for several reasons:
- turnaround time is way too long (compile, package, deploy, restart
Tomcat [sometimes])
- largely-meaningless stack traces.  Ok, some of this is my
inexperience, but I'm sure anyone would admit that the exceptions are
often very obscure, given the behind-the-scenes Grails magic)
- I have got debugging in Eclipse working, but it's pretty much
useless because of all the overhead imposed by Grails.  I spent 1/2
hour looking for a variable value & finally gave up).

As far as instability goes, I have not yet been able to get a stable
development environment set up.  I have environments on a Linux box
(testing, sometimes dev) & two PCs (development).  I often have to
restart Tomcat & sometimes have to redeploy the WAR.

Small changes in code seem to cause large changes in deployment,
reloading, etc.  For example, I recently made a small change to the
templates I use to render a page & I now find that I have to restart
Tomcat now when I deploy (something about "BeanFactory not
initialized...").

So, enough ranting, I have some questions for the crowd:

1) Is there any way to significantly minimize turnaround time? Or is
this just a fact of life in this environment?
2) Is there a good guide for setting up useful debugging available?
Or is this also just going to be painful?

Any help appreciated.  I really want to use Grails, but I'm spending
way too much time on non-programmatic issues.

Thanks for listening.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Joshua Kehn
In reply to this post by scryan
I was assuming issues with actual deployment in Tomcat, not debugging the application under Tomcat. If you are developing / debugging under Tomcat then I would say you should instead be using `grails run-app` instead for the exact reasons Scott mentions. 

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:13 PM, Scott Ryan wrote:

Why are you redeploying etc. If you just use grails run-app you can do your development and the application will interpret the changes and they will be immediately visible without any build and deploy.  Tomcat is built into the framework so running grails run-app will start your application inside tomcat.  it seems like you are experiencing what a lot of us in the J2EE arena experienced years ago and that is why grails is such a productivity win.   The stacktraces are a little verbose but experience in java and groovy will make that more bearable.  What IDE do you use for your development?  If you use Intellij or Spring STS the debugger is very easy to use.  I am sorry you had such a bad experience so far but it sounds like for some reason you were pointed down a bad path to begin with.  i hope you will keep with it and use this list and other tutorials to help make your experience a much better one.

Scott Ryan
On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:

I've been reading the thread on Grails adoption with great interest,
as I am considering adopting it for my own needs.  I'd like to give my
own hands-on point of view & also ask for some help/advice.

My background in a nutshell:
- CS background (CS PhD in 1987)
- programmed in many, many languages
- lots of Unix/Linux experience, sm amount Win experience
- lots of web programming experience (since 1995)
- been using PHP for 5 years or so
- small amount of Groovy experience, smaller anmount of Java experience
- no Tomcat (etc.) experience
- I run a non-profit.  I am the IT shop.  I only have to convince myself.

I have been working with Grails (on Tomcat) for about 2 months now.
Frankly, it's been hell, but the promise is so great that I have
persevered.  But I feel like I've now reached the breaking point & am
seriously considering bailing & looking for another framework.

There have been, of course, the usual learning curve problems (Tomcat,
Java, Groovy), which I expected.  The problems that are causing me
such distress are two-fold:

1) debugging
2) Instability

Debugging is painful for several reasons:
- turnaround time is way too long (compile, package, deploy, restart
Tomcat [sometimes])
- largely-meaningless stack traces.  Ok, some of this is my
inexperience, but I'm sure anyone would admit that the exceptions are
often very obscure, given the behind-the-scenes Grails magic)
- I have got debugging in Eclipse working, but it's pretty much
useless because of all the overhead imposed by Grails.  I spent 1/2
hour looking for a variable value & finally gave up).

As far as instability goes, I have not yet been able to get a stable
development environment set up.  I have environments on a Linux box
(testing, sometimes dev) & two PCs (development).  I often have to
restart Tomcat & sometimes have to redeploy the WAR.

Small changes in code seem to cause large changes in deployment,
reloading, etc.  For example, I recently made a small change to the
templates I use to render a page & I now find that I have to restart
Tomcat now when I deploy (something about "BeanFactory not
initialized...").

So, enough ranting, I have some questions for the crowd:

1) Is there any way to significantly minimize turnaround time? Or is
this just a fact of life in this environment?
2) Is there a good guide for setting up useful debugging available?
Or is this also just going to be painful?

Any help appreciated.  I really want to use Grails, but I'm spending
way too much time on non-programmatic issues.

Thanks for listening.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

---------------------------------------------------------------------
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



Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Roshan Dawrani
Debugging a grails app is a piece of cake with STS IDE...

On Mon, Feb 14, 2011 at 10:47 PM, Joshua Kehn <[hidden email]> wrote:
I was assuming issues with actual deployment in Tomcat, not debugging the application under Tomcat. If you are developing / debugging under Tomcat then I would say you should instead be using `grails run-app` instead for the exact reasons Scott mentions. 

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:13 PM, Scott Ryan wrote:

Why are you redeploying etc. If you just use grails run-app you can do your development and the application will interpret the changes and they will be immediately visible without any build and deploy.  Tomcat is built into the framework so running grails run-app will start your application inside tomcat.  it seems like you are experiencing what a lot of us in the J2EE arena experienced years ago and that is why grails is such a productivity win.   The stacktraces are a little verbose but experience in java and groovy will make that more bearable.  What IDE do you use for your development?  If you use Intellij or Spring STS the debugger is very easy to use.  I am sorry you had such a bad experience so far but it sounds like for some reason you were pointed down a bad path to begin with.  i hope you will keep with it and use this list and other tutorials to help make your experience a much better one.

Scott Ryan
On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:

I've been reading the thread on Grails adoption with great interest,
as I am considering adopting it for my own needs.  I'd like to give my
own hands-on point of view & also ask for some help/advice.

My background in a nutshell:
- CS background (CS PhD in 1987)
- programmed in many, many languages
- lots of Unix/Linux experience, sm amount Win experience
- lots of web programming experience (since 1995)
- been using PHP for 5 years or so
- small amount of Groovy experience, smaller anmount of Java experience
- no Tomcat (etc.) experience
- I run a non-profit.  I am the IT shop.  I only have to convince myself.

I have been working with Grails (on Tomcat) for about 2 months now.
Frankly, it's been hell, but the promise is so great that I have
persevered.  But I feel like I've now reached the breaking point & am
seriously considering bailing & looking for another framework.

There have been, of course, the usual learning curve problems (Tomcat,
Java, Groovy), which I expected.  The problems that are causing me
such distress are two-fold:

1) debugging
2) Instability

Debugging is painful for several reasons:
- turnaround time is way too long (compile, package, deploy, restart
Tomcat [sometimes])
- largely-meaningless stack traces.  Ok, some of this is my
inexperience, but I'm sure anyone would admit that the exceptions are
often very obscure, given the behind-the-scenes Grails magic)
- I have got debugging in Eclipse working, but it's pretty much
useless because of all the overhead imposed by Grails.  I spent 1/2
hour looking for a variable value & finally gave up).

As far as instability goes, I have not yet been able to get a stable
development environment set up.  I have environments on a Linux box
(testing, sometimes dev) & two PCs (development).  I often have to
restart Tomcat & sometimes have to redeploy the WAR.

Small changes in code seem to cause large changes in deployment,
reloading, etc.  For example, I recently made a small change to the
templates I use to render a page & I now find that I have to restart
Tomcat now when I deploy (something about "BeanFactory not
initialized...").

So, enough ranting, I have some questions for the crowd:

1) Is there any way to significantly minimize turnaround time? Or is
this just a fact of life in this environment?
2) Is there a good guide for setting up useful debugging available?
Or is this also just going to be painful?

Any help appreciated.  I really want to use Grails, but I'm spending
way too much time on non-programmatic issues.

Thanks for listening.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

---------------------------------------------------------------------
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




Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

xmly
Pretty easy with IDEA. But deployment to tomcat and tomcat management could be a headache. 
The beanstalk of Amazon is really good, though it is still in beta...




On Mon, Feb 14, 2011 at 12:21 PM, Roshan Dawrani <[hidden email]> wrote:
Debugging a grails app is a piece of cake with STS IDE...


On Mon, Feb 14, 2011 at 10:47 PM, Joshua Kehn <[hidden email]> wrote:
I was assuming issues with actual deployment in Tomcat, not debugging the application under Tomcat. If you are developing / debugging under Tomcat then I would say you should instead be using `grails run-app` instead for the exact reasons Scott mentions. 

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:13 PM, Scott Ryan wrote:

Why are you redeploying etc. If you just use grails run-app you can do your development and the application will interpret the changes and they will be immediately visible without any build and deploy.  Tomcat is built into the framework so running grails run-app will start your application inside tomcat.  it seems like you are experiencing what a lot of us in the J2EE arena experienced years ago and that is why grails is such a productivity win.   The stacktraces are a little verbose but experience in java and groovy will make that more bearable.  What IDE do you use for your development?  If you use Intellij or Spring STS the debugger is very easy to use.  I am sorry you had such a bad experience so far but it sounds like for some reason you were pointed down a bad path to begin with.  i hope you will keep with it and use this list and other tutorials to help make your experience a much better one.

Scott Ryan
On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:

I've been reading the thread on Grails adoption with great interest,
as I am considering adopting it for my own needs.  I'd like to give my
own hands-on point of view & also ask for some help/advice.

My background in a nutshell:
- CS background (CS PhD in 1987)
- programmed in many, many languages
- lots of Unix/Linux experience, sm amount Win experience
- lots of web programming experience (since 1995)
- been using PHP for 5 years or so
- small amount of Groovy experience, smaller anmount of Java experience
- no Tomcat (etc.) experience
- I run a non-profit.  I am the IT shop.  I only have to convince myself.

I have been working with Grails (on Tomcat) for about 2 months now.
Frankly, it's been hell, but the promise is so great that I have
persevered.  But I feel like I've now reached the breaking point & am
seriously considering bailing & looking for another framework.

There have been, of course, the usual learning curve problems (Tomcat,
Java, Groovy), which I expected.  The problems that are causing me
such distress are two-fold:

1) debugging
2) Instability

Debugging is painful for several reasons:
- turnaround time is way too long (compile, package, deploy, restart
Tomcat [sometimes])
- largely-meaningless stack traces.  Ok, some of this is my
inexperience, but I'm sure anyone would admit that the exceptions are
often very obscure, given the behind-the-scenes Grails magic)
- I have got debugging in Eclipse working, but it's pretty much
useless because of all the overhead imposed by Grails.  I spent 1/2
hour looking for a variable value & finally gave up).

As far as instability goes, I have not yet been able to get a stable
development environment set up.  I have environments on a Linux box
(testing, sometimes dev) & two PCs (development).  I often have to
restart Tomcat & sometimes have to redeploy the WAR.

Small changes in code seem to cause large changes in deployment,
reloading, etc.  For example, I recently made a small change to the
templates I use to render a page & I now find that I have to restart
Tomcat now when I deploy (something about "BeanFactory not
initialized...").

So, enough ranting, I have some questions for the crowd:

1) Is there any way to significantly minimize turnaround time? Or is
this just a fact of life in this environment?
2) Is there a good guide for setting up useful debugging available?
Or is this also just going to be painful?

Any help appreciated.  I really want to use Grails, but I'm spending
way too much time on non-programmatic issues.

Thanks for listening.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

---------------------------------------------------------------------
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





Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Joshua Kehn
In reply to this post by Roshan Dawrani
Is STS all that great? I haven't found an IDE worth my time since CodeWarrior (Metrowerks).

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:21 PM, Roshan Dawrani wrote:

Debugging a grails app is a piece of cake with STS IDE...

On Mon, Feb 14, 2011 at 10:47 PM, Joshua Kehn <[hidden email]> wrote:
I was assuming issues with actual deployment in Tomcat, not debugging the application under Tomcat. If you are developing / debugging under Tomcat then I would say you should instead be using `grails run-app` instead for the exact reasons Scott mentions. 

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:13 PM, Scott Ryan wrote:

Why are you redeploying etc. If you just use grails run-app you can do your development and the application will interpret the changes and they will be immediately visible without any build and deploy.  Tomcat is built into the framework so running grails run-app will start your application inside tomcat.  it seems like you are experiencing what a lot of us in the J2EE arena experienced years ago and that is why grails is such a productivity win.   The stacktraces are a little verbose but experience in java and groovy will make that more bearable.  What IDE do you use for your development?  If you use Intellij or Spring STS the debugger is very easy to use.  I am sorry you had such a bad experience so far but it sounds like for some reason you were pointed down a bad path to begin with.  i hope you will keep with it and use this list and other tutorials to help make your experience a much better one.

Scott Ryan
On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:

I've been reading the thread on Grails adoption with great interest,
as I am considering adopting it for my own needs.  I'd like to give my
own hands-on point of view & also ask for some help/advice.

My background in a nutshell:
- CS background (CS PhD in 1987)
- programmed in many, many languages
- lots of Unix/Linux experience, sm amount Win experience
- lots of web programming experience (since 1995)
- been using PHP for 5 years or so
- small amount of Groovy experience, smaller anmount of Java experience
- no Tomcat (etc.) experience
- I run a non-profit.  I am the IT shop.  I only have to convince myself.

I have been working with Grails (on Tomcat) for about 2 months now.
Frankly, it's been hell, but the promise is so great that I have
persevered.  But I feel like I've now reached the breaking point & am
seriously considering bailing & looking for another framework.

There have been, of course, the usual learning curve problems (Tomcat,
Java, Groovy), which I expected.  The problems that are causing me
such distress are two-fold:

1) debugging
2) Instability

Debugging is painful for several reasons:
- turnaround time is way too long (compile, package, deploy, restart
Tomcat [sometimes])
- largely-meaningless stack traces.  Ok, some of this is my
inexperience, but I'm sure anyone would admit that the exceptions are
often very obscure, given the behind-the-scenes Grails magic)
- I have got debugging in Eclipse working, but it's pretty much
useless because of all the overhead imposed by Grails.  I spent 1/2
hour looking for a variable value & finally gave up).

As far as instability goes, I have not yet been able to get a stable
development environment set up.  I have environments on a Linux box
(testing, sometimes dev) & two PCs (development).  I often have to
restart Tomcat & sometimes have to redeploy the WAR.

Small changes in code seem to cause large changes in deployment,
reloading, etc.  For example, I recently made a small change to the
templates I use to render a page & I now find that I have to restart
Tomcat now when I deploy (something about "BeanFactory not
initialized...").

So, enough ranting, I have some questions for the crowd:

1) Is there any way to significantly minimize turnaround time? Or is
this just a fact of life in this environment?
2) Is there a good guide for setting up useful debugging available?
Or is this also just going to be painful?

Any help appreciated.  I really want to use Grails, but I'm spending
way too much time on non-programmatic issues.

Thanks for listening.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

---------------------------------------------------------------------
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





Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

xmly
In reply to this post by Joshua Kehn
Which container is best, tomcat 6 or 7, glassfish, jitty or spring tc server?


On Mon, Feb 14, 2011 at 12:15 PM, Joshua Kehn <[hidden email]> wrote:
I'm not sure what you're doing wrong, but I haven't ever had to restart the container because of a deployment. If anything I much prefer using Tomcat and WAR's for deployment compared to PHP because everything is packaged up and deployable. 

Debugging time can be minimized using strategic testing. I won't claim the stacktraces are pretty - they never are. I traditionally use TextMate and/or VIM for coding, no IDE support here. Have you considered a different approach to debugging? I have never found myself needing to use a dedicated debugger.

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:04 PM, Jonathan Rosenberg wrote:

I've been reading the thread on Grails adoption with great interest,
as I am considering adopting it for my own needs.  I'd like to give my
own hands-on point of view & also ask for some help/advice.

My background in a nutshell:
- CS background (CS PhD in 1987)
- programmed in many, many languages
- lots of Unix/Linux experience, sm amount Win experience
- lots of web programming experience (since 1995)
- been using PHP for 5 years or so
- small amount of Groovy experience, smaller anmount of Java experience
- no Tomcat (etc.) experience
- I run a non-profit.  I am the IT shop.  I only have to convince myself.

I have been working with Grails (on Tomcat) for about 2 months now.
Frankly, it's been hell, but the promise is so great that I have
persevered.  But I feel like I've now reached the breaking point & am
seriously considering bailing & looking for another framework.

There have been, of course, the usual learning curve problems (Tomcat,
Java, Groovy), which I expected.  The problems that are causing me
such distress are two-fold:

1) debugging
2) Instability

Debugging is painful for several reasons:
- turnaround time is way too long (compile, package, deploy, restart
Tomcat [sometimes])
- largely-meaningless stack traces.  Ok, some of this is my
inexperience, but I'm sure anyone would admit that the exceptions are
often very obscure, given the behind-the-scenes Grails magic)
- I have got debugging in Eclipse working, but it's pretty much
useless because of all the overhead imposed by Grails.  I spent 1/2
hour looking for a variable value & finally gave up).

As far as instability goes, I have not yet been able to get a stable
development environment set up.  I have environments on a Linux box
(testing, sometimes dev) & two PCs (development).  I often have to
restart Tomcat & sometimes have to redeploy the WAR.

Small changes in code seem to cause large changes in deployment,
reloading, etc.  For example, I recently made a small change to the
templates I use to render a page & I now find that I have to restart
Tomcat now when I deploy (something about "BeanFactory not
initialized...").

So, enough ranting, I have some questions for the crowd:

1) Is there any way to significantly minimize turnaround time? Or is
this just a fact of life in this environment?
2) Is there a good guide for setting up useful debugging available?
Or is this also just going to be painful?

Any help appreciated.  I really want to use Grails, but I'm spending
way too much time on non-programmatic issues.

Thanks for listening.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

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

   http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Jonathan Rosenberg
In reply to this post by Roshan Dawrani
I very much appreciate the prompt replies.  I have some followup;

Your message says "Tomcat is built into the framework ...".  I thought
that run-app uses an embedded jetty server?

Someone else said

     Debugging a grails app is a piece of cake with STS IDE.

Gald to hear it.  Does this depend on using the embedded jetty server?

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/


On Mon, Feb 14, 2011 at 12:21 PM, Roshan Dawrani
<[hidden email]> wrote:

> Debugging a grails app is a piece of cake with STS IDE...
>
> On Mon, Feb 14, 2011 at 10:47 PM, Joshua Kehn <[hidden email]> wrote:
>>
>> I was assuming issues with actual deployment in Tomcat, not debugging the
>> application under Tomcat. If you are developing / debugging under Tomcat
>> then I would say you should instead be using `grails run-app` instead for
>> the exact reasons Scott mentions.
>> Regards,
>> -Josh
>> ____________________________________
>> Joshua Kehn | [hidden email]
>> http://joshuakehn.com
>> On Feb 14, 2011, at 12:13 PM, Scott Ryan wrote:
>>
>> Why are you redeploying etc. If you just use grails run-app you can do
>> your development and the application will interpret the changes and they
>> will be immediately visible without any build and deploy.  Tomcat is built
>> into the framework so running grails run-app will start your application
>> inside tomcat.  it seems like you are experiencing what a lot of us in the
>> J2EE arena experienced years ago and that is why grails is such a
>> productivity win.   The stacktraces are a little verbose but experience in
>> java and groovy will make that more bearable.  What IDE do you use for your
>> development?  If you use Intellij or Spring STS the debugger is very easy to
>> use.  I am sorry you had such a bad experience so far but it sounds like for
>> some reason you were pointed down a bad path to begin with.  i hope you will
>> keep with it and use this list and other tutorials to help make your
>> experience a much better one.
>>
>> Scott Ryan
>> On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:
>>
>> I've been reading the thread on Grails adoption with great interest,
>>
>> as I am considering adopting it for my own needs.  I'd like to give my
>>
>> own hands-on point of view & also ask for some help/advice.
>>
>> My background in a nutshell:
>>
>> - CS background (CS PhD in 1987)
>>
>> - programmed in many, many languages
>>
>> - lots of Unix/Linux experience, sm amount Win experience
>>
>> - lots of web programming experience (since 1995)
>>
>> - been using PHP for 5 years or so
>>
>> - small amount of Groovy experience, smaller anmount of Java experience
>>
>> - no Tomcat (etc.) experience
>>
>> - I run a non-profit.  I am the IT shop.  I only have to convince myself.
>>
>> I have been working with Grails (on Tomcat) for about 2 months now.
>>
>> Frankly, it's been hell, but the promise is so great that I have
>>
>> persevered.  But I feel like I've now reached the breaking point & am
>>
>> seriously considering bailing & looking for another framework.
>>
>> There have been, of course, the usual learning curve problems (Tomcat,
>>
>> Java, Groovy), which I expected.  The problems that are causing me
>>
>> such distress are two-fold:
>>
>> 1) debugging
>>
>> 2) Instability
>>
>> Debugging is painful for several reasons:
>>
>> - turnaround time is way too long (compile, package, deploy, restart
>>
>> Tomcat [sometimes])
>>
>> - largely-meaningless stack traces.  Ok, some of this is my
>>
>> inexperience, but I'm sure anyone would admit that the exceptions are
>>
>> often very obscure, given the behind-the-scenes Grails magic)
>>
>> - I have got debugging in Eclipse working, but it's pretty much
>>
>> useless because of all the overhead imposed by Grails.  I spent 1/2
>>
>> hour looking for a variable value & finally gave up).
>>
>> As far as instability goes, I have not yet been able to get a stable
>>
>> development environment set up.  I have environments on a Linux box
>>
>> (testing, sometimes dev) & two PCs (development).  I often have to
>>
>> restart Tomcat & sometimes have to redeploy the WAR.
>>
>> Small changes in code seem to cause large changes in deployment,
>>
>> reloading, etc.  For example, I recently made a small change to the
>>
>> templates I use to render a page & I now find that I have to restart
>>
>> Tomcat now when I deploy (something about "BeanFactory not
>>
>> initialized...").
>>
>> So, enough ranting, I have some questions for the crowd:
>>
>> 1) Is there any way to significantly minimize turnaround time? Or is
>>
>> this just a fact of life in this environment?
>>
>> 2) Is there a good guide for setting up useful debugging available?
>>
>> Or is this also just going to be painful?
>>
>> Any help appreciated.  I really want to use Grails, but I'm spending
>>
>> way too much time on non-programmatic issues.
>>
>> Thanks for listening.
>>
>> --
>>
>> Jonathan Rosenberg
>>
>> Founder & Executive Director
>>
>> Tabby's Place, a Cat Sanctuary
>>
>> http://www.tabbysplace.org/
>>
>> ---------------------------------------------------------------------
>>
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Joshua Kehn
In reply to this post by xmly
I wouldn't claim any of them are "best."

I have been using Tomcat 6 for most things. I will be looking at T7 now that they have released it as stable. It depends on what you're doing. Why use nginx over Apache?  New, speed, etc. Why use Apache over nginx? Features, stability, etc. There is no ubiquitous "best" though some are certainly better then others for certain tasks. 

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:32 PM, Gavin Yue wrote:

Which container is best, tomcat 6 or 7, glassfish, jitty or spring tc server?


On Mon, Feb 14, 2011 at 12:15 PM, Joshua Kehn <[hidden email]> wrote:
I'm not sure what you're doing wrong, but I haven't ever had to restart the container because of a deployment. If anything I much prefer using Tomcat and WAR's for deployment compared to PHP because everything is packaged up and deployable. 

Debugging time can be minimized using strategic testing. I won't claim the stacktraces are pretty - they never are. I traditionally use TextMate and/or VIM for coding, no IDE support here. Have you considered a different approach to debugging? I have never found myself needing to use a dedicated debugger.

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 12:04 PM, Jonathan Rosenberg wrote:

I've been reading the thread on Grails adoption with great interest,
as I am considering adopting it for my own needs.  I'd like to give my
own hands-on point of view & also ask for some help/advice.

My background in a nutshell:
- CS background (CS PhD in 1987)
- programmed in many, many languages
- lots of Unix/Linux experience, sm amount Win experience
- lots of web programming experience (since 1995)
- been using PHP for 5 years or so
- small amount of Groovy experience, smaller anmount of Java experience
- no Tomcat (etc.) experience
- I run a non-profit.  I am the IT shop.  I only have to convince myself.

I have been working with Grails (on Tomcat) for about 2 months now.
Frankly, it's been hell, but the promise is so great that I have
persevered.  But I feel like I've now reached the breaking point & am
seriously considering bailing & looking for another framework.

There have been, of course, the usual learning curve problems (Tomcat,
Java, Groovy), which I expected.  The problems that are causing me
such distress are two-fold:

1) debugging
2) Instability

Debugging is painful for several reasons:
- turnaround time is way too long (compile, package, deploy, restart
Tomcat [sometimes])
- largely-meaningless stack traces.  Ok, some of this is my
inexperience, but I'm sure anyone would admit that the exceptions are
often very obscure, given the behind-the-scenes Grails magic)
- I have got debugging in Eclipse working, but it's pretty much
useless because of all the overhead imposed by Grails.  I spent 1/2
hour looking for a variable value & finally gave up).

As far as instability goes, I have not yet been able to get a stable
development environment set up.  I have environments on a Linux box
(testing, sometimes dev) & two PCs (development).  I often have to
restart Tomcat & sometimes have to redeploy the WAR.

Small changes in code seem to cause large changes in deployment,
reloading, etc.  For example, I recently made a small change to the
templates I use to render a page & I now find that I have to restart
Tomcat now when I deploy (something about "BeanFactory not
initialized...").

So, enough ranting, I have some questions for the crowd:

1) Is there any way to significantly minimize turnaround time? Or is
this just a fact of life in this environment?
2) Is there a good guide for setting up useful debugging available?
Or is this also just going to be painful?

Any help appreciated.  I really want to use Grails, but I'm spending
way too much time on non-programmatic issues.

Thanks for listening.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

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

   http://xircles.codehaus.org/manage_email





Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

burtbeckwith
In reply to this post by Jonathan Rosenberg
Jetty was the default server but was switched to Tomcat in 1.2.

Burt

> I very much appreciate the prompt replies.  I have some followup;
>
> Your message says "Tomcat is built into the framework ...".  I thought
> that run-app uses an embedded jetty server?
>
> Someone else said
>
>      Debugging a grails app is a piece of cake with STS IDE.
>
> Gald to hear it.  Does this depend on using the embedded jetty server?
>
> --
> Jonathan Rosenberg
> Founder & Executive Director
> Tabby's Place, a Cat Sanctuary
> http://www.tabbysplace.org/
>
>
> On Mon, Feb 14, 2011 at 12:21 PM, Roshan Dawrani
> <[hidden email]> wrote:
> > Debugging a grails app is a piece of cake with STS IDE...
> >
> > On Mon, Feb 14, 2011 at 10:47 PM, Joshua Kehn <[hidden email]> wrote:
> >>
> >> I was assuming issues with actual deployment in Tomcat, not debugging the
> >> application under Tomcat. If you are developing / debugging under Tomcat
> >> then I would say you should instead be using `grails run-app` instead for
> >> the exact reasons Scott mentions.
> >> Regards,
> >> -Josh
> >> ____________________________________
> >> Joshua Kehn | [hidden email]
> >> http://joshuakehn.com
> >> On Feb 14, 2011, at 12:13 PM, Scott Ryan wrote:
> >>
> >> Why are you redeploying etc. If you just use grails run-app you can do
> >> your development and the application will interpret the changes and they
> >> will be immediately visible without any build and deploy.  Tomcat is built
> >> into the framework so running grails run-app will start your application
> >> inside tomcat.  it seems like you are experiencing what a lot of us in the
> >> J2EE arena experienced years ago and that is why grails is such a
> >> productivity win.   The stacktraces are a little verbose but experience in
> >> java and groovy will make that more bearable.  What IDE do you use for your
> >> development?  If you use Intellij or Spring STS the debugger is very easy to
> >> use.  I am sorry you had such a bad experience so far but it sounds like for
> >> some reason you were pointed down a bad path to begin with.  i hope you will
> >> keep with it and use this list and other tutorials to help make your
> >> experience a much better one.
> >>
> >> Scott Ryan
> >> On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:
> >>
> >> I've been reading the thread on Grails adoption with great interest,
> >>
> >> as I am considering adopting it for my own needs.  I'd like to give my
> >>
> >> own hands-on point of view & also ask for some help/advice.
> >>
> >> My background in a nutshell:
> >>
> >> - CS background (CS PhD in 1987)
> >>
> >> - programmed in many, many languages
> >>
> >> - lots of Unix/Linux experience, sm amount Win experience
> >>
> >> - lots of web programming experience (since 1995)
> >>
> >> - been using PHP for 5 years or so
> >>
> >> - small amount of Groovy experience, smaller anmount of Java experience
> >>
> >> - no Tomcat (etc.) experience
> >>
> >> - I run a non-profit.  I am the IT shop.  I only have to convince myself.
> >>
> >> I have been working with Grails (on Tomcat) for about 2 months now.
> >>
> >> Frankly, it's been hell, but the promise is so great that I have
> >>
> >> persevered.  But I feel like I've now reached the breaking point & am
> >>
> >> seriously considering bailing & looking for another framework.
> >>
> >> There have been, of course, the usual learning curve problems (Tomcat,
> >>
> >> Java, Groovy), which I expected.  The problems that are causing me
> >>
> >> such distress are two-fold:
> >>
> >> 1) debugging
> >>
> >> 2) Instability
> >>
> >> Debugging is painful for several reasons:
> >>
> >> - turnaround time is way too long (compile, package, deploy, restart
> >>
> >> Tomcat [sometimes])
> >>
> >> - largely-meaningless stack traces.  Ok, some of this is my
> >>
> >> inexperience, but I'm sure anyone would admit that the exceptions are
> >>
> >> often very obscure, given the behind-the-scenes Grails magic)
> >>
> >> - I have got debugging in Eclipse working, but it's pretty much
> >>
> >> useless because of all the overhead imposed by Grails.  I spent 1/2
> >>
> >> hour looking for a variable value & finally gave up).
> >>
> >> As far as instability goes, I have not yet been able to get a stable
> >>
> >> development environment set up.  I have environments on a Linux box
> >>
> >> (testing, sometimes dev) & two PCs (development).  I often have to
> >>
> >> restart Tomcat & sometimes have to redeploy the WAR.
> >>
> >> Small changes in code seem to cause large changes in deployment,
> >>
> >> reloading, etc.  For example, I recently made a small change to the
> >>
> >> templates I use to render a page & I now find that I have to restart
> >>
> >> Tomcat now when I deploy (something about "BeanFactory not
> >>
> >> initialized...").
> >>
> >> So, enough ranting, I have some questions for the crowd:
> >>
> >> 1) Is there any way to significantly minimize turnaround time? Or is
> >>
> >> this just a fact of life in this environment?
> >>
> >> 2) Is there a good guide for setting up useful debugging available?
> >>
> >> Or is this also just going to be painful?
> >>
> >> Any help appreciated.  I really want to use Grails, but I'm spending
> >>
> >> way too much time on non-programmatic issues.
> >>
> >> Thanks for listening.
> >>
> >> --
> >>
> >> Jonathan Rosenberg
> >>
> >> Founder & Executive Director
> >>
> >> Tabby's Place, a Cat Sanctuary
> >>
> >> http://www.tabbysplace.org/
> >>
> >> ---------------------------------------------------------------------
> >>
> >> 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


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Ian Roberts
In reply to this post by Jonathan Rosenberg
On 14/02/2011 17:35, Jonathan Rosenberg wrote:
> I very much appreciate the prompt replies.  I have some followup;
>
> Your message says "Tomcat is built into the framework ...".  I thought
> that run-app uses an embedded jetty server?

The run-app command can use either, but uses Tomcat by default (to
switch you uninstall-plugin tomcat and install-plugin jetty).

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

John Fletcher-3
In reply to this post by Jonathan Rosenberg
Was Jetty but when Springsource bought G2One (Grails) it was replaced with Tomcat, I guess because that's the app server they support. You can change it back by uninstalling/installing the related plugins, but don't unless you need to because it makes little difference for the basic user.
 
If you're using STS with Grails installed into STS, you can probably debug in one click. But I use a Grails install which is separate from the IDE, in which case debugging goes like this:
run: grails-debug run-app
 
STS:
Click on the dropdown next to the bug icon - debug configurations...
Create a new configuration for Remote Java Application
project: <your project>
host: localhost
port: 5005
the rest default and it should work...
 
John
 
2011/2/14 Jonathan Rosenberg <[hidden email]>
I very much appreciate the prompt replies.  I have some followup;

Your message says "Tomcat is built into the framework ...".  I thought
that run-app uses an embedded jetty server?

Someone else said

    Debugging a grails app is a piece of cake with STS IDE.

Gald to hear it.  Does this depend on using the embedded jetty server?

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/


On Mon, Feb 14, 2011 at 12:21 PM, Roshan Dawrani
<[hidden email]> wrote:
> Debugging a grails app is a piece of cake with STS IDE...
>
> On Mon, Feb 14, 2011 at 10:47 PM, Joshua Kehn <[hidden email]> wrote:
>>
>> I was assuming issues with actual deployment in Tomcat, not debugging the
>> application under Tomcat. If you are developing / debugging under Tomcat
>> then I would say you should instead be using `grails run-app` instead for
>> the exact reasons Scott mentions.
>> Regards,
>> -Josh
>> ____________________________________
>> Joshua Kehn | [hidden email]
>> http://joshuakehn.com
>> On Feb 14, 2011, at 12:13 PM, Scott Ryan wrote:
>>
>> Why are you redeploying etc. If you just use grails run-app you can do
>> your development and the application will interpret the changes and they
>> will be immediately visible without any build and deploy.  Tomcat is built
>> into the framework so running grails run-app will start your application
>> inside tomcat.  it seems like you are experiencing what a lot of us in the
>> J2EE arena experienced years ago and that is why grails is such a
>> productivity win.   The stacktraces are a little verbose but experience in
>> java and groovy will make that more bearable.  What IDE do you use for your
>> development?  If you use Intellij or Spring STS the debugger is very easy to
>> use.  I am sorry you had such a bad experience so far but it sounds like for
>> some reason you were pointed down a bad path to begin with.  i hope you will
>> keep with it and use this list and other tutorials to help make your
>> experience a much better one.
>>
>> Scott Ryan
>> On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:
>>
>> I've been reading the thread on Grails adoption with great interest,
>>
>> as I am considering adopting it for my own needs.  I'd like to give my
>>
>> own hands-on point of view & also ask for some help/advice.
>>
>> My background in a nutshell:
>>
>> - CS background (CS PhD in 1987)
>>
>> - programmed in many, many languages
>>
>> - lots of Unix/Linux experience, sm amount Win experience
>>
>> - lots of web programming experience (since 1995)
>>
>> - been using PHP for 5 years or so
>>
>> - small amount of Groovy experience, smaller anmount of Java experience
>>
>> - no Tomcat (etc.) experience
>>
>> - I run a non-profit.  I am the IT shop.  I only have to convince myself.
>>
>> I have been working with Grails (on Tomcat) for about 2 months now.
>>
>> Frankly, it's been hell, but the promise is so great that I have
>>
>> persevered.  But I feel like I've now reached the breaking point & am
>>
>> seriously considering bailing & looking for another framework.
>>
>> There have been, of course, the usual learning curve problems (Tomcat,
>>
>> Java, Groovy), which I expected.  The problems that are causing me
>>
>> such distress are two-fold:
>>
>> 1) debugging
>>
>> 2) Instability
>>
>> Debugging is painful for several reasons:
>>
>> - turnaround time is way too long (compile, package, deploy, restart
>>
>> Tomcat [sometimes])
>>
>> - largely-meaningless stack traces.  Ok, some of this is my
>>
>> inexperience, but I'm sure anyone would admit that the exceptions are
>>
>> often very obscure, given the behind-the-scenes Grails magic)
>>
>> - I have got debugging in Eclipse working, but it's pretty much
>>
>> useless because of all the overhead imposed by Grails.  I spent 1/2
>>
>> hour looking for a variable value & finally gave up).
>>
>> As far as instability goes, I have not yet been able to get a stable
>>
>> development environment set up.  I have environments on a Linux box
>>
>> (testing, sometimes dev) & two PCs (development).  I often have to
>>
>> restart Tomcat & sometimes have to redeploy the WAR.
>>
>> Small changes in code seem to cause large changes in deployment,
>>
>> reloading, etc.  For example, I recently made a small change to the
>>
>> templates I use to render a page & I now find that I have to restart
>>
>> Tomcat now when I deploy (something about "BeanFactory not
>>
>> initialized...").
>>
>> So, enough ranting, I have some questions for the crowd:
>>
>> 1) Is there any way to significantly minimize turnaround time? Or is
>>
>> this just a fact of life in this environment?
>>
>> 2) Is there a good guide for setting up useful debugging available?
>>
>> Or is this also just going to be painful?
>>
>> Any help appreciated.  I really want to use Grails, but I'm spending
>>
>> way too much time on non-programmatic issues.
>>
>> Thanks for listening.
>>
>> --
>>
>> Jonathan Rosenberg
>>
>> Founder & Executive Director
>>
>> Tabby's Place, a Cat Sanctuary
>>
>> http://www.tabbysplace.org/
>>
>> ---------------------------------------------------------------------
>>
>> 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



Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Roshan Dawrani
In reply to this post by Jonathan Rosenberg
On Mon, Feb 14, 2011 at 11:05 PM, Jonathan Rosenberg <[hidden email]> wrote:

Someone else said

    Debugging a grails app is a piece of cake with STS IDE.

Gald to hear it.  Does this depend on using the embedded jetty server?

No, it's just plain-old java debugging. If you do "grails-debug run-app", it will start in debug mode and you can attach the STS debugger at that port and step through things.

If you are deploying in some other web server, you can set the JAVA_OPTS accordingly and start the server in debug mode, and do the same.

Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Jonathan Rosenberg
In reply to this post by burtbeckwith
I see a have a whole lot to learn, so I hope I don;t tire everyone out
with my questions.

Regarding the embedded server.  Does Grails use its "own" Tomcat
server?  I assume it's not somehow finding my server config & using
that?  Can I mess with the embedded Tomcat config?

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/


On Mon, Feb 14, 2011 at 12:41 PM, Burt Beckwith <[hidden email]> wrote:

> Jetty was the default server but was switched to Tomcat in 1.2.
>
> Burt
>
>> I very much appreciate the prompt replies.  I have some followup;
>>
>> Your message says "Tomcat is built into the framework ...".  I thought
>> that run-app uses an embedded jetty server?
>>
>> Someone else said
>>
>>      Debugging a grails app is a piece of cake with STS IDE.
>>
>> Gald to hear it.  Does this depend on using the embedded jetty server?
>>
>> --
>> Jonathan Rosenberg
>> Founder & Executive Director
>> Tabby's Place, a Cat Sanctuary
>> http://www.tabbysplace.org/
>>
>>
>> On Mon, Feb 14, 2011 at 12:21 PM, Roshan Dawrani
>> <[hidden email]> wrote:
>> > Debugging a grails app is a piece of cake with STS IDE...
>> >
>> > On Mon, Feb 14, 2011 at 10:47 PM, Joshua Kehn <[hidden email]> wrote:
>> >>
>> >> I was assuming issues with actual deployment in Tomcat, not debugging the
>> >> application under Tomcat. If you are developing / debugging under Tomcat
>> >> then I would say you should instead be using `grails run-app` instead for
>> >> the exact reasons Scott mentions.
>> >> Regards,
>> >> -Josh
>> >> ____________________________________
>> >> Joshua Kehn | [hidden email]
>> >> http://joshuakehn.com
>> >> On Feb 14, 2011, at 12:13 PM, Scott Ryan wrote:
>> >>
>> >> Why are you redeploying etc. If you just use grails run-app you can do
>> >> your development and the application will interpret the changes and they
>> >> will be immediately visible without any build and deploy.  Tomcat is built
>> >> into the framework so running grails run-app will start your application
>> >> inside tomcat.  it seems like you are experiencing what a lot of us in the
>> >> J2EE arena experienced years ago and that is why grails is such a
>> >> productivity win.   The stacktraces are a little verbose but experience in
>> >> java and groovy will make that more bearable.  What IDE do you use for your
>> >> development?  If you use Intellij or Spring STS the debugger is very easy to
>> >> use.  I am sorry you had such a bad experience so far but it sounds like for
>> >> some reason you were pointed down a bad path to begin with.  i hope you will
>> >> keep with it and use this list and other tutorials to help make your
>> >> experience a much better one.
>> >>
>> >> Scott Ryan
>> >> On Feb 14, 2011, at 10:04 AM, Jonathan Rosenberg wrote:
>> >>
>> >> I've been reading the thread on Grails adoption with great interest,
>> >>
>> >> as I am considering adopting it for my own needs.  I'd like to give my
>> >>
>> >> own hands-on point of view & also ask for some help/advice.
>> >>
>> >> My background in a nutshell:
>> >>
>> >> - CS background (CS PhD in 1987)
>> >>
>> >> - programmed in many, many languages
>> >>
>> >> - lots of Unix/Linux experience, sm amount Win experience
>> >>
>> >> - lots of web programming experience (since 1995)
>> >>
>> >> - been using PHP for 5 years or so
>> >>
>> >> - small amount of Groovy experience, smaller anmount of Java experience
>> >>
>> >> - no Tomcat (etc.) experience
>> >>
>> >> - I run a non-profit.  I am the IT shop.  I only have to convince myself.
>> >>
>> >> I have been working with Grails (on Tomcat) for about 2 months now.
>> >>
>> >> Frankly, it's been hell, but the promise is so great that I have
>> >>
>> >> persevered.  But I feel like I've now reached the breaking point & am
>> >>
>> >> seriously considering bailing & looking for another framework.
>> >>
>> >> There have been, of course, the usual learning curve problems (Tomcat,
>> >>
>> >> Java, Groovy), which I expected.  The problems that are causing me
>> >>
>> >> such distress are two-fold:
>> >>
>> >> 1) debugging
>> >>
>> >> 2) Instability
>> >>
>> >> Debugging is painful for several reasons:
>> >>
>> >> - turnaround time is way too long (compile, package, deploy, restart
>> >>
>> >> Tomcat [sometimes])
>> >>
>> >> - largely-meaningless stack traces.  Ok, some of this is my
>> >>
>> >> inexperience, but I'm sure anyone would admit that the exceptions are
>> >>
>> >> often very obscure, given the behind-the-scenes Grails magic)
>> >>
>> >> - I have got debugging in Eclipse working, but it's pretty much
>> >>
>> >> useless because of all the overhead imposed by Grails.  I spent 1/2
>> >>
>> >> hour looking for a variable value & finally gave up).
>> >>
>> >> As far as instability goes, I have not yet been able to get a stable
>> >>
>> >> development environment set up.  I have environments on a Linux box
>> >>
>> >> (testing, sometimes dev) & two PCs (development).  I often have to
>> >>
>> >> restart Tomcat & sometimes have to redeploy the WAR.
>> >>
>> >> Small changes in code seem to cause large changes in deployment,
>> >>
>> >> reloading, etc.  For example, I recently made a small change to the
>> >>
>> >> templates I use to render a page & I now find that I have to restart
>> >>
>> >> Tomcat now when I deploy (something about "BeanFactory not
>> >>
>> >> initialized...").
>> >>
>> >> So, enough ranting, I have some questions for the crowd:
>> >>
>> >> 1) Is there any way to significantly minimize turnaround time? Or is
>> >>
>> >> this just a fact of life in this environment?
>> >>
>> >> 2) Is there a good guide for setting up useful debugging available?
>> >>
>> >> Or is this also just going to be painful?
>> >>
>> >> Any help appreciated.  I really want to use Grails, but I'm spending
>> >>
>> >> way too much time on non-programmatic issues.
>> >>
>> >> Thanks for listening.
>> >>
>> >> --
>> >>
>> >> Jonathan Rosenberg
>> >>
>> >> Founder & Executive Director
>> >>
>> >> Tabby's Place, a Cat Sanctuary
>> >>
>> >> http://www.tabbysplace.org/
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

pledbrook
> Regarding the embedded server.  Does Grails use its "own" Tomcat
> server?  I assume it's not somehow finding my server config & using
> that?  Can I mess with the embedded Tomcat config?

Yes. The Tomcat server is provided in the Tomcat plugin (which is
installed by default). Yes, you can mess with the embedded Tomcat
config, but it's not well documented at the moment. Hopefully someone
has an example they can share, but you basically create a
scripts/_Events.groovy file and add something like:

  eventConfigureTomcat = { tomcat ->
      tomcat.connector....
  }

The 'tomcat' variable is an instance of Tomcat (
http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/startup/Tomcat.html
) if I remember correctly.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

baldurian
In reply to this post by Jonathan Rosenberg

About debugging... I really would love to have something as 'simple' as ruby-debug (classic GDB?).
Be able to put a breakpoint somewhere in my code and continue from there. Netbeans and STS are really really slow, at least in my environment are unusable for debugging. (I have a quite decent machine)
I would only want to stop somewhere, check variables and possibly execute querys. No fancy UI is needed, execute and have the result, lightning fast, no deep evaluation, toString's and things that IDE's do.
I am used now to work this way in my job and every time I have to fallback to log.debug I cry.

Regards,
David
Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Jonathan Rosenberg
So, this has all been pretty useful so for.  I'm now able to deploy
quickly & set breakpoints.

But how in heck does one find a Groovy/Grails variable to inspect?  I
want to look at params, but can't seem to find it under "this" or
"it".  Is there some trick to looking at variables?  or is it just
gonna be this ugly?

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/


On Mon, Feb 14, 2011 at 1:15 PM, David <[hidden email]> wrote:

>
> About debugging... I really would love to have something as 'simple' as
> ruby-debug (classic GDB?).
> Be able to put a breakpoint somewhere in my code and continue from there.
> Netbeans and STS are really really slow, at least in my environment are
> unusable for debugging. (I have a quite decent machine)
> I would only want to stop somewhere, check variables and possibly execute
> querys. No fancy UI is needed, execute and have the result, lightning fast,
> no deep evaluation, toString's and things that IDE's do.
> I am used now to work this way in my job and every time I have to fallback
> to log.debug I cry.
>
> Regards,
> David
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

burtbeckwith
'params' is added to the MetaClass, so it's not directly accessible. For older versions of STS I'd add a line 'def p = params' or 'def r = request' to give the debugger a strong reference that I could work with.

Newer versions of the Groovy-Eclipse plugin let you create an Expression that references metaclass-added stuff like this and you can work with the variables as if they're 'really there'.

Burt

> So, this has all been pretty useful so for.  I'm now able to deploy
> quickly & set breakpoints.
>
> But how in heck does one find a Groovy/Grails variable to inspect?  I
> want to look at params, but can't seem to find it under "this" or
> "it".  Is there some trick to looking at variables?  or is it just
> gonna be this ugly?
>
> --
> Jonathan Rosenberg
> Founder & Executive Director
> Tabby's Place, a Cat Sanctuary
> http://www.tabbysplace.org/
 

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Adoption Hell: My Point of View

Joshua Kehn
In reply to this post by Jonathan Rosenberg
HTTP paramaters are available under the "params" object. You can see posted parameters using something like Firebug. Unless you are talking about something else, in which case I would clarify your question a bit. 

Regards,

-Josh
____________________________________
Joshua Kehn | [hidden email]
http://joshuakehn.com

On Feb 14, 2011, at 1:57 PM, Jonathan Rosenberg wrote:

So, this has all been pretty useful so for.  I'm now able to deploy
quickly & set breakpoints.

But how in heck does one find a Groovy/Grails variable to inspect?  I
want to look at params, but can't seem to find it under "this" or
"it".  Is there some trick to looking at variables?  or is it just
gonna be this ugly?

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/


On Mon, Feb 14, 2011 at 1:15 PM, David <[hidden email]> wrote:

About debugging... I really would love to have something as 'simple' as
ruby-debug (classic GDB?).
Be able to put a breakpoint somewhere in my code and continue from there.
Netbeans and STS are really really slow, at least in my environment are
unusable for debugging. (I have a quite decent machine)
I would only want to stop somewhere, check variables and possibly execute
querys. No fancy UI is needed, execute and have the result, lightning fast,
no deep evaluation, toString's and things that IDE's do.
I am used now to work this way in my job and every time I have to fallback
to log.debug I cry.

Regards,
David


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

   http://xircles.codehaus.org/manage_email



123