Dynamic Injection vs. Inheritance

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

Dynamic Injection vs. Inheritance

Kerry Wilson-3
I do not understand why inheritance is not used throughout the Grails
framework, I know that the current trend is to move away from
inheritance in favor of POJO with attributes/configuration.  I guess
people do not want frameworks structuring their class hierarchy.  But,
do we really want to be able to have a controller that inherits from a
domain object or classes that act as both?  IMO dynamic injection is not
an ideal solution, at least when using inheritance it is apparent in the
code that the class has intrinsic behavior, with DI it is just 'magic'.

Opinions?

--
Kerry Wilson
Lead Developer
Williams Web
[hidden email] | 423.485.4747


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

    http://xircles.codehaus.org/manage_email

kwilson.vcf (292 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Injection vs. Inheritance

graemer
On 6/27/06, Kerry Wilson <[hidden email]> wrote:
> I do not understand why inheritance is not used throughout the Grails
> framework, I know that the current trend is to move away from
> inheritance in favor of POJO with attributes/configuration.  I guess
> people do not want frameworks structuring their class hierarchy.  But,

I'm not sure there is a trend, if there is Grails started it as most
other web frameworks require you to implement some interface or extend
some framework class.

> do we really want to be able to have a controller that inherits from a
> domain object or classes that act as both?  IMO
The above is not possible as far as I know, what I do like about no
inheritance is that there is no framework object dictating how you
strcture your application or that you have to remember to inherit
from.

Combine this with how Grails doesn't do any background configuration
with the command line targets (like Rails does meaning you are reliant
on them) it means you can create objects in Grails without needing to
know much about how to go about it. This will only increase when we
implement the feature to inject properties and boilerplate code into
domain classes.

You will be able to define a domain class like this:

class Book {
}

Thats it, nothing more, how much simpler could that be? A sub class
would then be like this:

class RecipeBook extends Book {
}

This is how apps were meant to be built!


dynamic injection is not
> an ideal solution, at least when using inheritance it is apparent in the
> code that the class has intrinsic behavior, with DI it is just 'magic'.

It is magic, buts its groovy magic ;-)

Having said that I'm not oppose to inheritance for certain
circumstances, for example when we start creating the UI components
for Grails we may have specific controllers that you have to inherit
from the get a component to work like TreeController for a tree wdiget
for example


Graeme

>
> Opinions?
>
> --
> Kerry Wilson
> Lead Developer
> Williams Web
> [hidden email] | 423.485.4747
>
>
>
> ---------------------------------------------------------------------
> 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: Dynamic Injection vs. Inheritance

Kerry Wilson-3
Graeme Rocher wrote:
> On 6/27/06, Kerry Wilson <[hidden email]> wrote:
>> I do not understand why inheritance is not used throughout the Grails
>> framework, I know that the current trend is to move away from
>> inheritance in favor of POJO with attributes/configuration.  I guess
>> people do not want frameworks structuring their class hierarchy.  But,
>
> I'm not sure there is a trend, if there is Grails started it as most
> other web frameworks require you to implement some interface or extend
> some framework class.
It seems like there are more frameworks, articles, and general buzz
around POJO programming now, definitely started with the inclusion of
attributes in Tiger.

>
>> do we really want to be able to have a controller that inherits from a
>> domain object or classes that act as both?  IMO
> The above is not possible as far as I know, what I do like about no
> inheritance is that there is no framework object dictating how you
> strcture your application or that you have to remember to inherit
> from.
Forcing you to put groovy files into a certain directory and named a
certain way so that they will be injected with certain methods is not
dictating the structure of your application?

>
> Combine this with how Grails doesn't do any background configuration
> with the command line targets (like Rails does meaning you are reliant
> on them) it means you can create objects in Grails without needing to
> know much about how to go about it. This will only increase when we
> implement the feature to inject properties and boilerplate code into
> domain classes.
>
> You will be able to define a domain class like this:
>
> class Book {
> }
Inheritance would make this:

class Book extends DomainObject {
}

Below code would be the same.
>
> Thats it, nothing more, how much simpler could that be? A sub class
> would then be like this:
>
> class RecipeBook extends Book {
> }
>
> This is how apps were meant to be built!
I agree that it is nice and the difference between Inheritance and
Injection is really just a 'extends DomainObject' add to the code.
Unless, the framework does not check for the method before it 'injects
it' i.e. ( if( obj.save == null ) obj.save = { } ).
I am not that familiar with the framework yet, does it? ( First question
I would not have had to ask with inheritance )
I am really just talking about domain objects.  I am not sure if any
other 'types' ( For lack of a better way to describe them ) objects are
injected with behavior at runtime or not.  Are they?  ( Question #2 that
would be unnecessary with inheritance )

