Okay just an update on this. Even though our properties are read first and then ERJavaMail’s nex, for some reason ours end up on top when all properties are merged together.
So it is now working and I don’t understand why for a period of time it was not working. However the question still stands. Is it a deterministic algorithm that guarantees properties are merged in a given order? Thanks Sent from my iPhone > On Nov 3, 2025, at 9:47 AM, Ricardo Parada <[email protected]> wrote: > > Hello everyone, > > I’m comparing the order of property loading in the maven built application > and the non-maven ant built application. > > Has there ever been a specific order? > > I always thought it was reverse order from the classpath but maybe I’ve been > wrong all this time and have been lucky. > > For example, in the ant built application the ERJavaMail properties got > loaded first and then one of our frameworks got loaded afterwards overriding > the er.javamail.* properties. > > In the maven built application it appears the order is reversed and so > ERJavaMail is overridding the properties from our framework which got loaded > first > > I did notice that the classpath does list ERExtensions and other frameworks > first before the WebObjects frameworks as wonder replaces and patches some > classes in WebObjects this way. > > So this is fine in both the maven and ant built version. > > But the property loading seems to behave differently. > > Should I not rely on a particular order then? Should I maybe put these > properties in the application Resources assuming that one does get loaded > last hopefully allowing me to override properties from frameworks? > > Thanks > Ricardo Parada
