How to use interfaces in services (to hide the implementation)

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

How to use interfaces in services (to hide the implementation)

Felipe Cypriano
Hello,

I'd like to use interfaces for every service, because I don't like the other classes referring direct to the actual implementation. How could I do this?

I've tried to create the interface one package before the implementation, but it didn't work:
grails-app/services
- mypackage/DoSomethingService (the interface)
- mypackge/impl/DoSomethingServiceImpl

When I try to access the service using Dependency Injection I get a NullPointerException. How could I configure Grails to work as I need?

Regards,
---
Felipe Cypriano
Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Eric Martineau
I'm not 100% sure, but I think you would need to do the injection like this:

DoSomethingService doSomethingServiceImpl

or

def doSomethingServiceImpl

The spring bean will be named base on the implementing class, not the interface.

Eric

On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano <[hidden email]> wrote:
Hello,

I'd like to use interfaces for every service, because I don't like the other classes referring direct to the actual implementation. How could I do this?

I've tried to create the interface one package before the implementation, but it didn't work:
grails-app/services
- mypackage/DoSomethingService (the interface)
- mypackge/impl/DoSomethingServiceImpl

When I try to access the service using Dependency Injection I get a NullPointerException. How could I configure Grails to work as I need?

Regards,
---
Felipe Cypriano

Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Robert Fischer
Eric's right -- if you go this way, you'll end up wiring up your own service beans.  Which isn't the
end of the world, but it's annoying.

Explain to me what you're trying to gain with this stunt?  Do you have a particular example of code
you don't like?  I think you're swimming upstream against the Groovy.

~~ Robert.

Eric Martineau wrote:

> I'm not 100% sure, but I think you would need to do the injection like this:
>
> DoSomethingService doSomethingServiceImpl
>
> or
>
> def doSomethingServiceImpl
>
> The spring bean will be named base on the implementing class, not the
> interface.
>
> Eric
>
> On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hello,
>
>     I'd like to use interfaces for every service, because I don't like
>     the other classes referring direct to the actual implementation. How
>     could I do this?
>
>     I've tried to create the interface one package before the
>     implementation, but it didn't work:
>     grails-app/services
>     - mypackage/DoSomethingService (the interface)
>     - mypackge/impl/DoSomethingServiceImpl
>
>     When I try to access the service using Dependency Injection I get a
>     NullPointerException. How could I configure Grails to work as I need?
>
>     Regards,
>     ---
>     Felipe Cypriano
>
>

--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Eric Martineau
What do you mean by "you'll end up wiring your own service beans"?  It seems to me that you could still do autowiring as usual...



On Thu, May 28, 2009 at 1:58 PM, Robert Fischer <[hidden email]> wrote:
Eric's right -- if you go this way, you'll end up wiring up your own service beans.  Which isn't the end of the world, but it's annoying.

Explain to me what you're trying to gain with this stunt?  Do you have a particular example of code you don't like?  I think you're swimming upstream against the Groovy.

~~ Robert.

Eric Martineau wrote:
I'm not 100% sure, but I think you would need to do the injection like this:

DoSomethingService doSomethingServiceImpl

or

def doSomethingServiceImpl

The spring bean will be named base on the implementing class, not the interface.

Eric

On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano <[hidden email] <mailto:[hidden email]>> wrote:

   Hello,

   I'd like to use interfaces for every service, because I don't like
   the other classes referring direct to the actual implementation. How
   could I do this?

   I've tried to create the interface one package before the
   implementation, but it didn't work:
   grails-app/services
   - mypackage/DoSomethingService (the interface)
   - mypackge/impl/DoSomethingServiceImpl

   When I try to access the service using Dependency Injection I get a
   NullPointerException. How could I configure Grails to work as I need?

   Regards,
   ---
   Felipe Cypriano



--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

  http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Robert Fischer
True.  I misspoke: you'll end up having to place your own service beans into the context.  The
autowiring will take over from there as per normal.

~~ Robert.

Eric Martineau wrote:

> What do you mean by "you'll end up wiring your own service beans"?  It
> seems to me that you could still do autowiring as usual...
>
>
>
> On Thu, May 28, 2009 at 1:58 PM, Robert Fischer
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Eric's right -- if you go this way, you'll end up wiring up your own
>     service beans.  Which isn't the end of the world, but it's annoying.
>
>     Explain to me what you're trying to gain with this stunt?  Do you
>     have a particular example of code you don't like?  I think you're
>     swimming upstream against the Groovy.
>
>     ~~ Robert.
>
>     Eric Martineau wrote:
>
>         I'm not 100% sure, but I think you would need to do the
>         injection like this:
>
>         DoSomethingService doSomethingServiceImpl
>
>         or
>
>         def doSomethingServiceImpl
>
>         The spring bean will be named base on the implementing class,
>         not the interface.
>
>         Eric
>
>         On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>
>            Hello,
>
>            I'd like to use interfaces for every service, because I don't
>         like
>            the other classes referring direct to the actual
>         implementation. How
>            could I do this?
>
>            I've tried to create the interface one package before the
>            implementation, but it didn't work:
>            grails-app/services
>            - mypackage/DoSomethingService (the interface)
>            - mypackge/impl/DoSomethingServiceImpl
>
>            When I try to access the service using Dependency Injection I
>         get a
>            NullPointerException. How could I configure Grails to work as
>         I need?
>
>            Regards,
>            ---
>            Felipe Cypriano
>
>
>
>     --
>     ~~ Robert Fischer.
>     Grails Training        http://GroovyMag.com/training
>     Smokejumper Consulting http://SmokejumperIT.com
>     Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>     Check out my book, "Grails Persistence with GORM and GSQL"!
>     http://www.smokejumperit.com/redirect.html
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>

