Production and Development logistics slightly worse in 0.6?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Production and Development logistics slightly worse in 0.6?

Brian Huddleston-2
<This was originally part of the thread on the new groovyc compiler goodness, it just happened to be the first time I noticed that 0.6 was going to consolidate the various datasource files.>
 
 
Hmmm these does seem to be a good reason not to "just use a JNDI datasource in production" as per Alex's suggestion.  I was sitting down to do just that for our latest release.  It doesn't look like you *can* have a "production" JNDI datasource.  If I'm reading things right ( http://grails.codehaus.org/JNDI+Data+Sources), the only way to do JNDI is to completely replace dataSource.  So production is now JNDI, but so is Test and Dev.
 
It looks like I am worse predicament.  Before, I could just keep ProductionDataSource out of SVN and still have a setup where new devs could "svn co MyProject" and get going.
 
I can't keep resources.xml out of svn.
 
A couple of questions stemming from that:
 
Anyone have any suggestions on a reasonable workaround? 
 
Any thought about adding the capability to DataSource.groovy to specify that a given datasource comes from JNDI?  Something like:
production {
   dataSource {
       jndi {
             name="jdbc/productionds"
       }
   }
 
Something like that?
 
-Brian
 

 
On 8/16/07, Brian Huddleston <[hidden email]> wrote:
Because there was something goofy with my previous hosting providers Tomcat setup that would reset my JNDI datasources username and password to "root" and "" whenever I would touch anything to do with my Tomcat configuration (deploying/undeploying/etc).  So for about a three month period uploading a new war was like pulling teeth and I would have a stress reaction anytime I would hear the word JNDI.
 
That being said, I've got control of the box at my current hosting provider and using the JNDI is almost certainly the Right Thing To Do.
 
Thanks for the suggestion.  I'll give it a whirl.
 
-Brian

 
On 8/16/07, Alex Shneyderman <[hidden email]> wrote:
> This may be a concern that is specific to us, but I sort of liked having the
> separate files.  From a deployment perspective I would just not add
> ProductionDatasource.groovy into SVN.  My devs are happy as they just use
> test and dev.
>
> This way they are comingled and I have to be careful when doing global
> commits to make sure I'm not checking the production password into SVN. :-)
>
> (Again, I may be the only person on Earth who cares.)

But why not use JNDI bound datasource in production. This way your passwords
will live in your server config.

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

   <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://xircles.codehaus.org/manage_email" target="_blank">http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Production and Development logistics slightly worse in 0.6?

pledbrook
> A couple of questions stemming from that:
>
> Anyone have any suggestions on a reasonable workaround?
>

Off the top of my head, you could try to write a plugin that loads up
before DataSourceGrailsPlugin and HibernateGrailsPlugin. In the
"doWithSpring" enclosure you could then check the current environment
and configure the JNDI datasource accordingly. It's a bit clunky, but
it should work as long as the custom plugin can be forced to load
before the plugins mentioned earlier.

HTH,

Peter

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Production and Development logistics slightly worse in 0.6?

Brian Huddleston-2
Thanks Peter.
 
I've found a work-around for now.  I'm playing with Idea and discovered I can create a Don't Commit changeset and drag DataSource.groovy into it.  This effectively removes the threat of carelessly commiting the production password to SVN.
 
On my second question though: Marc, Graeme (or anyone else that is interested)?  Do you see being able to set your production datasource as JNDI while keeping your Dev and Test datasources their nice and friendly local equivalent as a useful/desirable feature?
 
Ideally I would be able to commit a DataSource.groovy that pointed to a local MySQL instance for Dev and Test and thus be nice and easy for developers while having the production datasource pointing at a JNDI name.
 
Thoughts?
 
-Brian

 
On 9/2/07, Peter Ledbrook <[hidden email]> wrote:
> A couple of questions stemming from that:
>
> Anyone have any suggestions on a reasonable workaround?
>

Off the top of my head, you could try to write a plugin that loads up
before DataSourceGrailsPlugin and HibernateGrailsPlugin. In the
"doWithSpring" enclosure you could then check the current environment
and configure the JNDI datasource accordingly. It's a bit clunky, but
it should work as long as the custom plugin can be forced to load
before the plugins mentioned earlier.

HTH,

Peter

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

   <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://xircles.codehaus.org/manage_email" target="_blank">http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Production and Development logistics slightly worse in 0.6?

peter_m
I could definitely use that functionality.

On 9/4/07, Brian Huddleston <[hidden email]> wrote:

> Thanks Peter.
>
> I've found a work-around for now.  I'm playing with Idea and discovered I
> can create a Don't Commit changeset and drag DataSource.groovy into it.
> This effectively removes the threat of carelessly commiting the production
> password to SVN.
>
> On my second question though: Marc, Graeme (or anyone else that is
> interested)?  Do you see being able to set your production datasource as
> JNDI while keeping your Dev and Test datasources their nice and friendly
> local equivalent as a useful/desirable feature?
>
> Ideally I would be able to commit a DataSource.groovy that pointed to a
> local MySQL instance for Dev and Test and thus be nice and easy for
> developers while having the production datasource pointing at a JNDI name.
>
> Thoughts?
>
> -Brian
>
>
>
> On 9/2/07, Peter Ledbrook <[hidden email] > wrote:
> > > A couple of questions stemming from that:
> > >
> > > Anyone have any suggestions on a reasonable workaround?
> > >
> >
> > Off the top of my head, you could try to write a plugin that loads up
> > before DataSourceGrailsPlugin and HibernateGrailsPlugin. In the
> > "doWithSpring" enclosure you could then check the current environment
> > and configure the JNDI datasource accordingly. It's a bit clunky, but
> > it should work as long as the custom plugin can be forced to load
> > before the plugins mentioned earlier.
> >
> > HTH,
> >
> > Peter
> >
> >
> ---------------------------------------------------------------------
> > 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: Production and Development logistics slightly worse in 0.6?

graemer
Please raise an issue with fix for 1.0-RC1 and we'll see what we can do

Cheers

On 9/4/07, Peter Mondlock <[hidden email]> wrote:

> I could definitely use that functionality.
>
> On 9/4/07, Brian Huddleston <[hidden email]> wrote:
> > Thanks Peter.
> >
> > I've found a work-around for now.  I'm playing with Idea and discovered I
> > can create a Don't Commit changeset and drag DataSource.groovy into it.
> > This effectively removes the threat of carelessly commiting the production
> > password to SVN.
> >
> > On my second question though: Marc, Graeme (or anyone else that is
> > interested)?  Do you see being able to set your production datasource as
> > JNDI while keeping your Dev and Test datasources their nice and friendly
> > local equivalent as a useful/desirable feature?
> >
> > Ideally I would be able to commit a DataSource.groovy that pointed to a
> > local MySQL instance for Dev and Test and thus be nice and easy for
> > developers while having the production datasource pointing at a JNDI name.
> >
> > Thoughts?
> >
> > -Brian
> >
> >
> >
> > On 9/2/07, Peter Ledbrook <[hidden email] > wrote:
> > > > A couple of questions stemming from that:
> > > >
> > > > Anyone have any suggestions on a reasonable workaround?
> > > >
> > >
> > > Off the top of my head, you could try to write a plugin that loads up
> > > before DataSourceGrailsPlugin and HibernateGrailsPlugin. In the
> > > "doWithSpring" enclosure you could then check the current environment
> > > and configure the JNDI datasource accordingly. It's a bit clunky, but
> > > it should work as long as the custom plugin can be forced to load
> > > before the plugins mentioned earlier.
> > >
> > > HTH,
> > >
> > > Peter
> > >
> > >
> > ---------------------------------------------------------------------
> > > 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
Grails Project Lead
http://grails.org

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Production and Development logistics slightly worse in 0.6?

Marc Palmer Local
In reply to this post by Brian Huddleston-2

On 4 Sep 2007, at 20:05, Brian Huddleston wrote:

> Thanks Peter.
>
> I've found a work-around for now.  I'm playing with Idea and  
> discovered I can create a Don't Commit changeset and drag  
> DataSource.groovy into it.  This effectively removes the threat of  
> carelessly commiting the production password to SVN.
>
> On my second question though: Marc, Graeme (or anyone else that is  
> interested)?  Do you see being able to set your production  
> datasource as JNDI while keeping your Dev and Test datasources  
> their nice and friendly local equivalent as a useful/desirable  
> feature?
>
> Ideally I would be able to commit a DataSource.groovy that pointed  
> to a local MySQL instance for Dev and Test and thus be nice and  
> easy for developers while having the production datasource pointing  
> at a JNDI name.
>

I definitely think for the next release we need a "jndiName" property  
that can be set in DataSource.groovy per-environment.

What do other devs think?

Marc


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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Production and Development logistics slightly worse in 0.6?

Sergey Nebolsin

2007/9/5, Marc Palmer <[hidden email]>:

On 4 Sep 2007, at 20:05, Brian Huddleston wrote:

> Thanks Peter.
>
> I've found a work-around for now.  I'm playing with Idea and
> discovered I can create a Don't Commit changeset and drag
> DataSource.groovy into it.  This effectively removes the threat of
> carelessly commiting the production password to SVN.
>
> On my second question though: Marc, Graeme (or anyone else that is
> interested)?  Do you see being able to set your production
> datasource as JNDI while keeping your Dev and Test datasources
> their nice and friendly local equivalent as a useful/desirable
> feature?
>
> Ideally I would be able to commit a DataSource.groovy that pointed
> to a local MySQL instance for Dev and Test and thus be nice and
> easy for developers while having the production datasource pointing
> at a JNDI name.
>

I definitely think for the next release we need a "jndiName" property
that can be set in DataSource.groovy per-environment.

What do other devs think?


I agree.

Cheers

--
Sergey Nebolsin
Reply | Threaded
Open this post in threaded view
|

Re: Production and Development logistics slightly worse in 0.6?

pledbrook
In reply to this post by Marc Palmer Local
> I definitely think for the next release we need a "jndiName" property
> that can be set in DataSource.groovy per-environment.
>
> What do other devs think?
>
> Marc

+1

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Production and Development logistics slightly worse in 0.6?

Steven Devijver
In reply to this post by Marc Palmer Local
On 9/5/07, Marc Palmer <[hidden email]> wrote:

>
> On 4 Sep 2007, at 20:05, Brian Huddleston wrote:
>
> > Thanks Peter.
> >
> > I've found a work-around for now.  I'm playing with Idea and
> > discovered I can create a Don't Commit changeset and drag
> > DataSource.groovy into it.  This effectively removes the threat of
> > carelessly commiting the production password to SVN.
> >
> > On my second question though: Marc, Graeme (or anyone else that is
> > interested)?  Do you see being able to set your production
> > datasource as JNDI while keeping your Dev and Test datasources
> > their nice and friendly local equivalent as a useful/desirable
> > feature?
> >
> > Ideally I would be able to commit a DataSource.groovy that pointed
> > to a local MySQL instance for Dev and Test and thus be nice and
> > easy for developers while having the production datasource pointing
> > at a JNDI name.
> >
>
> I definitely think for the next release we need a "jndiName" property
> that can be set in DataSource.groovy per-environment.
>
> What do other devs think?
>
> Marc
>

I think JNDI data sources aren't the only alternatives to the standard
Grails data sources.

Other scenarios include data sources with custom configuration. So
apart from a "jndiName" property I believe it should also be possible
to override the Grails data source with a custom data source object
coming from the Spring ApplicationContext.

So maybe also provide a "beanName" property?

Steven

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Production and Development logistics slightly worse in 0.6?

Lee Butts
Isn't that already possible by defining a bean named "dataSource" in resources.xml?

cheers

Lee

On 05/09/07, Steven Devijver < [hidden email]> wrote:
On 9/5/07, Marc Palmer < [hidden email]> wrote:

>
> On 4 Sep 2007, at 20:05, Brian Huddleston wrote:
>
> > Thanks Peter.
> >
> > I've found a work-around for now.  I'm playing with Idea and
> > discovered I can create a Don't Commit changeset and drag
> > DataSource.groovy into it.  This effectively removes the threat of
> > carelessly commiting the production password to SVN.
> >
> > On my second question though: Marc, Graeme (or anyone else that is
> > interested)?  Do you see being able to set your production
> > datasource as JNDI while keeping your Dev and Test datasources
> > their nice and friendly local equivalent as a useful/desirable
> > feature?
> >
> > Ideally I would be able to commit a DataSource.groovy that pointed
> > to a local MySQL instance for Dev and Test and thus be nice and
> > easy for developers while having the production datasource pointing
> > at a JNDI name.
> >
>
> I definitely think for the next release we need a "jndiName" property
> that can be set in DataSource.groovy per-environment.
>
> What do other devs think?
>
> Marc
>

I think JNDI data sources aren't the only alternatives to the standard
Grails data sources.

Other scenarios include data sources with custom configuration. So
apart from a "jndiName" property I believe it should also be possible
to override the Grails data source with a custom data source object
coming from the Spring ApplicationContext.

So maybe also provide a "beanName" property?

Steven

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

    http://xircles.codehaus.org/manage_email