Okay, so following your advice, I gave it another try.

Created a new project using tapestry jumpstart and experimented with case 1
type injection again. And guess what...it works!

I was able to test all three types and it worked without any issues! Great,
so then I moved back to my code and tried change from constructors to
fields (instance variables). I had couple of issues in certain places with
circular dependencies - which I realised were caused by not using auto
build method. Eventually I was able to get rid of all them and one final
service remained.

As I analysed the code again, I am wondering at what point does injection
really take place? It is not really an issue when using constructor based
injection, but what about instance variables?

I think that's what I was doing wrong (assuming in this case injection does
not happen until after the object has come into existence e.g. constructor
has returned?)

public class MyServiceImpl implements MyService {

    @Inject
      MyServiceB serviceB

      public MyServiceImpl() {
       serviceB.doSomething(); //Throws a NPE as Injection hasn't happened
yet?
     ....
      }

}
Thank you for all your help guys! Much appreciated.



Best Regards,
Sanket






one other thing occurs to me. you should also make sure you are using the
> Tapestry @Inject annotation and NOT the javax.inject one.
>
>
> On Sat, Apr 5, 2014 at 1:26 PM, Jon Williams <williams.jonat...@gmail.com
> >wrote:
>
> > your findings are a bit odd.
> >
> > case 1) should work.
> >  eg.
> > "
> > public class UserServiceImpl implements UserService {
> >
> >     @Inject
> >     private DomainObjectService domainObjectService;
> > "
> >
> > case 2) i never use case 2) because it's handled by your case 1).
> >
> > case 3) Constructor injection is also viable as you've verified.
> > i kinda like to be a bit more explicit about my constructor params than
> > your example
> > and use the @Inject annotation on them too.
> >
> >
> > Take another look at case 1) it should work.
> >
> >
> > On Sat, Apr 5, 2014 at 12:46 PM, Sanket Sharma <sanketsha...@gmail.com
> >wrote:
> >
> >> Sorry, I wrote that email in a rush - should have been more explicit.
> >>
> >> Let me try and explain with code:
> >>
> >> public class MyServiceImpl implements MyService {
> >>
> >>        @Inject                        //This is not supported for
> >> services,
> >> will not work
> >>         ServiceB serviceB;
> >>
> >>
> >>         @InjectService("ServiceC") //This is not supported either for
> >> Services, will not work
> >>          ServiceC serviceC
> >>
> >>
> >>         public MyServiceImpl(ServiceD serviceD, ServiceE serviceE) {
> >> //This
> >> is supported
> >>          ...
> >>         }
> >>
> >>     . ....
> >>
> >> }
> >>
> >>
> >> Thank you for the clarification regarding proxies/services.
> >>
> >>
> >> Best Regards,
> >> Sanket
> >>
> >>
> >>
> >>
> >> On Sat, Apr 5, 2014 at 7:57 PM, Thiago H de Paula Figueiredo <
> >> thiag...@gmail.com> wrote:
> >>
> >> > On Fri, 04 Apr 2014 18:25:41 -0300, Sanket Sharma <
> >> sanketsha...@gmail.com>
> >> > wrote:
> >> >
> >> >  Hi,
> >> >>
> >> >
> >> > Hi!
> >> >
> >> >  First, You cannot inject dependencies into fields of a service class.
> >> Now
> >> >> this is mentioned in the documentation very clearly, it took me some
> >> time
> >> >> to get my head around it. No matter what you do or customise or
> >> override,
> >> >> you cannot inject field values into a service class.
> >> >>
> >> >
> >> > What do you mean by injecting field values into a service class? Have
> >> you
> >> > checked the ShadowBuilder service? Here's the declaration of the
> Request
> >> > service, which is actually a property of RequestGlobals:
> >> >
> >> > public Request buildRequest() {
> >> >     return shadowBuilder.build(requestGlobals, "request",
> >> Request.class);
> >> > }
> >> >
> >> >  Lastly, (and I am not so sure about this one) - because tapestry
> >> proxies
> >> >> access to all objects,
> >> >>
> >> >
> >> > Nope, just to services which are created based on an interface.
> >> >
> >> >  you do not need to create/use singleton patterns
> >> >> explicitly in you services or patters - i.e. provide a static
> >> getInstance
> >> >> method..? Is that a correct?
> >> >>
> >> >
> >> > If the given object is a service and you always get service instances
> by
> >> > injecting them using Tapestry-IoC, no.
> >> >
> >> > --
> >> > Thiago H. de Paula Figueiredo
> >> > Tapestry, Java and Hibernate consultant and developer
> >> > http://machina.com.br
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >> >
> >> >
> >>
> >
> >
>

Reply via email to