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