On 2/26/07, Konstantin Priblouda <[EMAIL PROTECTED]> wrote:
> My point still holds true--Pico requires more code > than Guice. Structly speaking using pico in a webapp requires no code at all (except of course container configuration in xml or whatever else)
Ummmm, strictly speaking, that's still code. ;) What is with third party libraries, which do not know
anything about guice?
You can write a custom Provider as I illustrated above. If I understood you correctly, in guice there will be
need to write some adapter / factory. Who got more code?
I'm pretty sure Pico is still more verbose. If you explain what your example is doing a little better, I'll be happy to illustrate.
bind(Session.class) > .annotatedWith(Secure.class) > .to(FailoverSessionDelegator.class); > > Then apply "@Inject @Secure" wherever you want a > secure Session. You can > obviously reuse the @Secure annotation elsewhere, > too. Correct me if I'm wrong ( due to lack of complete undertanging of guice ), but this means that you need to tell explicitely that org.hibernate.Session would be represented by FailoverSessionDelegator class?
Yes. What if I like to use another session impl in the same
container?
Use an annotation. You do not have to specify this with pico - your
constructor states it need Session , container looks for implementation of session. If there is one than one available - ambiguity shall be resolved by means of explicit mapping ( no difference with guice? )
Correct. Scoping is another issue. Guice users depend on your
wisdom to provide them with annotations. If those annotations are to be applied on some framework ( say, my menu framework for example ), then there is a leak of concepts - I have to decide component scope in a project which has nothing to do with web application ( but will be used for it ). What if I need different scope?
You can override the scope in the configuration. You can also implement your own scopes and scope annotations. The users' guide explains this. Bob
