Re: Another unused import statement report is out...
On Wednesday 26 Feb 2003 7:57 pm, Tom Copeland wrote: unused imports are down 40% since last November, crikey! http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Past reports can be found here - http://cvs.apache.org/~tcopeland/, and mad props to the xml-xalan project, who went from 1421 unused imports to 2 in the last month. Do you have a tool for checking for unused imports? I know I have a lot of them in my code, but weeding them takes time and time is something I'm always short of... -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ See one nuclear war, you've seen them all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would Jakarta like to adopt MaybeUpload?
On Friday 21 Feb 2003 12:56 pm, Henri Yandell wrote: On Fri, 21 Feb 2003, Simon Brooke wrote: On Friday 21 Feb 2003 9:18 am, Henri Gomez wrote: Jon Scott Stevens wrote: Why not merge both projects ? I'd be happy to do that. I have working code, and a good, high-level API - much higher level than the commons fileupload package. Also, there are people (including the Cocoon project) using my API who have to be supported in the medium term. There's no reason why one codebase should not support both APIs. Who would I need to speak to to merge the projects? http://jakarta.apache.org/commons/fileupload/team-list.html I'd recommend speaking to Martin or John, OK, I've done this. -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ Iraq war: it's time for regime change... ... go now, Tony, while you can still go with dignity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Would Jakarta like to adopt MaybeUpload?
Hi Introduction: About MaybeUpload URL: http://www.weft.co.uk/library/maybeupload/ I wrote MaybeUpload, a package to make it easy to write Servlets which can do RFC 1867 style file upload, about two years ago, and immediately announced it on Freshmeat as an open source project (BSD license). In March 2002 the Cocoon project asked me if they could include MaybeUpload in the Cocoon 2 distribution, and of course I said I'd be delighted. As far as I'm aware it is still the only open source RFC 1867 compliant Servlet package available. I now think MaybeUpload is now pretty much stable - it is after all a fairly simple piece of functionality. It's to everyone's benefit if it is widely used, because it means that other people don't have to reinvent this particular wheel, and more improvements will feed back into the codebase. I feel it would be likely to get more users if it were an official Apache project. I'm not wishing to hand over or end-of-life MaybeUpload - I'm quite happy to continue to be a or even the maintainer, but I'm equally happy to share repsonsibility with others. Fit with the Jakarta criteria Community MaybeUpload has a mailing list (which isn't very active - I hope because the thing just works and there isn't much to discuss) and has had bug fixes and feature improvements submitted by about a dozen people. I've generally accepted other people's fixes into the codebase provided I've been happy that they do something useful and don't break anything else, and have announced new releases both on the mailing list and on Freshmeat. Core Developers Frankly MaybeUpload has been primarily a one-person project. It does not have three core developers. Alignment with existing Apache subprojects MaybeUpload is already used by the Cocoon project. However, it's not XML related, it's Servlet related, so it doesn't belong in xml.apache, and Jakarta looks a more natural home. MaybeUpload is relevent to Tomcat, and also to things like Struts and Turbine. MaybeUpload depends on Jakarta-RegExp. Scope MaybeUpload is a server side component in the Java language. -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ Iraq war: it's time for regime change... ... go now, Tony, while you can still go with dignity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would Jakarta like to adopt MaybeUpload?
On Thursday 20 Feb 2003 1:59 pm, Patrick Ferdig wrote:
how does it compare to http://jakarta.apache.org/commons/fileupload/?
It's well established, widely used, debugged, and stable.
It's also a lot simpler to use. The example given on
URL:
http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileupload/package-summary.html
becomes
public class Example extends MaybeUploadServlet
{
...
public void doPost( MaybeUploadRequestWrapper req,
HttpServletResponse res)
throws ServletException, java.io.IOException
{
Object foo = req.get( uploadedfile);
if ( foo instanceof File)
{
// do things with the file
}
}
}
Which, as you can see, saves 90% of the work. There's no distinction between
the types of things which can be got from the request wrapper; simply asking
for them by name (using the names ot the inputs in the HTML form) gets them.
If they're strings, you'll get instances of java.lang.String; if they're
files, you'll get instances of java.io.File. Technically if they are nested
multipart-mixeds (which seems to be allowed by the RFC) you'll get a vector
whose members are either strings or files of further nested vectos, but I
have yet to find a client which can send such a thing.
Of course, if you specify save_uploaded as false in the Servlet config
(web.xml) you'll get a java.io.ByteArrayInputStream instead of java.io.File.
Other things you can specify in the web.xml include:
allow_overwrite
Boolean: whether or not to allow uploaded files to overwrite previously
uploaded files with the same name. Default is we don't.
max_upload
Integer: maximum size in bytes of file to upload. Optional. Default is
524288.
save_uploaded
Boolean: whether or not to save uploaded files directly to disk. Optional.
Default is we do. If we don't, the uploaded file will be returned as a
java.io.ByteArrayInputStream by a call to MaybeUploadRequestWrapper.get()
silently_rename
Boolean: whether or not to rename files whose names collide with existing
files in the upload directory. Default is we do. Note that if both
allow_overwrite and silently_rename are false and a name collision occurs,
we will throw an (@see UploadException).
upload_dir_path
String: A path to a directory in the server-side local file-system in which
uploaded files can be saved. Optional. Defaults to /tmp
upload_dir_url
String: the path to my upload directory (work directory) within the
document root of the web server, if it is within the document root of the
web server, else null. For example, if uploadDirPath was
/home/httpd/htdocs/upload, and the document root of the Web server was
/home/httpd/htdocs, then it would make sense to have uploadDirURL set to
/upload/. Optional. No Default.
All parameters may be supplied either as context-params or as init-params; if
both are supplied the servlet-specific init-param will override the
context-param.
Cheers
Simon
--
[EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/
Iraq war: it's time for regime change...
... go now, Tony, while you can still go with dignity.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
