2009/5/27 Lars Helge Øverland <larshe...@gmail.com>: > >> >> >> Similarly there has been some talk of *possible* migration of DHIS2 >> towards struts 2 - at least there is a reasonably clear migration path >> and I know Murod has done some work with experimental module. Is this >> something to be considered? Lars what do you think? >> >> Regards >> Bob > > > I actually gave it a try yesterday. Migrating action classes/interceptors > is easy. I ran into some problems though: > > - I got some incomprehensible errors related to SAX xml parsing.
Is this related to our custom code using staxwax+woodstox, or something else? I'm not sure if its relevant to this discussion, but one thing to consider is the availablility of StAX parser within j2ee 6 which can reduce one more dependency. > - It's harder to get hold of the xwork ConfigurationManager (must be done > trough a DispatcherListener) which is required for the portal. I think we might be looking at overhauling the configuration framework eg. using the struts 2 plugin mechanism. > - Our old acegi security framework had some issues with xwork2. This should > be upgraded to Spring security, but will require more work. Agreed. > Anyways I think this is the way to go if we are to upgrade the existing > webwork code as this requires little modification to the hundreds of action > classes and interceptors, in contrast to eg spring mvc. > > > When it comes to technology stack for the houshold system my opinion is that > using something completely new like j2ee 6 is unrealistic if we are gonna > come up with something pretty soon as it requires all of us to learn new > technologies and start from scratch. I believe that, if necessary, we could > upgrade a few things in dhis2, like acegi and webwork, and then continue > with the same technology / components as today. I think there are a few other areas which could do with a dust-up/continued-evolution, including the API and our interoperability import/export format. Of course, with a substantially new model for the new component, we have something of a green field with the API which will allow us to absorb the lessons (the good, the bad and the ugly) of the existing stuff. This is part of the reason I am in favour of maintaining one api. As we add in the new stuff we can be refactoring the old. Having two API modules won't encourage this effect. Cheers Bob >If we want to use more > Spring out-of-the-box components later there is nothing stopping us. > > > Lars > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp