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
···
2009/5/27 Lars Helge Øverland <larshelge@gmail.com>:
If we want to use more
Spring out-of-the-box components later there is nothing stopping us.
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.
> - 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
···
2009/5/27 Lars Helge Øverland <larshelge@gmail.com>:
> - 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.
Haven’t tried on linux. But I made a simple webapp using struts 2 with an include file and it worked fine. I am a little unsure how the struts config files are loaded. The docs say they are loaded from classpath automatically.
If you like I can commit my work on struts2 integration into bazaar. These are copy of modules from existing webwork implementations, we can have all in one and even exclude new modules from the rest via poms. Currently two main modules - support-struts2 and web-commons-resources-struts2 and one working module - web-importexport-struts2 are converted.