Circular reference issues during wiring

[egravel]

Ok, simple scenerio.. object A & B get created but they also need a reference to each other. Obviously, this creates a circular reference issue and I understand it. I'm trying to find a way around it so I don't have to change the coding which is still used by legacy systems. I'd like to avoid that if possible but it's an option.

Anyway, maybe a bit more background info might help.


Right now, I have a bean definition for object A which is a connector object that provides communication facilities to our backend system. Once instantiated, it will read in a xml config file and start creating all these objects it needs such as pools, pool managers, pool monitors, etc. These are objects B. Some of these, such as the monitors, require a reference back to the connector (object a) so that they may send message/transaction to the backend system to see if it's alive. If it doesn't reply within N seconds, it considers it not available... similar to a ping. So the way it's setup works great.

The problem, and reason why I'm moving this config file to spring bean xml definitions, is that we have 2 or 3 versions of this config file for each environment we deploy to since the ip, user id, passwords, etc changes. It makes for a deployment nightmare! And this nightmare isn't restricted to only this connector, it affects other beans we have.

The solution I proposed was to create a enhanced Spring PropertyPlaceholderConfigurer class that could retrieve bean property values from a database. So now, whenever I have a bean whose property need to be configurable by environment, I create a row in our database CONFIG table and give the property the value of ${XXX} where XXX is the the config code/id entered in the database. Works like a charm.

So, I'm now trying to do the same for the connector config file.... moving it to spring bean xml definitions. But I can't seem to find a way around this circular reference problem.


The only idea I've come up with (and I don't really like the approach) is to have an init() method to be invoked by supplying the bean's "init-method" attribute. The init() would call the setXXX() on the monitor once it's been initialized.


I REALLY hope someone can propose a solution or at least give me some ideas that will nudge me in the right direction.

Thanks!

Eric A. Gravel

[Andreas Senft]

Maybe you can use a BeanPostProcessor for doing your initialization?

Regards,
Andreas

[egravel]

Is there no other way? I would rather make my objects unaware of the Spring container so that I can reuse the code in other applications that might not be using Spring.

[dhewitt]

I'm not entirely sure I follow, can you post some config? Simply having a & b depend on each other should not be a problem.

In any case, are the problems you are having anything that can be resolved using the "depends-on" attribute of the bean definitions?

[Andreas Senft]

Using a BeanPostProcessor does not impose any Spring-awareness onto your beans. The only Spring-aware component is the BeanPostProcessor implementation you have to provide. This one just takes care of the initialization of your beans (i.e. calling setters).

Maybe you can search a bit in the forum. I recall to have seen some postings concerning the resolving of circular refs by bean postprocessing.

Regards,
Andreas

[Costin Leau]

I had this problem inside our application and we solved it by creating dummy instances (unwirred). The dependecy between A and B usually happens becasue some part of A depends on B and some part of B depends on A but these parts don't depend on each others.
One thing we did was to create an instance of B, unwired which was passed to A (which was passed to B). The trick is to make sure that the dummy B which is used in A doesn't need A to be wired. Basically this means that the logic path is that A call some method (smth()) on B , but smth() doesn't call back anything on A.

[Colin Yates]

Can you not refactor out the dependency bit, i.e. create an object that consumes a and b?

Maybe describing the specific requirement might help...

[Andreas Senft]

Can you not refactor out the dependency bit, i.e. create an object that consumes a and b?

Or, what I initially thought of, wire just one side of the relation and let a post processor handle the other side.

Regards,
Andreas

[egravel]

I think the creating unwired bean and then injecting the dependencies (including circular references) using a BeanPostProcessor would work. The approach I took, however, is a bit different.

Looking at the code once again, I was able to remove one of the two circular ref that I had between a connection pool and a connection monitor (which is an event listener). The other one can't be removed. It's between the monitor and my connector (which does the communication to backend system). The monitor needs a ref to the connector to send a type of "ping" message. If a response is not received within N seconds, it assumes that it's not available. So how do you create this monitor bean and give it the connector dependency when the connector itself is in the process of being created?

My solution was to add some init() methods to my object that would pass a reference to the connector object down the chain of object. Seems to work.

I just didn't quite like the idea of having a bean simply to inject dependencies of another. There's just something bothering me about that design. But hey, if that had been my only solution, I would of taken it!


Thanks for the help guys!

[Colin Yates]

I usually find that if I have circular dependencies it is because my object model is wrong and there is indeed a 3rd object which is waiting to be identified

I am obviously not saying that ever circular dependency is due to incorrect modelling, just sometimes.