--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Eric Martineau
Robert -

You would only need to place your beans in the context manually if you didn't want the bean name to include the "Impl", thought, right?  And if you wanted to avoid the "Impl" in your bean name, you could avoid it by doing a .NET-style interface name:

grails-app/services/ICoolService.groovy (Interface)
grails-app/services/CoolService.groovy (Implementation)

Then, you could auto-wire like this:

ICoolService coolService

I'm pretty sure that this approach would not require you to declare your services manually in spring.

One other point - if you were to declare your services manually in spring, they most likely would not get the aop-wrapped transactional support.

Eric

On Thu, May 28, 2009 at 4:01 PM, Robert Fischer <[hidden email]> wrote:
True.  I misspoke: you'll end up having to place your own service beans into the context.  The autowiring will take over from there as per normal.

~~ Robert.

Eric Martineau wrote:
What do you mean by "you'll end up wiring your own service beans"?  It seems to me that you could still do autowiring as usual...



On Thu, May 28, 2009 at 1:58 PM, Robert Fischer <[hidden email] <mailto:[hidden email]>> wrote:

   Eric's right -- if you go this way, you'll end up wiring up your own
   service beans.  Which isn't the end of the world, but it's annoying.

   Explain to me what you're trying to gain with this stunt?  Do you
   have a particular example of code you don't like?  I think you're
   swimming upstream against the Groovy.

   ~~ Robert.

   Eric Martineau wrote:

       I'm not 100% sure, but I think you would need to do the
       injection like this:

       DoSomethingService doSomethingServiceImpl

       or

       def doSomethingServiceImpl

       The spring bean will be named base on the implementing class,
       not the interface.

       Eric

       On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano
       <[hidden email] <mailto:[hidden email]>
       <mailto:[hidden email] <mailto:[hidden email]>>> wrote:

          Hello,

          I'd like to use interfaces for every service, because I don't
       like
          the other classes referring direct to the actual
       implementation. How
          could I do this?

          I've tried to create the interface one package before the
          implementation, but it didn't work:
          grails-app/services
          - mypackage/DoSomethingService (the interface)
          - mypackge/impl/DoSomethingServiceImpl

          When I try to access the service using Dependency Injection I
       get a
          NullPointerException. How could I configure Grails to work as
       I need?

          Regards,
          ---
          Felipe Cypriano



   --    ~~ Robert Fischer.
   Grails Training        http://GroovyMag.com/training
   Smokejumper Consulting http://SmokejumperIT.com
   Enfranchised Mind Blog http://EnfranchisedMind.com/blog

   Check out my book, "Grails Persistence with GORM and GSQL"!
   http://www.smokejumperit.com/redirect.html

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

     http://xircles.codehaus.org/manage_email




--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

  http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Robert Fischer
Assuming that works, now you've got one implementation class and everything is functionally
identical if I say "CoolService coolService" or "def coolService".  Which gets me back to the
original point: what are you trying to accomplish here?  What's the value you're trying to get?

~~ Robert.

Eric Martineau wrote:

> Robert -
>
> You would only need to place your beans in the context manually if you
> didn't want the bean name to include the "Impl", thought, right?  And if
> you wanted to avoid the "Impl" in your bean name, you could avoid it by
> doing a .NET-style interface name:
>
> grails-app/services/ICoolService.groovy (Interface)
> grails-app/services/CoolService.groovy (Implementation)
>
> Then, you could auto-wire like this:
>
> ICoolService coolService
>
> I'm pretty sure that this approach would not require you to declare your
> services manually in spring.
>
> One other point - if you were to declare your services manually in
> spring, they most likely would not get the aop-wrapped transactional
> support.
>
> Eric
>
> On Thu, May 28, 2009 at 4:01 PM, Robert Fischer
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     True.  I misspoke: you'll end up having to place your own service
>     beans into the context.  The autowiring will take over from there as
>     per normal.
>
>     ~~ Robert.
>
>     Eric Martineau wrote:
>
>         What do you mean by "you'll end up wiring your own service
>         beans"?  It seems to me that you could still do autowiring as
>         usual...
>
>
>
>         On Thu, May 28, 2009 at 1:58 PM, Robert Fischer
>         <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>            Eric's right -- if you go this way, you'll end up wiring up
>         your own
>            service beans.  Which isn't the end of the world, but it's
>         annoying.
>
>            Explain to me what you're trying to gain with this stunt?  Do you
>            have a particular example of code you don't like?  I think you're
>            swimming upstream against the Groovy.
>
>            ~~ Robert.
>
>            Eric Martineau wrote:
>
>                I'm not 100% sure, but I think you would need to do the
>                injection like this:
>
>                DoSomethingService doSomethingServiceImpl
>
>                or
>
>                def doSomethingServiceImpl
>
>                The spring bean will be named base on the implementing class,
>                not the interface.
>
>                Eric
>
>                On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano
>                <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>> wrote:
>
>                   Hello,
>
>                   I'd like to use interfaces for every service, because
>         I don't
>                like
>                   the other classes referring direct to the actual
>                implementation. How
>                   could I do this?
>
>                   I've tried to create the interface one package before the
>                   implementation, but it didn't work:
>                   grails-app/services
>                   - mypackage/DoSomethingService (the interface)
>                   - mypackge/impl/DoSomethingServiceImpl
>
>                   When I try to access the service using Dependency
>         Injection I
>                get a
>                   NullPointerException. How could I configure Grails to
>         work as
>                I need?
>
>                   Regards,
>                   ---
>                   Felipe Cypriano
>
>
>
>            --    ~~ Robert Fischer.
>            Grails Training        http://GroovyMag.com/training
>            Smokejumper Consulting http://SmokejumperIT.com
>            Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>            Check out my book, "Grails Persistence with GORM and GSQL"!
>            http://www.smokejumperit.com/redirect.html
>
>          
>          ---------------------------------------------------------------------
>            To unsubscribe from this list, please visit:
>
>              http://xircles.codehaus.org/manage_email
>
>
>
>
>     --
>     ~~ Robert Fischer.
>     Grails Training        http://GroovyMag.com/training
>     Smokejumper Consulting http://SmokejumperIT.com
>     Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>     Check out my book, "Grails Persistence with GORM and GSQL"!
>     http://www.smokejumperit.com/redirect.html
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>

