dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

>
> > - 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 occurred while initializing Struts. The Struts VelocityManager complained
that "content is not allowed in prolog" while initializing a Toolbox. No
idea...


>
> > - 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.
>

Sounds fine.

Sidenote: I learned today that one of our student groups managed to apply
Spring-Hibernate support in dhis2 pretty smoothly. Only a hibernate mapping
file provider is left of our custom code. Nice.