>
>> dynamic injection is not an ideal solution, at least when using
>> inheritance it is apparent in the
>> code that the class has intrinsic behavior, with DI it is just 'magic'.
>
> It is magic, buts its groovy magic ;-)
>
> Having said that I'm not oppose to inheritance for certain
> circumstances, for example when we start creating the UI components
> for Grails we may have specific controllers that you have to inherit
> from the get a component to work like TreeController for a tree wdiget
> for example
Not trying to say that either is wrong or right, just food for thought
from someone who is trying to learn the Grails framework.  Also, I
realize that dynamic injection is necessary for some stuff, ( i.e. the
FindByXX methods ), and that it may be a bad idea to use Domain
Injection and Inheritance.

>
>
> Graeme
>>
>> Opinions?
>>
>> --
>> Kerry Wilson
>> Lead Developer
>> Williams Web
>> [hidden email] | 423.485.4747
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>

--
Kerry Wilson
Lead Developer
Williams Web
[hidden email] | 423.485.4747


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

    http://xircles.codehaus.org/manage_email

kwilson.vcf (292 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Any luck with the data sources?

Peter Wayner
In reply to this post by Kerry Wilson-3
I've been trying to experiment with putting one of the JDBC calls in a Service object like this:

import java.sql.*;
import javax.sql.*;


class TestService {

def String list(String table) {
     javax.sql.DataSource dataSource
  Connection con=dataSource.getConnection();
  PreparedStatement ps=con.prepareStatement("select * from "+table);
    ResultSet rs = ps.execute()

   

      return ""+table
   }
}

Any ideas of how I can avoid errors like these:



Message: Cannot invoke method getConnection() on null object 
Caused by: java.lang.NullPointerException: Cannot invoke method getConnection() on null object 
Class: CarController 




Reply | Threaded
Open this post in threaded view
|

Re: Any luck with the data sources?

Guillaume Laforge-2
The datasource is injected in the class properties, not in local
variables of the method.

Could you try to put your javax.sql.DataSource dataSource line just
after class TestService { ...

I think that will help the injection.


On 6/27/06, Peter Wayner <[hidden email]> wrote:

>
> I've been trying to experiment with putting one of the JDBC calls in a
> Service object like this:
>
> import java.sql.*;
> import javax.sql.*;
>
>
> class TestService {
>
> def String list(String table) {
>      javax.sql.DataSource dataSource
>    Connection con=dataSource.getConnection();
>    PreparedStatement ps=con.prepareStatement("select * from "+table);
>     ResultSet rs = ps.execute()
>
>
>       return ""+table
>    }
> }
>
> Any ideas of how I can avoid errors like these:
>
>
>
> Message: Cannot invoke method getConnection() on null object
> Caused by: java.lang.NullPointerException: Cannot invoke method
> getConnection() on null object
> Class: CarController
>
>
>
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Injection vs. Inheritance

Gregory Pierce-2
In reply to this post by Kerry Wilson-3
Well DI solves considerably more problems than Inheritance solves,  
but that said - you still have inheritance in your code. You can have  
your classes extend other classes. However, inheritance is a very  
static approach to writing code. Changes in the hierarchy above you  
would ripple down through your code having effects that would be  
largely unknown to framework developers. Its no mystery that when  
asked if he would change anything about Java, Gosling's response was  
that he would have gotten rid of object inheritance altogether. Class  
inheritance has its problems.



On Jun 27, 2006, at 10:22 AM, Kerry Wilson wrote:

> I do not understand why inheritance is not used throughout the  
> Grails framework, I know that the current trend is to move away  
> from inheritance in favor of POJO with attributes/configuration.  I  
> guess people do not want frameworks structuring their class  
> hierarchy.  But, do we really want to be able to have a controller  
> that inherits from a domain object or classes that act as both?  
> IMO dynamic injection is not an ideal solution, at least when using  
> inheritance it is apparent in the code that the class has intrinsic  
> behavior, with DI it is just 'magic'.
>
> Opinions?
>
> --
> Kerry Wilson
> Lead Developer
> Williams Web
> [hidden email] | 423.485.4747
>
> <kwilson.vcf>
> ---------------------------------------------------------------------
> 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: Dynamic Injection vs. Inheritance

Kerry Wilson-3
Gregory Pierce wrote:
> Well DI solves considerably more problems than Inheritance solves,
Care to elaborate?
> but that said - you still have inheritance in your code. You can have
> your classes extend other classes. However, inheritance is a very
> static approach to writing code. Changes in the hierarchy above you
> would ripple down through your code having effects that would be
> largely unknown to framework developers.
Changing the injected methods would not ripple throughout code?  As far
as I can tell injection is conceptually the same thing as inheritance,
am I missing something?
> Its no mystery that when asked if he would change anything about Java,
> Gosling's response was that he would have gotten rid of object
> inheritance altogether. Class inheritance has its problems
Funny how something can be 'the greatest thing' one day then all of a
sudden it is frowned upon.   I wonder if people are turning against
inheritance because of people's inability to practice good design with
it, or is it considered evil even with good design?

>
>
>
> On Jun 27, 2006, at 10:22 AM, Kerry Wilson wrote:
>
>> I do not understand why inheritance is not used throughout the Grails
>> framework, I know that the current trend is to move away from
>> inheritance in favor of POJO with attributes/configuration.  I guess
>> people do not want frameworks structuring their class hierarchy.  
>> But, do we really want to be able to have a controller that inherits
>> from a domain object or classes that act as both?  IMO dynamic
>> injection is not an ideal solution, at least when using inheritance
>> it is apparent in the code that the class has intrinsic behavior,
>> with DI it is just 'magic'.
>>
>> Opinions?
>>
>> --Kerry Wilson
>> Lead Developer
>> Williams Web
>> [hidden email] | 423.485.4747
>>
>> <kwilson.vcf>
>> ---------------------------------------------------------------------
>> 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
>
>

--
Kerry Wilson
Lead Developer
Williams Web
[hidden email] | 423.485.4747


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

    http://xircles.codehaus.org/manage_email

kwilson.vcf (292 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Injection vs. Inheritance

Marc Palmer Local

On 27 Jun 2006, at 16:37, Kerry Wilson wrote:

> Gregory Pierce wrote:
>> Well DI solves considerably more problems than Inheritance solves,
> Care to elaborate?
>> but that said - you still have inheritance in your code. You can  
>> have your classes extend other classes. However, inheritance is a  
>> very static approach to writing code. Changes in the hierarchy  
>> above you would ripple down through your code having effects that  
>> would be largely unknown to framework developers.
> Changing the injected methods would not ripple throughout code?  As  
> far as I can tell injection is conceptually the same thing as  
> inheritance, am I missing something?
>> Its no mystery that when asked if he would change anything about  
>> Java, Gosling's response was that he would have gotten rid of  
>> object inheritance altogether. Class inheritance has its problems
> Funny how something can be 'the greatest thing' one day then all of  
> a sudden it is frowned upon.   I wonder if people are turning  
> against inheritance because of people's inability to practice good  
> design with it, or is it considered evil even with good design?
>>

I'm half way between the two camps on this. For stuff that does not  
involve method or property name magic - i.e. DomainClass.list(),  
default hashCode/toString/equals etc I think injection is a waste of  
time (and in some cases possible a performance hit).

For great stuff like Grails' dynamic finder methods however, it is  
essential.

I concur with your contention that injection frees the developer from  
the framework, it's patently not true as you have to call these magic  
methods or properties and outside the context of Grails your code  
will -not- work.

On the flip side, if you extend a base class (for non-dynamic  
framework "magic"), it is clear what the contract is and you even  
have the option of writing an alternative base class implementation  
so that you -can- easily run your code outside of Grails.

Of course you could take injected code outside of grails by writing  
another Metaclass that provides all the bits you need just as Grails  
does, but this requires more expertise and infrastructure than a  
regular base class.

Injection of non-dynamic methods = Grails lock-in ;-)

$0.02

Cheers


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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Injection vs. Inheritance

Gregory Pierce-2
In reply to this post by Kerry Wilson-3

On Jun 27, 2006, at 11:37 AM, Kerry Wilson wrote:

> Gregory Pierce wrote:
>> Well DI solves considerably more problems than Inheritance solves,
> Care to elaborate?

Sure I'll give you the big one. Inheritance requires that you have  
some prior knowledge of how a container or other mechanism would  
work. You inherit functionality from it or implement its interfaces  
to conform to its specification. In essence you have now bound your  
domain to another domain. With DI you deal exclusively in your own  
domain - your domain objects. You don't care what services a  
container or similar will provide. You just know that your domain  
objects do what they are supposed to. You can then sight-unseen put  
them into a DI container and the container would do what is necessary  
for it. There is no contract between you and the container at that  
point.

>> but that said - you still have inheritance in your code. You can  
>> have your classes extend other classes. However, inheritance is a  
>> very static approach to writing code. Changes in the hierarchy  
>> above you would ripple down through your code having effects that  
>> would be largely unknown to framework developers.
> Changing the injected methods would not ripple throughout code?  As  
> far as I can tell injection is conceptually the same thing as  
> inheritance, am I missing something?

Nope, because in many instances you wouldn't even know or care that  
the injected methods exist. The injection methodology isn't the same  
as copy and pasting the code into your class. The injection can be  
conditional based on how the container views your object. Take a look  
at EJB. If you are an EJB (2.0), you extend some classes and  
implement some interfaces. Your code is not coupled with the  
implementation of the specification and the container. There will be  
concerns in your code that have absolutely nothing to do with your  
domain objects. If you extend an session bean, that's all you can  
ever be. With DI you are just a java class and functionality can be  
interwoven into you without your knowledge or concern.


>> Its no mystery that when asked if he would change anything about  
>> Java, Gosling's response was that he would have gotten rid of  
>> object inheritance altogether. Class inheritance has its problems
> Funny how something can be 'the greatest thing' one day then all of  
> a sudden it is frowned upon.   I wonder if people are turning  
> against inheritance because of people's inability to practice good  
> design with it, or is it considered evil even with good design?


It isn't that its frowned upon, we just find better ways to do  
things. As we evolve as developers and architects we will discover  
that some approaches to doing things are better than others. Its like  
looking at C and Java. We used to do this procedural programming for  
decades and then one day this OO stuff showed up and we went over to  
it. There are still many well designed C programs out there in the  
world, but they have distinct issues compared to an OO program. Sure  
you can continue to work in procedural programming, or you can become  
an OO developer. There will always be progress in our approaches  -  
that's just the way of things. Progress is a good thing :)


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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Injection vs. Inheritance

graemer
Conceptually what Grails does is more AOP than inhertance. Go back to
the early OO lessons, remember that inheritance implies a "is a"
relationship, now imagine for a moment you inherit from a Frog class.
Your object "is a" Frog.

Now imagine one day your object says "hey I don't wanna be a Frog I
wanna be a Prince", you can't just go off and be a Prince can you? AOP
and Grails advises and weaves the behaviour into your object so that
it can be anything it wants within the environment it is operating in,
think of Grails as the princess that kisses the object to make it
prince.... ok maybe i've taken this analogy too far ;-)

Cheers
Graeme

On 6/27/06, Gregory Pierce <[hidden email]> wrote:

>
> On Jun 27, 2006, at 11:37 AM, Kerry Wilson wrote:
>
> > Gregory Pierce wrote:
> >> Well DI solves considerably more problems than Inheritance solves,
> > Care to elaborate?
>
> Sure I'll give you the big one. Inheritance requires that you have
> some prior knowledge of how a container or other mechanism would
> work. You inherit functionality from it or implement its interfaces
> to conform to its specification. In essence you have now bound your
> domain to another domain. With DI you deal exclusively in your own
> domain - your domain objects. You don't care what services a
> container or similar will provide. You just know that your domain
> objects do what they are supposed to. You can then sight-unseen put
> them into a DI container and the container would do what is necessary
> for it. There is no contract between you and the container at that
> point.
>
> >> but that said - you still have inheritance in your code. You can
> >> have your classes extend other classes. However, inheritance is a
> >> very static approach to writing code. Changes in the hierarchy
> >> above you would ripple down through your code having effects that
> >> would be largely unknown to framework developers.
> > Changing the injected methods would not ripple throughout code?  As
> > far as I can tell injection is conceptually the same thing as
> > inheritance, am I missing something?
>
> Nope, because in many instances you wouldn't even know or care that
> the injected methods exist. The injection methodology isn't the same
> as copy and pasting the code into your class. The injection can be
> conditional based on how the container views your object. Take a look
> at EJB. If you are an EJB (2.0), you extend some classes and
> implement some interfaces. Your code is not coupled with the
> implementation of the specification and the container. There will be
> concerns in your code that have absolutely nothing to do with your
> domain objects. If you extend an session bean, that's all you can
> ever be. With DI you are just a java class and functionality can be
> interwoven into you without your knowledge or concern.
>
>
> >> Its no mystery that when asked if he would change anything about
> >> Java, Gosling's response was that he would have gotten rid of
> >> object inheritance altogether. Class inheritance has its problems
> > Funny how something can be 'the greatest thing' one day then all of
> > a sudden it is frowned upon.   I wonder if people are turning
> > against inheritance because of people's inability to practice good
> > design with it, or is it considered evil even with good design?
>
>
> It isn't that its frowned upon, we just find better ways to do
> things. As we evolve as developers and architects we will discover
> that some approaches to doing things are better than others. Its like
> looking at C and Java. We used to do this procedural programming for
> decades and then one day this OO stuff showed up and we went over to
> it. There are still many well designed C programs out there in the
> world, but they have distinct issues compared to an OO program. Sure
> you can continue to work in procedural programming, or you can become
> an OO developer. There will always be progress in our approaches  -
> that's just the way of things. Progress is a good thing :)
>
>
> ---------------------------------------------------------------------
> 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: Dynamic Injection vs. Inheritance

Guillaume Laforge-2
On 6/27/06, Graeme Rocher <[hidden email]> wrote:

> Conceptually what Grails does is more AOP than inhertance. Go back to
> the early OO lessons, remember that inheritance implies a "is a"
> relationship, now imagine for a moment you inherit from a Frog class.
> Your object "is a" Frog.
>
> Now imagine one day your object says "hey I don't wanna be a Frog I
> wanna be a Prince", you can't just go off and be a Prince can you? AOP
> and Grails advises and weaves the behaviour into your object so that
> it can be anything it wants within the environment it is operating in,
> think of Grails as the princess that kisses the object to make it
> prince.... ok maybe i've taken this analogy too far ;-)

At least, I guess it's more politically correct than if your prince
had wanted to become a princess! :-)

Sorry for the disturbance...

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Injection vs. Inheritance

Kerry Wilson-3
In reply to this post by graemer
Graeme Rocher wrote:

> Conceptually what Grails does is more AOP than inhertance. Go back to
> the early OO lessons, remember that inheritance implies a "is a"
> relationship, now imagine for a moment you inherit from a Frog class.
> Your object "is a" Frog.
>
> Now imagine one day your object says "hey I don't wanna be a Frog I
> wanna be a Prince", you can't just go off and be a Prince can you? AOP
> and Grails advises and weaves the behaviour into your object so that
> it can be anything it wants within the environment it is operating in,
> think of Grails as the princess that kisses the object to make it
> prince.... ok maybe i've taken this analogy too far ;-)
>
> Cheers
> Graeme
Best analogy I have heard yet!  However, what is more important ( or
encountered more frequently ) that a developer wants to use a Grails
domain object ( written in Groovy ) and moving it to use in another
framework or a new user needing to know how domain objects work and what
methods are available?  IMO, the second is far more likely.  Besides,
since Domain Objects are only a few lines of code anyways, how long will
it take to rewrite them?  I just feel that Grails does not happen to be
very friendly for reusing the classes in another framework.  Maybe I am
wrong, has anyone done this?

>
> On 6/27/06, Gregory Pierce <[hidden email]> wrote:
>>
>> On Jun 27, 2006, at 11:37 AM, Kerry Wilson wrote:
>>
>> > Gregory Pierce wrote:
>> >> Well DI solves considerably more problems than Inheritance solves,
>> > Care to elaborate?
>>
>> Sure I'll give you the big one. Inheritance requires that you have
>> some prior knowledge of how a container or other mechanism would
>> work. You inherit functionality from it or implement its interfaces
>> to conform to its specification. In essence you have now bound your
>> domain to another domain. With DI you deal exclusively in your own
>> domain - your domain objects. You don't care what services a
>> container or similar will provide. You just know that your domain
>> objects do what they are supposed to. You can then sight-unseen put
>> them into a DI container and the container would do what is necessary
>> for it. There is no contract between you and the container at that
>> point.
>>
>> >> but that said - you still have inheritance in your code. You can
>> >> have your classes extend other classes. However, inheritance is a
>> >> very static approach to writing code. Changes in the hierarchy
>> >> above you would ripple down through your code having effects that
>> >> would be largely unknown to framework developers.
>> > Changing the injected methods would not ripple throughout code?  As
>> > far as I can tell injection is conceptually the same thing as
>> > inheritance, am I missing something?
>>
>> Nope, because in many instances you wouldn't even know or care that
>> the injected methods exist. The injection methodology isn't the same
>> as copy and pasting the code into your class. The injection can be
>> conditional based on how the container views your object. Take a look
>> at EJB. If you are an EJB (2.0), you extend some classes and
>> implement some interfaces. Your code is not coupled with the
>> implementation of the specification and the container. There will be
>> concerns in your code that have absolutely nothing to do with your
>> domain objects. If you extend an session bean, that's all you can
>> ever be. With DI you are just a java class and functionality can be
>> interwoven into you without your knowledge or concern.
>>
>>
>> >> Its no mystery that when asked if he would change anything about
>> >> Java, Gosling's response was that he would have gotten rid of
>> >> object inheritance altogether. Class inheritance has its problems
>> > Funny how something can be 'the greatest thing' one day then all of
>> > a sudden it is frowned upon.   I wonder if people are turning
>> > against inheritance because of people's inability to practice good
>> > design with it, or is it considered evil even with good design?
>>
>>
>> It isn't that its frowned upon, we just find better ways to do
>> things. As we evolve as developers and architects we will discover
>> that some approaches to doing things are better than others. Its like
>> looking at C and Java. We used to do this procedural programming for
>> decades and then one day this OO stuff showed up and we went over to
>> it. There are still many well designed C programs out there in the
>> world, but they have distinct issues compared to an OO program. Sure
>> you can continue to work in procedural programming, or you can become
>> an OO developer. There will always be progress in our approaches  -
>> that's just the way of things. Progress is a good thing :)
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>

--
Kerry Wilson
Lead Developer
Williams Web
[hidden email] | 423.485.4747


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

    http://xircles.codehaus.org/manage_email

kwilson.vcf (292 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Injection vs. Inheritance

graemer
On 6/27/06, Kerry Wilson <[hidden email]> wrote:

> Graeme Rocher wrote:
> > Conceptually what Grails does is more AOP than inhertance. Go back to
> > the early OO lessons, remember that inheritance implies a "is a"
> > relationship, now imagine for a moment you inherit from a Frog class.
> > Your object "is a" Frog.
> >
> > Now imagine one day your object says "hey I don't wanna be a Frog I
> > wanna be a Prince", you can't just go off and be a Prince can you? AOP
> > and Grails advises and weaves the behaviour into your object so that
> > it can be anything it wants within the environment it is operating in,
> > think of Grails as the princess that kisses the object to make it
> > prince.... ok maybe i've taken this analogy too far ;-)
> >
> > Cheers
> > Graeme
> Best analogy I have heard yet!  However, what is more important ( or
> encountered more frequently ) that a developer wants to use a Grails
> domain object ( written in Groovy ) and moving it to use in another
> framework or a new user needing to know how domain objects work and what
> methods are available?  IMO, the second is far more likely.  Besides,
> since Domain Objects are only a few lines of code anyways, how long will
> it take to rewrite them?  I just feel that Grails does not happen to be
> very friendly for reusing the classes in another framework.  Maybe I am
> wrong, has anyone done this?

I strongly believe there will be a large amount of re-use for domain
models that are written in java and mapped with EJB3 annotations.
Remember Grails injects all the same dynamic methods into java classes
as well as those written in Groovy. A very powerful feature :-)

Graeme

> >
> > On 6/27/06, Gregory Pierce <[hidden email]> wrote:
> >>
> >> On Jun 27, 2006, at 11:37 AM, Kerry Wilson wrote:
> >>
> >> > Gregory Pierce wrote:
> >> >> Well DI solves considerably more problems than Inheritance solves,
> >> > Care to elaborate?
> >>
> >> Sure I'll give you the big one. Inheritance requires that you have
> >> some prior knowledge of how a container or other mechanism would
> >> work. You inherit functionality from it or implement its interfaces
> >> to conform to its specification. In essence you have now bound your
> >> domain to another domain. With DI you deal exclusively in your own
> >> domain - your domain objects. You don't care what services a
> >> container or similar will provide. You just know that your domain
> >> objects do what they are supposed to. You can then sight-unseen put
> >> them into a DI container and the container would do what is necessary
> >> for it. There is no contract between you and the container at that
> >> point.
> >>
> >> >> but that said - you still have inheritance in your code. You can
> >> >> have your classes extend other classes. However, inheritance is a
> >> >> very static approach to writing code. Changes in the hierarchy
> >> >> above you would ripple down through your code having effects that
> >> >> would be largely unknown to framework developers.
> >> > Changing the injected methods would not ripple throughout code?  As
> >> > far as I can tell injection is conceptually the same thing as
> >> > inheritance, am I missing something?
> >>
> >> Nope, because in many instances you wouldn't even know or care that
> >> the injected methods exist. The injection methodology isn't the same
> >> as copy and pasting the code into your class. The injection can be
> >> conditional based on how the container views your object. Take a look
> >> at EJB. If you are an EJB (2.0), you extend some classes and
> >> implement some interfaces. Your code is not coupled with the
> >> implementation of the specification and the container. There will be
> >> concerns in your code that have absolutely nothing to do with your
> >> domain objects. If you extend an session bean, that's all you can
> >> ever be. With DI you are just a java class and functionality can be
> >> interwoven into you without your knowledge or concern.
> >>
> >>
> >> >> Its no mystery that when asked if he would change anything about
> >> >> Java, Gosling's response was that he would have gotten rid of
> >> >> object inheritance altogether. Class inheritance has its problems
> >> > Funny how something can be 'the greatest thing' one day then all of
> >> > a sudden it is frowned upon.   I wonder if people are turning
> >> > against inheritance because of people's inability to practice good
> >> > design with it, or is it considered evil even with good design?
> >>
> >>
> >> It isn't that its frowned upon, we just find better ways to do
> >> things. As we evolve as developers and architects we will discover
> >> that some approaches to doing things are better than others. Its like
> >> looking at C and Java. We used to do this procedural programming for
> >> decades and then one day this OO stuff showed up and we went over to
> >> it. There are still many well designed C programs out there in the
> >> world, but they have distinct issues compared to an OO program. Sure
> >> you can continue to work in procedural programming, or you can become
> >> an OO developer. There will always be progress in our approaches  -
> >> that's just the way of things. Progress is a good thing :)
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
>
> --
> Kerry Wilson
> Lead Developer
> Williams Web
> [hidden email] | 423.485.4747
>
>
>
> ---------------------------------------------------------------------
> 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: Any luck with the data sources?

Peter Wayner
In reply to this post by Guillaume Laforge-2
Much thanks. This works-- until I actually try to execute the prepared statement. When I execute this code:

   def String list(String table) {
  StringBuffer answer=new StringBuffer();
      Connection con=dataSource.getConnection();
      PreparedStatement ps=con.prepareStatement("select * from "+table);
      ResultSet rs = ps.execute()

     

     

      return "freee"+rs
   }


I get this error:



org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.ClassCastException: java.lang.Boolean at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:659) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:350) at groovy.lang.Closure.call(Closure.java:175) at groovy.lang.Closure.call(Closure.java:170) at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleAction(SimpleGrailsControllerHelper.java:354) at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleURI(SimpleGrailsControllerHelper.java:289) at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleURI(SimpleGrailsControllerHelper.java:117) at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsController.handleRequest(SimpleGrailsController.java:79) at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:717) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:658) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:347) at javax.servlet.http.HttpServlet.service(HttpServlet.java:596) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:119) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:55) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:75) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:137) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.codehaus.groovy.grails.web.servlet.filter.GrailsReloadServletFilter.doFilterInternal(GrailsReloadServletFilter.java:205) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: java.lang.ClassCastException: java.lang.Boolean at RoundoffService.list(RoundoffService:29) at RoundoffService$$FastClassByCGLIB$$6d4fd634.invoke(<generated>) at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:698) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:148) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:643) at RoundoffService$$EnhancerByCGLIB$$a7d2f3d3.list(<generated>) at gjdk.RoundoffService_GroovyReflector.invoke(Unknown Source) at groovy.lang.MetaMethod.invoke(MetaMethod.java:111) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:657) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:350) at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:156) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:104) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.java:85) at CarController$_closure6.doCall(CarController:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:67) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:657) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:350) at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:156) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:104) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.java:85) at CarController$_closure6.doCall(CarController) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:67) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:657) ... 38 more



