dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/5/27 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>>
>>
>> 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
>
>