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: 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