--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Daniel Honig
Yeah R. Fishcher, you gunning right at what I was thinking.  In dynamic languages interfaces don't hold the value they do in static languages and often just add overhead.

On Thu, May 28, 2009 at 9:20 PM, Robert Fischer <[hidden email]> wrote:
Assuming that works, now you've got one implementation class and everything is functionally identical if I say "CoolService coolService" or "def coolService".  Which gets me back to the original point: what are you trying to accomplish here?  What's the value you're trying to get?

~~ Robert.

Eric Martineau wrote:
Robert -

You would only need to place your beans in the context manually if you didn't want the bean name to include the "Impl", thought, right?  And if you wanted to avoid the "Impl" in your bean name, you could avoid it by doing a .NET-style interface name:

grails-app/services/ICoolService.groovy (Interface)
grails-app/services/CoolService.groovy (Implementation)

Then, you could auto-wire like this:

ICoolService coolService

I'm pretty sure that this approach would not require you to declare your services manually in spring.

One other point - if you were to declare your services manually in spring, they most likely would not get the aop-wrapped transactional support.

Eric

On Thu, May 28, 2009 at 4:01 PM, Robert Fischer <[hidden email] <mailto:[hidden email]>> wrote:

   True.  I misspoke: you'll end up having to place your own service
   beans into the context.  The autowiring will take over from there as
   per normal.

   ~~ Robert.

   Eric Martineau wrote:

       What do you mean by "you'll end up wiring your own service
       beans"?  It seems to me that you could still do autowiring as
       usual...



       On Thu, May 28, 2009 at 1:58 PM, Robert Fischer
       <[hidden email]
       <mailto:[hidden email]>
       <mailto:[hidden email]
       <mailto:[hidden email]>>> wrote:

          Eric's right -- if you go this way, you'll end up wiring up
       your own
          service beans.  Which isn't the end of the world, but it's
       annoying.

          Explain to me what you're trying to gain with this stunt?  Do you
          have a particular example of code you don't like?  I think you're
          swimming upstream against the Groovy.

          ~~ Robert.

          Eric Martineau wrote:

              I'm not 100% sure, but I think you would need to do the
              injection like this:

              DoSomethingService doSomethingServiceImpl

              or

              def doSomethingServiceImpl

              The spring bean will be named base on the implementing class,
              not the interface.

              Eric

              On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano
              <[hidden email] <mailto:[hidden email]>
       <mailto:[hidden email] <mailto:[hidden email]>>
              <mailto:[hidden email]
       <mailto:[hidden email]> <mailto:[hidden email]
       <mailto:[hidden email]>>>> wrote:

                 Hello,

                 I'd like to use interfaces for every service, because
       I don't
              like
                 the other classes referring direct to the actual
              implementation. How
                 could I do this?

                 I've tried to create the interface one package before the
                 implementation, but it didn't work:
                 grails-app/services
                 - mypackage/DoSomethingService (the interface)
                 - mypackge/impl/DoSomethingServiceImpl

                 When I try to access the service using Dependency
       Injection I
              get a
                 NullPointerException. How could I configure Grails to
       work as
              I need?

                 Regards,
                 ---
                 Felipe Cypriano



          --    ~~ Robert Fischer.
          Grails Training        http://GroovyMag.com/training
          Smokejumper Consulting http://SmokejumperIT.com
          Enfranchised Mind Blog http://EnfranchisedMind.com/blog

          Check out my book, "Grails Persistence with GORM and GSQL"!
          http://www.smokejumperit.com/redirect.html

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

            http://xircles.codehaus.org/manage_email




   --    ~~ Robert Fischer.
   Grails Training        http://GroovyMag.com/training
   Smokejumper Consulting http://SmokejumperIT.com
   Enfranchised Mind Blog http://EnfranchisedMind.com/blog

   Check out my book, "Grails Persistence with GORM and GSQL"!
   http://www.smokejumperit.com/redirect.html

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

     http://xircles.codehaus.org/manage_email




--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

  http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Eric Martineau
Ah, I see what you're saying. 

I'm sure I'm in the minority, but I always static type and only def where I feel it makes sense.  Maybe it's just old habits dying hard, but I honestly felt like I was running in sand with Groovy until I started static typing everything. 

There are definitely cases where Felipe's use-case would be required.  For example, the multi-tenant plugin will wrap multi-tenant spring beans with aop proxies.  AOP proxies will "implement" the same interfaces as the class being decorated, but cannot "extend" or be assigned to variables of the original type. 

These proxies can be easily wired into regular groovy classes using "def", but if you needed to wire these beans into a java class, or if you wanted to have them maintain static typing, you would HAVE to create the interface and assign the bean using the interface.

Eric

On Thu, May 28, 2009 at 7:13 PM, Daniel Honig <[hidden email]> wrote:
Yeah R. Fishcher, you gunning right at what I was thinking.  In dynamic languages interfaces don't hold the value they do in static languages and often just add overhead.


