dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/5/27 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...

You'd have to know what "xml" file the VelocityManager was trying to
read at the time.  Seems the parser didn't see it as kosher xml.
Could be all manner of reasons.  The prolog is the <?xml version="1.0"
encoding="utf-8"?> and the <!DOCTYPE ... bits.

Usually you see this when trying to process a non-xml eg. binary file.
 Could also be hidden characters, funny linefeeds in the file.  Do you
get same error on windoze and linux?

Cheers
Bob

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