Re: Avoid serialization troubles with static members
no because the component isnt instantiated so that wount be called. after
deserialization that field will be null.
maybe you could bulid in a container/page a deserialize hook and when that
is called go over all your components and inject it again
johan
On Thu, Feb 19, 2009 at 08:41, Martin Sachs sachs.mar...@gmail.com wrote:
Hi
If we use @SpringBean we have automaticaly a serialized proxy object. Is it
possible to use a transient variable to avoid the serialization at all ?
public MyPanel extends Panel{
@SpringBean(name=myserviceBean)
private transient MyServiceInterface service;
...
}
What do we need to inject the service after de-serialization ? We have the
ComponentInstantiationListener, maybe this would work also with transient ?
Martin
--
View this message in context:
http://www.nabble.com/Avoid-serialization-troubles-with-static-members-tp22082899p22095373.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
AW: Avoid serialization troubles with static members
Thanks for your answer.
Wouldn't it be sufficient to use a static member to hold a reference to a
service? i.e.
public class SomeWicketComponent{
private static MyService service;
// ...
}
How would you intialize these? Would you have a static getter, and force
yourself to remember to always use it? Or would you have a static setter
and centralize the initialization code somewhere else? Either way sounds
ugly to me.
This is the DI problem, but in this step I only regarded the serialization
problem. I wanted to fetch object as you described it:
MyService svc = (MyService) MyApp.getBean(myService);
Let's see, where to start...
- it's ugly
- the cast and the bean name can fail in a way that is only detectable
at runtime
- it ties all your components to your application class
- it's difficult to test, since you need to mock up a MyApp instance for
your component to work
You're right. My solution is like a solution without DI and with all the
dependency troubles DI should avoid.
What don't you like about them?
Annotations are often missused and they bring a declarative programming style
to Java. Sometimes you don't know what happens in the background. A programm
can better be understood if you can follow the instruction instead of guessing
how annotions will be interpreted. I think of Spring MVC where a @Controller
exists. It indicates that you want the class to be a controller. But you don't
see how the controller must look like, you don't see that you need other
annotations to get your controller working. The old style with extendig some
framework classes are much more readable but a bit more verbose.
But there are also some good use cases for annotations like JPA and maybe the
mentonioned annotation to integrate Spring in Wicket.
I tried to use Spring integration but failed. I wonder about the class
org.apache.wicket.spring.injection.annot.SpringComponentInjector mentioned in
the API doc. This class does not exist! I've only found
wicket.spring.injection.annot.SpringComponentInjector. The missing org.apache
should be irrelevant, but the following example doesn't work:
package some.package;
import org.apache.wicket.Page;
import org.apache.wicket.protocol.http.WebApplication;
import wicket.spring.injection.annot.SpringComponentInjector;
public class WickiApplication extends WebApplication
{
@Override
public void init()
{
addComponentInstantiationListener(new SpringComponentInjector(this));
}
// ...
}
The compiler says: cannot find symbol. symbold: constructor
SpringComponentInjector(...)
SpringComponentInjector is on the classpath, the import is correct, but it
doesn't work. Have you any idea why?
Thanks.
Christian
--
http://www.groovy-forum.de
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Avoid serialization troubles with static members
but if you just use static fields then the only thing you have to do in your app is when the Application.init() is called you just set them once through a static setter on that component. (or reflection) So you have to do all your injection over your components onces at startup of your application. You just inject class instances not object instances johan On Thu, Feb 19, 2009 at 11:27, Christian Helmbold christian.helmb...@yahoo.de wrote: a static service inside a component? Why not? Services are typically singletons and I can't see a problem to share an instance. From the dependency point of view it is equal to use * static Service svc, * transient Service svc or * Service svc I think the disadvantage of my solution is the inversion of inversion of control ;-) But even if I start to use the Spring annotation, I'm interested in possible disadvantages of using static members to avoid serialization. Maybe there will be a use case where dependencies are not important ... Thanks. Christian -- http://www.groovy-forum.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: Avoid serialization troubles with static members
if the org.apache is missing, you're using an old version of wicket. check
your dependencies for 1.2 versions (the version before wicket moved to
apache)
for the DI stuff: I'm using the annotation approach throughout my
applications and never had any problems
regards,
Michael
christian.helmbold wrote:
Thanks for your answer.
Wouldn't it be sufficient to use a static member to hold a reference to
a
service? i.e.
public class SomeWicketComponent{
private static MyService service;
// ...
}
How would you intialize these? Would you have a static getter, and force
yourself to remember to always use it? Or would you have a static setter
and centralize the initialization code somewhere else? Either way sounds
ugly to me.
This is the DI problem, but in this step I only regarded the serialization
problem. I wanted to fetch object as you described it:
MyService svc = (MyService) MyApp.getBean(myService);
Let's see, where to start...
- it's ugly
- the cast and the bean name can fail in a way that is only detectable
at runtime
- it ties all your components to your application class
- it's difficult to test, since you need to mock up a MyApp instance for
your component to work
You're right. My solution is like a solution without DI and with all the
dependency troubles DI should avoid.
What don't you like about them?
Annotations are often missused and they bring a declarative programming
style to Java. Sometimes you don't know what happens in the background. A
programm can better be understood if you can follow the instruction
instead of guessing how annotions will be interpreted. I think of Spring
MVC where a @Controller exists. It indicates that you want the class to be
a controller. But you don't see how the controller must look like, you
don't see that you need other annotations to get your controller working.
The old style with extendig some framework classes are much more readable
but a bit more verbose.
But there are also some good use cases for annotations like JPA and maybe
the mentonioned annotation to integrate Spring in Wicket.
I tried to use Spring integration but failed. I wonder about the class
org.apache.wicket.spring.injection.annot.SpringComponentInjector mentioned
in the API doc. This class does not exist! I've only found
wicket.spring.injection.annot.SpringComponentInjector. The missing
org.apache should be irrelevant, but the following example doesn't work:
package some.package;
import org.apache.wicket.Page;
import org.apache.wicket.protocol.http.WebApplication;
import wicket.spring.injection.annot.SpringComponentInjector;
public class WickiApplication extends WebApplication
{
@Override
public void init()
{
addComponentInstantiationListener(new SpringComponentInjector(this));
}
// ...
}
The compiler says: cannot find symbol. symbold: constructor
SpringComponentInjector(...)
SpringComponentInjector is on the classpath, the import is correct, but it
doesn't work. Have you any idea why?
Thanks.
Christian
--
http://www.groovy-forum.de
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
Michael Sparer
http://techblog.molindo.at
--
View this message in context:
http://www.nabble.com/Avoid-serialization-troubles-with-static-members-tp22082899p22097988.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
AW: AW: Avoid serialization troubles with static members
if the org.apache is missing, you're using an old version of wicket. I use Wicket 1.4 RC2. Maybe I use an old version (1.2.7) of the Spring integration. Where can I get the current version? http://cwiki.apache.org/WICKET/spring.html says nothing about where to download it (without maven).. Regards, Christian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: AW: Avoid serialization troubles with static members
then I'd recommend using maven (or similar) :-) managing all dependencies manually seems to me quite masochistically and yepp, you're using an old version of spring integration then ... christian.helmbold wrote: if the org.apache is missing, you're using an old version of wicket. I use Wicket 1.4 RC2. Maybe I use an old version (1.2.7) of the Spring integration. Where can I get the current version? http://cwiki.apache.org/WICKET/spring.html says nothing about where to download it (without maven).. Regards, Christian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - Michael Sparer http://techblog.molindo.at -- View this message in context: http://www.nabble.com/Avoid-serialization-troubles-with-static-members-tp22082899p22098368.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: AW: Avoid serialization troubles with static members
Yes, but if the frameworks and tools can make you actually more productive, why not use them? The @SpringBean annotation-based approach just works. I've never had any troubles with it and I really don't have to think about it. There's a very shallow learning curve, especially if you're already using Spring. If I've got a need for something in my spring context, I create a field for it and slap that annotation on it and I'm done. I don't have to make sure I initialize some static field in my application class. I don't have to worry about serialization issues. It just works. As Ron Burgundy said, sixty percent of the time, it works every time. :) On Thu, Feb 19, 2009 at 6:38 AM, Christian Helmbold christian.helmb...@yahoo.de wrote: then I'd recommend using maven (or similar) :-) I try to use only tools I really nead. Sometimes it seems to me that in Java programming most time is spent in frameworks and tools and not in the programming itself. But, yes, I know the JAR hell and time for maven (or Ivy?) has been come to me ... Regards, Christian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: Avoid serialization troubles with static members
If you don't want to use maven, then download the distribution of Wicket, and look in the lib folder. All the wicket jars are there. How did you get wicket-1.4-rc2.jar then? Martijn On Thu, Feb 19, 2009 at 12:10 PM, Christian Helmbold christian.helmb...@yahoo.de wrote: if the org.apache is missing, you're using an old version of wicket. I use Wicket 1.4 RC2. Maybe I use an old version (1.2.7) of the Spring integration. Where can I get the current version? http://cwiki.apache.org/WICKET/spring.html says nothing about where to download it (without maven).. Regards, Christian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: AW: Avoid serialization troubles with static members
vi is not only a tool, but a whole platform, so that would exclude it. Personally, I find that echo import org.apache.wicket.* MyClass.java echo import java.util.* MyClass.java works best. :) j/k j/k -- Jeremy Thomerson http://www.wickettraining.com On Thu, Feb 19, 2009 at 10:40 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: so you only use javac, java, and vi? :) -igor On Thu, Feb 19, 2009 at 3:38 AM, Christian Helmbold christian.helmb...@yahoo.de wrote: then I'd recommend using maven (or similar) :-) I try to use only tools I really nead. Sometimes it seems to me that in Java programming most time is spent in frameworks and tools and not in the programming itself. But, yes, I know the JAR hell and time for maven (or Ivy?) has been come to me ... Regards, Christian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: AW: Avoid serialization troubles with static members
javac is kinda redundant too. Real men sling raw bytecode. jk On Thu, Feb 19, 2009 at 12:02:36PM -0600, Jeremy Thomerson wrote: vi is not only a tool, but a whole platform, so that would exclude it. Personally, I find that echo import org.apache.wicket.* MyClass.java echo import java.util.* MyClass.java works best. :) j/k j/k -- Jeremy Thomerson http://www.wickettraining.com On Thu, Feb 19, 2009 at 10:40 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: so you only use javac, java, and vi? :) -igor On Thu, Feb 19, 2009 at 3:38 AM, Christian Helmbold christian.helmb...@yahoo.de wrote: then I'd recommend using maven (or similar) :-) I try to use only tools I really nead. Sometimes it seems to me that in Java programming most time is spent in frameworks and tools and not in the programming itself. But, yes, I know the JAR hell and time for maven (or Ivy?) has been come to me ... Regards, Christian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Avoid serialization troubles with static members
I've read http://cwiki.apache.org/WICKET/spring.html and the corresponding
section in Wicket in Action about the troubles with serialization of injected
services.
Dependencies often have references to other dependencies in the
container, and so if one is serialized it will probably serialize a few
others and can possibly cascade to serializing the entire container.
(http://cwiki.apache.org/WICKET/spring.html)
As
far as I understand this is not a dependency injection specific issue.
In either case all referenced objects are serialized recursively. So I
think I have to take care about serialization not only when using
Spring or Guice.
Wouldn't it be sufficient to use a static member to hold a reference to a
service? i.e.
public class SomeWicketComponent{
private static MyService service;
// ...
}
Remains
the problem with the injection. To solve this the mentioned website
suggests several ways. The Application Object Approach seems to be most
wicket like to me. But as mentioned there it is very verbose. Why not
simply insert a method to deliver requested beans into the Application
class? It would look like this:
class MyApplication extends WebApplication {
private ApplicationContext ctx = new ClassPathXmlContext(context.xml); //
Spring context
public Object getBean(String beanName){
return ctx.getBean(beanName);
}
}
Is
anything wrong with it? I find it much more elegant than to store a
reference for each bean in in the application class as suggested on
http://cwiki.apache.org/WICKET/spring.html#Spring-ApplicationObjectApproach.
Maybe the annotation-based approach is a bit more elegant but I don't like
annotations much.
It
seems to me, that dependency injection (DI) and wicket is not a dream
team. Do you use DI with Wicket or do you use the classic approach
like Wicket itself does?
Thanks.
Christian
--
www.groovy-forum.de
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Avoid serialization troubles with static members
I've read http://cwiki.apache.org/WICKET/spring.html and the corresponding
section in Wicket in Action about the troubles with serialization of injected
services.
Dependencies often have references to other dependencies in the
container, and so if one is serialized it will probably serialize a few
others and can possibly cascade to serializing the entire container.
(http://cwiki.apache.org/WICKET/spring.html)
As far as I understand this is not a dependency injection specific issue. In
either case all referenced objects are serialized recursively. So I think I
have to take care about serialization not only when using Spring or Guice.
Wouldn't it be sufficient to use a static member to hold a reference to a
service? i..e.
public class SomeWicketComponent{
private static MyService service;
// ...
}
Remains the problem with the injection. To solve this the mentioned website
suggests several ways. The Application Object Approach seems to be most wicket
like to me. But as mentioned there it is very verbose. Why not simply insert a
method to deliver requested beans into the Application class? It would look
like this:
class MyApplication extends WebApplication {
private ApplicationContext ctx = new ClassPathXmlContext(context.xml); //
Spring context
public Object getBean(String beanName){
return ctx.getBean(beanName);
}
}
Is anything wrong with it? I find it much more elegant than to store a
reference for each bean in in the application class as suggested on
http://cwiki.apache.org/WICKET/spring.html#Spring-ApplicationObjectApproach.
Maybe the annotation-based approach is a bit more elegant but I don't like
annotations much.
It seems to me, that dependency injection (DI) and wicket is not a dream team.
Do you use DI with Wicket or do you use the classic approach like Wicket
itself does?
Thanks.
Christian
--
www..groovy-forum.de
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Avoid serialization troubles with static members
a static service inside a component?
why would you have that? that sounds weird to me
Then you share that services over all sessions, if that is the case then you
can just as well make it a single ton class by itself
(MyService.getInstance())
johan
On Wed, Feb 18, 2009 at 15:52, Christian Helmbold cryptos...@yahoo.dewrote:
I've read http://cwiki.apache.org/WICKET/spring.html and the corresponding
section in Wicket in Action about the troubles with serialization of
injected services.
Dependencies often have references to other dependencies in the
container, and so if one is serialized it will probably serialize a few
others and can possibly cascade to serializing the entire container.
(http://cwiki.apache.org/WICKET/spring.html)
As far as I understand this is not a dependency injection specific issue.
In either case all referenced objects are serialized recursively. So I think
I have to take care about serialization not only when using Spring or Guice.
Wouldn't it be sufficient to use a static member to hold a reference to a
service? i..e.
public class SomeWicketComponent{
private static MyService service;
// ...
}
Remains the problem with the injection. To solve this the mentioned website
suggests several ways. The Application Object Approach seems to be most
wicket like to me. But as mentioned there it is very verbose. Why not simply
insert a method to deliver requested beans into the Application class? It
would look like this:
class MyApplication extends WebApplication {
private ApplicationContext ctx = new ClassPathXmlContext(context.xml);
// Spring context
public Object getBean(String beanName){
return ctx.getBean(beanName);
}
}
Is anything wrong with it? I find it much more elegant than to store a
reference for each bean in in the application class as suggested on
http://cwiki.apache.org/WICKET/spring.html#Spring-ApplicationObjectApproach
.
Maybe the annotation-based approach is a bit more elegant but I don't like
annotations much.
It seems to me, that dependency injection (DI) and wicket is not a dream
team. Do you use DI with Wicket or do you use the classic approach like
Wicket itself does?
Thanks.
Christian
--
www..groovy-forum.de
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Avoid serialization troubles with static members
I agree with John Krasnay
I am new to wicket( 2 months old) but I find @SpringBean very easy to
use and it minimizes the spring-context concern while developing the
application.
and I think avoiding annotations is something you wont be able to do for long..
tawus
On Wed, Feb 18, 2009 at 11:36 PM, John Krasnay j...@krasnay.ca wrote:
On Wed, Feb 18, 2009 at 04:45:26PM +, Christian Helmbold wrote:
I've read http://cwiki.apache.org/WICKET/spring.html and the corresponding
section in Wicket in Action about the troubles with serialization of
injected services.
Dependencies often have references to other dependencies in the
container, and so if one is serialized it will probably serialize a few
others and can possibly cascade to serializing the entire container.
(http://cwiki.apache.org/WICKET/spring.html)
As
far as I understand this is not a dependency injection specific issue.
In either case all referenced objects are serialized recursively. So I
think I have to take care about serialization not only when using
Spring or Guice.
Wouldn't it be sufficient to use a static member to hold a reference to a
service? i.e.
public class SomeWicketComponent{
private static MyService service;
// ...
}
How would you intialize these? Would you have a static getter, and force
yourself to remember to always use it? Or would you have a static setter
and centralize the initialization code somewhere else? Either way sounds
ugly to me.
Remains
the problem with the injection. To solve this the mentioned website
suggests several ways. The Application Object Approach seems to be most
wicket like to me. But as mentioned there it is very verbose. Why not
simply insert a method to deliver requested beans into the Application
class? It would look like this:
class MyApplication extends WebApplication {
private ApplicationContext ctx = new ClassPathXmlContext(context.xml);
// Spring context
public Object getBean(String beanName){
return ctx.getBean(beanName);
}
}
Is
anything wrong with it?
The problem is you'll end up with code like this sprinkled throughout
your app:
MyService svc = (MyService) MyApp.getBean(myService);
Let's see, where to start...
- it's ugly
- the cast and the bean name can fail in a way that is only detectable
at runtime
- it ties all your components to your application class
- it's difficult to test, since you need to mock up a MyApp instance for
your component to work
I find it much more elegant than to store a
reference for each bean in in the application class as suggested on
http://cwiki.apache.org/WICKET/spring.html#Spring-ApplicationObjectApproach.
I don't find either very elegant.
Maybe the annotation-based approach is a bit more elegant but I don't like
annotations much.
What don't you like about them? Annotations are a tool just like any
other part of the language. A carpenter doesn't use a brick because he
doesn't like hammers much.
It
seems to me, that dependency injection (DI) and wicket is not a dream
team. Do you use DI with Wicket or do you use the classic approach
like Wicket itself does?
I've been very happy with @SpringBean so far.
jk
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Avoid serialization troubles with static members
Hi
If we use @SpringBean we have automaticaly a serialized proxy object. Is it
possible to use a transient variable to avoid the serialization at all ?
public MyPanel extends Panel{
@SpringBean(name=myserviceBean)
private transient MyServiceInterface service;
...
}
What do we need to inject the service after de-serialization ? We have the
ComponentInstantiationListener, maybe this would work also with transient ?
Martin
--
View this message in context:
http://www.nabble.com/Avoid-serialization-troubles-with-static-members-tp22082899p22095373.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
