my dog learned polymorphism*
The moose likes Spring and the fly likes Object creation using dynamic values stored in local variables Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Object creation using dynamic values stored in local variables" Watch "Object creation using dynamic values stored in local variables" New topic
Author

Object creation using dynamic values stored in local variables

Sanjay Virkar
Greenhorn

Joined: Apr 03, 2005
Posts: 19
Just have started reading Spring in Ation- Second Edition. So far have liked the book, DI pattern and Spring in general.

Many examples in the first few chapters describe how to let spring create and get objects (using getBean) for you instead of you having to do 'new'
These examples use predefined values stored in XML file.

But, most of the times objects are needed to use init values which are not known when .XML file is created.
for e.g. batch job that reads from flat file or Servlet program that reads from parameters or interactive
program that reads data from screen.

In these cases, are we first supposed to let Spring create object for us using values defined in .Xml file and then
manually call the set(Property) methods ? or there is any other way you can feed these values stored in local
variables, during object creation ?
Sagar Rohankar
Ranch Hand

Joined: Feb 19, 2008
Posts: 2902
    
    1

I use the setter methods (or builder pattern if object is large) to create a VO/bean and then use that VO by passing to the bean method. So, I generally don't wire VO class as they can't be used as dependencies (they have no business behavior as such).

Please correct me If I'm missing or breaking any design principal here.


[LEARNING bLOG] | [Freelance Web Designer] | [and "Rohan" is part of my surname]
Sanjay Virkar
Greenhorn

Joined: Apr 03, 2005
Posts: 19
Thanks Sagar.

Correct me if I did not understand you correctly, It seems your method seems to be a three step process.

1) Get the Bean using getBean.
2) Create and populate VO with setters
3) Set this VO in the bean method using setProperty and then use values stored in VO in the bean.

I was expecting a single step call that would do all of the above.... Just like the "new" call lets me do.

So to replace

ClassA objA = new ClassA ("val1", "val2", "val3") ;

I was expecting call like....

ClassA objA = ( ClassA ) factory.getBean("BeanId","val1", "val2", "val3");



Sagar Rohankar
Ranch Hand

Joined: Feb 19, 2008
Posts: 2902
    
    1

Sanjay Virkar wrote:
1) Get the Bean using getBean.
2) Create and populate VO with setters
3) Set this VO in the bean method using setProperty and then use values stored in VO in the bean.

First 2 steps are OK, but I never come across a situation where I need to "set" a VO object as a property field. This is the common code with VO:

Sanjay Virkar wrote:
I was expecting a single step call that would do all of the above.... Just like the "new" call lets me do.

So to replace

ClassA objA = new ClassA ("val1", "val2", "val3") ;

I was expecting call like....

ClassA objA = ( ClassA ) factory.getBean("BeanId","val1", "val2", "val3");

Spring gives you power to bind the specific implementation for composed objects externally, but this is something runtime "values" which need to be crated on the fly.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Without knowing the specifics of what you're trying to do, might I suggest creating an implementation of FactoryBean? It lets you get involved in the creation of your bean, but still be able to wire it up as a bean in Spring. Within the factory bean, you can set its properties to whatever you want. You might even consider setting those properties through constructor arguments and not providing setters to make them immutable. Really depends on what you're trying to do and what your need are.

There are other options, too. The Spring Expression Language can do runtime evaluation of an expression when setting properties. That expression could be written to call out to some object that looks up the info you won't know until runtime.

If you're using Spring 3.1, there is the new concept of property sources, where you can draw properties from a variety of sources (property files, servlet init parameters, etc) or even write your own extension of PropertySource to draw data from wherever you want. (In demos, I have a ChuckNorrisPropertySource that *always* returns "Roundhouse Kick" regardless of the property being asked for.)

You might even consider (if none of the above meet your needs) writing an Aspect (AspectJ, not Spring AOP) that intercepts the creation of your class and does injection at creation time. That's a bit heavy-handed, but it's a workable option. Something to keep in mind, anyway.

And there are probably other options that aren't coming directly to mind. These are just a few that I thought of right away.


Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Object creation using dynamic values stored in local variables