Re: IE7 and Apache Common File Upload
On 7/18/07, redomancer redomancer [EMAIL PROTECTED] wrote:
Hello!
I am not sure i am posting the questions in right place, but i have no
other
option.
Um, yes, you do - the Commons User list is the place for questions like
this. Nevertheless, the answer to your question is in the FileUpload FAQ:
http://jakarta.apache.org/commons/fileupload/faq.html#whole-path-from-IE
--
Martin Cooper
I have problem witch is related to Apache Common File Upload.
First of all - the code I am using for file saving:
//
FileItemIterator anIterator = (new
ServletFileUpload()).getItemIterator(aRequest);
FileItemStream anItem = null;
InputStream aInputStream = null;
while (anIterator.hasNext()) {
anItem = anIterator.next();
aInputStream = anItem.openStream();
if (anItem.isFormField())
// ... form field
else {
BufferedInputStream aBufferedInputStream = new
BufferedInputStream(aInputStream);
OutputStream aOutputStream = new
FileOutputStream(getRealPath() + anItem.getName());
BufferedOutputStream aBufferedOutputStream = new
BufferedOutputStream(aOutputStream);
int aStreamedDataSize = 0;
while((aStreamedDataSize =
aBufferedInputStream.read())!=-1)
{
aBufferedOutputStream.write
(aStreamedDataSize);
}
aBufferedOutputStream.flush();
aBufferedOutputStream.close();
aBufferedInputStream.close();
aOutputStream.flush();
aOutputStream.close();
}
}
//
getRealPath() is my function what returns the directory where file must be
saved.
And now the problem: anItem.getName() for IE7 returns FULL path to file on
client side machine.
For example: if i had file C:\upload_me.txt, then anItem.getName() will
contain C:\upload_me.txt if IE7 submits data;
for other browsers anItem.getName() will contail value upload_me.txt.
Is it supposed to be so?
What data anItem.getName() must return? And what is the correct way to get
file name for all browsers then?
P.S.
Sorry, if my question is silly.
redo
Re: Help! Download .CSV file using SurvletResponse, it added unwanted characters in the end of the file!!
On 7/17/07, Bibs L [EMAIL PROTECTED] wrote:
Hi, I need some help woth downloading .CSV file with the regular
ServletResponseObject, it is adding unwanted characters (2 boxes) in the end
of the file when I download it. Your help would be greatly appreciated!
This really is not related to Commons in any way that I can see, but...
I have a download.jsp file
This is your problem. Move your code to a servlet. The extra characters are
almost certainly spaces or line breaks from your JSP page.
--
Martin Cooper
, that calls a manage bean downloadfile.java to render a file, it is all
working well with the excaption of downloading .CSV file. The problem is
that when I try to download a CSV file, by clickin on the link, thats calls
the Download.java bean which set the Response object, and opens up the
Download File Diaglog - Open/Save As, when I open/save as the CSV file, it
added unwanted characters at the very bottom of the file. Even when I
tested to upload a totally empty file, when I download it, it added the
unwanted characters (2 Boxes) , where it should have been empty.
Orignally, I have the htmlbody..etc tags on the download.jsp, and
all of those HTML code were added to the end of the CSV file in addition to
the unwanted file. So, I removed all of the unnesscary html tags, and the
HTML codes are gone from the CSV file, but the unwanted characters are still
being added at the end of the file. I have no idea how it got
there. PLEASE HELP!
---
Download.jsp:
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ page import=java.util.ResourceBundle %
%@ page import=com..bean.DownloadFileBean %
f:loadBundle basename=.nl.Resource_en var=msgBundle /
%
javax.faces.context.FacesContext facesContext = null;
ResourceBundle messages = ResourceBundle.getBundle
(com..nl.ErrorMessages);
LogServices LOG = LogServicesFactory.getInstance().createLogServices(
DownloadFileBean.class);
try{
//get an instance from faceContext
facesContext = javax.faces.context.FacesContext.getCurrentInstance();
DownloadFileBean downloadFileBean =
(DownloadFileBean)facesContext.getApplication().getVariableResolver().resolveVariable(facesContext,
downloadFileBean);
String result = downloadFileBean.DownloadFile();
} catch (Exception e) {
LOG.error(Exception : RenderFile.jsp - + e.getMessage(), e);
} finally {
if (facesContext != null) facesContext = null;
}
%
---
DownloadFile.Java:
public boolean DownloadFile (){
boolean result = false;
FacesContext faces = null;
HttpServletResponse response = null;
File file = null;
FileInputStream fileIn = null;
ServletOutputStream output = null;
try{
MyFileBean myFileBean = (MyFileBean)getBean(myFileBean);
String fileName = myFileBean.getRenderingFileName();
String filePath = myFileBean.getRenderingFilePath();
String fileFullPath = myFileBean.getRenderingFilePath() + fileName;
LOG.debug(file full path = + fileFullPath);
if (fileFullPath == null) {
LOG.debug(file path is null...);
return result;
}
file = new File(fileFullPath);
if(file.exists() == false){
LOG.debug(fileName + - file not found...);
return result;
}
faces = FacesContext.getCurrentInstance();
response = (HttpServletResponse) faces.getExternalContext
().getResponse();
long startTime = System.currentTimeMillis();
fileIn = new FileInputStream(file);
output = response.getOutputStream();
response.setContentType(application/octet-stream);
response.setHeader(Content-Disposition,attachment; filename=\ +
file.getName() + \);
IOUtils.copy(fileIn, output);
output.flush();
faces.responseComplete();
long endTime = System.currentTimeMillis();
result = true;
LOG.debug(Total Time Taken to download: +(endTime - startTime) +
ms);
} catch (FileNotFoundException e) {
LOG.error(FileNotFoundException : DownloadFileBean.java - +
e.getMessage(), e);
} catch (IOException e) {
LOG.error(IOException : DownloadFileBean.java - + e.getMessage(),
e);
} catch (Exception e) {
LOG.error(Exception : DownloadFileBean.java - + e.getMessage(), e);
} finally {
//Close output and input resources.
try {
if (faces != null) faces = null;
if (response != null) response = null;
if (file != null) file = null;
if (output != null) output.close();
} catch (Exception e) {
LOG.error(Exception : DownloadFileBean.java - Closing objects +
e.getMessage(), e);
}
}
LOG.debug(END - DownloadFileBean : downloadFile );
return result;
}
--
Unwanted Code added to CSV File: (Used to be like this before I removed
all the HTML tags from Download.jsp)
META http-equiv=Content-Type content=text/html;
charset=ISO-8859-1 META name=GENERATOR content=IBM
Re: org.apache.commons.fileupload.MultipartStream constructors
On 7/17/07, James Riordan [EMAIL PROTECTED] wrote: Should it be the case that all of the public constructors of org.apache.commons.fileupload.MultipartStream are marked are marked @deprecated Use [EMAIL PROTECTED] #MultipartStream(InputStream, byte[], int, org.apache.commons.fileupload.MultipartStream.ProgressNotifier)}. (which is not public) The class itself should _not_ be considered part of the public API for Commons FileUpload. It is intended to be an internal implementation detail. That was a mistake that we need to rectify. -- Martin Cooper // Constructors public MultipartStream(); public MultipartStream(InputStream, byte[], int); MultipartStream(InputStream, byte[], int, MultipartStream$ProgressNotifier); MultipartStream(InputStream, byte[], MultipartStream$ProgressNotifier); public MultipartStream(InputStream, byte[]); James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation
[ https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511638 ] Martin Cooper commented on VALIDATOR-232: - Except that 'scriptable' does not describe the purpose of the flag in any meaningful way. It's not making the field scriptable, it's causing Validator to generate script to validate it, which is something else entirely. I'd prefer to see something more descriptive like, perhaps, 'clientValidation'. Add script attribute to control script generation - Key: VALIDATOR-232 URL: https://issues.apache.org/jira/browse/VALIDATOR-232 Project: Commons Validator Issue Type: New Feature Components: Framework Reporter: Paul Benedict Priority: Minor Fix For: 1.4 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch Add a script=true|false attribute to field to control whether JavaScript should be generated. Also see: https://issues.apache.org/struts/browse/STR-1888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation
[ https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511642 ] Martin Cooper commented on VALIDATOR-232: - If we were talking about these words in a vacuum, I might agree with you, but we are not. This is an attribute of a field. That field is going to be scriptable, as in able to be scripted, regardless of whether or not Validator generates JavaScript code to validate the value of the field. In fact, regardless of whether or not Validator does anything at all. Making a field scriptable is not a function of Validator. Providing client-side validation, on the other hand, is very much a part of what Validator does. With regard to 'clientValidation' not describing the kind of client-side validation, well, can you suggest other kinds of client-side validation that someone might think of when they see that name, rather than JavaScript, and get confused? If you want to get pedantic about the name, then 'scriptable' doesn't do it either, because that name omits the scripting language, and also omits whether the scripting will happen on the client or the server. Add script attribute to control script generation - Key: VALIDATOR-232 URL: https://issues.apache.org/jira/browse/VALIDATOR-232 Project: Commons Validator Issue Type: New Feature Components: Framework Reporter: Paul Benedict Priority: Minor Fix For: 1.4 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch Add a script=true|false attribute to field to control whether JavaScript should be generated. Also see: https://issues.apache.org/struts/browse/STR-1888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Fileupload 1.3 or 2.0?
On 7/3/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, when applying the fixes for IO-99 to commons-fileupload, I was originally under the impression, that this would be easily possible without any or at least with fully upward compliant API changes. Until I detected that for reasons, which absolutely escape me, someone made FileItem to implement the Serializable interface. Ah, history... Commons FileUpload originated as part of the Turbine framework long, long ago. When it first came to Commons, FileItem extended javax.activation.DataSource, I believe to allow Turbine to directly e-mail uploaded files using JavaMail. In one of my early clean-up sprees, and after some discussion with Turbine folks, I removed the extension of DataSource but left the methods that are defined on DataSource, so that creating a FileItem extension that implemented DataSource was a trivial task. About 6 months after that, a patch supplied by Jon Stevens (of Turbine) was applied that added the extension of Serializable. This was presumably for Turbine compatibility, but I wasn't the person who committed the change, the log message from the person who did was a somewhat unhelpful PATH ( :) ) from Jon Scott Stevens, my memory isn't good enough to recall an associated thread (this was in 2002), and I'm too lazy to trawl the archives right now to find out if it was discussed at the time. ;-) I can only guess, that someone had the idea to put a FileItem into the HttpSession. But resource tracking within a persistent HttpSession, seems to me to be clearly outside the scope of commons-fileupload. At least, this doesn't fit into the default implementation, which assumes temporary files, for good reasons. At first, I have attempted to fix the problem by making the FileCleaner serializable, but Rahul has rightly pointed out, that I am doing nonsense. See http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html for details. I have reverted the changes in commons-io and rethought my approach. The longer I thought about it, the more I came to the conclusion, that the only clean solution is to accept API changes. In particular, let FileItem no longer implement the Serializable interface. While we are at it, we could as well dissolve the the FileItemFactory and the multipart parser. Remove the whole bunch of deprecated methods. In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125 finally by dropping binary compatibilty and declaring the next version as commons-fileupload 2.0, not 1.3. I know that others (in particular Martin) had bigger plans for 2.0: Reimplement the thing based on httpcomponents, or commons-codec, or whatever, and stuff like that. Unfortunately I see noone who'd be ready to do that. In particular, not me. Yeah, I did, and no, I'm not likely to be jumping in at this particular point in time. My original thoughts, to the extent that I can remember them (it was quite a while ago!), were: * We were already starting to clone classes from what was originally HttpClient and is now HttpComponents. One example is the ParameterParser class. When I saw HttpComponents being born, saw a lot of other stuff in there that FileUpload was doing, it looked like it would make a lot of sense to build FileUpload on top of HttpComponents, thus dramatically cutting down the amount of code necessary to build a FileUpload package. * I wanted to reorganise the package structure, for a variety of reasons. The interfaces needed separating from implementations, and we needed to allow for multiple implementations, of different types. Yes, I know we have most of that now. We didn't, originally, and I ended up dealing with it while more or less retaining the original structure and just adding more structure on top of that. There's still a bunch of litter lying around that could do with cleaning up (il.e. removing) in a 2.0 release, though. Also, it would still be good to have a much more clear distinction between what is supposed to be public and what is not. (For example, recall the MultipartStream threads from not so long ago.) * I wanted to add a servlet filter along with multiple associated configuration implementations, so that we could provide much more of a drop-in capability, rather than requiring so much explicit integration into most consumer applications and frameworks. I actually went quite far down that path, and might even still have the code lying around somewhere, if anyone wanted to pick that up and finish it. That's about all I can think of right now, although I suspect there was more. I'll post again if I remember anything else. Oh, and I'm definitely in favour of going for a 2.0 release and cleaning up some crud along the way. I just don't think I'll be in a position to help any time soon, I'm afraid. -- Martin
Re: Commons is TLP
On 6/21/07, Brett Porter [EMAIL PROTECTED] wrote: On 22/06/07, Henri Yandell [EMAIL PROTECTED] wrote: Joe will then work with you to get all the bits taken care of. Priority is the mailing list and the unix group (as that makes life easier on various other parts of the move). First priority is the DNS, since it's a prereq to everything else :) Well, except that commons.apache.org already exists, and has a web site that refers to the Jakarta, XML and Web Services Commons sites. Are there any other DNS changes that we need? -- Martin Cooper We may have some interesting times on that one if we clash with the previous commons mailing lists. ie) Do we go with the clash, or do we choose different names. Just checked - no clash in either lists or archives (only commons-pmc still exists and the new list will be commons-private). Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CHAIN-37) The problem of org.apache.commons.chain.impl.ChainBase.execute
[
https://issues.apache.org/jira/browse/CHAIN-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Cooper resolved CHAIN-37.
Resolution: Won't Fix
Niall is correct. This is as designed.
The problem of org.apache.commons.chain.impl.ChainBase.execute
--
Key: CHAIN-37
URL: https://issues.apache.org/jira/browse/CHAIN-37
Project: Commons Chain
Issue Type: Bug
Affects Versions: 1.0, 1.1
Reporter: kylin
Priority: Critical
The ChainBase.execute metod is not thread safety,I Change the code like that:
// Execute the commands in this list until one returns true
// or throws an exception
boolean saveResult = false;
Exception saveException = null;
int i = 0;
int n = commands.length;
for (i = 0; i n; i++) {
try {
Command command = (Command)commands[i];
Command newCommand =
((Command)commands[i].getClass().newInstance());
PropertyUtils.copyProperties(newCommand,command);
saveResult = newCommand.execute(context);
if (saveResult) {
break;
}
} catch (Exception e) {
saveException = e;
break;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Brainstorming for 2.0
On 3/12/07, Oliver Zeigermann [EMAIL PROTECTED] wrote: I have now created a Wiki page for the 2.0 discussion: http://wiki.apache.org/jakarta-commons/Brainstorm_2%2e0 Not a particularly good page name, given that it's not scoped to Transaction in a any way. It could apply equally well to any Commons component heading for 2.0. -- Martin Cooper 2007/3/9, Oliver Zeigermann [EMAIL PROTECTED]: Packae naming: As discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] it might be a good idea to have a new package name for the 2.x version. I'd be +1 for that Oliver 2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]: Folks! As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) 2.) Library requirement (1.5 concurrent package?) 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) 4.) Scope (all restricted as possible) 5.) What else? Cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] when are svn commit mails generated ?
On 1/16/07, Luc Maisonobe [EMAIL PROTECTED] wrote: Hello, I just realized recently that not all commits to the subversion base generated mails to the dev list. Not true. Since the repository is also shared by other Apache projects outside of commons, I thought there was some filter for commons, based for example on directories tree structure. However, I performed a small commit for three files in [math] yesterday which bumped version to r496489 and no mail was generated. Since it was my very first commit, I am a little affraid I can have done something wrong. Most likely, since it was your first commit, the commit message is sitting in the moderation queue, waiting for a moderator to approve it (and add your address to the allowed posters). -- Martin Cooper I used the subclipse plugin (version 1.1.9) with eclipse (version 3.2.1) on a Linux box. Should a specific commit procedure be followed or can I use any client ? Was the behaviour normal when no mail is generated ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/11/07, James Carman [EMAIL PROTECTED] wrote: Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK I don't know if I agree with this point, Niall. The stuff that's in IO wasn't left out of the JDK because of coding style, which is the reason Stephen (I believe that's who said it) is saying we shouldn't use nested exception classes. I would agree that nested exception classes should be avoided. I wouldn't want to have to qualify my exceptions in my catch blocks: catch( DirectoryWalker.CancelException e ) That just looks ugly/weird to me and people just usually don't do that. That depends a _lot_ on the kind of coding you're doing / exposed to. For example, it's not particularly common for web apps to use a lot of anonymous inner classes, but if you were looking at Swing code, you'd likely see them all over the place. The above may look ugly / weird to you, but it looks elegant / self-documenting to me. -- Martin Cooper I would agree, however, that it does group stuff logically. On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 1/9/07, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] This helps with naming, but without the scoping, you're left with the Javadocs as the only way to specify that the exception is intended to be used only within the DirectoryWalker class. Of course, a public static inner class can be used elsewhere as well, but the relationship with the enclosing class makes a clear statement of intent. We can agree to disagree, though - I was mostly just interested in what the arguments are against using inner classes, given that I see very clear and meaningful reasons for using them. Ditto. Your arguments are good, so I'm quite happy to go with whatever consensus is on this one. I think the other argument is that the JDK doesn't have inner exception classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io] is a JDK+ library, I'd say we should have no inner exceptions. Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK :-) If you could point to a no inner exceptions in the jdk policy with reasons why then that would be a different thing. Two of the reasons for inner classes on the Sun Java tutorial[1] apply to this case IMO - it logically groups the exception with the class it applies to - i.e. DirectoryWalker - it makes for more readable/maintainable code From whats been said in this thread then at the end of the day is purely down to different stylistic preferences. On that basis I'd prefer it to remain how I originally coded it. Having said that - if its going to prevent/hold up an IO 1.3 release then, as I said before, I'm not going to object to it being changed. Niall [1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Martin Cooper [EMAIL PROTECTED] wrote:
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
Martin Cooper wrote:
Could you say more about this, please? I happen to disagree on
exceptions as
inner classes being a bad idea; FileUpload has done this for
years,
without
any problems. But I'm always interested in hearing new
perspectives...
I guess its stylistic, and therefore subjective. But I see an
exception
as a critical system object, and not one that should be relegated to
inner class status.
+1
} catch( DirectoryWalker.CancellationException ce) {
...
}
feels weak to me.
Weak why?
Because I'm not used to it I suspect. It's not a common idiom so not
something my eyes naturally parse, and if I was writing the code I
suspect it would take a bit longer to write. Not char-wise, I mean in
terms of realising what I was meant to catch.
Stephen mentioned the javadoc. Looking at that, I doubt I'd be
catching DirectoryWalker.CancellationException anyway - the method
that it is thrown from throws IOException. The
DirectoryWalker.CancellationException isn't in its contract, except as
an argument passed in.
The examples in the Javadoc look bad btw. They refer to CancelException
and not
DirectoryWalker.CancellationException.
To me, it makes the code very explicit about what is being
cancelled. It also, by the way, allows for other classes to have a
CancellationException without having to make up some other name, because
the
enclosing class scopes the exception class name and allows its reuse in
other classes. It seems like an eminently suitable way of naming /
scoping
tightly coupled classes such as we see with these types of exceptions.
Good arguments - though they just make me think in terms of a more
specific class name - WalkCancelledException.
Probably because you're not used to the inner class way. ;-)
This helps with naming, but without the scoping, you're left with the
Javadocs as the only way to specify that the exception is intended to be
used only within the DirectoryWalker class. Of course, a public static inner
class can be used elsewhere as well, but the relationship with the enclosing
class makes a clear statement of intent.
We can agree to disagree, though - I was mostly just interested in what the
arguments are against using inner classes, given that I see very clear and
meaningful reasons for using them.
--
Martin Cooper
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3 RC1
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote: -1, here's why... After reviewing the javadoc, I realised that having an inner class as an exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong in code. Could you say more about this, please? I happen to disagree on exceptions as inner classes being a bad idea; FileUpload has done this for years, without any problems. But I'm always interested in hearing new perspectives... -- Martin Cooper I propose that this exception is promoted to a top level class, and renamed to DirectoryWalkCancelledException. Since we need to build a new RC for Niall's fix, this shouldn't be a big problem if people agree. If people disagree with my analysis, then I will of course re-evaluate this -1 (for which I apologise...) Stephen Henri Yandell wrote: I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc1/ Various build files, clirr/jardiff reports and the proposed site. [ ] +1 [ ] -1 Vote to end on Friday (if it makes it that far). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote: Martin Cooper wrote: Could you say more about this, please? I happen to disagree on exceptions as inner classes being a bad idea; FileUpload has done this for years, without any problems. But I'm always interested in hearing new perspectives... I guess its stylistic, and therefore subjective. But I see an exception as a critical system object, and not one that should be relegated to inner class status. Inner classes are not inferior in any way, so there's no relegation going on. An inner class makes perfect sense for a class that has little relevance in isolation from another class, which is exactly the situation when you have a exception that is tied to its enclosing class. If the exception is specific to that class, what better way to document that than by making the exception an inner class? I pretty much only use inner classes for the internals of the main class. Details that shouldn't be exposed as part of the public API, except for very specialist users. Catching a cancellation exception doesn't seem to be a special case. As I mentioned above, there is nothing inferior about inner classes. If you choose to view them that way, well, that's a separate issue altogether. ;-) -- Martin Cooper For example, I also dislike Map.Entry, and think it should be MapEntry. (Well, actually I think map entries are the biggest mistake in the collections framework but thats another story...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
Martin Cooper wrote:
Could you say more about this, please? I happen to disagree on
exceptions as
inner classes being a bad idea; FileUpload has done this for years,
without
any problems. But I'm always interested in hearing new perspectives...
I guess its stylistic, and therefore subjective. But I see an exception
as a critical system object, and not one that should be relegated to
inner class status.
+1
} catch( DirectoryWalker.CancellationException ce) {
...
}
feels weak to me.
Weak why? To me, it makes the code very explicit about what is being
cancelled. It also, by the way, allows for other classes to have a
CancellationException without having to make up some other name, because the
enclosing class scopes the exception class name and allows its reuse in
other classes. It seems like an eminently suitable way of naming / scoping
tightly coupled classes such as we see with these types of exceptions.
--
Martin Cooper
Either we should catch CancellationException and its
a normal class, or we should catch IOException and it's package static
rather than public static.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
On 1/7/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Simon Kitching skitching at apache.org writes: For a start, if every project were to do this, the impact on the Apache SVN repository would be huge. Cocoon (maintenance branch 2.1) has currently 111 jars with about 40 MB in its repository (+ the one for the environment [2]), we are regularly upgrading them and it has never been seen as a problem from infrastructure team. I would instead prefer to see ant builds using get to download jars as needed. The maven repositories can be used as a convenient source for the jars, eg http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/build.xml I posted my opinion on this recently [3]: In general I don't like the need for internet access on build time. This is a red herring. One way or another, you're going to have to get the jars from the network, whether it's getting them from SVN, or having Maven or Ant retrieve them. And in all of those three cases, once you have them on your local machine, you don't need the network to build the next time. -- Martin Cooper But with Ant it's at least better than with Maven as the build environment itself does not get changed. My concerns are raised after one year mess with Maven in Cocoon trunk. Regards Jörg [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/lib/ [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/lib/ [3] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116811395603150w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
On 1/6/07, Simon Kitching [EMAIL PROTECTED] wrote: Hi, I noticed (due to a recent commit message) that commons-transaction has jarfiles checked in to svn, eg http://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/trunk/lib/ What's the general policy on this? Sorry if this has been discussed before; I don't remember it. It has been discussed before, but it's been a while since it's come up. The general consensus has been don't do it. There are lots of reasons to avoid doing this, and no good reasons to do so, especially since we're using Maven now. Personally, I really really dislike jarfiles in the version control system. For a start, if every project were to do this, the impact on the Apache SVN repository would be huge. Yep. I'm with you on both points. I would instead prefer to see ant builds using get to download jars as needed. The maven repositories can be used as a convenient source for the jars, eg http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/build.xml Right, and an Ant build generated by Maven will in fact get the dependencies from the Maven repo, just as Maven does. -- Martin Cooper BTW, note that there is *no* way to remove a file from SVN once it is committed short of a repo dump/restore (which is a major effort on a repo the size of Apache). A svnadmin obliterate command is about the oldest outstanding feature request... Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
On 1/3/07, Henri Yandell [EMAIL PROTECTED] wrote: On 1/3/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Henri Yandell flamefew at gmail.com writes: The aim is to provide us with information on where projects are release-wise and where we are in terms of answering new issues. Some of our components aren't there - for example Jelly which has 77 unversioned issues and Attributes/Discovery which are ready to be retired. Some of the ones there should probably be removed for having too many unversioned issues. I wonder what's the problem with unversioned issues. It simply says in the future. Any exact targetting for unresolved issues will lead to this issues hasn't made it into the latest release, we try to get it into the next one mails polluting the mailing lists without nearly any additional value. I think that is a good thing as it means someone is looking at that issue each release and deciding that it won't go in that release. If it keeps getting punted all the time then someone can ask if it's ever going to happen. This is exactly why we moved to something like what Hen is proposing for Struts. We had oodles of issues just sitting there with no indication of when, if ever, they were likely to be fixed, and no indication of whether anyone was committed to looking at them. Once you start versioning the issues, you get the beginnings of a roadmap rather than just a bucket of issues. -- Martin Cooper Lang has a good example of an 'in the future' version. There's a JDK 1.5 Release version for a couple of issues that have constraints holding them back from going in any version soon. More importantly to the above - my comment that components with lots of unversioned issues need to be removed is not a slander against those components but a sign that they're not using the lightweight workflow I'm creating the report for: * unversioned = unaccepted * next version = being worked upon * post next version = later (though can usually be bumped to next version if it has a patch/unit test) * other versions = Dennis Lundberg dennisl at apache.org writes: And any component with a high number of solved issues deserves a release, no matter what the total says, say like 40/300. If it's just the number of resolved issues, you don't need the number of unresolved issues assigned to a target release. I tend to agree with this POV. It can depend. I agree with Dennis' statement that a high number of resolved should be flagging a release (which is one of the reasons for the report), but if there were truly 300 issues planned for that release, then it's possible there was a reason. The first step after the release has been flagging is for someone to review the 260 and move them to another version - ie) to rethink the release plan. Seeing the 300 figure is pretty useful in that it tells us that a release plan is probably too much. BeanUtils has 79 issues in its 1.8.0. A bunch probably shouldn't go in 1.8.0, but when I went through the 100+ issues that were there those were the ones that I thought we should at least be looking at prior to the next release. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS and EMF Awareness
On 1/1/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I just got the VFS 1.0 announcement a little while back and did a cross post on the EMF mailing list, since EMF has similar capabilities. This was mainly for awareness and possible future collaboration opportunities. Here's the reply from Marcelo on the EMF team (Including a test link showing how some of the EMF stuff works): That link requires a login (and therefore registration). Could you provide more information here, please? -- Martin Cooper http://www.eclipse.org/newsportal/article.php?id=21615group=eclipse.tools.emf#21615 Cheers, - Ole __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS and EMF Awareness
On 1/2/07, Ole Ersoy [EMAIL PROTECTED] wrote: OH - Sure - You just need to sign up for an Eclipse Newsgroup Account. No, I mean please post information about the possible overlap between EMF and VFS. You can't expect everyone here to go register for an Eclipse account just for that. -- Martin Cooper http://www.eclipse.org/newsgroups/register.php Cheers, - Ole --- Martin Cooper [EMAIL PROTECTED] wrote: On 1/1/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I just got the VFS 1.0 announcement a little while back and did a cross post on the EMF mailing list, since EMF has similar capabilities. This was mainly for awareness and possible future collaboration opportunities. Here's the reply from Marcelo on the EMF team (Including a test link showing how some of the EMF stuff works): That link requires a login (and therefore registration). Could you provide more information here, please? -- Martin Cooper http://www.eclipse.org/newsportal/article.php?id=21615group=eclipse.tools.emf#21615 Cheers, - Ole __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
On 12/28/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 12/27/06, Henri Yandell [EMAIL PROTECTED] wrote: Looks good - nice work :) Only bit that leaps out to me as missing are the little arrows to symbolize external links. We may not care. Actually, I like those. :-) A couple of things I noticed: * The Docs for 2.2 is missing. Personally, I think it's important to know the version that I'm looking at, so I hope that can be put back. I'll see if that is available in M2, but that is not part of the skin. Right. Sorry, I was just spotting differences between the pages I was looking at, and not really thinking skin versus non-skin. If it's in there it is an addition to site.xml, which for commons-lang is just something I put together quickly for now. We should however create a parent site.xml for all of commons. This gets inherited, published and versioned along side of our parent pom.xml. But that's an issue for another thread :) * The current page now shows in the menu as black, and looks the same as a menu heading. Previously it was bolded blue, which made it a distinct style from other items and from the headers. Yes, hmm. The current page is no longer a link, like it was in M1, so I was reluctant to change it to a link-like color. It should be doable though, if you feel strongly about it. Perhaps a slightly lighter shade of gray rather than black? I'm not sure I would say I feel _strongly_ about it, but I think it would be good for the current page to have a distinct style, whatever that might be. A different colour, an underscore, a background colour - I'm not that fussed. Just not blinking, please. ;-) -- Martin Cooper Other than that, they look a lot alike. ;-) -- Martin Cooper Definitely don't care that 'About Lang' is gone; and I'm not bothered that 'Development Process' is gone either. I presume these are standard Maven things that have gone from m1 to m2. Hen On 12/27/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi all Finally I took the time to sit down and create a Maven 2 skin for Jakarta Commons. What I have done is taken maven-classic-skin and combined that with the stylesheet rules that can be found in the site.xml file in commons/trunks-sandbox. Then I played around with the site for commons-lang to try to create a site that resembles what we get when we build the site using Maven 1. A SNAPSHOT of the skin has been uploaded to the Apache M2 SNAPSHOT repository, so you don't need to build it yourself to try it. You may need to tweak some files in your component to be able try out the skin. Instructions for this is on the wiki [1]. They should really be in SVN along with commons-skin, but I figured we should use wiki to get things started. To make it easier for you to review I have staged the commons-lang site that was generated using Maven 2 and commons-skin [2]. Compare it to the original commons-lang site [3] and give me some feedback. [1] http://wiki.apache.org/jakarta-commons/UsingCommonsSkin [2] http://people.apache.org/~dennisl/commons-lang/ [3] http://jakarta.apache.org/commons/lang/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
On 12/27/06, Henri Yandell [EMAIL PROTECTED] wrote: Looks good - nice work :) Only bit that leaps out to me as missing are the little arrows to symbolize external links. We may not care. Actually, I like those. :-) A couple of things I noticed: * The Docs for 2.2 is missing. Personally, I think it's important to know the version that I'm looking at, so I hope that can be put back. * The current page now shows in the menu as black, and looks the same as a menu heading. Previously it was bolded blue, which made it a distinct style from other items and from the headers. Other than that, they look a lot alike. ;-) -- Martin Cooper Definitely don't care that 'About Lang' is gone; and I'm not bothered that 'Development Process' is gone either. I presume these are standard Maven things that have gone from m1 to m2. Hen On 12/27/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi all Finally I took the time to sit down and create a Maven 2 skin for Jakarta Commons. What I have done is taken maven-classic-skin and combined that with the stylesheet rules that can be found in the site.xml file in commons/trunks-sandbox. Then I played around with the site for commons-lang to try to create a site that resembles what we get when we build the site using Maven 1. A SNAPSHOT of the skin has been uploaded to the Apache M2 SNAPSHOT repository, so you don't need to build it yourself to try it. You may need to tweak some files in your component to be able try out the skin. Instructions for this is on the wiki [1]. They should really be in SVN along with commons-skin, but I figured we should use wiki to get things started. To make it easier for you to review I have staged the commons-lang site that was generated using Maven 2 and commons-skin [2]. Compare it to the original commons-lang site [3] and give me some feedback. [1] http://wiki.apache.org/jakarta-commons/UsingCommonsSkin [2] http://people.apache.org/~dennisl/commons-lang/ [3] http://jakarta.apache.org/commons/lang/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-122) Filename may contain a full path
[
http://issues.apache.org/jira/browse/FILEUPLOAD-122?page=comments#action_12458552
]
Martin Cooper commented on FILEUPLOAD-122:
--
From the Javadocs for FilenameUtils.getName:
This method will handle a file in either Unix or Windows format.
It does this regardless of which OS it is running on. I checked this before
adding the FAQ item. :-)
Filename may contain a full path
Key: FILEUPLOAD-122
URL: http://issues.apache.org/jira/browse/FILEUPLOAD-122
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Sebastian Beigel
Priority: Blocker
The filename extracted from the content disposition may contain a full path
(i.e. as submitted by the Internet Explorer for example).
It's is important to check for this and strip the path information
accordingly as the upload fails if you use FileItem#getName() to build your
destination path.
I patched the abstract class FileUploadBase#getFileName(...) with a few lines
of code inspired by COS' MultiPartParser :)
Starting on line 447 (after fileName = fileName.trim(); )
// The filename may contain a full path. Cut to just
the filename.
int slash = Math.max(fileName.lastIndexOf('/'),
fileName.lastIndexOf('\\')); // check for Unix AND Win separator
if (slash -1) {
fileName = fileName.substring(slash + 1); // past
last slash
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2
in on a project that has been very close to Checkstyle-clean for years, you make changes that introduce hundreds of new violations, and you have the gall to say that you refuse to fix the ones you don't agree with? That's not how we work here at Commons either. -- Martin Cooper Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRI Implementation
On 11/20/06, Garrett Rooney [EMAIL PROTECTED] wrote: On 11/20/06, Jeremy Hughes [EMAIL PROTECTED] wrote: +1 from me to separating it out. In Woden we could really use IRI - WSDL 2.0 spec uses them, but we're having to work around this since JSE 6 dropped it. Question about incubation though - you say IRI is part of abdera so does IRI require a graduation vote to get into jakarta commons? BTW: IMHO jakarta commons would be a great place for it - as long as we can keep the impl small. I imagine that there is some sort of hoop to jump through to make this happen, but I'm not sure about the details. I'm pretty sure something similar happened in another incubator project fairly recently though, so the archives of [EMAIL PROTECTED] would probably be enlightening. I seem to recall something about moving a bit of some incubator project into Jackrabbit... Not sure where we ended up on this, but, modulo the procedural issues, +1 from me for bringing this to Commons. -- Martin Cooper -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-99) FileCleaner thread never ends and cause memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=comments#action_12450929 ] Martin Cooper commented on IO-99: - It would make sense to me for FileCleaner to provide a method to cleanly stop the reaper thread, and possiby another method to (re-)start it. This way, an application using Commons IO could gain control over this thread. Today, no control is provided - the thread is started automatically, and cannot be (cleanly) stopped. In the context of Commons FileUpload, this would allow a web application to start the reaper thread at startup time (e.g. servlet or filter init) and shut it down when the web app is being stopped (e.g. servlet or filter destroy). The question then arises of what to do by default. If we decide not to start the reaper automatically, we would be breaking backwards compatibility with the current version of IO, although I do think this would be the more sensible option. FileCleaner thread never ends and cause memory leak in AS - Key: IO-99 URL: http://issues.apache.org/jira/browse/IO-99 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: JBOssPortal with commons.fileupload Reporter: Vera Mickaël Priority: Critical FileCleaner opens a thread and no solution is given to the user to end it. So when an application is undeployed in an Application Server, a thread is still alive. The WebApp can't be undeployed and this results in a classloader leak that will cause an OutOfMemoryError. I think the API should be extended so that a user can end the thread. A better way would be to provide a class that cleans everything for commons IO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUpload Errors
On 11/15/06, Mundell, R. (Ronald) [EMAIL PROTECTED] wrote: Good Day I downloaded on of the examples from the website site (http://www.onjava.com/onjava/2003/06/25/examples/commons1src.zip) and am having problems getting it to work. This example is from the O'Reilly OnJava site, not the Commons FileUpload site. It is probably just plain buggy. For one thing, using Commons FileUpload in a JSP page is a really bad idea. For another, a quick look at the imports on that page suggests that they are wrong; if the code was in a Java file instead, and you were using an IDE, you'd probably see the errors straight away. I would recommend working from the code fragments in the Commons FileUpload User Guide instead: http://jakarta.apache.org/commons/fileupload/using.html If you really want to persist with the OnJava example, I suggest you take it up with them, since we don't have any control over it. -- Martin Cooper I don't know what the problem is. I have included the latest commons-fileupload.jar file. I also have included org.apache.commons.is_1.2.0.jar. The error I am getting is as follows. I also have included my source HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: 2 in the jsp file: /FileUploadDemo/commons1src/fileupload/fileuploaddemo.jsp Generated servlet error: C:\Documents and Settings\Ronald\.netbeans\5.5\apache- tomcat-5.5.17_base\work\Catalina\localh ost\dms\org\apache\jsp\FileUploadDemo\commons1src\fileupload\fileuploaddemo_ jsp.java:52: cannot find symbol symbol : variable ServletFileUpload location: class org.apache.jsp.FileUploadDemo.commons1src.fileupload.fileuploaddemo_jsp boolean isMultipart = ServletFileUpload.isMultipartContent (request); ^ An error occurred at line: 2 in the jsp file: /FileUploadDemo/commons1src/fileupload/fileuploaddemo.jsp Generated servlet error: C:\Documents and Settings\Ronald\.netbeans\5.5\apache- tomcat-5.5.17_base\work\Catalina\localh ost\dms\org\apache\jsp\FileUploadDemo\commons1src\fileupload\fileuploaddemo_ jsp.java:61: cannot find symbol symbol : class DiskFileItemFactory location: class org.apache.jsp.FileUploadDemo.commons1src.fileupload.fileuploaddemo_jsp DiskFileItemFactory factory = new DiskFileItemFactory(); ^ An error occurred at line: 2 in the jsp file: /FileUploadDemo/commons1src/fileupload/fileuploaddemo.jsp Generated servlet error: C:\Documents and Settings\Ronald\.netbeans\5.5\apache- tomcat-5.5.17_base\work\Catalina\localh ost\dms\org\apache\jsp\FileUploadDemo\commons1src\fileupload\fileuploaddemo_ jsp.java:61: cannot find symbol symbol : class DiskFileItemFactory location: class org.apache.jsp.FileUploadDemo.commons1src.fileupload.fileuploaddemo_jsp DiskFileItemFactory factory = new DiskFileItemFactory(); ^ An error occurred at line: 2 in the jsp file: /FileUploadDemo/commons1src/fileupload/fileuploaddemo.jsp Generated servlet error: C:\Documents and Settings\Ronald\.netbeans\5.5\apache- tomcat-5.5.17_base\work\Catalina\localh ost\dms\org\apache\jsp\FileUploadDemo\commons1src\fileupload\fileuploaddemo_ jsp.java:65: cannot find symbol symbol : class ServletFileUpload location: class org.apache.jsp.FileUploadDemo.commons1src.fileupload.fileuploaddemo_jsp ServletFileUpload upload = new ServletFileUpload(); ^ An error occurred at line: 2 in the jsp file: /FileUploadDemo/commons1src/fileupload/fileuploaddemo.jsp Generated servlet error: C:\Documents and Settings\Ronald\.netbeans\5.5\apache- tomcat-5.5.17_base\work\Catalina\localh ost\dms\org\apache\jsp\FileUploadDemo\commons1src\fileupload\fileuploaddemo_ jsp.java:65: cannot find symbol symbol : class ServletFileUpload location: class org.apache.jsp.FileUploadDemo.commons1src.fileupload.fileuploaddemo_jsp ServletFileUpload upload = new ServletFileUpload(); ^ 5 errors org.apache.jasper.servlet.JspServletWrapper.handleJspException (JspServletWra pper.java:510) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java :3 75) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter (MonitorFilter .java:368) root cause org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: 2 in the jsp file: /FileUploadDemo/commons1src/fileupload/fileuploaddemo.jsp Generated servlet error: C:\Documents and Settings\Ronald\.netbeans\5.5\apache- tomcat
Re: VOTE: Release commons-fileupload 1.2
On 11/15/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, after the release of commons-parent, the hurdles for publishing the next version of commons-fileupload have now gone. So I'd like to request a release of Commons Fileupload 1.2 I'm not going to have time to look at this until the weekend, but I will try to spend some time on it then. In the meantime, a couple of requests: 1) Given the significant API changes since 1.1.1, I would like to see clirr and jdiff reports, so that we can verify backwards compatibility more reliably. 2) I would like to see the output of Robert's RAT tool, run over the proposed distro, to make sure were not missing anything. -- Martin Cooper The proposed distributables can be found at http://people.apache.org/~jochen/commons-fileupload/dist The proposed web site is at http://people.apache.org/~jochen/commons-fileupload/site Notable changes in 1.2 are: - Made Streams.asString static. Thanks to Aaron Freeman. - Eliminated duplicate code. (FILEUPLOAD-109) - Added a streaming API. (FILEUPLOAD-112) - Eliminated the necessity of a content-length header. (FILEUPLOAD-93) - Eliminated the limitation of a maximum size for a single header line. (FILEUPLOAD-108) Thanks to Amichai Rothman. - Added the ProgressListener, which allows to implement a progress bar. (FILEUPLOAD-87) - Added support for header continuation lines. (FILEUPLOAD-111) Thanks to Amichai Rothman. - It is now possible to limit the actual file size and not the request size. (FILEUPLOAD-88) Thanks to Andrey Aristarkhov. Please cast your vote: [] +1 [] =0 [] -1 Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-119) The encryption decryption of uploaded file
[ http://issues.apache.org/jira/browse/FILEUPLOAD-119?page=comments#action_12449065 ] Martin Cooper commented on FILEUPLOAD-119: -- Even without the latest streaming changes, encrypting the file on the server, prior to writing it to disk, could be accomplished by providing your own FileItem implementation, along with a factory for it. You could probably get away with subclassing DiskFileItem. The encryption decryption of uploaded file Key: FILEUPLOAD-119 URL: http://issues.apache.org/jira/browse/FILEUPLOAD-119 Project: Commons FileUpload Issue Type: New Feature Environment: Windows/Linux Reporter: inderjeet Priority: Critical Hi, Can we upload the file in the encypted format and later decrypt it to show the file so that noone can directly open the file from the disk space (hard disk) where i have uploaded the file usinf fileUpload functionality. This is the major concern for our project ? Is there any external library which can do this for us even just after we upload the file through this API ? Thanks Regards Inderjeet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-119) The encryption decryption of uploaded file
[ http://issues.apache.org/jira/browse/FILEUPLOAD-119?page=all ] Martin Cooper resolved FILEUPLOAD-119. -- Resolution: Won't Fix Resolving as Won't Fix, since this is a specialised application which can be implemented with no additional enhancements to FileUpload. The encryption decryption of uploaded file Key: FILEUPLOAD-119 URL: http://issues.apache.org/jira/browse/FILEUPLOAD-119 Project: Commons FileUpload Issue Type: New Feature Environment: Windows/Linux Reporter: inderjeet Priority: Critical Hi, Can we upload the file in the encypted format and later decrypt it to show the file so that noone can directly open the file from the disk space (hard disk) where i have uploaded the file usinf fileUpload functionality. This is the major concern for our project ? Is there any external library which can do this for us even just after we upload the file through this API ? Thanks Regards Inderjeet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (FILEUPLOAD-119) The encryption decryption of uploaded file
[ http://issues.apache.org/jira/browse/FILEUPLOAD-119?page=all ] Martin Cooper closed FILEUPLOAD-119. The encryption decryption of uploaded file Key: FILEUPLOAD-119 URL: http://issues.apache.org/jira/browse/FILEUPLOAD-119 Project: Commons FileUpload Issue Type: New Feature Environment: Windows/Linux Reporter: inderjeet Priority: Critical Hi, Can we upload the file in the encypted format and later decrypt it to show the file so that noone can directly open the file from the disk space (hard disk) where i have uploaded the file usinf fileUpload functionality. This is the major concern for our project ? Is there any external library which can do this for us even just after we upload the file through this API ? Thanks Regards Inderjeet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
On 10/30/06, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Sandy McArthur [EMAIL PROTECTED] If we want to come up with the notion of a super version, something that is more broad than a major version and includes non-backwards compatible changes I'm fine with that. But mandating that any major release be completely non-backwards compatible is silly. So what does a major version mean? Surely a major version means we have changed the code so it is no longer compatible, you cannot upgrade simlpy and easily Not necessarily, no. It could just as easily mean we've added a boatload of functionality that adds so much to the component that we feel a major version bump is warranted. -- Martin Cooper Occasional drastic pruning of code is needed to keep it healthy and manageable. But we should not be eager to run out and break compatibility without deliberate and compelling reasons. I agree that we should not run out and break compatibility without deliberate and compelling reasons. In fact, I'd suggest that one of the beneficial side-effects of adopting this as a policy would be that we would all be more reticent about making those incompatible changes, leading to more minor and compatible releases - which I would argue is a Good Thing. I'll admit its less fun though. Is that what the negative viewpoint here is? Or is it just that the negatives have never faced jar hell? At the moment, I haven't heard any debate of the validity of the problem, or alternatives to the solution/ Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
On 10/30/06, Henri Yandell [EMAIL PROTECTED] wrote: On 10/30/06, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Sandy McArthur [EMAIL PROTECTED] If we want to come up with the notion of a super version, something that is more broad than a major version and includes non-backwards compatible changes I'm fine with that. But mandating that any major release be completely non-backwards compatible is silly. So what does a major version mean? Surely a major version means we have changed the code so it is no longer compatible, you cannot upgrade simlpy and easily I was thinking the same thing - we define major version as a non-backwards compatible API change. A lot of people (as Martin pointed out) bump the major version because they've added a lot to the API - but we've not done that that often and I'm tempted to think we should mandate that that doesn't happen. Why is it necessary to mandate such a thing? -- Martin Cooper Occasional drastic pruning of code is needed to keep it healthy and manageable. But we should not be eager to run out and break compatibility without deliberate and compelling reasons. I agree that we should not run out and break compatibility without deliberate and compelling reasons. In fact, I'd suggest that one of the beneficial side-effects of adopting this as a policy would be that we would all be more reticent about making those incompatible changes, leading to more minor and compatible releases - which I would argue is a Good Thing. Yeah. Basically we'll do what Java does - charge on with new things and keep the old ones hanging on. Seems like Lang 3.0 could be JDK 1.5 only and not need any package renaming, as long as it maintained the backwards compatibilty. I'll admit its less fun though. Is that what the negative viewpoint here is? Or is it just that the negatives have never faced jar hell? Solving jar hell isn't that hard. You do internal releases, you pester projects to do a release, or you just don't upgrade. Runtime bugs from jar hell are more of a worry for me. People who have built against a version of Project A that needs Commons B-1.0, and then they put it into production/testing with Commons B-2.0 and not B-1.0. The other side is going to the the new jar hell. Trying to deploy a war file and make sure you have all the necessary transitive dependencies of Commons. Unless we also include the version number in the artifact-id; Maven's going to become painful I think. And how do I know which Commons jars to deploy? Let's say I resolve my transitive structure and I've got a list with Commons Lang 3.0, 2.1 and 2.0 in it. Which ones do I deploy? All three? Just 3.0 and 2.1? How do I know which ones are package name compatible? Seems that we end up with the Axis way: Lang2 1.0. Just so people can tell that it's okay to have Lang2 1.0 and Lang 2.1 in the same classpath but not Lang 2.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-117) Check file upload size only if an upload limit has been imposed
[
http://issues.apache.org/jira/browse/FILEUPLOAD-117?page=comments#action_12445746
]
Martin Cooper commented on FILEUPLOAD-117:
--
This is probably no longer relevant, since Jochen's streaming changes also
eliminate the up-front request size check, as well as the throwing of
UnknownSizeException. I'm not positive, though - I'll leave it to Jochen to
comment definitively.
Check file upload size only if an upload limit has been imposed
---
Key: FILEUPLOAD-117
URL: http://issues.apache.org/jira/browse/FILEUPLOAD-117
Project: Commons FileUpload
Issue Type: Improvement
Affects Versions: 1.1.1
Reporter: Mark Vollmann
The current implementation asks the request for the content length and exits
if the stream does not know the size (i.e. -1).
Within Bea portal this does not work because the action request always
returns -1 for getContentLength.
However, if the portal does not impose an upload limit, this hsould be ok.
The problematic code snippet is
int requestSize = ctx.getContentLength();
if (requestSize == -1) {
throw new UnknownSizeException(
the request was rejected because its size is unknown);
}
if (sizeMax = 0 requestSize sizeMax) {
throw new SizeLimitExceededException(
the request was rejected because its size ( + requestSize
+ ) exceeds the configured maximum ( + sizeMax + ),
requestSize, sizeMax);
}
This should ne rewritten to
int requestSize = ctx.getContentLength();
if (sizeMax = 0)
{
if (requestSize == -1) {
throw new UnknownSizeException(
the request was rejected because its size is unknown);
}
if(requestSize sizeMax) {
throw new SizeLimitExceededException(
the request was rejected because its size ( + requestSize
+ ) exceeds the configured maximum ( + sizeMax + ),
requestSize, sizeMax);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r428804 - /jakarta/commons/proper/fileupload/trunk/xdocs/using.xml
On 8/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bayard Date: Fri Aug 4 11:04:36 2006 New Revision: 428804 URL: http://svn.apache.org/viewvc?rev=428804view=rev Log: isMultipartContent is not available in ServletFileUpload - just FileUploadBase. So fixing the user guide as wished for in #FILEUPLOAD-114 I suppose. The problem is that this method _should_ be in ServletFileUpload and _should not_ be in FileUploadBase, but there is no way to make that happen (that I am aware of, anyway) without breaking backward compatibility. -- Martin Cooper Modified: jakarta/commons/proper/fileupload/trunk/xdocs/using.xml Modified: jakarta/commons/proper/fileupload/trunk/xdocs/using.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/xdocs/using.xml?rev=428804r1=428803r2=428804view=diff == --- jakarta/commons/proper/fileupload/trunk/xdocs/using.xml (original) +++ jakarta/commons/proper/fileupload/trunk/xdocs/using.xml Fri Aug 4 11:04:36 2006 @@ -113,7 +113,7 @@ providing a static method to do just that. /p source![CDATA[// Check that we have a file upload request -boolean isMultipart = ServletFileUpload.isMultipartContent (request);]]/source +boolean isMultipart = FileUploadBase.isMultipartContent (request);]]/source p Now we are ready to parse the request into its constituent items. /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r439789 - in /jakarta/commons/proper/fileupload/trunk: ./ src/checkstyle/ src/main/assembly/
On 9/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jochen Date: Sun Sep 3 08:20:39 2006 New Revision: 439789 URL: http://svn.apache.org/viewvc?rev=439789view=rev Log: Moved the checkstyle and PMD files to src/checkstyle. Storing PMD configuration in a 'checkstyle' directory doesn't make much sense. If we want to store both in the same directory, how about calling that directory just 'checks' or 'code-checks'? -- Martin Cooper Added: jakarta/commons/proper/fileupload/trunk/src/checkstyle/ jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_basic.xml (props changed) - copied unchanged from r429099, jakarta/commons/proper/fileupload/trunk/fileupload_basic.xml jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_checks.xml (contents, props changed) - copied, changed from r439479, jakarta/commons/proper/fileupload/trunk/fileupload_checks.xml jakarta/commons/proper/fileupload/trunk/src/checkstyle/license- header.txt (contents, props changed) - copied, changed from r429099, jakarta/commons/proper/fileupload/trunk/license-header.txt Removed: jakarta/commons/proper/fileupload/trunk/fileupload_basic.xml jakarta/commons/proper/fileupload/trunk/fileupload_checks.xml jakarta/commons/proper/fileupload/trunk/license-header.txt Modified: jakarta/commons/proper/fileupload/trunk/pom.xml jakarta/commons/proper/fileupload/trunk/src/main/assembly/src.xml Modified: jakarta/commons/proper/fileupload/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?rev=439789r1=439788r2=439789view=diff == --- jakarta/commons/proper/fileupload/trunk/pom.xml (original) +++ jakarta/commons/proper/fileupload/trunk/pom.xml Sun Sep 3 08:20:39 2006 @@ -177,7 +177,7 @@ groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId configuration - configLocationfileupload_checks.xml/configLocation + configLocationsrc/checkstyle/fileupload_checks.xml/configLocation /configuration /plugin plugin @@ -204,6 +204,11 @@ plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId +configuration + rulesets +rulesetsrc/checkstyle/fileupload_basic.xml/ruleset + /rulesets +/configuration /plugin /plugins /reporting Propchange: jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_basic.xml -- svn:keywords = Date Author Id Revision HeadURL Copied: jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_checks.xml (from r439479, jakarta/commons/proper/fileupload/trunk/fileupload_checks.xml) URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_checks.xml?p2=jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_checks.xmlp1=jakarta/commons/proper/fileupload/trunk/fileupload_checks.xmlr1=439479r2=439789rev=439789view=diff == --- jakarta/commons/proper/fileupload/trunk/fileupload_checks.xml (original) +++ jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_checks.xml Sun Sep 3 08:20:39 2006 @@ -123,7 +123,7 @@ !-- Following interprets the header file as regular expressions. -- !-- module name=RegexpHeader/-- module name=RegexpHeader -property name=headerFile value=license-header.txt/ +property name=headerFile value=src/checkstyle/license- header.txt/ /module Propchange: jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_checks.xml -- svn:eol-style = native Propchange: jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_checks.xml -- svn:keywords = Date Author Id Revision HeadURL Copied: jakarta/commons/proper/fileupload/trunk/src/checkstyle/license- header.txt (from r429099, jakarta/commons/proper/fileupload/trunk/license- header.txt) URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/checkstyle/license-header.txt?p2=jakarta/commons/proper/fileupload/trunk/src/checkstyle/license-header.txtp1=jakarta/commons/proper/fileupload/trunk/license-header.txtr1=429099r2=439789rev=439789view=diff == (empty) Propchange: jakarta/commons/proper/fileupload/trunk/src/checkstyle/license-header.txt -- svn:eol-style = native Propchange
Re: Migrate commons-fileupload to Maven 2
On 9/1/06, Bill Barker [EMAIL PROTECTED] wrote: -0 Since it will kill the Gump build (as well as all of the 23 projects that depend directly or indirectly on c-f :). However, the Maven people don't care, and I'm getting tired of fighting this war, so no veto from me. Jochen is proposing to get rid of the Maven 1 build. The Gump build uses Ant. What's the problem? -- Martin Cooper Jochen Wiedmann [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I have just checked in the required changes for building site and distribution of commons-fileupload with Maven 2. See http://people.apache.org/~jochen/commons-fileupload for details. Now that is done, I'd like to get rid of the Maven 1 stuff. In particular, I'd like to change the project layout, so that it matches the Maven 2 standards. Additionally, I'd like to remove the files project.(properties|xml) and maven.xml, as well as xdocs/navigation.xml. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
On 7/20/06, Phil Steitz [EMAIL PROTECTED] wrote: On 7/20/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/20/06, Henri Yandell [EMAIL PROTECTED] wrote: Is it as important for contributors? If I understand it correctly, the idea of this change (a bunch of projects seem to be moving this way) is that the developers see exactly what they used to see and the contributors get a less spammy list and thus get more involved. Commit diffs are not spam, IMO, nor are issue reports / comments. This is core to what is happening on a project. I agree with Phil. And I don't buy that more people would get involved if they didn't see the commit messages. How can they be properly involved if they're not watching what's happening to the code and the issues? -- Martin Cooper It also allows people to choose not only what they receive, but how. Email isn't the only way to 'subscribe' to the lists, you can also get the Atom feed from the ASF mail archives, or use a forum interface like Nabble. (I'd keep dev@ for discussion only, and send wiki diffs to [EMAIL PROTECTED] While we're on the subject, will there be CI server notifications?) Probably yet another little list, if we chase this to logical conclusion. One problem that I have with splitting things is that Jira comments *are* discussion, as are commit log messages and responses to these, etc. I don't like the idea of splitting these. As far as the arguments about getting new contributors in, I would like to hear from them. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using FileUpload with Jsp page
On 7/3/06, Patrick Fulgence G.A. [EMAIL PROTECTED] wrote: Hi, I'm working on a project using JSP and Apache Tomcat. I'm new to this technology and I'm getting some problems when trying to upload a file from the client post to my server. I want to allow users to browse their computer for a file and upload it on my server. After that, I want to have a reference on the new uploaded to in order to parse it for making some operations with it. Can you help me please ? Two suggestions: 1) Do your uploaded file handling in a servlet instead of a JSP page. 2) See the FileUpload User Guide for information on how to use the component: http://jakarta.apache.org/commons/fileupload/using.html -- Martin Cooper -- p.f. Goudjo-Ako
Re: FileUpload form field issue
On 6/27/06, Edwin Ramirez [EMAIL PROTECTED] wrote: Hello, I've started using the fileUpload component to handle form submissions containing files. I am following a very simple example and everything is working as expected. However, it seems that multi-value form elements are not handled properly. For example, the select tag such as: select name=multi multiple size=5 optionOne optionTwo optionThree optionFour optionFive optionSix optionSeven optionEight optionNine optionTen /selectbr/ will only retrieve the last item selected. No, it will result in N separate FileItem instances, one for each selected item. I am using the getString() method of the FileItem interface. Is there another method which returns an array of values? There is no array of values, unless you build one. Each value is a separate item. -- Martin Cooper Thanks, -- Edwin S. Ramirez Senior Developer Mount Sinai Medical Center Information Technology 212-659-5614 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fileupload question
On 6/23/06, Nima [EMAIL PROTECTED] wrote:
Hey all
I am trying to handle a JSP file upload with the Commons Fileupload api
but
to no avail. The problem is that I never manage to parse the request
coming
from my JSP
to my Servlet. Any ideas on what I might be doing wrong? There are no
exceptions thrown and I have the commons-io.jar in my web-inf/lib so I
should be all set. I've been dealing with this issue for over two days
now,
any form of input is helpful!
A couple of things:
1) What container are you using? Are you sure the container itself has not
already parsed the input before you try to do so?
2) You are setting the threshold and the max to the same value, so nothing
will ever be stored on disk. And then you are trying to configure a
repository on disk, which would never be used. Not sure what you're trying
to accomplish, but whatever it is, this combination doesn't make sense.
3) You are passing a bogus value to setRepository. If you want it to use a
specific directory, pass that. If you don't, don't call the method.
--
Martin Cooper
Here's the Servlet method
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
PrintWriter out = response.getWriter();
DiskFileItemFactory factory = new DiskFileItemFactory();
factory.setSizeThreshold(2);
factory.setRepository(new File());
ServletFileUpload upload = new ServletFileUpload(factory);
upload.setSizeMax(2);
File file = new File(/);
try {
List items = upload.parseRequest(request); //List never
populates :(
Iterator iter = items.iterator();
while(iter.hasNext()) {
FileItem item = (FileItem) iter.next();
item.write(file);
}
} catch(Exception e) {
e.printStackTrace();
}
}
And the JSP HTML
form action=FrontController method=POST
enctype=multipart/form-data
input type=file value=filename /
input type=submit value=Submit /
/form
Re: Fileupload question
On 6/23/06, Nima [EMAIL PROTECTED] wrote:
I did ignore setting the threshold and max file size before, but that
didn't
result in any luck either... basically I had the following in my method
body
DiskFileItemFactory factory = new DiskFileItemFactory();
factory.setRepository(new File(C:/));
ServletFileUpload upload = new ServletFileUpload(factory);
try {
List items = upload.parseRequest(request);
Iterator iter = items.iterator();
while(iter.hasNext()) {
FileItem item = (FileItem) iter.next();
item.write(new File(test.jpg));
}
} catch(
The Eclipse debugger shows these variable values for the upload
object:
upload= ServletFileUpload (id=1454)
fileItemFactory= DiskFileItemFactory (id=1443)
headerEncoding= null
sizeMax= -1
I also tried setting the repository location to the servlet path (and not
setting it at all) but no dice. I am running Eclipse WTP alongside Tomcat
5.5. My gut feeling is that something must be configured wrong - what are
the most basic steps that must be taken to get a single file uploaded via
the Commons Fileupload? (the documentation is rather scarce for this API).
The user guide shows you exactly the minimum set of steps you need to get
going. It's in the section titled The simplest case. ;-)
If that isn't working, then I'd look to the environment, rather than your
code. Tomcat won't automatically parse multipart requests, but if you have a
framework in place (e.g. Struts), then that might be doing it. The issue
here is that the request can be parsed only once, so if anything else gets
to it before you do, then there will be nothing left for you to parse. And
if that also isn't the case, then you may need to look at the stream itself,
and add a test to your code to check for a multipart request.
--
Martin Cooper
Thanks again!
On 6/23/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 6/23/06, Nima [EMAIL PROTECTED] wrote:
Hey all
I am trying to handle a JSP file upload with the Commons Fileupload
api
but
to no avail. The problem is that I never manage to parse the request
coming
from my JSP
to my Servlet. Any ideas on what I might be doing wrong? There are no
exceptions thrown and I have the commons-io.jar in my web-inf/lib so I
should be all set. I've been dealing with this issue for over two days
now,
any form of input is helpful!
A couple of things:
1) What container are you using? Are you sure the container itself has
not
already parsed the input before you try to do so?
2) You are setting the threshold and the max to the same value, so
nothing
will ever be stored on disk. And then you are trying to configure a
repository on disk, which would never be used. Not sure what you're
trying
to accomplish, but whatever it is, this combination doesn't make sense.
3) You are passing a bogus value to setRepository. If you want it to use
a
specific directory, pass that. If you don't, don't call the method.
--
Martin Cooper
Here's the Servlet method
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
PrintWriter out = response.getWriter();
DiskFileItemFactory factory = new DiskFileItemFactory();
factory.setSizeThreshold(2);
factory.setRepository(new File());
ServletFileUpload upload = new ServletFileUpload(factory);
upload.setSizeMax(2);
File file = new File(/);
try {
List items = upload.parseRequest(request); //List never
populates :(
Iterator iter = items.iterator();
while(iter.hasNext()) {
FileItem item = (FileItem) iter.next();
item.write(file);
}
} catch(Exception e) {
e.printStackTrace();
}
}
And the JSP HTML
form action=FrontController method=POST
enctype=multipart/form-data
input type=file value=filename /
input type=submit value=Submit /
/form
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
On 6/18/06, Vitaliy S [EMAIL PROTECTED] wrote: re:but AFAIK zip and jar share the same compression algorithm anyway. The algorithms are similar but not the same. re:...and then add a methods for bzip2, compress and gzip, too? See where I am heading? Better let's have a CompressUtils in compress. Compress doesn't work with files while IO does. On the other hand IO doesn't work with compression while Compress does ;-) I think it would be good idea to add compress to IO :-) I agree with Torsten that what you are suggesting would be a better fit for the Compress component. The way I look at it is that IO is a more general purpose library, and handling compression is more specialised. Once we start adding specialised functionality to IO, where would we draw the line? It would quickly become bloated and unwieldy. Better to keep specialised functionality in a component focussed on that specialisation. -- Martin Cooper IMHO My codes fits better IO (I took the idea from IO source code). But if the community won't reject I'll post a patch to IO. Regards, Vitaliy S On 6/18/06, Torsten Curdt [EMAIL PROTECTED] wrote: re: http://jakarta.apache.org/commons/sandbox/compress/ Thanks for a link, but my code couldn't be applied to compress. Compress does nothing with jar. Doesn't mean that could not be changed ;-) ...but AFAIK zip and jar share the same compression algorithm anyway. So why the two methods? (Did I miss something?) re:IMO compression is beyond the scope of IO. Consider this example from http://weblogs.java.net/blog/kgh/archive/2005/11/my_favorite_dea.html snip/ To me apache commons is a set of projects that provide short cuts for common things. Of course we all like clean disgin, but I like clean design unless it doesn't make me to write 20 lines of code to simply zip or jar the folder (same goes for file reading). I agree. All I am saying is that it should probably better go into the compress component. IO Commons provides means to read file into byte array, why not to add a method to read a file or dir as compressed byte array too? ...and then add a methods for bzip2, compress and gzip, too? See where I am heading? Better let's have a CompressUtils in compress. WDYT? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Vitaliy S
Re: How can I search the mailing list archive
On 6/17/06, Simon Kitching [EMAIL PROTECTED] wrote: On Sun, 2006-06-18 at 13:54 +1000, Torsten Curdt wrote: try this http://marc.theaimsgroup.com/?l=jakarta-commons-devr=1w=2 Why do we feature our own archive (in most of the project info reports) if it is not even searchable? Instead people have to be pointed to other searchable archives ...or find them on their own. Not really user-friendly. It's an archive that is stable, long-term and trustable. That means it's a great historical resource, and that when providing URLs referencing past discussions, a URL to the Apache email archives is a very good way to do that. I agree that it's a shame there is no decent search facility though. I thought that last year's Google Summer of Code included a project to enhance the apache http mod_mbox to provide search functionality. Do I remember wrong, or did that project not work out? I don't know anything about a SoC project, but it appears that Google does (or did?) index the mod_mbox files, so you can search them with Google by adding site:mail-archives.apache.org to your Google search. -- Martin Cooper Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [FILEUPLOAD] RfC: Proposed API changes for streaming
On 6/9/06, Jochen Wiedmann [EMAIL PROTECTED] wrote:
Hi,
first of all, let me say thanks for giving me the possibility to
contribute
to the project as a committer. Let's hope, I'll be doing fine. ;-)
Let's hope. ;-) Please add youself to the list of developers in the
project.xml file.
As already written, the changes required for streaming are nontrivial.
This looks interesting. However, given the non-trivial nature of the
changes, and the stylistic effect on the way FileUpload works, I wonder if
this wouldn't be better incorporated into the FileUpload 2 design, rather
than being retrofitted into FileUpload 1.x.
Sadly, there is no one place where the goals for FileUpload 2 are written
down right now. Some are in existing enhancement requests, some are
mentioned in random old e-mail threads, and some are still just in my head.
Now that there are two of us, I guess I'd better try to find some time to
write things down. ;-)
I'd
like to discuss them even if I were an experienced project member. Which I
am not, so please be alert even more.
I've had coffee. I'm alert. ;-)
The main reason for API changes is, that the existing interface FileItem is
to powerful.
By too powerful, you mean that it tackles two tasks - providing an
interface to the incoming data, and implicitly providing storage for it.
That's true, and if we want to separate those functions, then perhaps that
calls for a more radical separation than you are suggesting.
Therefore I propose to introduce a new interface, let's call it
SlimFileItem, or StreamingFileItem, with the following signature:
I don't like Slim. Stream or Streaming would be better. But I'm
wondering if the relationship between this and the existing notion of a
FileItem should be so direct. I'm really thinking off the top of my head
here, and haven't thought it through, though, so I don't have any more
concrete ideas at this point. It's worth some thought, though.
public interface SlimFileItem extends Serializable {
InputStream getInputStream() throws IOException;
String getContentType();
String getName();
String getFieldName();
boolean isFormField();
}
As you can see, the FileItem can be changed to extend SlimFileItem.
Additionally, FileItem has a semantic difference: It allows to invoke
getInputStream() more than once, while SlimFileItem should throw an
IllegalStateException on the second invocation. So far, these changes
should
not introduce a problem.
Well, I guess I don't agree here. If FileItem extended SimFileItem, then I
could pass a FileItem to methods that accept a SlimFileItem. At that point,
that SlimFileItem may or may not throw an exception if getInputStream is
called more than once. That's bad API behaviour.
The SlimFileItem is not to be created by a factory: The need for a factory
is mainly caused by the fact, that the FileItem's data needs to be
written.
Sort of. It's really that FileItem is accomplishing two different tasks, as
I noted above.
SlimFileItem is best implemented as an inner class of the MultipartStream.
Hmm. Not if you expect to expose SlimFileItem as part of the public API,
which you are suggesting with the getItemIterator method below.
Multipartstream isn't (supposed to be) part of the public API, so exposing
an inner class of it through the public API is a no-no.
So the API changes can be reduced to an additional method
Iterator /* SlimFileItem */ getItemIterator(RequestContext ctx)
throws FileUploadException;
in FileUploadBase. The existing method
List parseRequest(RequestContext ctx) throws FileUploadException;
would be changed to use getItemIterator internally and convert the
SlimFileItem instances into FileItem.
Finally, a suggestion for simplification: Let's change the
FileUploadException to extend IOException, and not Exception.
No. A FileUploadException isn't always related to IO, so extending
IOException would simply be wrong.
--
Martin Cooper
It will avoid
a lot of casting, type checking, and conversions. Besides, it also makes
sense in the semantic level. At least, I do thing so.
The only argument I can see against the exception change is the following:
People will see compiler errors when using constructs like
try {
...
} catch (IOException e) {
...
} catch (FileUploadException e) {
...
}
The obvious solution would be to change the order. IMO, that's acceptable.
Regards for any comments,
Jochen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? -- Martin Cooper we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
By the way, your questions are more appropriate for the User list than the Dev list. -- Martin Cooper On 6/7/06, Martin Cooper [EMAIL PROTECTED] wrote: On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? -- Martin Cooper we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote:
Martin Cooper wrote:
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote:
hi,all
i got a problem .
our requirements is upload some jpg/gif to the server(images server).
also,we maybe upload a file more than one time.
we found , some times, all(radom) files of the folder (upload use in
the
server)
are lost !!
our version is 1.0 .
The first thing you should do is upgrade to FileUpload 1.1. There were
several changes in that release to the way in which uploaded files are
cleaned up.
I used FileUpload 1.0 . I am changing to 1.1 :)
That said, without seeing any code, or reading any explanation of how
you
are using FileUpload, it's a little hard to know what you're doing
wrong...
My code is :
DiskFileUpload nDiskFileUpload = new DiskFileUpload();
nDiskFileUpload.setSizeMax(50*1024*1024);
nDiskFileUpload.setSizeThreshold(60*1024);
i use the java.io.tmp env ( /tmp ) to safe my temptory upload files .
List nFileItems = nDiskFileUpload.parseRequest(request);
Iterator nIterator1 = nFileItems.iterator();
while(nIterator1.hasNext()){
FileItem nFileItem1 = (FileItem)nIterator1.next();
if(!nFileItem1.isFormField()){
String strFieldName=nFileItem1.getFieldName();
if(!strFieldName.equals(UploadTemp)){
String strFileName=nFileItem1.getName();
String
strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName);
Is this method call guaranteed to return a unique name, even if the same
parameters are passed more than once? If not, then you could be overwriting
files that were previously uploaded.
Also, does this method return a full path to where the file should be saved?
You are using the returned value with no additional directory specified when
you call FileItem.write() later in your code, so unless this method returns
the full path, write() will use whatever the current working directory
happens to be.
if(blnGetRepositoryPath){
nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath
());
This is too late. The repository path is part of the file item factory, and
the path for a file item is set at creation time. Calling
setRepositoryPath() here will do nothing at all, since the file items are
all created by the time parseRequest() completes.
blnGetRepositoryPath=false;
}
if(!strSaveAsName.equals()){
File saveFile=new File(strSaveAsName);
nFileItem1.write(saveFile); //this is where i
save my files .
}
else{
System.out.println();
}
}
}
}
is there any problem with my codes ?
i do not know whether it is the problem of
fileupload component.
I find this
http://issues.apache.org/jira/browse/FILEUPLOAD-85
That has to do with the exact manner in which files are deleted, not
whether
or not they are deleted.
any secure way to delete the tempotery files? so does any one has
solutions ?
I thought your problem was that files are being deleted that you do
not want
deleted, right? What does that have to do with secure deletion?
images files uploaded to the server ...lost .
I guess whether is the reason of FileUpload1.0 ?
But that has nothing to so with whether deletion is secure or not, does it?
It relates only to whether deletion happens at all.
You know ,1.0 use
File f =new File(.)
f.deleteOnExit() ;
All the upload-temp files are registered to the JVM . Got any prob ?
Yes, there are problems with that. That is why the deletion code was changed
for FileUpload 1.1.
--
Martin Cooper
Will the pointer mis-point to the files i wanna save and delete them
all ,when the server reboot.
I am really confused by the lost images files .
Will FileUpload 1.1 cause the same prob ?
I am not sure what is the point (delete files),so ..
any suggestion and guess is welcome !
--
Martin Cooper
Thanks you any way .
yours,biglaughing
[free as freedom]
we are confuesed by the radom delete of the jpg/gif files.
any suggestion is welcome.
thank you all !
yours,biglaughing
[free as freedom]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release FileUpload 1.1.1-RC1
On 6/3/06, Henri Yandell [EMAIL PROTECTED] wrote: On 6/2/06, Henri Yandell [EMAIL PROTECTED] wrote: On 6/2/06, Niall Pemberton [EMAIL PROTECTED] wrote: maven.changelog.date=2005-12-24 That way you can put the proper release date back into the changes file. Much better. I'll do so and replace the docs with a new docs directory. Have done this. So the process is: svn co edit build.properties to contain the 2nd to last date instead of lastRelease cut release There are other things you have to do in there too (commit a change to the doap file, put the final date in the site and changes) so it's not as if it's the only thing. Does this new changelog look okay? Yep, it looks like everything is in there now. -- Martin Cooper If so I'll start the vote on RC1 again as we've had a lot of noise on this thread. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release FileUpload 1.1.1-RC1 (take two)
On 6/3/06, Henri Yandell [EMAIL PROTECTED] wrote: Repeating this vote call because the last one got a bit lost in getting the site generation right, but I don't think an RC2 is required just for that. - I've prepared a release for FileUpload; http://people.apache.org/~bayard/fileupload/ [X] +1, looks good. [ ] -1, nope, something needs fixing. It looks like something weird has happened to the FAQ plugin. The item titles are now showing up as (inoperative) links instead of bold text. Very strange, but I doubt it's anything you've done. ;-) -- Martin Cooper Will keep the vote open until Wednesday. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release FileUpload 1.1.1-RC1
On 6/2/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 6/2/06, Henri Yandell [EMAIL PROTECTED] wrote: On 5/28/06, Dennis Lundberg [EMAIL PROTECTED] wrote: In version 1.9 of the changelog-plugin a new option was added that might solve this problem. Add these lines to the project.properties file: maven.changelog.date=lastRelease maven.changelog.type=date The plugin looks in the changes.xml file to find the previous release. Fileupload has such a file so that's good. I tried this on fileupload and the plugin choked because of an unparseable date 2006-05-??, which is the date set for the 1.1.1 release. So I changed that date to In SVN and ran maven site again and the plugin correctly picked up 2005-12-24 from the 1.1 release. This does work, though it means the changes report has In SVN in and not the date. Still, I can generate this to get that page and put it in later on the main build. Any objections to that? Yes its messy and liable to go wrong when you forget to do something when cutting the actual release. Given that you're never going to know the actual release date until you're actually cutting the release, the date in the change log will _always_ have to be updated by the RM at that time. It wouldn't be any worse to have In SVN than 2006-05-?? (especially given that it's now June ;). I used to use Pending for the date value until I cut the release. And it seems to me that using lastRelease is always correct, so that seems like the right value to use. I just didn't know about it until Dennis mentioned it. You know that you can override settings if you have a local build.properties file? Better to just override this locally with the actual date: maven.changelog.date=2005-12-24 That way you can put the proper release date back into the changes file. But you'll never know what that date is until you're actually cutting the release, so what are you going to put there before you're in the process of rolling it? -- Martin Cooper Niall I've uploaded the new page to the rc1 site: http://people.apache.org/~bayard/fileupload/docs/changelog-report.html Does that resolve the problem satisfactorily? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release FileUpload 1.1.1-RC1
On 6/2/06, Henri Yandell [EMAIL PROTECTED] wrote: On 6/2/06, Martin Cooper [EMAIL PROTECTED] wrote: On 6/2/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 6/2/06, Henri Yandell [EMAIL PROTECTED] wrote: On 5/28/06, Dennis Lundberg [EMAIL PROTECTED] wrote: In version 1.9 of the changelog-plugin a new option was added that might solve this problem. Add these lines to the project.propertiesfile: maven.changelog.date=lastRelease maven.changelog.type=date The plugin looks in the changes.xml file to find the previous release. Fileupload has such a file so that's good. I tried this on fileupload and the plugin choked because of an unparseable date 2006-05-??, which is the date set for the 1.1.1 release. So I changed that date to In SVN and ran maven site again and the plugin correctly picked up 2005-12-24 from the 1.1 release. This does work, though it means the changes report has In SVN in and not the date. Still, I can generate this to get that page and put it in later on the main build. Any objections to that? Yes its messy and liable to go wrong when you forget to do something when cutting the actual release. Given that you're never going to know the actual release date until you're actually cutting the release, the date in the change log will _always_ have to be updated by the RM at that time. It wouldn't be any worse to have In SVN than 2006-05-?? (especially given that it's now June ;). I used to use Pending for the date value until I cut the release. And it seems to me that using lastRelease is always correct, so that seems like the right value to use. I just didn't know about it until Dennis mentioned it. The problem is that at the moment of the release, lastRelease should still mean the previous release but it doesn't. At that moment it suddenly means that release and you get a really small changelog. Well that's brilliant. I wonder if anyone can come up with a use case for that behaviour... ;-) -- Martin Cooper Easiest solution is for the release manager to change project.properties to list the lastRelease date just prior to building the release as Niall suggested. (Well, easiest easiest would be to dump the report as too much trouble ;) ) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Bug report for Commons [2006/05/28]
On 5/29/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Any way to turn this off now we are on JIRA ? It's a simple edit, but I don't have karma. I've submitted a ticket for infra@: http://issues.apache.org/jira/browse/INFRA-821 -- Martin Cooper [EMAIL PROTECTED] wrote: +---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Where do Nightly Builds Come From?
On 5/29/06, Leo Sutic [EMAIL PROTECTED] wrote: Hi, how are the nightly builds created? As far as I'm aware, they're still created on Craig's machine, by running 'ant clean dist', and pushed up from there. I thought his script grabbed a clean tree each time. Sounds like there might be a bug in the script if your changes are not being picked up. -- Martin Cooper I've tried to make a change to the nightly build of Commons-Attributes, by editing the Ant build.xml file for the project, but the nightly build process keeps churning out the same old artifacts. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release FileUpload 1.1.1-RC1
On 5/28/06, Henri Yandell [EMAIL PROTECTED] wrote: Sorry, habit. +1 I remember Martin having pain with changelogs and things last time, so if you or Martin remember what they were exactly that would be a good thing to check. I couldn't see any obvious issues looking at the report. The problem is that it's picking up only the last 30 days of commits, instead of all of the changes since the 1.1 release. In this case, it doesn't even seem to have done that, since it's missed both of the bug fixes that we're doing this release for. ;-( (The second of those was checked in early this month, but it was still missed.) For the last release, I used a patched version of the Maven plugin that Niall built to fix this. I'm not sure if the plugin itself has been fixed since then, though, in which case all we'd need to do is change config for it. A couple of other minor things I noticed: I'm guessing you built on a *nix box, because the license and notice files have those line ends, which means they don't come up right in notepad on Windows. And the manifest file says it was built by hen - although around here we all know who hen is. ;-) -- Martin Cooper Hen On 5/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: +1 from me. All looks good to me - builds fine from the source distro and I tried the jar in my webapp with no problems (and saw the lowercase filenames bug fixed). Niall P.S. Henri are you going to vote? On 5/28/06, Henri Yandell [EMAIL PROTECTED] wrote: I've prepared a release for FileUpload; http://people.apache.org/~bayard/fileupload/ [ ] +1, looks good. [ ] -1, nope, something needs fixing. Will keep the vote open until Thursday (given that Monday is a holiday for many). [I haven't created an SVN tag for the RC1. Is there any particular reason the release info says to create a tag?] Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r409818 - /jakarta/commons/proper/fileupload/trunk/xdocs/index.xml
On 5/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Huh? Wrong download URL? It's not actually wrong, it's just not as specific as the one you provided. (And it's the same as for previous releases, so I can see why Hen used it. ;) I've gone ahead and replaced all of the download URLs with the more specific one, though. -- Martin Cooper Try http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi [EMAIL PROTECTED] wrote: section name=Downloading subsection name='Full Releases' p +strongFileUpload 1.1.1/strong - ?? May 2006 +ul + liDownload the binary distribution from a mirror site +a href='http://jakarta.apache.org/site/binindex.cgi' here/a + /li + liDownload the source distribution from a mirror site +a href=' http://jakarta.apache.org/site/sourceindex.cgi'here/a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] Do we change the groupId for the 1.1.1 release?
On 5/27/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi I'm in the process of updating all commons components to the new groupId org.apache.commons. It sounds like the 1.1.1 release of fileupload is imminent. Should I do fileupload *before* or *after* the release? I'd be OK either way, but I'd lean slightly towards after, since this is a dot dot release. -- Martin Cooper -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] Remove dependency on commons-build
On 5/25/06, Niall Pemberton [EMAIL PROTECTED] wrote: As Henri seems to be getting ready for a FileUpload release do we want to remove the dependency on commons-build as other projects have done? I can do this if you want. What do we gain, and what do we lose, by dissociating ourselves from commons-build? I'm fine with independence, just curious as to the reasoning behind the change. Niall P.S. I already fixed a couple of things (checksum generation in build and Jira issue numbers on the changes report) - since they were just minor build/site issues I hoped noone would mind if I just jumped in and corrected them. Not at all. Thanks for fixing them. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] commons karma for Jochen Wiedmann
On 5/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: Jochen Wiedmann ([EMAIL PROTECTED]) is a pmc'er over in web services land. Jochen would like commons karma (http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/% [EMAIL PROTECTED]) to help work on file-upload. Since when did we start inviting people into Jakarta based on their first (AFAIK) proposed - and not yet accepted - patch? Has anyone looked at the patch? I haven't seen any discussion on it, and I know that I'm not going to have time to look at it until the weekend, long after this vote will have closed, apparently. This is nothing personal against Jochen - I don't know him at all - and is not related to the fact that his contribution is for FileUpload. I'm just very concerned at how low we're setting the bar these days. I, for one, do not subscribe to the Some of the guys over in project X think Fred is OK, so he must be OK modus operandum. Are we really saying that we'll allow other projects to decide on who merits commit access to Jakarta? That's what Hen appears to be saying, and I object strongly. -- Martin Cooper i trust that he'll discuss any plans with the file upload team but i think we can use his help. since this is a vote for karma, i think this can be executed a little quicker than normal. i'll tally votes not earlier than 2230 hours GMT on Thursday 25th of May. here's my +1 - robert --8 [ ] +1 grant Jochen Wiedmann commons karma [ ] +0 [ ] -0 [ ] -1 do not grant Jochen Wiedmann commons karma --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBEc41X1TNOdbExPeIRAg+xAKCZYOGmRiIaWRm6ahZkKCRS6iVNsgCgiNSS sJe7UQU/8bO3x5HsIXLikKA= =LRFX -END PGP SIGNATURE-
Re: [VOTE] commons karma for Jochen Wiedmann
On 5/23/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, On 5/23/06, robert burrell donkin rdonkin at apache.org wrote: Jochen Wiedmann (jochen at apache.org) is a pmc'er over in web services land. Jochen would like commons karma ( http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/% 3c4472E7BD.2080709 at gmail.com%3e) to help work on file-upload. Since when did we start inviting people into Jakarta based on their first (AFAIK) proposed - and not yet accepted - patch? Has anyone looked at the patch? I haven't seen any discussion on it, and I know that I'm not going to have time to look at it until the weekend, long after this vote will have closed, apparently. I imagine we can keep the vote open that long if you have concerns. As to the question at the beginning of the paragraph, I would imagine it's a fairly unusual scenario, but one answer that comes to mind is when the component has no other active developers. So I guess the fact that I've only fixed a handful of FileUpload issues this year makes me an inactive developer? And thus being the last one to have been active, opens the door as you suggest? -- Martin Cooper --8--- [ X ] +1 grant Jochen Wiedmann commons karma [ ] +0 [ ] -0 [ ] -1 do not grant Jochen Wiedmann commons karma Yoav (via gmane) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-daemon
On 5/20/06, Bernard [EMAIL PROTECTED] wrote: Hi How can I enter an issue for commons-daemon at http://issues.apache.org/bugzilla/enter_bug.cgi I can't find the product/category anymore. Commons has moved to JIRA, and no longer uses Bugzilla. For Daemon issues, please see: http://issues.apache.org/jira/browse/DAEMON -- Martin Cooper Many thanks Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Lead thought
On 5/19/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: How about this for policy regarding Leads in Jira. Generally projects have the Commons Developers user as their lead - unless the component is in the process of working towards a release. In which case the release manager volunteer puts their name down as the lead. Any thoughts? It would probably work, but feels a little unecessary to me. I agree. I'm not sure what we'd be gaining by changing the lead when a release is coming up and then changing it back when the release is done. In fact, I'm not sure what the point of having the lead is in the first place, other than that Jira needs one, so I don't think it matters much what name we put there. -- Martin Cooper Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Unifying maven reports?
On 5/19/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Hello I would like to start a discussion about trying to unify which Maven reports should be used for each commons component. The reasons I find for unifying the reports are these: - Makes it easy for our users if we are consistent - they know what to expect - Makes it easier for us to maintain our project.xml files - Facilitate Maven 2 migration Digging into the Maven 1 POMs for commons proper I have come up with the list of reports here below. Some reports that are only used in a few components have been omitted. I have also tried to categorize and describe each report, borrowing/stealing a lot from chapter 6 in the new book Better Builds with Maven. + means that I think that all components should use this report o means that I think this report should be optional - means that I don't think any component should use this report Standard + license Source health + checkstyle (code formatting) Agree. But different components use different coding styles, so although we could standardise on the use of the plugin, we can't standardise on the actual rule configuration. + jdepend (quality metrics) + pmd/cpd (bugs, code duplication, coding standards) + tasklist (to do list) - findbugs (same as pmd?) I would rather see this as + than -. FindBugs is an awesome tool, and is absolutely not the same as PMD. In my experience, FindBugs does find real, and, in some cases, serious, bugs within the code that no other tool that I'm aware of can discover. (Don't get me wrong - I love PMD too, but these tools do different things, and both are very valuable.) - simian (same as cpd) Tests + cobertura (test coverage) + junit (test reports) - clover (same as cobertura) - jcoverage (same as cobertura) Changes since last release + changelog (SCM activity per commit) + clirr (binary compatibility) + developer-activity (SCM activity per developer) Does anyone really care? + file-activity (SCM activity per file) As with developer-activity, I'm not sure that anyone really cares, although I could see ever-so-slightly more justificatoin for this one. o changes This is only useful if people actually update it. ;-) - jdiff (same as clirr) Reference + javadoc + jxr (cross reference) User guide o faq I like the FAQ plugin. I like the way it creates all the links and sections for you. I, for one, am not interested in having to do all that myself, so I disagree with Hen's suggestion that we just use xdocs for the FAQs. -- Martin Cooper - linkcheck (might be enabled during development) With that I will duck from the flames and see what the rest of you think :) -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/17/06, Henri Yandell [EMAIL PROTECTED] wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X The former. -- Martin Cooper ?? The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Bugzilla change
On 5/13/06, Henri Yandell [EMAIL PROTECTED] wrote: Bugzilla gods in the sky, could you unclose the Commons project please? Done. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] [PATCH] ComparatorPredicate
On 5/14/06, Rune Peter Bjørnstad [EMAIL PROTECTED] wrote: When I try to create a new bug in ASF Bugzilla, the Commons does not appear as one of products to register under. Can you give me a pointer to where I can register a report? Commons in Bugzilla had been closed for bug entry, pending the move to JIRA. Since that is now on hold, the Bugzilla component has been re-opened, so you should now be able to create a new enhancement request. Sorry for the confusion. -- Martin Cooper The documentation that I've found points to ASF Bugzilla. Rune. -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: 13. mai 2006 00:43 To: Jakarta Commons Developers List Subject: Re: [collections] [PATCH] ComparatorPredicate You'll need to raise a Bugzilla enhancement to attache a patch. Stephen Rune Peter Bjørnstad wrote: I've submitted an implementation of a predicate that utilizes a Comparator for evaluation. I feel this is a missing feature in commons-collection's functor package. The implementation is supplied in the file ComparatorPredicate.java, as well as a patch to PredicateUtils and TestPredicateUtils that incorporates the introduced predicate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? I would be in favour of that. The sooner all ASF projects use a consistent groupId scheme, the better. how much hassle would this change be for downstream consumers? Virtually none, as long as we make the change obvious, e.g. by including the groupId and artifactId in release announcements and download pages, or somewhere of that sort. -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [openpgp] Building openpgp
On 5/3/06, Henri Yandell [EMAIL PROTECTED] wrote: I get the following error (using a fresh install of Maven 2.0.4) when trying to build OpenPGP, or indeed trying to domvn -N install in the sandbox directory to put the parent pom into the local repository. I just built it successfully with Maven 2.0.4. I had problems when I didn't have the right parent POM, but once I updated my whole sandbox tree, it was fine. (mvn package, at least.) -- Martin Cooper Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-SNAPSHOT/maven-site-plugin-2.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository snapshots (http://snapshots.maven.codehaus.org/maven2) [INFO] Skipping missing optional mojo: org.apache.maven.plugins:maven-site-plugin:attach-descriptor Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-SNAPSHOT/maven-site-plugin-2.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository snapshots (http://snapshots.maven.codehaus.org/maven2) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-site-plugin \ -Dversion=2.0-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/to/file Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][all] Switch to Jira
On 5/2/06, Henri Yandell [EMAIL PROTECTED] wrote: I'd like to call a vote that we switch to Jira. Here's the loose migration plan: * Make Bugzilla read-only * Import Commons project in Bugzilla into Commons project in JIRA This will pull over users, components, versions etc. * Setup notification scheme * Setup permission scheme * Setup group * For each of the 37 components ** Create new project - name: Commons Xxxx, key . ** Assign notification, permission and group ** Create relevant versions ** View component, bulk move all issues to new project * Cleanup Commons project (we'll still use it as a catch-all). Delete components/versions. The 37 components don't all have to be set up at the same time, we can take our time to move things out of the Commons project and into the individual Commons Foo projects. [X] +1 [ ] -1 -- Martin Cooper Vote to last 72 hours, 3 +1s required, 3/4 of active vote being +1. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira migration Was: [VOTE][all] Switch to Jira
On 5/2/06, Henri Yandell [EMAIL PROTECTED] wrote: On 5/2/06, Gary Gregory [EMAIL PROTECTED] wrote: * Cleanup Commons project (we'll still use it as a catch-all). Delete components/versions. This does not match: * Make Bugzilla read-only What about creating an 'Catch all' product in JIRA and only using JIRA? It would be. My fault for not saying Jira/Bugzilla when refering to the Commons project. We'd suck all the data into a project in Jira called Commons. Then we'd move stuff out of it into individual projects until we had just [site]/[all] issues left. Then we'd delete the versions and components in that Jira project and it becomes our catch-all Jira project. The problem with that is that you can be sure that plenty of people will file issues under something called just Commons without looking for the component. We'd be better off, IMHO, creating explicit components for 'site' and 'all'. (I'm not at all convinced we need the latter, though, since there would be issues with figuring out when it's ready to be marked Closed.) -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] JSExtensions - Integrating Java into Javascript
On 4/27/06, Don Brown [EMAIL PROTECTED] wrote:
I propose a new commons sandbox project, JSExtensions, aimed at providing
a
library of server-side Javascript (Rhino ATM) extensions that better
integrate Java into the Javascript environment. This is implemented in
two
areas:
- Making the Java collections more natural to Javascript
- Extending the Java API to add convenience properties and methods
Sounds fine to me. Interesting implementation, too. ;-)
--
Martin Cooper
The inital code will come from Struts Flow[1], a Struts sandbox project that
brought server-side Javascript to Struts. In its development, I looked at
Groovy and saw how they improved the Java API [2] to make it better
integrated and more natural in the Groovy environment. I brought its
ideas
over to Struts Flow [3], attempting to do the same for Javascript. This
code is better suited as an individual project, usable by other
Javascript-using Apache projects like Cocoon. In addition, these changes
make Javascript equally appropriate for standalone shell scripting-type
tasks.
As a quick example, here is the eachLine() extension method on the
java.io.File object, printing each line's contents to System.out:
file = new java.io.File(foo.txt);
file.eachLine(function(line) { print(line) });
To be clear, this proposal has nothing to do with client-side Javascript,
only server-side Javascript through Rhino and soon Java 6. The code
already
runs and uses a special unit testing framework for testing. Looking
forward
to the feedback.
Don
[1] http://struts.apache.org/struts-sandbox/struts-flow/
[2] http://groovy.codehaus.org/groovy-jdk.html
[3]
http://struts.apache.org/struts-sandbox/struts-flow/FileExtensions.html(one
example)
Re: Current Status of Commons FileUpload
On 4/27/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/26/06, Jeffrey Zellman [EMAIL PROTECTED] wrote: Hi, I was wondering when the next release/beta will be for Commmons FileUpload. Afaik, and it's from being a user not a developer of fileupload, the conversation has turned to a FileUpload 2.0 - in which the major issue I've seen discussed is changing things so that the handling of errors/overly large files is not so arbitrary. Right. There are a number of issues to tackle for 2.0. I really need to write something up on the wiki so that there's a roadmap that's not just inside my head. ;-) -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. Personally, I'd like to see each component able to move grouping within Jakarta, thus we should use naming like JAKLANG or JAKARTALANG, rather than JLCLANG (for Jakarta Language Components). Another option, now that infra is open, at least to some extent, to multiple JIRA instances (Struts has its own, for example), is to create a separate instance for Jakarta. Then you could just have LANG, and forget about prefixes altogether. -- Martin Cooper We also need to be aware that about half the commons websites now have links tailored to bugzilla, and these links get placed into maven built distributed projects. Another bit of work to do. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/27/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. That's the id-code rather than the name (afaik). I didn't know that that was being standardised - JHCHTTPCORE is terrible, sounds like a sneeze. Ideally we should use whatever we want, it's not a namespace to fight over, just need to be unique. Personally, I'd like to see each component able to move grouping within Jakarta, thus we should use naming like JAKLANG or JAKARTALANG, rather than JLCLANG (for Jakarta Language Components). We also need to be aware that about half the commons websites now have links tailored to bugzilla, and these links get placed into maven built distributed projects. Another bit of work to do. Not sure anything can be done about that one. Do you mean the sites that get stuck in the zips (by maven built distributed projects) or something else? I suspect that every project has had a period of cold turkey when it moved over. Any idea Martin? Is there a .htaccess in the Bugzilla somehow? Not directly. There was some discussion on this on infra@ a while ago. ISTR that someone (Jean Anderson, I think) was going to write something, but I've kinda lost track of whether anything actually happened. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/25/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I am -1 on moving to jira. I dont understand why we - the open source developers and our users - should help testing a commercial application. And given that even for a mid-size company the minimum required license is the professional one - and its update policy - it is a rather expensive thing. Expensive? It's one of the least expensive enterprise-grade applications I've ever seen! At $4,800 for an enterprise license and a $2,400 annual upgrade, it's a steal. The serious competitors run into tens of thousands of dollars for an enterprise license. Also, JIRA is free for all non-profit and charitable organisations, and for open source. Also I dont understand whats the great benefit for us - compared to bugzilla - that we act as a marketing plattform for jira. We're no more a marketing platform for it than any of the other open source organisations that use it. As others have pointed out, many projects - and I do mean *many* projects - at the ASF already use it. See: http://issues.apache.org/jira/secure/Dashboard.jspa One other point: JIRA is a glowing example of what open source can do. It is built upon a ton of other open source projects, some of which were even founded by the JIRA authors themselves. As for features, I think the dashboard is very valuable, as is the project summary, and the ability to use it for planning and roadmap tracking in a *much* more usable manner than Bugzilla. -- Martin Cooper Sorry if I completely missed the point. Do not hesitate to correct me. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [bugzilla] 2.2-Final target version for Commons Lang
On 4/25/06, Henri Yandell [EMAIL PROTECTED] wrote: Scratch that, I don't see any reason for the Final stuff; so could I have the following two target milestones please: 1.0.1 2.2 Done. I added 1.0.1 Final to make it consistent with Versions, and just plain 2.2. -- Martin Cooper Hen On 4/25/06, Henri Yandell [EMAIL PROTECTED] wrote: Appealing to the great BZ admins in the sky, could I have a 2.2-Final target version so I can specify such for Commons Lang issues? Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
On 4/25/06, Henri Yandell [EMAIL PROTECTED] wrote: I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I used to be a -0.5 on moving to JIRA simply because it's not open source. However, having delved into JIRA more than a little, both on open source projects and in my day job, I've converted to a +1. There's a lot we could use it for that Bugzilla just doesn't do. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][SCXML] Whats in the name ...
On 4/19/06, Niall Pemberton [EMAIL PROTECTED] wrote: +1 for keeping SCXML. Firstly since Rahul has done the work then I don't think we should try to impose a name. Secondly, since it is an implementation of a spec, then using that in its names looks like a good idea to me. Lastly if we want a component with a generic name like state, statechart, etc - then IMO we need someone to come forward with some generic state, statechart etc. code. As no-one seems to proposing/offering that - then lets stick with the actual concrete thing we have - which is Rahul's SCXML. What Niall said. +1. -- Martin Cooper Niall On 4/17/06, Rahul Akolkar [EMAIL PROTECTED] wrote: A fairly random stringing on my thoughts on the topic ... Since there was talk about whether SCXML makes a good name for the component, its only appropriate that I list some reasons. State means little to me (or better, means so many things that is becomes extremely fuzzy). A statechart, to me, is a graphical entity, tied to the modeling layer, and in general does not cleanly tie in to any execution environment. There is lot of state chart theory around, many flavors exist with minor semantic deltas (UML 1.5/2.0, STATEMATE, RHAPSODY, and now SCXML). I think nothing defines scope and semantics better for this component that clarifying that we use SCXML semantics (by default) via the component name. We shouldn't lose this clarity only to have to struggle to regain it via numerous clarifications on the mailing lists each time a related question is raised. We need an oracle. We have a bunch of smart folks from a leading standards organization giving us just that. Maybe some years down the line, the abbreviation SCXML may become more commonly known. If all of us here drop this component on the floor and walk away from it today, I believe that after any arbitrary amount of time, someone with a beginner level understanding of Java and XML can pick it up, hold the SCXML document from the W3C by its side, and atleast figure out if the thing is doing what it is supposed to do -- and if not, attempt to correct it. Also, JCP, RFE and W3C standard driven projects have an easier time managing their scope. No user has complained about the component name, mailing list prefix used etc. (though having injected this debate into the mix, this may now come up frequently). StateChartXML is a decent suggestion, though I'm personally not motivated enough to make the change. I will be breaking some user code before the first RC (I'll post a note to the user list when that happens), but changing Java package names will probably cause more confusion that is warranted, so those are best retained. Finally, recounting from personal experience, when I came to Commons, I knew what I was looking for (Digester). I didn't know what Jelly was, what JEXL stood for, what betwixt was getting in between, what configuration was configuring nor what latka did. Then one day, I read the descriptions. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] Compile against Servlet 2.4 spec?
On 4/12/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/11/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/11/06, Henri Yandell [EMAIL PROTECTED] wrote: At work I compile FileUpload against the Servlet 2.4 spec. This means a patch so that the mock classes in the unit test will successfully extend the 2.4 super classes. Any interest in this being applied to fileupload? Can you say more about the nature of the changes? I guess as long as the end result still allows FileUpload to be built and tested against the Servlet 2.3 API, per the Maven POM, I'm not averse to enabling it to be built and tested against the Servlet 2.4 API as well. About 10 methods added to the PageContext, HttpServletRequest and HttpServletResponse classes; thus their mock descendants in the test package need them too. I implemented them all as UnsupportedOperationExceptions. Pretty sure it'd be fine with 2.2, but will definitely test this prior to committing. It's not a biggy - but as I was doing it for work, I figured I'd offer. Sure, go for it. And thanks! -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] FileItem.getName() IE prefix
On 4/12/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Martin Cooper wrote: The point is not that this code is onerous, but that it is knowledge about fileuploading that we have not encapsulated in [fileupload]. Because it was specifically not intended to be addressed by FileUpload. But that doesn't answer why it can't. Should I be quoting examples of where people have suggested enhancements to Commons IO that you have claimed are out of scope for that component? I seem to remember essentially the same discussion coming up there. Certain methods _could_ be added, but were not. Why? -- Martin Cooper This is a component to assist with file uploading. This is a known problem with file uploading. It comes up reapeatedly in user queries. Surely this points to a missing method. Is the problem the fact that FileItem is an interface and thus can't be changed? As a user of [fileupload] I should be presented with the fact that I have to make a choice in the API. At the very least, the javadoc for getName() should provide a full description of the problem. You mean like this? http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileupload/FileItem.html#getName() Yes. I looked in the disk package, where the text isn't present. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] FileItem.getName() IE prefix
On 4/11/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Martin Cooper wrote: Well, they've already got Commons IO, since FileUpload depends on that, and that has FileNameUtils.getName() to get just the file name, so do we really need to add another method in FileUpload that just wraps that call? String filename = FileNameUtils.getName(item.getName()); instead of: String file name = item.getName(); doesn't seem so onerous. The point is not that this code is onerous, but that it is knowledge about fileuploading that we have not encapsulated in [fileupload]. Because it was specifically not intended to be addressed by FileUpload. As a user of [fileupload] I should be presented with the fact that I have to make a choice in the API. At the very least, the javadoc for getName() should provide a full description of the problem. You mean like this? http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileupload/FileItem.html#getName() -- Martin Cooper I think I prefer getNameNoPath() as the method name. The reason is that it will appear next to getName() in IDE auto-complete, thus causing casual users to stop and think. I volunteer to code this (or apply an external patch ;-) if it won't be -1'ed. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] Compile against Servlet 2.4 spec?
On 4/11/06, Henri Yandell [EMAIL PROTECTED] wrote: At work I compile FileUpload against the Servlet 2.4 spec. This means a patch so that the mock classes in the unit test will successfully extend the 2.4 super classes. Any interest in this being applied to fileupload? Can you say more about the nature of the changes? I guess as long as the end result still allows FileUpload to be built and tested against the Servlet 2.3 API, per the Maven POM, I'm not averse to enabling it to be built and tested against the Servlet 2.4 API as well. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] FileItem.getName() IE prefix
On 4/8/06, Stephen Colebourne [EMAIL PROTECTED] wrote: From commons-user: True, but I noted that O'Reilly's version just added this snippet to remove any trailing / or \: Right. The Commons FileUpload philosophy, though, is to give you exactly what the browser sent, no more and no less. It's not up to FileUpload to determine what the caller wants - some callers may want or need the extra information if it's available. Thats probably the right philosopy for getName(), but shouldn't we have a getBaseName() or similarly named method _as_well_ that does the stripping of the IE rubbish? Well, they've already got Commons IO, since FileUpload depends on that, and that has FileNameUtils.getName() to get just the file name, so do we really need to add another method in FileUpload that just wraps that call? And if you think we do, what would we call it? You mentioned getBaseName(), but there's a method in FileNameUtils with that name that does something different, so I think that would be confusing. At present we are forcing every user of [fileupload] to know this naming fact and write code to handle it, which surely goes against commons philosophy. String filename = FileNameUtils.getName(item.getName()); instead of: String file name = item.getName(); doesn't seem so onerous. -- Martin Cooper Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] RC on ibiblio ?
On 4/5/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2006-04-05 at 20:41 +1200, Simon Kitching wrote: On Wed, 2006-04-05 at 10:05 +0200, Nicolas De Loof wrote: Hello, Can someone upload commons-logging RC on Maven2 ibiblio repository ? It would be very cool to also upload a POM and the sources jar... That would be a good idea. sadly policy dictates that we can't upload release candidates to ibiblio Right. But is there any reason we couldn't create a Maven 2 parallel to the Maven 1 repo we have at http://cvs.apache.org/repository/? We could deploy RCs there. -- Martin Cooper We should also provide a link on the downloads page or something similar. Just today a work colleague was looking for a later version than 1.0.4 in order to get log4j TRACE support. I told him there was an RC out, but there was just no way for him to locate it... i've been at work off list and things look good. i think i'm just about ready to cut the final release candidate this weekend and try a release vote. By the way, there is still an outstanding discussion about whether to add JDK14Logger back into the commons-logging-api.jar file. It was there in the previous release. It probably shouldn't be; it's not logical. However it does no harm as far as I can see, and the point was made that because the current RC doesn't include it, it isn't a drop-in replacement. yep i agree that it's not logical but ATM it would be good to ship a fixed replacement. it's likely that tomcat 6 will ship a JCL library created by costin which is static bound to java.util.logging. So I'm +1 on adding JDK14Logger back to the api jar, then cutting a new RC and uploading to ibiblio + linking from useful places. Alternatively, we could just make the above change then hold a release vote. I think we've given this RC enough time for feedback. i've got the feedback i wanted now (off list) so i think the time is right to cut another release candidate and hold a release vote next week. i'll probably give the vote two weeks this time. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] RC on ibiblio ?
On 4/5/06, Carlos Sanchez [EMAIL PROTECTED] wrote: On 4/5/06, robert burrell donkin [EMAIL PROTECTED] wrote: sadly policy dictates that we can't upload release candidates to ibiblio AFAIK is PMC decision what gets uploaded No, this is bigger than any individual PMC. Only official releases can be deployed outside of ASF infrastructure, meaning that RCs cannot be deployed to ibiblio or made available via mirrors. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] RC on ibiblio ?
On 4/5/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/5/06, Martin Cooper [EMAIL PROTECTED] wrote: Right. But is there any reason we couldn't create a Maven 2 parallel to the Maven 1 repo we have at http://cvs.apache.org/repository/? We could deploy RCs there. It's already there: http://cvs.apache.org/maven-snapshot-repository Oh, that's what that is. ;-) The name threw me. -- Martin Cooper You can use 'mvn deploy:deploy-file' to deploy the RC, and Maven will generate a pom for it. That should be fine since Logging has no required dependencies. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] Unit test for 38490?
On 4/4/06, Henri Yandell [EMAIL PROTECTED] wrote: Anyone mind if I add a unit test for: http://issues.apache.org/bugzilla/show_bug.cgi?id=38490 ? There's no way I'm going to turn away good unit tests. Knock yourself out, Hen! -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Author tags [was Line width and such minutiae]
On 4/2/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 4/2/06, robert burrell donkin [EMAIL PROTECTED] wrote: Gary Gregory wrote: Based on the February 18, 2004, Apache Software Foundation Board of Directors Meeting Minutes, author tags are discouraged. snip Sandy McArthur wrote: I have searched some and the arguments don't hold water with me. :-) Many things from lawyers and the board don't make sense ;-) here's the only convincing argument i know of: what worries the board (and other open source folks) is the effective destruction of open source projects by targeting (with individual lawsuits) the limited number of critical contributors who do crucial things such as cutting releases. if these individuals are acting on their own behalf, as a non-profit the ASF cannot help them. if they are acting for the ASF then the ASF can defend them in court. so, the trick is setting up a structure which imposes as little friction on development as possible but which allows developers to develop for the ASF rather than on their own behalf. PMC'ers are part of the ASF organisation by their membership of an ASF committee and can bind the ASF to a particular course of action. they should therefore be protected from disruptive litigation by the ASF legal umbrella. committers are not. so, it's important for PMC's so recognise those who make important contributions to the ASF in a reasonably prompt fashion. the question of the policy on author tags is related to this. it was felt that PMC'ers may be weakening the legal argument (that they acting on behalf on the ASF) if they added author tags to the code. might look to a lawyer as if they were working for themselves. that's why recognition elsewhere is fine. For me that falls apart in two places: 1. authorship != ownership, this is made clear by the file's header. 2. subversion contains enough information to target critical contributors. In my mind that is like worrying about a second story window that may be unlocked when your front door is off the hinges. Subversion does indeed contain plenty of information. However, lawyers don't understand source control systems, but they do understand plain text. A technical perspective isn't what's important here; what lawyers understand, and what is supported by legal precedent, is. That's where the board is coming from, backed by legal advice. note that this argument is only valid for PMC'ers and is not relevant for author tags for other developers. when committing patches from developers who are not committers, it is important that the source of the patch is noted in the commit (so that it can be tracked). I'm proud of the code I've contributed and I think an @author tag is proper recognition. I suppose that five years ago when I joined, I felt something similar. At that time author tags were allowed, so it wasn't a problem. Over time, that desire for such 'base' recognition has gone. You're probably right eventually. When I'm married and have kids I probably won't even remember this but until then I do care with respect to my own contributions. the maven generated team list and commit emails are better indexed (and analysed) than the source. so, as a form of recognition, these generally work better. author tags also seem to attract the wrong kind of recognition: spam from uneducated users (who should be posting their questions to the user list). we've also had arguments in the past about authors who no longer wished to be associated with particular classes. life is usually easier without them. I think the best policy is to stay true to yourself and be tolerant of people with different policies. In my mind that will work today, tomorrow, and up until the earth is swallowed by the sun. that's pretty much my approach. i generally leave author tags alone. for new classes, i add apache as the author. but my opinion is in the minority and i can understand why components with classes with long author lists prefer to insist on the maven team list. Well, IDEs with code folding make that irrelevant and those list of @author tags not need be so long as the @author can can be either one name per tag (common) or many comma separated names per tag (seemingly unknown). Not everyone uses an IDE, and we shouldn't be basing decisions on the assumption that everyone is. Many of us prefer to work with the same tools we've been using for years, and we're just as productive with those tools as others might be with an IDE. -- Martin Cooper -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion for all of Commons
On 3/29/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Hey all,
I just spent about 20 minutes working through a problem with FileUpload...
turned out to be my fault entirely, I didn't include Commons IO (FYI, I'm
not seeing a dependency list on the FileUpload site... maybe I missed it).
You did. See:
http://jakarta.apache.org/commons/fileupload/dependencies.html
This is the standard location for the dependency list for all Commons
components.
The problem is, it was one of those aggrevating problems to track down
because the stack trace didn't reveal the actual line where the failure
occured, and catching Exception didn't get triggered. I wound up catching
Throwable, and I was then able to figure it out.
The stack trace should have shown a NoClassDefFoundError indicating a class
in Commons IO. I haven't seen a situation where that's not the case, and
that's also been the case for all of the people who've asked about it on the
list, at least that I can recall.
I know that missing dependencies is always a b**ch, and they tend to be
these annoying problems with no error messages or anything (sure, a
debugger helps, but that doesn't seem like the best answer to me). So, I
have a suggestion that could well go all across Commons, or any other
project for that matter.
In Java Web Parts, we've gotten into the habit of putting this in all
classes:
/**
* This static initializer block tries to load all the classes this one
* depends on (those not from standard Java anyway) and prints an error
* meesage if any cannot be loaded for any reason.
*/
static {
try {
Class.forName(org.apache.commons.logging.Log);
Class.forName(org.apache.commons.logging.LogFactory);
} catch (ClassNotFoundException e) {
System.err.println(CacheControlFilter +
could not be loaded by classloader because classes it depends +
on could not be found in the classpath...);
e.printStackTrace();
}
}
Aside from the fact that Class.forName is generally not a good idea in a
J2EE environment, I personally have a strong dislike for static
initialisers, so I'm not inclined to do something like this for components I
work on. Other folks may like it, though. ;-)
--
Martin Cooper
It's just echoing the import list, minus classes found in the SDK (if
that's missing, you aren't getting *this* far!). This saves a lot of time
and headache when you are missing a dependency. I know that adds
something additional to maintain in the class, but it seems a fair
trade-off to me.
Does anyone see this as being something that might be helpful for Commons?
If there is a better way to get the same effect I'm all ears too (I could
see setting a string to the name of the class being checked so that it
could be output as part of the error message, but I'm talking about a
whole other way to check for dependencies).
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. Urk. No thanks. If I download a couple of Commons components, and they share a couple of dependencies, and the bundled versions of those dependencies are different, what should I, as a user, do? I think that would just cause more confusion within the user base. As for having just a single distribution, I'm not in favour of that either. The vast majority of users don't give a dickey bird about the source, and it just bulks up the distribution, and therefore the size of the end user's distribution as well. I doubt our users will thank us for increasing the size of their own applications, potentially increasing their bandwidth usage for customers to download their products. -- Martin Cooper 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. Agreed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/27/06, Sandy McArthur [EMAIL PROTECTED] wrote: snip/ P.S.- [pool] code is quite hard to read with all that horizontal scrolling. Irrespective of the code already in place, maybe we should stick to a reasonable (80?) character line width for new code? The code I contribute to apache is code I wrote for pleasure. The code I contribute is in the form that was most pleasurable for me to write in. When contributing to a community code base, you also need to think about how approachable your code is to other contributors, many / most of whom may not currently be working on the project. I impose no restrictions on how others choose to write their code. If you wish to compensate me to write code differently or reject my contributions because of such trivial issues, that is fine. The ASL grants anyone the right reformat ASL licensed code however they see fit. I only request that I am not stripped of attribution for my contributions. snap/ The comment wasn't about imposing restrictions, that would never work anyway. Even while writing for pleasure, a lot of components still check for style (I think its valuable). The line width style criteria has some valid reasons, not the least of which is its accessibility implication that those more fortunate tend to not realize. So, I am implicitly -0 for any *new* commits that are needlessly and consistently too wide which indicates my personal preference (a -1 ofcourse would be an attempt to impose a restriction). And I will always respect your opinion, even if it doesn't match mine. Compensation never comes to my mind in face of any discussions on these mailing lists, that bit was a no-brainer. +1 - regarding style issues, we have been fairly consistent in the following: * When contributing code to an existing component, follow the style of the surrounding code * Decisions to change the coding style or set checkstyle / pmd / other rules for style checking are made by (lazy) consensus at the component level, with opinions of those actively working on the code having greatest weight * Separate reformatting commits from commits that change behavior and try to avoid extraneous diffs in commits. My personal preference is 80 column line widths, partly because this makes diffs readable. As a sidebar, since attribution got mentioned -- its an old, widely discussed topic at the ASF. Some of us believe that author tags in source code are a distraction (doesn't mean we want everyone to change their opinion). It has to do with issues arising out of how you define the least unit of work that warrants an author tag, the tedium of having to remember to add an author tag while applying a patch, and issues of fairness (should the author tags be ordered by size of contribution to the source file, name, chronology). A lot of older projects traditionally had author tags, so its more effort to discontinue, but for newer projects, I personally have begun to prefer the no author tags policy. Accordingly, I will likely -1 a patch to the [scxml] code if the author insists on having an author tag. And maybe that means [scxml] will miss out on some valuable contributions from talented folks purely for that reason, but that is perhaps the lesser of the two evils. Attribution then, gets handled via commit messages and the team page. All commit messages contain attribution as the case may be, and anyone who contributes any code -- be it a line or a million -- gets listed on the team page. +1 and search the archives for lots of discussion about why we should not be adding new @author tags. I have searched some and the arguments don't hold water with me. I'm proud of the code I've contributed and I think an @author tag is proper recognition. I feel strongly enough about this that I'd rather not contribute to apache at all than loose that recognition. We are not the Apache Borg. We are a group of individuals that enjoy programming. I am not willing to be assimilated and if the rest of apache has a problem with that then revoke my commit rights. All of us are proud of our contributions here. But the ASF is not about egos, and it is not about recognition. I don't know who came up with the phrase, but egoless programming is an appropriate term for the way we work. If you came here for the recognition, then I'm afraid you made a mistake. Perhaps we need to make a more prominent statement about author tags somewhere, for the benefit of potential future contributors. -- Martin Cooper I find listening to the variety of opinions on almost all things here at the ASF
Re: [all] Line width and such minutiae
On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Sandy McArthur [EMAIL PROTECTED] wrote: I have searched some and the arguments don't hold water with me. Main reasons I cba to put my name on stuff I touch or create nowadays: * Private emails asking questions, offering patches etc. It starts to add up. * It's an effort to put @author in. I'm lazy. Lots of names in one file does start to feel spammy. * It's pretty minor in terms of recognition. I'm proud of the code I've contributed and I think an @author tag is proper recognition. I feel strongly enough about this that I'd rather not contribute to apache at all than loose that recognition. We are not the Apache Borg. We are a group of individuals that enjoy programming. I am not willing to be assimilated and if the rest of apache has a problem with that then revoke my commit rights. Until we decide as a community to remove the @author bits Hmm, I thought we'd made that decision some time ago. Am I spacing? , you're welcome to keep adding them in. I'm pretty sure we've not made any community decisions as that thread would have stretched on for a long time. It's not a case of borg btw; the alternative to @author appears to be listing the people involved in a project somewhere. Might be interesting to do that per release :) Very Sesame St; Commons Lang 2.2 came to you via the work of . We already list the developers on the component web sites. For Pool, for example: http://jakarta.apache.org/commons/pool/team-list.html -- Martin Cooper To refer directly to Rahul's some of us believe bit; I also believe that 50% of javadoc is a distraction to the code :) I doubt we're going to change that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Gary Gregory [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Tuesday, March 28, 2006 3:02 PM To: Jakarta Commons Developers List Subject: Re: [all] Line width and such minutiae On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. This sounds to me like a problem with a particular diff tool. I do not think we should restrict our source code based on the limitations of /one/ tool. For those of us using Eclipse, this is not an issue since the tool (Eclipse) presents a nice user-interface that allows me to focus on the nature of the changes as opposed to the changes and the format the changes are given in. We use 120 at work. I think we got the idea from Jakarata Commons but I cannot find a link right now. Plenty of Commons projects use 120, so the number must come from some previous agreement. Perhaps agreement among some subset of us - the components I've worked on use 80 characters. ;-) -- Martin Cooper Gary -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] Announcing Release Candidate 2 for Pool 1.3
On 3/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-03-23 at 15:45 -0500, Sandy McArthur wrote: On 3/23/06, Oliver Heger [EMAIL PROTECTED] wrote: snip - LICENSE.txt and NOTICE.txt have unix style line endings in the zips. (This is not a problem for me, but was cause for some discussions in the past.) I'm on a mac os x box and unix style would be the default. How do other projects solve this other than building on win32? not sure if it can be done in maven 1. anyone know? Well, Maven can invoke Ant, so you could use this: http://ant.apache.org/manual/CoreTasks/fixcrlf.html -- Martin Cooper (if not, don't worry too much) the source is easy: export twice and set svn --native-eols appropriately for each. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Metadata?
On 3/8/06, James Carman [EMAIL PROTECTED] wrote: So, what's the next step here? Do I need more votes? Do I need to have a formal [PROPOSAL] prior to adding the starting the project in the sandbox? Technically, you don't need any votes. What you do need to consider, though, is whether or not there is, or will be, enough interest that you'll be able to form a community around the code. If that doesn't happen, then the component won't get out of the sandbox, and therefore won't be able to release. So far, I see only one person expressing interest. If it were me, I don't think I'd proceed with code at this point. But then it's not me, it's you, so it's really your call. ;-) -- Martin Cooper -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 1:02 PM To: 'Jakarta Commons Developers List' Subject: RE: Commons Metadata? Well, that's the thing. That's up to the decorator to decide how it gets the metadata information. Jakarta Commons Attributes does a pre-compilation step to set up the .class files so that their attributes can be read from them (from what I can glean from the docs). -Original Message- From: Thomas Dudziak [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 12:57 PM To: Jakarta Commons Developers List Subject: Re: Commons Metadata? On 3/7/06, James Carman [EMAIL PROTECTED] wrote: I believe I brought this up before, but I really think there's a need for this. We need a metadata framework which abstracts away the details of exactly how the metadata is found/provided. For example, some applications use only JDK5 annotations to add metadata to their classes. Others might use Jakarta Commons Attributes. Others might want to use XML files (if they don't want to have to touch the source). So, what we could provide is a MetadataFactory (or whatever you want to call it) which can have metadata decorators added to it. The decorators are added to a pipeline and are given a chance to append metadata information to the metadata object. We created something like this for the Trails (www.trailsframework.org) project so that we could use off-the-shelf domain models (how many times have you seen those at Best Buy?) within the framework by providing metadata via XML files as opposed to using JDK5 annotations. We could start this off in the sandbox, of course. Anyone interested in helping out? I could start off developing the core classes (the metatdata holder classes). +1 That sounds useful, especially if it also can be used at compile time, and if it can work with XDoclet-style Javadoc tags (e.g. using qdox or similar). cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources][all] Resources status
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/5/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Can we establish the status of [resources]. Rahul Akolkar wrote: * [resources] Since now it isn't part of Struts 1.3.0, seems thats a setback to interest in releasing. IFAIK: - its unreleased - there is little development effort (although something happened in November) - there could be a overlap with [configuration] - its raison d'etre seems to have disappeared Does a [resources] developer want to speak up in its favour? Or should we fast track it to dormant? Just to confirm - this means putting it back into the sandbox, right? Um, no, I believe fast track it to dormant means moving it to dormant. I know that the web site currently describes dormant as inactive sandbox components, but that is not accurate. FeedParser was promoted before it went dormant, and Resources is in the same boat. The web site is wrong - dormant components can come from Proper too. Phil's suggestion for FeedParser was: We need to make a decision on which way to go here...either demote back to sandbox/dormant or have someone step up to drive this component toward a release. I don't see anything that argued with the demoting, though I can only find the thread suggesting the change. Sorry, I didn't follow the FeedParser discussions too closely. What are the criteria, then, for deciding between a Proper component going back to the sandbox and going straight to dormant? I'm assuming that, should BeanUtils, for example, remain inactive, you wouldn't argue for that to go back to the sandbox. -- Martin Cooper I'm also unsure why we'd be happy to move FeedParser and Resources from Proper to Dormant (without going back to the Sandbox) and yet the same doesn't seem to hold true for Jakarta components (referring to the thread on general@). Whatever happens, Latka needs the same to happen for it. It's been released, but only a 1.0-alpha1 N years ago. Not sure that even counts. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Proposal: Jakarta Language Components
On 3/6/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: snip/ It might make things simpler to draw up an entire future re-org of Jakarta. See who gets dropped through the cracks and decide if we have to kill, accept or leave them to stand alone. There are some obvious ones for JWC, and some that just don't seem to fit and would have to stand alone. I disagree there, and that is what actually led me to move to +1 for Stephen's proposal, when I have consistently argued against breaking j-c up in the past. I think it is reasonable to attack the problem (which, like some others I am not sure is as much a problem as some of us think) of lack of organization by letting self-organizing ideas like the one being discussed here move forward. In other words, instead of asking, OK, so now how to we organize the rest of the stuff? we instead focus on getting JLC going and then keep an open mind for the rest. Maybe the remaining commons components continue just fine for another several years. Maybe the struts components move over to struts and the JEE-ish things move into Geronimo or JWC really happens and they mostly move there. Maybe [math] finally gets a job and leaves home. And maybe none of this happens, or it happens slowly and independently. The key thing is to have it driven by people who want to make it happen. Nicely said. Exactly. Organic growth. -- Martin Cooper So who is going to make JWC happen :-) Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems...
On 3/5/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: snip/ We have a very noisy set of mailing lists. Need to ask how the Jive forum is going for Struts (I think I heard that was in place?). Watching how the Maven-dev move to separate lists for commits, jira, dev, ci goes. Here are some views on mailing list noise from someone who has only recently become a commons committer. I am also somewhat involved in Maven without being a committer. I think that the sheer volume of traffic on commons-dev is a big hurdle for people wanting to get more involved with commons. This is from my own experience. The lists that we have today are suitable for users (commons-user) and committers (commons-dev). As i see it, there is a couple of more steps in between, in the natural progression from user to committer. The important thing to bear in mind here is that, to a very large extent, commons-dev *is* the Jakarta Commons community. Meddling with that, for example by breaking up the list, is walking a tighrope. 1. Someone becomes interested in using a commons component, we'll take commons-lang as an example. The user starts using it and maybe has a few questions, so the user joins the user-list. 2. The user realizes that this is good stuff and starts to wonder how they accomplish this, so the user joins the dev-list. Note: this is where it usually ends because the user can't handle the volume of mails, so he/she just unsubscribes from the list and continues to be a happy user. 3. If we had a list where discussions on organization, methodology and design issues were available the above user might become more interested in the Apache way and stay if the traffic was reasonable. This would be the current commons-dev list without some extra baggage, see more below. 4. As the user becomes an involved user he or she might want to create an occasional patch for StringUtils or something. The involved user files an issue, attaches a patch and feels warn and fuzzy inside when the patch gets accepted. The involved user wants this feeling to last and joins the issues-list, where all bugzilla and jira issues are sent, looking for more to do. 5. The involved user is starting to wonder how those committer do their coding and joins the commits-list to see what everyone is doing and how they do it. 6. Time passes and the person gets more involved and is elected as committer. This means more responsibility and the person now has to worry about things like CI (GUMP) and subscribes to the ci-list or build-list (haven't got a good name for this one) Where does that leave us? If we create a couple of more lists I believe that we would attract more involved users. So my suggestion is to have these lists: commons-user commons-dev (includes the wiki stuff) commons-issues commons-commits commons-ci (perhaps with a better name) Breaking out these pieces is trivial to do with mail filters, which, as you mention below, people will still need to master anyway. If someone wants to be only partly a part of the community, they are free to filter whichever pieces they don't want directly to /dev/null. I'm not in favour of splitting the list this way as a solution for people who can't grok their own mail filters. -- Martin Cooper Subscribe all current commons-dev subscribers to the new lists commons-issues, commons-commits and commons-ci. Then announce the separation of lists on commons-user and invite folks to join in. Subscribers will still need to master their mail filters though. snip/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems...
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Yes we have many, many problems. Site Is this really our top priority? Is maven 2 helping here? Is maven 1? I Apart from thinking that our failure to work on an out of the box system is weak; my complaints are all on the site design. Will write stuff up on that - I've a long way to go before anyone is convinced by the sounds of it :) Inactivity Dormant has helped clarify the position. But are we willing to kick [beanutils] and [dbcp] into dormant? Since all user requests and bugs seem to have been ignored for many months, surely they are dormant? I await the screams from the wider community... Inactivity is the number one issue Is it really? Yes, there are one or two components that have a growing list of open issues that aren't being addressed, but is inactivity really the number one issue for Commons as a whole? Have we stepped back and taken a look to see how many components are just done for the vast majority of users? Sure, there will always be things that some people would like to see added or changed, but is that our business? Taking on any change that any one person wants to see? Frankly, I think one of the things that's hurting Commons is excessive navel-gazing. It's all the threads about how Commons (or Jakarta) is broken that make me tired of being here. I might even spend some time on code if I didn't have to spend it reading through all that mail... -- Martin Cooper , in the same way that breathing is the number one issue for any organism. We need to get the blood flowing; (nealry?) all of the other things mentioned are either to this end or to the same end for Jakarta. Commons as the solution We're not. We're barely holding our head above water. I'm definitely being chicken little and running around complaining about the sky falling; but my answer would be to look down at the drowned corpses below you :) Your answer does raise a very good point. My thinking has been that the various small components in Jakarta should fold into Commons - they're lost as subprojects. The larger subprojects would be split up, ie) velocity-core and velocity-dvsl would both be directly under Commons/Jakarta. However - this is under the huge assumption that this won't harm Commons. Option number 2 would be for Commons to goto TLP - and Jakarta could bury the corpses that don't twitch enough to keep their heads above water. Leadership Something Apache counsels against. Often however, the most successful projects have a leader who drives the project forward and on occaisions takes decisions. In commons we do have this, but only at the component level. We feel unwilling, or are unable, or don't want, a cross commons leader a lot of the time. There's a difference between a leader and Commons leading the way for Jakarta. Commons is talking about the issues that Jakarta is facing and not talking about. The answers Commons come up with will almost definitely be the answers Jakarta adopts. It's also proof for me on the Jakarta problem - it shoud be that issues in Commons are not a Commons problem, they are a Jakarta problem - there is no Commons. Unless you mean me bringing this stuff up and throwing out insane ideas :) That's your own faults - you turned me into this hideously deformed middle-tier cat-herder and now I can't help it. My analysis is that its time for a bit more radical surgery. And I mean splitting commons into smaller communities. Jakarta Xxx Components sets the naming pattern. If we do this, then each new group will be small enough to be able to take decisions by itself, for example on the site. Agreed with Brett on my reply to him about this being Jakartazization. We can't go this way without radically new ideas on how to organize an umbrella. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
