We are ask­ing for com­mu­ni­ty in­put on the fol­low­ing: over time, our ini­tial­iza­tion mech­a­nism (prop­er­ty file, sys­tem prop­er­ties, prop­er­ties sup­plied pro­gram­mat­i­cal­ly) has been pol­lut­ed a bit and as a re­sult the lookups are not al­ways in­tu­itive. We would like to im­prove this and are work­ing on a new de­sign pro­posed here. Let us know what you think!

Pro­posed new prop­er­ty lookup pro­ce­dure when Atomikos starts:

1. de­fault prop­er­ties are looked up via a prop­er­ty file in the Atomikos jars (should al­ways be found) 2. over­ride with spe­cif­ic cus­tom prop­er­ties looked up in the jta.prop­er­ties file in the class­path (like now) 3. if no jta.prop­er­ties found: NO log­ging to Sys­tem.err any more (so no need to dis­able that with sys­tem props ei­ther) 4. over­ride with spe­cif­ic prop­er­ties that are set pro­gram­mat­i­cal­ly on the UserTrans­ac­tionSer­vice 5. re­solve any place­hold­er prop­er­ties (i.e., ant-style ex­pan­sion of ref­er­ences to oth­er props) 6. this yields the fi­nal prop­er­ties to use for the init pro­ce­dure

What do you think? Did we miss some­thing im­por­tant?

Thanks!

BRIC coun­tries have the tremen­dous op­por­tu­ni­ty to start out with no lega­cy, no old-style in­fra­struc­ture like ap­pli­ca­tion servers, no mes­sage bro­kers, no en­ter­prise ser­vice bus (ESB) or oth­er non­sense like that - the typ­i­cal stuff big en­ter­prise ven­dors will try to trick you into (if they do: just ig­nore them - you will be bet­ter off).

In­stead, BRIC coun­tries have the lux­u­ry of be­ing able to pick a light-weight mod­el such as JEE with­out ap­pli­ca­tion serv­er to achieve un­lim­it­ed scal­a­bil­i­ty at vir­tu­al­ly no cost, us­ing com­mod­i­ty hard­ware and soft­ware.

With the re­cent eco­nom­ic crises in both the US and Europe, it is the BRIC coun­tries that are help­ing out (in­stead of the oth­er way around). The fu­ture will in­volve a lot more BRIC. And with that, a lot more Atomikos.

Western com­pa­nies that want to be as ag­ile, pro­duc­tive and com­pet­i­tive as the BRIC coun­tries: what are you wait­ing for? Call us to get an in­tro­duc­tion and mi­gra­tion path for your lega­cy.

If you have been pur­chas­ing the 'En­ter­prise Ar­chi­tec­ture' port­fo­lio from the big O then guess what: you've paid way too much for some­thing you don't need, and which will over­load your (way too heavy) hard­ware even more.

We've been claim­ing this for years so it is about time to show it: how to re­place Tuxe­do ap­pli­ca­tions with open source and free soft­ware. Com­ing soon to this site!

Stay with us...

PS Tuxe­do is a reg­is­tered trade­mark owned by Or­a­cle

In a re­cent post we've an­nounced our end-to-end sup­port pro­gram. We are glad to be able to add Post­greSQL to the list of sup­port­ed JDBC ven­dors - thanks to and via our Post­greSQL sup­port part­ner 2ndQuad­rant.

This blog post de­scribes yet again how you can use best-of-breed com­po­nents to do the job.

In par­tic­u­lar, it de­scribes in­te­gra­tion of Atomikos as well as all of the oth­er cool li­braries that to­geth­er out­per­form the ap­pli­ca­tion serv­er in sim­plic­i­ty, cost and per­for­mance... Good job!