On Thu, May 28, 2009 at 9:20 PM, Robert Fischer <[hidden email]> wrote:
Assuming that works, now you've got one implementation class and everything is functionally identical if I say "CoolService coolService" or "def coolService".  Which gets me back to the original point: what are you trying to accomplish here?  What's the value you're trying to get?

~~ Robert.

Eric Martineau wrote:
Robert -

You would only need to place your beans in the context manually if you didn't want the bean name to include the "Impl", thought, right?  And if you wanted to avoid the "Impl" in your bean name, you could avoid it by doing a .NET-style interface name:

grails-app/services/ICoolService.groovy (Interface)
grails-app/services/CoolService.groovy (Implementation)

Then, you could auto-wire like this:

ICoolService coolService

I'm pretty sure that this approach would not require you to declare your services manually in spring.

One other point - if you were to declare your services manually in spring, they most likely would not get the aop-wrapped transactional support.

Eric

On Thu, May 28, 2009 at 4:01 PM, Robert Fischer <[hidden email] <mailto:[hidden email]>> wrote:

   True.  I misspoke: you'll end up having to place your own service
   beans into the context.  The autowiring will take over from there as
   per normal.

   ~~ Robert.

   Eric Martineau wrote:

       What do you mean by "you'll end up wiring your own service
       beans"?  It seems to me that you could still do autowiring as
       usual...



       On Thu, May 28, 2009 at 1:58 PM, Robert Fischer
       <[hidden email]
       <mailto:[hidden email]>
       <mailto:[hidden email]
       <mailto:[hidden email]>>> wrote:

          Eric's right -- if you go this way, you'll end up wiring up
       your own
          service beans.  Which isn't the end of the world, but it's
       annoying.

          Explain to me what you're trying to gain with this stunt?  Do you
          have a particular example of code you don't like?  I think you're
          swimming upstream against the Groovy.

          ~~ Robert.

          Eric Martineau wrote:

              I'm not 100% sure, but I think you would need to do the
              injection like this:

              DoSomethingService doSomethingServiceImpl

              or

              def doSomethingServiceImpl

              The spring bean will be named base on the implementing class,
              not the interface.

              Eric

              On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano
              <[hidden email] <mailto:[hidden email]>
       <mailto:[hidden email] <mailto:[hidden email]>>
              <mailto:[hidden email]
       <mailto:[hidden email]> <mailto:[hidden email]
       <mailto:[hidden email]>>>> wrote:

                 Hello,

                 I'd like to use interfaces for every service, because
       I don't
              like
                 the other classes referring direct to the actual
              implementation. How
                 could I do this?

                 I've tried to create the interface one package before the
                 implementation, but it didn't work:
                 grails-app/services
                 - mypackage/DoSomethingService (the interface)
                 - mypackge/impl/DoSomethingServiceImpl

                 When I try to access the service using Dependency
       Injection I
              get a
                 NullPointerException. How could I configure Grails to
       work as
              I need?

                 Regards,
                 ---
                 Felipe Cypriano



          --    ~~ Robert Fischer.
          Grails Training        http://GroovyMag.com/training
          Smokejumper Consulting http://SmokejumperIT.com
          Enfranchised Mind Blog http://EnfranchisedMind.com/blog

          Check out my book, "Grails Persistence with GORM and GSQL"!
          http://www.smokejumperit.com/redirect.html

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

            http://xircles.codehaus.org/manage_email




   --    ~~ Robert Fischer.
   Grails Training        http://GroovyMag.com/training
   Smokejumper Consulting http://SmokejumperIT.com
   Enfranchised Mind Blog http://EnfranchisedMind.com/blog

   Check out my book, "Grails Persistence with GORM and GSQL"!
   http://www.smokejumperit.com/redirect.html

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

     http://xircles.codehaus.org/manage_email




--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

  http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Felipe Cypriano
I think just like Eric, I like to static type things, for me is kinda strange to call methods that return def in all cases. Since the idea of services is to be used not only by groovy code I'd like a way to guarantee that the service's interface is what I expected no matter where I'm consuming the service. IMO use only dynamic types makes the code more complex to understand at long term.

If after a few months or years I realize that my services implementation using groovy isn't fast enough (or any other reason) and I need to change it to pure java, since all my consumers refers to the interface I can change the implementation without change the consumers. I want to use the groovy's power to implement things and not to define the contract between classes.

Another value that I'll have is that my IDE will deal better with well defined services, it will show me tha javadoc for each method and the code completion, refactoring and the other stuff will work better too. I could also package my interfaces in a separated project and my client only need this package.

Now let's go to the suggested implementation.

I think that if I the service's class name must end with "Service" if not it isn't injected, so this didn't work for me:
grails-app/service/CoolService // The interface
grails-app/service/CoolServiceImpl // The implementation

CoolService coolServiceImpl // or def coolServiceImpl
coolServiceImpl.doStuff() // throws can't call do doStuff() on null object