On Jun 27, 2006, at 11:16 AM, Guillaume Laforge wrote:

The datasource is injected in the class properties, not in local
variables of the method.

Could you try to put your javax.sql.DataSource dataSource line just
after class TestService { ...

I think that will help the injection.


On 6/27/06, Peter Wayner <[hidden email]> wrote:

I've been trying to experiment with putting one of the JDBC calls in a
Service object like this:

import java.sql.*;
import javax.sql.*;


class TestService {

def String list(String table) {
     javax.sql.DataSource dataSource
   Connection con=dataSource.getConnection();
   PreparedStatement ps=con.prepareStatement("select * from "+table);
    ResultSet rs = ps.execute()


      return ""+table
   }
}

Any ideas of how I can avoid errors like these:



Message: Cannot invoke method getConnection() on null object
Caused by: java.lang.NullPointerException: Cannot invoke method
getConnection() on null object
Class: CarController







-- 
Guillaume Laforge
Groovy Project Manager

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



Reply | Threaded
Open this post in threaded view
|

Re: Any luck with the data sources?

graemer
What line of your class does the problem occur on, the class cast
exception occurs within the spring proxy code, the line in your
RoundoffService where it happens is line 29... which line is that in
the example you have posted?

Graeme

On 6/27/06, Peter Wayner <[hidden email]> wrote:

>
> Much thanks. This works-- until I actually try to execute the prepared
> statement. When I execute this code:
>
>    def String list(String table) {
>    StringBuffer answer=new StringBuffer();
>        Connection con=dataSource.getConnection();
>        PreparedStatement ps=con.prepareStatement("select * from "+table);
>        ResultSet rs = ps.execute()
>
>
>
>
>
>
>       return "freee"+rs
>    }
>
>
> I get this error:
>
>
>
> org.codehaus.groovy.runtime.InvokerInvocationException:
> java.lang.ClassCastException: java.lang.Boolean at
> org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:659)
> at
> groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:350)
> at groovy.lang.Closure.call(Closure.java:175) at
> groovy.lang.Closure.call(Closure.java:170) at
> org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleAction(SimpleGrailsControllerHelper.java:354)
> at
> org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleURI(SimpleGrailsControllerHelper.java:289)
> at
> org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleURI(SimpleGrailsControllerHelper.java:117)
> at
> org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsController.handleRequest(SimpleGrailsController.java:79)
> at
> org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
> at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:717)
> at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:658)
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
> at
> org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:347)
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:119)
> at
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:55)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at
> org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:75)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:137)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at
> org.codehaus.groovy.grails.web.servlet.filter.GrailsReloadServletFilter.doFilterInternal(GrailsReloadServletFilter.java:205)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> at
> org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
> at
> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635)
> at
> org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
> at org.mortbay.http.HttpServer.service(HttpServer.java:954)
> at
> org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> at
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
> at
> org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> at
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> at
> org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> at
> org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> Caused by: java.lang.ClassCastException: java.lang.Boolean at
> RoundoffService.list(RoundoffService:29) at
> RoundoffService$$FastClassByCGLIB$$6d4fd634.invoke(<generated>)
> at
> net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> at
> org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:698)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:148)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
> at
> org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:643)
> at
> RoundoffService$$EnhancerByCGLIB$$a7d2f3d3.list(<generated>)
> at gjdk.RoundoffService_GroovyReflector.invoke(Unknown
> Source) at groovy.lang.MetaMethod.invoke(MetaMethod.java:111) at
> org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:657)
> at
> groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:350)
> at
> org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:156)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:104)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.java:85)
> at CarController$_closure6.doCall(CarController:33) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585) at
> org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:67)
> at
> org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:657)
> at
> groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:350)
> at
> org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:156)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:104)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.java:85)
> at CarController$_closure6.doCall(CarController) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585) at
> org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:67)
> at
> org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:657)
> ... 38 more
>
>
>
>
> On Jun 27, 2006, at 11:16 AM, Guillaume Laforge wrote:
>
> The datasource is injected in the class properties, not in local
> variables of the method.
>
> Could you try to put your javax.sql.DataSource dataSource line just
> after class TestService { ...
>
> I think that will help the injection.
>
>
> On 6/27/06, Peter Wayner <[hidden email]> wrote:
>
> I've been trying to experiment with putting one of the JDBC calls in a
> Service object like this:
>
> import java.sql.*;
> import javax.sql.*;
>
>
> class TestService {
>
> def String list(String table) {
>      javax.sql.DataSource dataSource
>    Connection con=dataSource.getConnection();
>    PreparedStatement ps=con.prepareStatement("select * from "+table);
>     ResultSet rs = ps.execute()
>
>
>       return ""+table
>    }
> }
>
> Any ideas of how I can avoid errors like these:
>
>
>
> Message: Cannot invoke method getConnection() on null object
> Caused by: java.lang.NullPointerException: Cannot invoke method
> getConnection() on null object
> Class: CarController
>
>
>
>
>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> http://glaforge.free.fr/blog/groovy
>
> ---------------------------------------------------------------------
> 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: Dynamic Injection vs. Inheritance

Jochen Theodorou
In reply to this post by graemer
Graeme Rocher schrieb:
> Conceptually what Grails does is more AOP than inhertance.

What I have in mind for my side of the implementation of this is not
AOP, it is AST level mixins. I just add methods/fields/properties from
another class to my current class without changing the inheritance
structure. If you name that makros, templates, AOP or mixin... I don't
care. I think that mixins are the best erm here, since all others have
slightly different assoziations for me.


bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

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

    http://xircles.codehaus.org/manage_email