Igor --
Here is what I had:
class Bean1 {...}
class Bean2 {
public Bean2(Bean1 bean1) {}
}
Spring config:
<bean name="bean1" class="Bean1"/>
<bean name="bean2" class="Bean2">
<constructor-arg name="bean1" ref="bean1"/>
</bean>
class MyPanel extends Panel {
...
@SpringBean Bean2 bean2;
...
}
The problem was that bean2 could not initialize, it was looking for
empty constructor which the class didn't have and failed. I tried using
property initialization but ended up with null value for Bean1 and
methods of bean2 were failing with NPE.
I had another group of beans like that in the program which was working
fine.
Another thing that got me scared was that the initializer for Bean1 got
called twice: once on application initialization and once on
initialization of the page. I spent some time within initialization
code, CGLib and such and figured I needed much more time to figure out
what's happening there.
I will report more on this problem when I have time to assemble test
case. I have workaround now and I am on to the next problem -- see my
separate email.
Thanks,
-- Sasha
Igor Vaynberg wrote:
On Sun, Aug 31, 2008 at 3:44 PM, Sasha Ovsankin
<[EMAIL PROTECTED]> wrote:
You may end up with a solution that is quite convoluted, hard to
learn/maintain, less elegant and hard to get just right in all cases (for
example testing, serialization/deserialisation etc...).
We will see, but so far I have a solution that is under 100 LOC, works for
me and saves me from debugging in the internals of CGLib.
how does springbean require you to debug cglib internals?
Locatable<MyDAO> dao= new Locatable<MyDAO>("myDAO", MyDAO.class);
Locatable<MyDAO2> dao= new Locatable<MyDAO2>("myDAO2", MyDAO2.class);
vs
@SpringBean MyDAO dao;
@SpringBean MyDAO2 dao2;
i still like springbean :) also, considering most of the frameworks
use cglib anyways (spring, hibernate, etc) you dont really win
anything...
-igor
I will still report the parent problem when I have time to compose a test
case.
Thanks for your feedback,
-- Sasha
jWeekend wrote:
If you mark that DAO as transient, what will happen after deserialising
your
page? Will you implement your own serialisation strategy to go with your
home-made dependency injection mechanism?
Are you just trying to avoid using Spring or do you just not like
@SpringBean and the underlying Wicket proxying beneat h the covers? FYI,
it
has worked fine for us.
You may end up with a solution that is quite convoluted, hard to
learn/maintain, less elegant and hard to get just right in all cases (for
example testing, serialization/deserialisation etc...). But at the end of
the day, one of the key features of a framework like Wicket is that you
can
do anything that Java lets you - so the choice is always yours.
Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
Sasha Ovsankin wrote:
> Are you planning on serialising your DAOs?
No -- I mark them as "transient".
> How will you mock out your "Locator" for unit tests?
I didn't provide the implementation in the parent, but it's pretty
obvious:
/** Use for unit tests */
public static class MockLocator extends Locator {
HashMap<String, Object> map= new HashMap<String, Object>();
Object find(String name) {
return map.get(name);
}
public void put(String name, Object value) {
map.put(name, value);
}
}
class MyTest extends TestCase {
void setUp() {
MockLocator mockLocator= new MockLocator();
MyDAO dao= new MyDAO(...);
mockLocator.put("dao", dao);
Locator.register(mockLocator);
}
}
Hope this makes sense.
jWeekend wrote:
Are you planning on serialising your DAOs?
How will you mock out your "Locator" for unit tests?
Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
Sasha O-2 wrote:
Dear All --
I was having an issue with @SpringBean injection -- my dao class was
not initialized properly with the dependent beans. I spent some time
exploring internals of CGLib and Spring Injections and then a thought struck
me: how really helpful is this injection?
Consider this code:
class MyPage extends Page {
...
@SpringBean
MyDAO dao;
...
}
vs. this code:
class MyPage {
...
MyDAO dao= Locator.find("myDAO", MyDAO.class);
...
}
The Locator is a pretty straightforward guy who pulls
ApplicationContext out of thin air^^^^^ThreadLocal variable and looks up on
it, see the example code below.
The former uses annotations, CGLIB and delicate injection. The latter
uses nothing and is a lot simpler and robust. Aside from marginal savings in
typing I couldn't find any advantages of the former approach. Can you?
Unless convinced otherwise, I am going to skip the @SpringBean
altogether and use the Locator thing in my application.
Thanks,
-- Sasha
-----------------------------------------------------------------------
public abstract class Locator {
abstract Object find(String name);
static Locator locator= null;
public static Locator register(Locator inLocator) {
Locator result= locator;
locator= inLocator;
return result;
}
public static class SpringLocator extends Locator {
ApplicationContext context=
WebApplicationContextUtils.getRequiredWebApplicationContext(
WebApplication.get().getServletContext());
Object find(String name) {
return context.getBean(name);
}
}
/** To be called in the application initialization */
public static void registerSpringLocator() {
register(new SpringLocator());
}
/** Use for unit tests */
public static class MockLocator extends Locator {
@Override
Object find(String name) {
// TODO implement
return null;
}
}
public static<T> T find(String name, Class<T> clazz) {
Object found= locator.find(name);
if (found==null)
return null;
return clazz.cast(found);
}
}
-----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