If I use the .Net style (or any other style that the implementation's class name end with Service) it works:
grails-app/service/ISomeService // The interface
grails-app/service/SomeService // the implementation

I'd like to avoid the interface's name to change but seems it isn't possible.

Regards,
---
Felipe Cypriano


On Fri, May 29, 2009 at 3:50 AM, Eric Martineau <[hidden email]> wrote:
Ah, I see what you're saying. 

I'm sure I'm in the minority, but I always static type and only def where I feel it makes sense.  Maybe it's just old habits dying hard, but I honestly felt like I was running in sand with Groovy until I started static typing everything. 

There are definitely cases where Felipe's use-case would be required.  For example, the multi-tenant plugin will wrap multi-tenant spring beans with aop proxies.  AOP proxies will "implement" the same interfaces as the class being decorated, but cannot "extend" or be assigned to variables of the original type. 

These proxies can be easily wired into regular groovy classes using "def", but if you needed to wire these beans into a java class, or if you wanted to have them maintain static typing, you would HAVE to create the interface and assign the bean using the interface.

Eric


On Thu, May 28, 2009 at 7:13 PM, Daniel Honig <[hidden email]> wrote:
Yeah R. Fishcher, you gunning right at what I was thinking.  In dynamic languages interfaces don't hold the value they do in static languages and often just add overhead.


On Thu, May 28, 2009 at 9:20 PM, Robert Fischer <[hidden email]> wrote:
Assuming that works, now you've got one implementation class and everything is functionally identical if I say "CoolService coolService" or "def coolService".  Which gets me back to the original point: what are you trying to accomplish here?  What's the value you're trying to get?

~~ Robert.

Eric Martineau wrote:
Robert -

You would only need to place your beans in the context manually if you didn't want the bean name to include the "Impl", thought, right?  And if you wanted to avoid the "Impl" in your bean name, you could avoid it by doing a .NET-style interface name:

grails-app/services/ICoolService.groovy (Interface)
grails-app/services/CoolService.groovy (Implementation)

Then, you could auto-wire like this:

ICoolService coolService

I'm pretty sure that this approach would not require you to declare your services manually in spring.

One other point - if you were to declare your services manually in spring, they most likely would not get the aop-wrapped transactional support.

Eric

On Thu, May 28, 2009 at 4:01 PM, Robert Fischer <[hidden email] <mailto:[hidden email]>> wrote:

   True.  I misspoke: you'll end up having to place your own service
   beans into the context.  The autowiring will take over from there as
   per normal.

   ~~ Robert.

   Eric Martineau wrote:

       What do you mean by "you'll end up wiring your own service
       beans"?  It seems to me that you could still do autowiring as
       usual...



       On Thu, May 28, 2009 at 1:58 PM, Robert Fischer
       <[hidden email]
       <mailto:[hidden email]>
       <mailto:[hidden email]
       <mailto:[hidden email]>>> wrote:

          Eric's right -- if you go this way, you'll end up wiring up
       your own
          service beans.  Which isn't the end of the world, but it's
       annoying.

          Explain to me what you're trying to gain with this stunt?  Do you
          have a particular example of code you don't like?  I think you're
          swimming upstream against the Groovy.

          ~~ Robert.

          Eric Martineau wrote:

              I'm not 100% sure, but I think you would need to do the
              injection like this:

              DoSomethingService doSomethingServiceImpl

              or

              def doSomethingServiceImpl

              The spring bean will be named base on the implementing class,
              not the interface.

              Eric

              On Thu, May 28, 2009 at 11:12 AM, Felipe Cypriano
              <[hidden email] <mailto:[hidden email]>
       <mailto:[hidden email] <mailto:[hidden email]>>
              <mailto:[hidden email]
       <mailto:[hidden email]> <mailto:[hidden email]
       <mailto:[hidden email]>>>> wrote:

                 Hello,

                 I'd like to use interfaces for every service, because
       I don't
              like
                 the other classes referring direct to the actual
              implementation. How
                 could I do this?

                 I've tried to create the interface one package before the
                 implementation, but it didn't work:
                 grails-app/services
                 - mypackage/DoSomethingService (the interface)
                 - mypackge/impl/DoSomethingServiceImpl

                 When I try to access the service using Dependency
       Injection I
              get a
                 NullPointerException. How could I configure Grails to
       work as
              I need?

                 Regards,
                 ---
                 Felipe Cypriano



          --    ~~ Robert Fischer.
          Grails Training        http://GroovyMag.com/training
          Smokejumper Consulting http://SmokejumperIT.com
          Enfranchised Mind Blog http://EnfranchisedMind.com/blog

          Check out my book, "Grails Persistence with GORM and GSQL"!
          http://www.smokejumperit.com/redirect.html

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

            http://xircles.codehaus.org/manage_email




   --    ~~ Robert Fischer.
   Grails Training        http://GroovyMag.com/training
   Smokejumper Consulting http://SmokejumperIT.com
   Enfranchised Mind Blog http://EnfranchisedMind.com/blog

   Check out my book, "Grails Persistence with GORM and GSQL"!
   http://www.smokejumperit.com/redirect.html

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

     http://xircles.codehaus.org/manage_email




--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

  http://xircles.codehaus.org/manage_email





Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Robert Fischer
You can change the implementation of a method and not change the consumers -- simply replace your
existing service with a new one that has the same API.

Can you demonstrate (with some Grails code) how you would use this approach with two different
implementations of the same interface?  I suspect what's actually going on is that you're just
injecting your chosen implementation, and the interface isn't really gaining you anything.

I can't speak to the usefulness of interfaces for the IDE, since I'm yet to catch the IDE bug for
Groovy/Grails.

~~ Robert.

Felipe Cypriano wrote:

> I think just like Eric, I like to static type things, for me is kinda
> strange to call methods that return def in all cases. Since the idea of
> services is to be used not only by groovy code I'd like a way to
> guarantee that the service's interface is what I expected no matter
> where I'm consuming the service. IMO use only dynamic types makes the
> code more complex to understand at long term.
>
> If after a few months or years I realize that my services implementation
> using groovy isn't fast enough (or any other reason) and I need to
> change it to pure java, since all my consumers refers to the interface I
> can change the implementation without change the consumers. I want to
> use the groovy's power to implement things and not to define the
> contract between classes.
>
> Another value that I'll have is that my IDE will deal better with well
> defined services, it will show me tha javadoc for each method and the
> code completion, refactoring and the other stuff will work better too. I
> could also package my interfaces in a separated project and my client
> only need this package.
>
> Now let's go to the suggested implementation.
>
> I think that if I the service's class name must end with "Service" if
> not it isn't injected, so this didn't work for me:
> grails-app/service/CoolService // The interface
> grails-app/service/CoolServiceImpl // The implementation
>
> CoolService coolServiceImpl // or def coolServiceImpl
> coolServiceImpl.doStuff() // throws can't call do doStuff() on null object
>
> If I use the .Net style (or any other style that the implementation's
> class name end with Service) it works:
> grails-app/service/ISomeService // The interface
> grails-app/service/SomeService // the implementation
>
> I'd like to avoid the interface's name to change but seems it isn't
> possible.
>
> Regards,
> ---
> Felipe Cypriano
>
>
> On Fri, May 29, 2009 at 3:50 AM, Eric Martineau <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Ah, I see what you're saying.
>
>     I'm sure I'm in the minority, but I always static type and only def
>     where I feel it makes sense.  Maybe it's just old habits dying hard,
>     but I honestly felt like I was running in sand with Groovy until I
>     started static typing everything.
>
>     There are definitely cases where Felipe's use-case would be
>     required.  For example, the multi-tenant plugin will wrap
>     multi-tenant spring beans with aop proxies.  AOP proxies will
>     "implement" the same interfaces as the class being decorated, but
>     cannot "extend" or be assigned to variables of the original type.
>
>     These proxies can be easily wired into regular groovy classes using
>     "def", but if you needed to wire these beans into a java class, or
>     if you wanted to have them maintain static typing, you would HAVE to
>     create the interface and assign the bean using the interface.
>
>     Eric
>
>
>     On Thu, May 28, 2009 at 7:13 PM, Daniel Honig
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         Yeah R. Fishcher, you gunning right at what I was thinking.  In
>         dynamic languages interfaces don't hold the value they do in
>         static languages and often just add overhead.
>
>
>         On Thu, May 28, 2009 at 9:20 PM, Robert Fischer
>         <[hidden email]
>         <mailto:[hidden email]>> wrote:
>
>             Assuming that works, now you've got one implementation class
>             and everything is functionally identical if I say
>             "CoolService coolService" or "def coolService".  Which gets
>             me back to the original point: what are you trying to
>             accomplish here?  What's the value you're trying to get?
>
>             ~~ Robert.
>
>             Eric Martineau wrote:
>
>                 Robert -
>
>                 You would only need to place your beans in the context
>                 manually if you didn't want the bean name to include the
>                 "Impl", thought, right?  And if you wanted to avoid the
>                 "Impl" in your bean name, you could avoid it by doing a
>                 .NET-style interface name:
>
>                 grails-app/services/ICoolService.groovy (Interface)
>                 grails-app/services/CoolService.groovy (Implementation)
>
>                 Then, you could auto-wire like this:
>
>                 ICoolService coolService
>
>                 I'm pretty sure that this approach would not require you
>                 to declare your services manually in spring.
>
>                 One other point - if you were to declare your services
>                 manually in spring, they most likely would not get the
>                 aop-wrapped transactional support.
>
>                 Eric
>
>                 On Thu, May 28, 2009 at 4:01 PM, Robert Fischer
>                 <[hidden email]
>                 <mailto:[hidden email]>
>                 <mailto:[hidden email]
>                 <mailto:[hidden email]>>> wrote:
>
>                    True.  I misspoke: you'll end up having to place your
>                 own service
>                    beans into the context.  The autowiring will take
>                 over from there as
>                    per normal.
>
>                    ~~ Robert.
>
>                    Eric Martineau wrote:
>
>                        What do you mean by "you'll end up wiring your
>                 own service
>                        beans"?  It seems to me that you could still do
>                 autowiring as
>                        usual...
>
>
>
>                        On Thu, May 28, 2009 at 1:58 PM, Robert Fischer
>                        <[hidden email]
>                 <mailto:[hidden email]>
>                        <mailto:[hidden email]
>                 <mailto:[hidden email]>>
>                        <mailto:[hidden email]
>                 <mailto:[hidden email]>
>                        <mailto:[hidden email]
>                 <mailto:[hidden email]>>>> wrote:
>
>                           Eric's right -- if you go this way, you'll end
>                 up wiring up
>                        your own
>                           service beans.  Which isn't the end of the
>                 world, but it's
>                        annoying.
>
>                           Explain to me what you're trying to gain with
>                 this stunt?  Do you
>                           have a particular example of code you don't
>                 like?  I think you're
>                           swimming upstream against the Groovy.
>
>                           ~~ Robert.
>
>                           Eric Martineau wrote:
>
>                               I'm not 100% sure, but I think you would
>                 need to do the
>                               injection like this:
>
>                               DoSomethingService doSomethingServiceImpl
>
>                               or
>
>                               def doSomethingServiceImpl
>
>                               The spring bean will be named base on the
>                 implementing class,
>                               not the interface.
>
>                               Eric
>
>                               On Thu, May 28, 2009 at 11:12 AM, Felipe
>                 Cypriano
>                               <[hidden email]
>                 <mailto:[hidden email]>
>                 <mailto:[hidden email] <mailto:[hidden email]>>
>                        <mailto:[hidden email]
>                 <mailto:[hidden email]>
>                 <mailto:[hidden email] <mailto:[hidden email]>>>
>                               <mailto:[hidden email]
>                 <mailto:[hidden email]>
>                        <mailto:[hidden email]
>                 <mailto:[hidden email]>>
>                 <mailto:[hidden email] <mailto:[hidden email]>
>                        <mailto:[hidden email]
>                 <mailto:[hidden email]>>>>> wrote:
>
>                                  Hello,
>
>                                  I'd like to use interfaces for every
>                 service, because
>                        I don't
>                               like
>                                  the other classes referring direct to
>                 the actual
>                               implementation. How
>                                  could I do this?
>
>                                  I've tried to create the interface one
>                 package before the
>                                  implementation, but it didn't work:
>                                  grails-app/services
>                                  - mypackage/DoSomethingService (the
>                 interface)
>                                  - mypackge/impl/DoSomethingServiceImpl
>
>                                  When I try to access the service using
>                 Dependency
>                        Injection I
>                               get a
>                                  NullPointerException. How could I
>                 configure Grails to
>                        work as
>                               I need?
>
>                                  Regards,
>                                  ---
>                                  Felipe Cypriano
>
>
>
>                           --    ~~ Robert Fischer.
>                           Grails Training      
>                  http://GroovyMag.com/training
>                           Smokejumper Consulting http://SmokejumperIT.com
>                           Enfranchised Mind Blog
>                 http://EnfranchisedMind.com/blog
>
>                           Check out my book, "Grails Persistence with
>                 GORM and GSQL"!
>                           http://www.smokejumperit.com/redirect.html
>
>                                
>                 ---------------------------------------------------------------------
>                           To unsubscribe from this list, please visit:
>
>                             http://xircles.codehaus.org/manage_email
>
>
>
>
>                    --    ~~ Robert Fischer.
>                    Grails Training        http://GroovyMag.com/training
>                    Smokejumper Consulting http://SmokejumperIT.com
>                    Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>                    Check out my book, "Grails Persistence with GORM and
>                 GSQL"!
>                    http://www.smokejumperit.com/redirect.html
>
>                  
>                  ---------------------------------------------------------------------
>                    To unsubscribe from this list, please visit:
>
>                      http://xircles.codehaus.org/manage_email
>
>
>
>
>             --
>             ~~ Robert Fischer.
>             Grails Training        http://GroovyMag.com/training
>             Smokejumper Consulting http://SmokejumperIT.com
>             Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>             Check out my book, "Grails Persistence with GORM and GSQL"!
>             http://www.smokejumperit.com/redirect.html
>
>             ---------------------------------------------------------------------
>             To unsubscribe from this list, please visit:
>
>               http://xircles.codehaus.org/manage_email
>
>
>
>
>

--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: How to use interfaces in services (to hide the implementation)

Felipe Cypriano
You can change the implementation of a method and not change the consumers -- simply replace your existing service with a new one that has the same API.

Yes, this is right and the thing that guarantee this exactly same API is the interface.

From the groovy language there's no difference between using interface or not since groovy is dynamic and can call everything you want, it'll not get compiler error with non "API methods". But when I need to implement a consumer using java I've to use a well defined and static typed API. See it: Using Services from Java

BTW, I'll not do interfaces for everything just because the name is "cutty". The mais point is to guarantee a common API for my services and maintain loose coupling between classes.

Cheers,
---
Felipe Cypriano


On Fri, May 29, 2009 at 12:55 PM, Robert Fischer <[hidden email]> wrote:
You can change the implementation of a method and not change the consumers -- simply replace your existing service with a new one that has the same API.

Can you demonstrate (with some Grails code) how you would use this approach with two different implementations of the same interface?  I suspect what's actually going on is that you're just injecting your chosen implementation, and the interface isn't really gaining you anything.

I can't speak to the usefulness of interfaces for the IDE, since I'm yet to catch the IDE bug for Groovy/Grails.

~~ Robert.

Felipe Cypriano wrote:
I think just like Eric, I like to static type things, for me is kinda strange to call methods that return def in all cases. Since the idea of services is to be used not only by groovy code I'd like a way to guarantee that the service's interface is what I expected no matter where I'm consuming the service. IMO use only dynamic types makes the code more complex to understand at long term.

If after a few months or years I realize that my services implementation using groovy isn't fast enough (or any other reason) and I need to change it to pure java, since all my consumers refers to the interface I can change the implementation without change the consumers. I want to use the groovy's power to implement things and not to define the contract between classes.

Another value that I'll have is that my IDE will deal better with well defined services, it will show me tha javadoc for each method and the code completion, refactoring and the other stuff will work better too. I could also package my interfaces in a separated project and my client only need this package.

Now let's go to the suggested implementation.

I think that if I the service's class name must end with "Service" if not it isn't injected, so this didn't work for me:
grails-app/service/CoolService // The interface
grails-app/service/CoolServiceImpl // The implementation

CoolService coolServiceImpl // or def coolServiceImpl
coolServiceImpl.doStuff() // throws can't call do doStuff() on null object

If I use the .Net style (or any other style that the implementation's class name end with Service) it works:
grails-app/service/ISomeService // The interface
grails-app/service/SomeService // the implementation

I'd like to avoid the interface's name to change but seems it isn't possible.

Regards,
---
Felipe Cypriano


On Fri, May 29, 2009 at 3:50 AM, Eric Martineau <[hidden email] <mailto:[hidden email]>> wrote:

   Ah, I see what you're saying.
   I'm sure I'm in the minority, but I always static type and only def
   where I feel it makes sense.  Maybe it's just old habits dying hard,
   but I honestly felt like I was running in sand with Groovy until I
   started static typing everything.
   There are definitely cases where Felipe's use-case would be
   required.  For example, the multi-tenant plugin will wrap
   multi-tenant spring beans with aop proxies.  AOP proxies will
   "implement" the same interfaces as the class being decorated, but
   cannot "extend" or be assigned to variables of the original type.
   These proxies can be easily wired into regular groovy classes using
   "def", but if you needed to wire these beans into a java class, or
   if you wanted to have them maintain static typing, you would HAVE to
   create the interface and assign the bean using the interface.

   Eric


   On Thu, May 28, 2009 at 7:13 PM, Daniel Honig
   <[hidden email] <mailto:[hidden email]>> wrote:

       Yeah R. Fishcher, you gunning right at what I was thinking.  In
       dynamic languages interfaces don't hold the value they do in
       static languages and often just add overhead.


       On Thu, May 28, 2009 at 9:20 PM, Robert Fischer
       <[hidden email]
       <mailto:[hidden email]>> wrote:

           Assuming that works, now you've got one implementation class
           and everything is functionally identical if I say
           "CoolService coolService" or "def coolService".  Which gets
           me back to the original point: what are you trying to
           accomplish here?  What's the value you're trying to get?

           ~~ Robert.

           Eric Martineau wrote:

               Robert -

               You would only need to place your beans in the context
               manually if you didn't want the bean name to include the
               "Impl", thought, right?  And if you wanted to avoid the
               "Impl" in your bean name, you could avoid it by doing a
               .NET-style interface name:

               grails-app/services/ICoolService.groovy (Interface)
               grails-app/services/CoolService.groovy (Implementation)

               Then, you could auto-wire like this:

               ICoolService coolService

               I'm pretty sure that this approach would not require you
               to declare your services manually in spring.

               One other point - if you were to declare your services
               manually in spring, they most likely would not get the
               aop-wrapped transactional support.

               Eric

               On Thu, May 28, 2009 at 4:01 PM, Robert Fischer
               <[hidden email]
               <mailto:[hidden email]>
               <mailto:[hidden email]
               <mailto:[hidden email]>>> wrote:

                  True.  I misspoke: you'll end up having to place your
               own service
                  beans into the context.  The autowiring will take
               over from there as
                  per normal.

                  ~~ Robert.

                  Eric Martineau wrote:

                      What do you mean by "you'll end up wiring your
               own service
                      beans"?  It seems to me that you could still do
               autowiring as
                      usual...



                      On Thu, May 28, 2009 at 1:58 PM, Robert Fischer
                      <[hidden email]
               <mailto:[hidden email]>
                      <mailto:[hidden email]
               <mailto:[hidden email]>>
                      <mailto:[hidden email]
               <mailto:[hidden email]>
                      <mailto:[hidden email]
               <mailto:[hidden email]>>>> wrote:

                         Eric's right -- if you go this way, you'll end
               up wiring up
                      your own
                         service beans.  Which isn't the end of the
               world, but it's
                      annoying.

                         Explain to me what you're trying to gain with
               this stunt?  Do you
                         have a particular example of code you don't
               like?  I think you're
                         swimming upstream against the Groovy.

                         ~~ Robert.

                         Eric Martineau wrote:

                             I'm not 100% sure, but I think you would
               need to do the
                             injection like this:

                             DoSomethingService doSomethingServiceImpl

                             or

                             def doSomethingServiceImpl

                             The spring bean will be named base on the
               implementing class,
                             not the interface.

                             Eric

                             On Thu, May 28, 2009 at 11:12 AM, Felipe
               Cypriano
                             <[hidden email]
               <mailto:[hidden email]>
               <mailto:[hidden email] <mailto:[hidden email]>>
                      <mailto:[hidden email]
               <mailto:[hidden email]>
               <mailto:[hidden email] <mailto:[hidden email]>>>
                             <mailto:[hidden email]
               <mailto:[hidden email]>
                      <mailto:[hidden email]
               <mailto:[hidden email]>>
               <mailto:[hidden email] <mailto:[hidden email]>
                      <mailto:[hidden email]
               <mailto:[hidden email]>>>>> wrote:

                                Hello,

                                I'd like to use interfaces for every
               service, because
                      I don't
                             like
                                the other classes referring direct to
               the actual
                             implementation. How
                                could I do this?

                                I've tried to create the interface one
               package before the
                                implementation, but it didn't work:
                                grails-app/services
                                - mypackage/DoSomethingService (the
               interface)
                                - mypackge/impl/DoSomethingServiceImpl

                                When I try to access the service using
               Dependency
                      Injection I
                             get a
                                NullPointerException. How could I
               configure Grails to
                      work as
                             I need?

                                Regards,
                                ---
                                Felipe Cypriano



                         --    ~~ Robert Fischer.
                         Grails Training                       http://GroovyMag.com/training
                         Smokejumper Consulting http://SmokejumperIT.com
                         Enfranchised Mind Blog
               http://EnfranchisedMind.com/blog

                         Check out my book, "Grails Persistence with
               GORM and GSQL"!
                         http://www.smokejumperit.com/redirect.html

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

                           http://xircles.codehaus.org/manage_email




                  --    ~~ Robert Fischer.
                  Grails Training        http://GroovyMag.com/training
                  Smokejumper Consulting http://SmokejumperIT.com
                  Enfranchised Mind Blog http://EnfranchisedMind.com/blog

                  Check out my book, "Grails Persistence with GORM and
               GSQL"!
                  http://www.smokejumperit.com/redirect.html

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

                    http://xircles.codehaus.org/manage_email




           --            ~~ Robert Fischer.
           Grails Training        http://GroovyMag.com/training
           Smokejumper Consulting http://SmokejumperIT.com
           Enfranchised Mind Blog http://EnfranchisedMind.com/blog

           Check out my book, "Grails Persistence with GORM and GSQL"!
           http://www.smokejumperit.com/redirect.html

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

             http://xircles.codehaus.org/manage_email






--
~~ Robert Fischer.
Grails Training        http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

  http://xircles.codehaus.org/manage_email