Spring configurability

[dudleygb]

Hi all,

I am going to beat someones brains out here.
There are certain developers on the team that feel Spring isnt the tool for the job because you have to restart the appserver to change configuration like q names etc. They are proposing a database driven configuration, which stores the q name, qm, ports, url's etc, then that gets linked to a message type and then they lookup the delivery details and send to that q or webservice.
While I think its all fancy to do that, really, I mean come on, just how often are you going to change such config details?

Anyways, long story short, they now dont want to use spring because of this one thing! I'm sure I can still use Spring somehow, but it kind of defeats the point having an external delivery agent where SI already handles all of this.

Comments, suggestions?

[iwein]

Anyways, long story short, they now dont want to use spring because of this one thing!

Let's see if I get this right.

1. Your team feels that they need runtime configurability of the system specifically to change the jms properties at runtime.
2. Also they have investigated Spring and found it did not meet their needs.

Because of these premises they have decided that they can do better themselves.

Both premises are false. The conclusion is, let's put this nicely, probably false. I don't have time to go into the details now, but DestinationResolver, ChannelResolver, Spring JMX, Spring DM are more than adequate tools to prove them wrong.

Spring Integration is just a very small part of Spring. If you want access to certain features from the SI namespace you can create an issue for it, but there is no reason you couldn't wire beans right now.

This might look insulting (just remember I can be insulting without even trying ), but the ignorance of the opinion you describe is astonishing. There might be many good reasons not to use Spring, but not being educated is not one of them. I think you did the right thing testing this opinion outside your team, maybe you can suggest they get some professional help (no not the insulting kind, but from a Spring expert).

[dudleygb]

hi iwein,

The standard within this organization is Websphere. As much as I would love to use dm, I wont win that one But..at least I can still make some wins though.
I will be discussing this config issue with the so-called 'lead architect' later this week. Regardless of what they decide, we have split the project up in 3 chunks, for my chunk, I am going to use Spring and manage tx and naming using jndi in WAS. I care less for the apparent run-time config requirement. When their architecture falls flat and they start having resource/tx management issues, I will point my finger and laugh, and say...'Well, at least you can configure it dynamically in the DB.....'
Its so tiring to keep trying to convince people of the 'better way'.
I dont see why you should sacrifice huge gains and offerings just to have database driven config, its just STUPID!!! How often do you change q names and URL's anyways. NEVER! ITS DAFT!
ANyways, thank u for your words of advice, somehow, I can still convert some of these uneducated, unbelievers and sceptics

[iwein]

That doesn't sound like a very healthy situation. I don't think it will help you much if you pick a fight.

You could support db configured routing with minimal extension of SI.

@Router public String getChannelNameFromDB(Message m) {
    return channelNameRepository.getNameForParticularTypeOfMessage();
}

You can do something similar using a custom DestinationResolver in the JmsTemplate. That will give you the option not to say: "It can't be done, but you shouldn't want it anyway". Instead you can tell your team mates that it can be done easily with Spring, but you don't see the merit in doing it right now. That emphasizes that whether or not the requirement is daft or stupid, it is not an argument to decide against Spring or Spring Integration either way.

Good education enforces scepticism and disarms belief. If the people making your organizations standards were sceptic unbelievers, I don't believe you would be running WAS.

[dudleygb]

haha, yeah by now I'm ready to draw blood

If I use that sort of routing, theres still config somewhere in spring that's 'hardcoded' xml, to map it up.
For now, I've opted to let the developer go ahead and thrash out the java code in the mean time. When he's done, then I will attempt to refactor it into pieces that I can slot into SI. This avoids conflict and everyone gets what they want. I agree, achieving a balance and a bit of compromise will go a long way. Just very frustating when u know something should be a done a certain way and they want to go and reinvent the wheel. Oh well, I will persist.

Unfortunately for me, the guys who decided on WAS and the guys who are making the decisions now, arent the same ppl.

Thanx again, if u have any other suggestions, it is most welcome