done.
-Igor
On 11/17/05, Christian Essl <[EMAIL PROTECTED]> wrote:
On Wed, 16 Nov 2005 23:50:11 -0800, Igor Vaynberg<[EMAIL PROTECTED]> wrote:>>
http://cvs.sourceforge.net/viewcvs.py/wicket-stuff/wicket-contrib-spring/src/java/wicket/contrib/> here i can see the proxy/injection/spring packages, so
On Wed, 16 Nov 2005 23:50:11 -0800, Igor Vaynberg
<[EMAIL PROTECTED]> wrote:
http://cvs.sourceforge.net/viewcvs.py/wicket-stuff/wicket-contrib-spring/src/java/wicket/contrib/
here i can see the proxy/injection/spring packages, so its up to date.
Thanks now I can also check it out.
One final
I think the web-access is also not uptodate
http://cvs.sourceforge.net/viewcvs.py/wicket-stuff/wicket-contrib-spring/
http://cvs.sourceforge.net/viewcvs.py/wicket-stuff/wicket-contrib-spring/src/java/wicket/contrib/
here i can see the proxy/injection/spring packages, so its up to date.
I was just
On Wed, 16 Nov 2005 08:32:06 -0800, Igor Vaynberg
<[EMAIL PROTECTED]> wrote:
yes it should all still be in the cvs in the same project. there are a
few
more packages in that project, wicket.contrib.proxy and
wicket.contrib.injection. Johan said he was having weird issues with cvs
also, not sur
yes it should all still be in the cvs in the same project. there are a
few more packages in that project, wicket.contrib.proxy and
wicket.contrib.injection. Johan said he was having weird issues with
cvs also, not sure what i can do about that.
Im not sure about the injector being created as a spr
Sorry for my late replay and thanks for fixing all you did. Unfortunately
I can still not find the code which does not forward finalize and has the
IFieldValueFactory. Is it still in wicket-contrib-spring - is it tagged?
Do you mind if i put your stuff into the main project? Not sure how to
ma
fixed the serialization problem. it was just too tired last night to see it.
-Igor
On 11/12/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
ok, lots more refactoring in.
lazy init proxies now intercept hashcode,equals,tostring,finalize.
i tried implementing writereplace and readresolve but it doesn
Looking at your code makes me want to think we can use some abstract
classes. The fact that you extended SpringInjector instead of
ProxyInjector ... i will need to come up with something for that...
Do you mind if i put your stuff into the main project? Not sure how to
manage this stuff best...plu
fixed the serialization problem. it was just too tired last night to see it.
-Igor
On 11/12/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
ok, lots more refactoring in.
lazy init proxies now intercept hashcode,equals,tostring,finalize.
i tried implementing writereplace and readresolve but it doesn
Thanks a lot for doing this. Unfortunately I can still not check out the
changes. When I can I'll take a look at the LazyInitProxyFactory.
Christian
On Sat, 12 Nov 2005 01:12:21 -0800, Igor Vaynberg
<[EMAIL PROTECTED]> wrote:
ok, lots more refactoring in.
lazy init proxies now intercept ha
ok, lots more refactoring in.
lazy init proxies now intercept hashcode,equals,tostring,finalize.
i tried implementing writereplace and readresolve but it doesnt seem to
be working, getting another weird class cast exception. writereplace
works fine, and the object it generates deserializes into a
On Fri, 11 Nov 2005 14:51:16 -0800, Igor Vaynberg
<[EMAIL PROTECTED]> wrote:
i was actually thinking of creating a CompoundObjectLocatorFactory which
would try its children until one returns a non-null.
will try to get to that tonight as well :)
That's better than my suggestion - Thank you
i was actually thinking of creating a CompoundObjectLocatorFactory which would try its children until one returns a non-null.
will try to get to that tonight as well :)
-Igor
On 11/11/05, Christian Essl <[EMAIL PROTECTED]> wrote:
Igor made it quite easy to add your own way to inject things (not j
Igor made it quite easy to add your own way to inject things (not just
SpringBeans). You just implement your own IObjectLocatorFactory and extend
the SpringInjector to use this one.
Enclosed is some code which uses jakarta commons-attributes to do the same
thing as JDK1.5 annotations does with
yeah, you are right. i will try to add that stuff in tonight.
-Igor
On 11/11/05, Christian Essl <[EMAIL PROTECTED]> wrote:
The code realy looks good.Concerning the Proxy. For the cglib proxy you should definately notforward the call to finalize(), because when the proxy gets GC it willcall finaliz
unlike annotations javadocs are not present at runtime, so i dont see a
way to extract that metadata without some code generation step.
a simple approach for 1.4 would be to "autowire" the dependencies.
1) try to find a bean with name==field.name and type==field.type
2) if 1 fails try to lookup be
I would be very interested in a 1.4 port of this. Do you think it
could use the same annotation based approach, but using Qdox to
process instead of the built in 1.5 annotation functionality?
On 11/11/05, Christian Essl <[EMAIL PROTECTED]> wrote:
> The code realy looks good.
>
> Concerning the Pr
The code realy looks good.
Concerning the Proxy. For the cglib proxy you should definately not
forward the call to finalize(), because when the proxy gets GC it will
call finalize() on the target and that is not what you want. I think same
reasons apply for the other Object methods except equa
more refactoring/tests and some new things:
SpringWebApplicationFactory - which will pull the webapplication subclass out of spring application context
SpringInjector/SpringWebApplica
tion - make it very simple to inject objects using @SpringBean annotation with lazy-init proxies
SpringWebPa
It is in wicket-stuff under wicket-contrib-spring. And there in the
wicket.contrib.spring.injection package.
Christian
On Thu, 10 Nov 2005 00:07:44 +0200, Alexandru Popescu
<[EMAIL PROTECTED]> wrote:
Looks like I've missed the part of where is this work available. Is it a
way to access i
Unfortunately the public cvs is late so I can't see your changes yet.
Anyway before I've read this mail I started on reworking the proxing code
(attached). SerializableLazyProxyCreator is the only thing with content
the others are interfaces and one (basic) test.
There are quite some changes:
round 1 of refactoring is in. its much more elegant now. feedback please.
-Igor
On 11/8/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
thats pretty much exactly what i was thinking.
-Igor
On 11/8/05, Christian Essl <[EMAIL PROTECTED]
> wrote:
Very good. I am still playing around with the writeReplac
thats pretty much exactly what i was thinking.
-Igor
On 11/8/05, Christian Essl <[EMAIL PROTECTED]> wrote:
Very good. I am still playing around with the writeReplace thing.Regarding the refactoring what do you thing about this:Instead of the ISpringContextLocator have ainterface ObjectResolverFacto
Very good. I am still playing around with the writeReplace thing.
Regarding the refactoring what do you thing about this:
Instead of the ISpringContextLocator have a
interface ObjectResolverFactory{
ObjectResolver getObjectResolver(Field field);
}
interface ObjectResolver{
Object resolve();
ok, got the pure cglib solution working.
just had to call enhancer.setInterfaces(new Class[] { Serializable.class}) to weave in the serializable interface.
now it appears everything is working. sweet.
i am going to do a lot of refactoring today. maybe you can make your
wrappingcontext use the same
I would rather weave it in using cglib and stay away from a
spring-specific proxy impl, becuase this thing can easily be
generalized to things beyound spring, like jndi lookups, etc.
-Igor
On 11/8/05, Christian Essl <[EMAIL PROTECTED]> wrote:
On Tue, 8 Nov 2005 11:59:22 -0800, Igor Vaynberg <[EMAI
On Tue, 8 Nov 2005 11:59:22 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
Im still getting a class cast exception using cglib directly. im probably
doing something dumb, you want to take a look? SpringInitializer line 61
is
commented out, thats where proxies are created for concrete objects
Im still getting a class cast exception using cglib directly. im
probably doing something dumb, you want to take a look?
SpringInitializer line 61 is commented out, thats where proxies are
created for concrete objects.
By the way, the spring one works fine IF the dependency implements
Serializable
I do not know wheter read/writeObject is called on objects referenced from
session attributes ("full serialization closure"). However the spec does
not speak about writeReplace()
and readResolve() so 'legaly' you should be on the right side if you rely
on these.
Enclosed is some code which I g
It is more for components:
//constructor
public OrderPage(){
add(new
CustomerPanel("customer",getWrappingContext().getBean("customerDAO",CustomerDAO.class));
}
Just for normal DI in code.
Christian
On Tue, 8 Nov 2005 08:31:47 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
What I'm work
What I'm working on now is an ApplicationContext which wrapps the 'real'ApplicationContext and does create for getBean() etc automatically the
proxies. I think this way I'll never have to worry about the serializationproblem for such beans.
but what will inject your pages?
-Igor
there are too many gotchas like this with doing it from the inside. i
would make the page constructors protected and create simple static
factory methods that create the page and then do the injection.
-Igor
On 11/8/05, Christian Essl <[EMAIL PROTECTED]> wrote:
Yes you are right!I was now more thi
Yes you are right!
I was now more thinking of Igors proposal todo the 'injection' from the
outside:
MyComponent comp = new MyComponent("id");
//set this and that
SpringInitializer.initialize(comp,locator);
If you'd do it from the inside (as the original code) it is a different
story.
I don
Just of my head two further suggestions:1.) If a field is not null than do not inject anything. This way custom
injections could be done
Fields are always null because they are not initialized yet by the sub class
(when having a super class that does the injections)
Wow great job Igor. Thanks for doing it. I think that's the proper way to
go.
Regarding cglib I think you should use spring AOP (it is already a
dependency and generalization can wait a bit). Spring AOP handles all that
and a bit more and is easy to use. Ie for cglib like in the current
imple
I think there should be both of your implementations.
IMO the constructor based impl should have the protected doInject method,
because to me it seems to be the easiest way to inject manually services
in the constructor without the need to manually proxy them.
Yes with cglib we'll hit the fin
That's right. That's propably the cleanest way and you can use it on each
component.
The problem why I came up with the constructor aproach initially was that
generally all the subcomponents are created and setup in the constructor.
And it would than be IMO more wicket like if you can also inj
mensagem original --- De: [EMAIL PROTECTED]
Para: wicket-user@lists.sourceforge.net Cc:Data: Mon, 7 Nov 2005 13:56:39 -0200 Assunto: Re: Re: [Wicket-user] My take on Spring integration
> PS.: Someone responded this thread in a way that gmail (only gmail?)> could not find
l changes to object interfaces
have to be done by hand.
[]s Gus
-- Início da mensagem original ---
De: [EMAIL PROTECTED]
Para: wicket-user@lists.sourceforge.net
Cc:
Data: Mon, 7 Nov 2005 13:56:39 -0200
Assunto: Re: Re: [Wicket-user] My take on Spri
Unfortunately I think this does not work.
Actually cglib creates at runtime a subclass where you can override
methods and as with any java code you can not override final (or private)
methods. So when a non overridable method is called on the proxy it is not
possible to delegate it and any sta
yes. but instead of doing the injection right away the proxy would do injection-on-first-access.
that way you get lazy injection and strongly typed pages.
so you would annotate getter functions with the @SpringBean annot, and
the proxy would first call the getter ... if the getter returns null
the
Do you mean when you construct the page you do something like
MyPage page = (MyPage) wrapInProxy(new MyPage(..));
and wrapInProxy does create the Proxy and does all the injection?
On Mon, 7 Nov 2005 11:56:23 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
yeah, i was thinking cglib and ext
yeah, i was thinking cglib and extract at runtime
never used cglib before though
that way you just wrap the page with the proxy after you create it and
there is no need to worry about serialization/deserialiation garbage
-Igor
On 11/7/05, Christian Essl <[EMAIL PROTECTED]> wrote:
The interface of
The interface of the setter parameter or of the field type. Of course a
restriction. If you want more you could use cglib (or spring aop). Don't
know.
On Mon, 7 Nov 2005 11:27:28 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
what interface would you use for the proxy though?
-Igor
On
what interface would you use for the proxy though?
-Igor
On 11/7/05, Christian Essl <[EMAIL PROTECTED]> wrote:
Thanks for the clarification and sorry for the confusion. So readObject()as you have it in your code is fine.> To get the bean context i simply make my applicationbean implement> applicati
Thanks for the clarification and sorry for the confusion. So readObject()
as you have it in your code is fine.
To get the bean context i simply make my applicationbean implement
applicationcontextaware and then i use
((MyApplication)Application.get()).getBeanContext() static lookup which
works
I think with xml sereialization getobject is never called so there we
still have a problem. But i think when the pagemap will deserialize the
page if normal serialization is used then the readobject will be called
on the page.
The serialization closure, i think, reffers to the fact that container
On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner <[EMAIL PROTECTED]>
wrote:
And there is also a thing like XML Serialization
Which also doesn't use the java read/write object at all.
Does this mean that the readObject is guaranteed to be called on Page
because it is serialized through the
Yes, it is not ioc, i never claimed it was. Sven's page factory is not
ioc either because the container does not manage the lifecycle of the
page.
Does an ioc page make sense? I dont think so. I like to use the new
operator to instantiate pages myself, I also really like to have
strongly typed con
PS.: Someone responded this thread in a way that gmail (only gmail?)
could not find it associated with previous messages, I hope people
continue to discuss and keep this, and not open a new thread with (AW:
Re: Re: My take on Spring integration).
Igor, the class you have implemented is exactly the
Those method names are really wrong.
Because those are not called when a request begins they are called when
the response begins so it should be called
onBeginRespond()/onEndRespond()
onBeginRequest() should also be there but that one should be called right after the page is reconstructed from the
Maybe RequestCycle.onBegin/EndRequest is what you are looking for?
Juergen
On 11/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi Igor,
>
> >here is something i threw together that solves the deserialization
> >>andability to use the new operator to create pages.
>
> thanks for your work
Hi Igor,
>here is something i threw together that solves the deserialization >andability
>to use the new operator to create pages.
thanks for your work on this.
Regretfully it's still a solution I wouldn't like to use:
IMHO dependency injection should not be done by the object which has the
d
>and you have to have the pages defined as beans in the application >context?
>with their properties specified?
Yes, I configure most wicket stuff in a separate context, which is bootstrapped
by a custom application factory:
>but how does the above handle deserealization of pages?
>
And there is also a thing like XML Serialization
Which also doesn't use the java read/write object at all.
On 11/7/05, Christian Essl <[EMAIL PROTECTED]> wrote:
Hi Igor,I looked through your code. Thanks for implementing it. I am not surewheter readObject() is the right place to do the (re)injectio
Hi Igor,
I looked through your code. Thanks for implementing it. I am not sure
wheter readObject() is the right place to do the (re)injection. According
to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be
called on session-attributes. (Instead session attributes which implem
here is something i threw together that solves the deserialization and
ability to use the new operator to create pages. atleast i think it
doesits really late here and all i really know so far is that it
compiles :)
the idea is pretty simple, do the injection in the default constructor,
and th
and you have to have the pages defined as beans in the application context? with their properties specified?
-Igor
On 11/7/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
but how does the above handle deserealization of pages? there is nothing to reinject the dependencies.
-Igor
On 11/7/05, [EMAIL P
but how does the above handle deserealization of pages? there is nothing to reinject the dependencies.
-Igor
On 11/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
IMHO pages are standing on the borderline between a stateful GUI and the rest of the application in form of stateless services.DI
sh
if you want to create youre own page factory. And use PagePArameters
for everything to supply params back and forth you are ofcourse free to
do that right now.
On 10/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>An EditUserPage for example cannot be bookmarkable>>because it needs to know wh
>>An EditUserPage for example cannot be bookmarkable
>>because it needs to know which user to edit.
IMHO an EditUserPage parameterized with a userId is a perfect match for a
bookmarkable URL.
I didn't say, I'd never use setResponsePage(..).
If I have large transactional state to be transferred t
Furthermore, it is an excellent way of passing models/ other state to pages.
Eelco
On 10/24/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> i completely agree with igor.
> I use setResponsePage(new XxxPage(yy)) all over the place.
> I find this kind of code the most readable what you can get.
i completely agree with igor.
I use setResponsePage(new XxxPage(yy)) all over the place.
I find this kind of code the most readable what you can get.
No magic. A person can directly see what really happens.
johan
On 10/24/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >> 2) to use the page factory
> >> 2) to use the page factory your pages can only have the default or
> >> PageParameter constructors. This prevents you from doing
> things like
> >> setResponsePage(new EditUserPage(userId));
>
> That is the price to pay for IoC: you have to let the factory
> create the beans.
> BTW I don'
64 matches
Mail list logo
