I use the Injector only on BookmarkablePages otherwise I inject by hand
-
a lot of real DI citicens. And for the BookmarkablePages I have two
constructors one which calls the Injector the other one which does not.
So
I don't even have to set context mock. There is no difference to
AspectJ.
I am curious about good citizen usage. Suppose I have a case when only
the SecondPage is using some service, and FirstPage and SecondPage are
instantiated with the new operator and applying good citizen. Besides
only SecondPage needs the service, the service is injected at
HomePage, and FirstPage references as well. I do like good citizen,
but in this case it is unnecessarily coupling some pages to the
service.
HomePage:
setResponsePage(new FirstPage(service));
FirstPage:
setResponsePage(new SecondPage(service));
You have a point here. But if FirstPage does link to say 5 other pages and
these link to other Pages I will end up creatig a whole page-net in
advance and keeping it in the session. So if I don't want to do that for
testing FirstPage needs the reference: I want to use a MockService. So I
do new FirstPage(mockService). Than if the firstPage dose in Link.onClick
create a new secondPage instance,it is the only way to give further the
mockService if the firstPage actually has the mockService.
BTW: when I use the SpringBean annotation. I never provide beanNames as
literals but as public static final constants. Just in case the beanName
changes once.
>
> I don't know if IoC means the container must manage the lifecycle, I
> would go for something like "the environment is the responsible".
> Using AspectJ you are setting the environment to do DI for you, so
> inverting the control; the page (or its superclass) is not looking for
> the dependency, an outside code it is.
Please see the arictel of Fowlers
(http://www.martinfowler.com/articles/injection.html). According to this
articel I'd say both AspectJ and the Injector use more the
ServiceLocator
pattern than DI. The ServiceLocator is the SpringContext. Something
Spring
is very proud of is that no bean is dependent on the ApplicationContext
(because of DI). However this is not true for either the AspectJ
approach
nor the current Injector approach, because you'll always need a
ApplicationContext to look up the bean to inject.
I am pretty sold on this. If you take what Igor paste here from
hivemind, the aspect is the container, it does not have do be
Hivemind, Spring, Pico, etc. With AspectJ approach, the page is not
dependent at all at the ApplicationContext.
If you track dependencies you would have (for proxy based, something
like this):
MyPage -> SpringWebPage -> SpringInjector -> ApplicationContext
(with AspectJ)
MyPage -> SpringBean (the annotation)
SpringBeanAspect -> SpringBean (the annotation)
The page is only tied to the annotation, it does nothing about
ApplicationContext, no reference at all. There is no coupling between
the page and the aspect, that's why is a really IoC solution.
Somekind also the SpringBeanAscpect has to get to the ApplicatoinContext.
You are right it is not in the Java code but it is in the byte-code weaved
into the Page. IMO with - a theoratical kleen - DI like often in Spring
you'll not find any execution-path from within the Page wich will lead to
an ApplicationContext, because the bean does get what it needs from the
outside.
In the end I'd say this can be discussed for a long time, where it looks
like you have the better position, because you are right AspectJ is more
kleen in this way.
Beside this (the new) AspectJ has an issue with (old) CGLIB (see the
CGLIB
users list) and this is extensively used in a lot of projects (like
Hibernate, Spring etc).
I am having no problems at all.
I don't want to spread FUD here. When I read the stuff on the mailinglist
it shyed me away. Its quite involved. Maybe you can take a look yourself.
(As I read from the mailing-list it is not a problem of AspectJ but in
older versions of CGLIB which are still used a lot). And it also does not
adress your solition either.
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
