Reading this thread I wonder what upgrading/moving to 1.8 means?
Does it mean, throw in the jars and it should work? Or does it mean that
the application uses the preferred syntax/settings of 1.8?
The former case does not make any sense to me. Upgrading because you
want the same functionality the old one has?
The latter case requires some effort. In 1.8 several projects introduced
significant changes in code and configuration.
- Servlet 2.4/jsp 2.0 (web.xml changes and EL support)
- One storage layer. old 'database-support' classes are not supported
anymore
- ResourceLoader to run as unpacked war
- Builder files use XSD instead of DTD and has new tags and attributes
- Datatype are added
- Functions framework is funished
- New tags/attributes in taglib and use of escapers
- New event and query cache features.
- ....
For me it is the latter and that means that it will take at least a week
to upgrade and test the application.
Nico
Michiel Meeuwissen wrote:
Lately I have done several quite involving updates in MMBase core
(because of cleaning, function, datatypes projecs). Most of them should
be back-wards compatible on the 'bridge' side of MMBase.
There is one noticable exception, which I want you to notice. Or
complain about...
It used to be the case that you could happily requests fields which don't
exist.
<mm:field name="tilte" /> would happily compile and run, simply printing
out an empty string, and with some bad luck nobody would notice the bug,
which obvious is present.
Current 1.8 builds will throw an IllegalArgumentException here,
reporting that the field 'tilte' does not exist (you probably meant
'title', didn't you...).
It think this is a good improvement, but well, it may greathen the
hassle to upgrade from pre-1.8 to 1.8, because JSP's containing these
kind of bugs will do nothing useful any more.
So what more should be done. Pick your pick.
- nothing. This is good behaviour, one should check one's code, because if
it didn't throw excepiton previously, it contained a bug any way, so
it is good that you are forced to fixed those.
- Change mm:field to only print out the exception, so not failing the
complete page. This seems a good idea, and I think I will do this any
way.
- Make the behaviour configurable, so you can have an mmbase with
old-style sloppyness. If switched 'off' it can e.g. only log an error,
so that the bugs don't remain unnoticed.
- More suggestions/ideas?
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
