The FileUploadFilter:
The implementation of the FileUploadFilter makes the assumption that all files loaded by Nukes will be loaded into memory. This is inline with the idea that all Nukes content will be stored in the database. In making the download module a file share, however, uploaded files have to be stored to disk and not the DB. For example - If I want to allow uploading and sharing of a file that is 1 GB, MySQL cannot accommodate this.
The image gallery might also have this same problem. For example - uploading a zip file and unzipping into a directory structure.
And any number of other possibilities exist where storing information to the disk may be necessary for a module that someone wants to implement.
I suggest the FileUploadFilter be removed from the list of filters. Also, it is currently being called multiple times per request and produces a stack trace in the client web browser if a file larger than max size is uploaded.

Also, I see places where the standard JSR APIs have been rewrapped in an effort to provide a simplified or specialized view of that API. For example - Page wrapping HttpServletRequest and HttpServletResponse. Please try to avoid rewrapping the standard APIs. The standard APIs are well documented and understood by other developers while a custom rewrapping of the APIs is not. Also, rewrapping the APIs only provides a subset of the functionality of the APIs and makes it more complicated for other developers to use the API in a way that they will need to use it to implement their custom modules. With Nukes 1.x, some tricky problems had to be resolved to allow the development of pluggable modules into the web app so it is understandable why rewrapping APIs was done. This may be a mute point with Nukes 2.0 (JBoss Portal), as the implementation of modules as portlets may take care of some of these issues.

Danny