Sasha,
Does the trace at the end of this note, in my PS, look familiar?
Now try the following code (notice the addition and use of the IBean2
interface) - things should work once you make the type of the reference in
your component (a Page in this case) the interface. If you can't do that on
your
Sasha,
If you have time to make a minimal http://wicket.apache.org/quickstart.html
quickstart project that demonstrates the issue you might find that you can
save yourself "100 LOC", or at least that someone here will spot what's not
right and then you can make your decision.
Regards - Cemal
h
Igor --
Here is what I had:
class Bean1 {...}
class Bean2 {
public Bean2(Bean1 bean1) {}
}
Spring config:
class MyPanel extends Panel {
...
@SpringBean Bean2 bean2;
.
On Sun, Aug 31, 2008 at 7:00 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> i still like springbean :) also, considering most of the frameworks
> use cglib anyways (spring, hibernate, etc) you dont really win
> anything...
+1. @SpringBean has been no trouble for me.
-
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
Cemal --
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?
By using little extra indirection we can solve this, too -- see my other
email to the list.
> class constructor is not called after deserialization...
Oops, I didn't know that :-$
In this case, I will need to use extra indirection; still pretty
straightforward:
class MyPage ... {
...
Locatable dao= new Locatable("myDAO", MyDAO.class);
...
dao.get().findSom
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 pr
class constructor is not called after deserialization...
-igor
On Sun, Aug 31, 2008 at 12:31 PM, Sasha Ovsankin
<[EMAIL PROTECTED]> wrote:
>> what happens after your page is serialized and deserialized, then dao > is
>> null...
>
> The dao field is supposed to be initialized again in the class co
> what happens after your page is serialized and deserialized, then dao
> is null...
The dao field is supposed to be initialized again in the class constructor.
Igor Vaynberg wrote:
what happens after your page is serialized and deserialized, then dao is null...
-igor
On Sun, Aug 31, 2008 at
what happens after your page is serialized and deserialized, then dao is null...
-igor
On Sun, Aug 31, 2008 at 12:09 PM, Sasha Ovsankin
<[EMAIL PROTECTED]> wrote:
>>> The problem is keeping a reference to the service.
>
> Right, actually I skipped the "transient" keyword I use in my code:
>
>
The problem is keeping a reference to the service.
Right, actually I skipped the "transient" keyword I use in my code:
class MyPage {
...
transient MyDAO dao= Locator.find("myDAO", MyDAO.class);
...
}
"transient" prevents the field from being se
> 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 Lo
Did you read http://cwiki.apache.org/WICKET/spring.html and see why
@SpringBean is important?
The problem is keeping a reference to the service. You might be good
enough to understand that, but how good do you trust your co-workers,
and even new members joining your team?
Martijn
On Sun, Aug 31,
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 proper
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:
Dear All --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
17 matches
Mail list logo