RE: dbcp bug
Noel I took the latest snap shot and this seems to work fine. Is there a plan for a new release in the near future? I am also interested in how dbcp deals with closed or 'stale' connections i.e. in the event of a db outage. Is it possible that stale connections could remain in the pool ? Thanks Liam -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: 18 August 2003 17:02 To: Jakarta Commons Developers List Subject: RE: dbcp bug Check this against the CVS. There were recent changes to make sure that operations were not performed on null references. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Attributes] Inherit and Develop
Hi, I'm a comitter at the Avalon project (avalon.apache.org), and I have developed tools and API to enable C#/.Net like attributes in Java. Originally I developed it as a proof-of-concept, and we held a vote on what to do with the project once the proof was done. The result was basically nice code, make it a real project - but do it elsewhere. The Commons Attributes project seemed to be the most natural place to go to. As far as I can see, Commons Attributes is *dead* in terms of development. Therefore I ask the following: + Commit access to jakarta-commons-sandbox/attributes + Some indication that the attributes project is indeed dead and that I can inherit it. This is just to pre-empt any conflicts arising from committing code to a repository that used to be used by someone else. For an explanation of what I have done, you can read the Javadoc Overview (along with some QA) at: http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon-sandbox/attributes/a pi/src/java/overview.html?rev=HEADcontent-type=text/html /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
From: Leo Sutic [mailto:[EMAIL PROTECTED] + Commit access to jakarta-commons-sandbox/attributes My apache user id is [EMAIL PROTECTED] (Might be good to include in a request for commit access.) /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] Inherit and Develop
Search back through the commons-dev archives. This code originally came from nanning, and there is a more recent version available. Some discussion began about incorporating attrib4j and the new stuff in nanning, but I think we got stuck because few of the interested developers are currently commons committers. In any case, it can only be a good thing to compare notes with the other implementations out there. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Leo Sutic wrote: Hi, I'm a comitter at the Avalon project (avalon.apache.org), and I have developed tools and API to enable C#/.Net like attributes in Java. Originally I developed it as a proof-of-concept, and we held a vote on what to do with the project once the proof was done. The result was basically nice code, make it a real project - but do it elsewhere. The Commons Attributes project seemed to be the most natural place to go to. As far as I can see, Commons Attributes is *dead* in terms of development. Therefore I ask the following: + Commit access to jakarta-commons-sandbox/attributes + Some indication that the attributes project is indeed dead and that I can inherit it. This is just to pre-empt any conflicts arising from committing code to a repository that used to be used by someone else. For an explanation of what I have done, you can read the Javadoc Overview (along with some QA) at: http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon-sandbox/attributes/a pi/src/java/overview.html?rev=HEADcontent-type=text/html /LS - 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: [Attributes] Inherit and Develop
From: Ryan Hoegg [mailto:[EMAIL PROTECTED] Search back through the commons-dev archives. This code originally came from nanning, and there is a more recent version available. Thanks. I've checked it out. However, I think that the approach taken in the Avalon version still deserves to be explored more before a merge can be discussed. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
I believe that as an Apache committer, you already have Karma for the sandbox. Eric Pugh -Original Message- From: Leo Sutic [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 1:01 PM To: 'Jakarta Commons Developers List' Subject: RE: [Attributes] Inherit and Develop From: Ryan Hoegg [mailto:[EMAIL PROTECTED] Search back through the commons-dev archives. This code originally came from nanning, and there is a more recent version available. Thanks. I've checked it out. However, I think that the approach taken in the Avalon version still deserves to be explored more before a merge can be discussed. /LS - 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: [docs] extra menus for mavenised components
Howdy, I like it ;) Except there's a Betwixt section and a Project Documentation section, which I think could be the same section no? It is the Betwixt project page after all ;) Regardless, I want to see Project Documentation above the general commons menus. But I imagine that would be a simple matter of which order the entities were included right? Yoav Shapira Millennium ChemInformatics -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 6:28 PM To: Jakarta Commons Developers List Subject: Re: [docs] extra menus for mavenised components i've committed the factoring out the main menu's into entity's. i've added some commons menus into betwixt (http://jakarta.apache.org/commons/betwixt/ index.html) if you want to take a look. probably needs some more tweaks before it's really right (i'd like to be able to separate out the commons menus) but it shows the basic idea ok. - robert On Saturday, August 16, 2003, at 07:12 PM, Henri Yandell wrote: +1 for this. Do you have a url example of what change we can expect to see to a mavenised project? Hen On Sat, 16 Aug 2003, robert burrell donkin wrote: one of the problems with the current commons website is that most mavenized components do not carry links back into jakarta-commons. i think that a major reason for this is that these have to maintained separately for each component and can easily become out-of-date. i've been playing around today and would like to offer a (partial) solution. it's possible to declare the menu entries as entities in a DTD. this DTD can include these from xml fragment files. the information would be moved from the project.xml into fragments and referenced from a DTD. (yes, i know that XInclude's are much better but it would involve extra overhead and extra learning for people. this way means that the existing process can be retained.) anyway, in practice this means that by adding a DTD definition to the top of a navigation.xml, mavenized components will be able to choose to include menus from the jakarta commons main menu. ever time that the documentation is rebuilt, the most up to date versions will be grabbed and used - zero maintenance for the component. unless some folks come up with some good reasons not to do this, i'll move the menus from the project.xml into xml fragment files sometime soon. - robert - 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] Inherit and Develop
On Tue, 19 Aug 2003, Leo Sutic wrote: Date: Tue, 19 Aug 2003 11:43:44 +0200 From: Leo Sutic [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Attributes] Inherit and Develop Hi, I'm a comitter at the Avalon project (avalon.apache.org), and I have developed tools and API to enable C#/.Net like attributes in Java. Originally I developed it as a proof-of-concept, and we held a vote on what to do with the project once the proof was done. The result was basically nice code, make it a real project - but do it elsewhere. The Commons Attributes project seemed to be the most natural place to go to. As far as I can see, Commons Attributes is *dead* in terms of development. Therefore I ask the following: + Commit access to jakarta-commons-sandbox/attributes Historically, commit access to jakarta-commons-sandbox has been granted on request to any *Jakarta* committer. I personally don't have any problem with widening that rule to any Apache committer, which would therefore include Leo automatically (he has commit access on Avalon, which used to be a Jakarta sub-project but is now top level). Does any other Commons-Dev committer or Jakarta PMC member have any problem with that? + Some indication that the attributes project is indeed dead and that I can inherit it. This is just to pre-empt any conflicts arising from committing code to a repository that used to be used by someone else. For an explanation of what I have done, you can read the Javadoc Overview (along with some QA) at: http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon-sandbox/attributes/a pi/src/java/overview.html?rev=HEADcontent-type=text/html /LS Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dbcp bug
Liam, Is there a plan for a new release in the near future? Possibly after some current changes settle. It might make sense to do a release with the fixes before changing how abandoned handling works. I am also interested in how dbcp deals with closed or 'stale' connections i.e. in the event of a db outage. There are several options for when even the currently available binary will handle those. If you look at http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/uti l/dbcp/ you can see how we turn that on in our server app. A problem is that the current code does not expose the property to client code, but that was easily handled. The options that are turned on for our code are on testing on borrow and return; I didn't bother to enable the periodic checking. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] Inherit and Develop
On Tuesday, August 19, 2003, at 10:43 am, Leo Sutic wrote: As far as I can see, Commons Attributes is *dead* in terms of development. Yep. Most of the folks who wanted to help out develop it (committers from QDox, Nanning, attrib4j etc) can't because its in the commons sandbox. It looks like those folks are getting together to develop something at codehaus.org instead. So you're most welcome to the commons-attributes project. James --- http://radio.weblogs.com/0112098/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: UUID Reuse proposal
+1, with the same experience. For 2.0. Gary -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 19:46 To: Jakarta Commons Developers List Subject: Re: UUID Reuse proposal From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, August 18, 2003 3:05 AM Subject: Re: UUID Reuse proposal SNIP Sorry, I had forgotten about the existing IdentifierUtils. I would suggest that all of the things above could be added there, at least to start. As a long time user of a UUID class, I would suggest *not* adding it to the existing IdentifierUtils class. There is more than enough behavior in a UUID to warrant its own class, even if most of that behavior revolves around creating immutable instances of itself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbcp project.xml
mpoeschl2003/08/19 10:33:54 Modified:dbcp project.xml Log: upgrade to latest commons-pool snapshot Revision ChangesPath 1.12 +1 -1 jakarta-commons/dbcp/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/dbcp/project.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- project.xml 11 Aug 2003 12:07:43 - 1.11 +++ project.xml 19 Aug 2003 17:33:54 - 1.12 @@ -106,7 +106,7 @@ /dependency dependency idcommons-pool/id - version20030623.172700/version + version20030818.195203/version /dependency dependency idjdbc/id - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
From: Eric Pugh [mailto:[EMAIL PROTECTED] I believe that as an Apache committer, you already have Karma for the sandbox. You're right! (At least I am part of the jakarta group.) I thought that my *Jakarta* privs were lost when Avalon became a top-level project (and moved out of Jakarta). Guess they weren't. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
From: James Strachan [mailto:[EMAIL PROTECTED] So you're most welcome to the commons-attributes project. Thanks! /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
I personally don't have any problem with widening that rule to any Apache committer, which would therefore include Leo automatically (he has commit access on Avalon, which used to be a Jakarta sub-project but is now top level). Does any other Commons-Dev committer or Jakarta PMC member have any problem with that? Not me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docs] extra menus for mavenised components
On Tuesday, August 19, 2003, at 01:39 PM, Shapira, Yoav wrote: Howdy, I like it ;) Except there's a Betwixt section and a Project Documentation section, which I think could be the same section no? It is the Betwixt project page after all ;) anakia does not allow sub-menus which means i can't have a menu section containing those of the commons menus i want to include. i've been thinking about separating out the contents elements from the menu elements - that way components would be able to call it something like 'about jakarta commons' rather than 'about us'. or maybe some other people will be able to come up with some better ideas. .. Regardless, I want to see Project Documentation above the general commons menus. But I imagine that would be a simple matter of which order the entities were included right? nope. project documentation is a maven thingy. maven puts it below everything else. (this is something else i'd hoped to do.) i suppose that it might be possible to create some sort of custom jelly script to do this (but i'd hoped to keep the barriers to entry as low as possible). anyone know how to do this easily? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] patch: usage examples
On Friday, August 15, 2003, at 03:38 AM, Simon Kitching wrote: On Fri, 2003-08-15 at 06:32, robert burrell donkin wrote: committed. many thanks. it all looks fine. i've managed to resist the temptation to tinker too much (just yet ;) but i have renamed the directory from example1 to addressbook since i prefer descriptive names where possible. (i think that it makes it easier for users.) Tweak away :-) Any improvements to the examples are welcome; I would be keen to see better ways of implementing the addressbook example. I should have explained why I picked the name example1; it was chosen so that we could also have example2, example3, etc. Example 1 is the start here point, showing the simplest features of Digester. I had intended to add an Example 2 with more complex things like: * passing Digester as a SAXContentHandler to an existing SAXParser instead of calling parse(File), as done in example 1 * demonstrating ObjectFactoryRule * wildcards in patterns And maybe example 3 getting on to really tricky stuff like: * extended rules matching * NodeCreateRule (if I can figure it out myself :-) * subclassing the Digester * handling namespaces that sounds great. If you want to name the examples by the example filetype they happen to process, then I suggest the readme file be modified to indicate which order a newbie to Digester should read the examples in. what i'd really like to do is to integrate the examples into a set of html documents which can be posted on the site and browsed. i know that this is quite a long way off at the moment but it's nive to dream :) i prefer examples with names since it's easier to remember which is which when answering user questions. we should certainly make sure that the (maybe something like the descriptions you've given about would be cool in the readme). don't worry too much about the build script, it not a priority. maybe it' d be a good idea to have a separate build.xml script in the examples directory. I just want to make sure that changes in Digester itself don't break the examples. It would be rather embarrassing to ship a digester release where the examples don't compile. To avoid this, I suggest that the examples be *compiled* as part of the dist target, though of course the resulting class files shouldn't be included in the distribution jar! +1 That way, any time someone runs ant dist, they immediately see if the examples are broken or not. Agreed, they don't know if the examples still *work*; that would require them to be written as unit tests, which unfortunately then makes them less useful as tutorials (too much unit-test-related clutter). it might be nice to have a few example unit tests as part of the examples. there are some tricks such as using a StringReader (rather than reading the xml from a file) which people might find useful. Or we could build them whenever the unit tests are built? I don't think that the Digester unit tests are in a very good state though (I was going to look into this soon, as I also need to build unit tests for the Plugins module). the digester unit tests may not look pretty but they have provided pretty effective. i'm particularly guilty since i tend to leave a lot of commented out logging in there. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] commons jars in ibiblio maven repo
This may be an obvious question, but... Wouldn't it make more sense to have all of the jakarta-commons jars in the maven repository on ibiblio.org under a jakarta-commons directory (groupId=jakarta)? I don't think that maven supports nested groups, but as the number of jars increase, it would be nice to have a more layered structure such as apache/jakarta/commons/*. 18 out of the 67 directories in my local repo have the commons- prefix. At a glance, it seems kind of flat and disorganized. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] Jar does not contain version number
A version number in the filename? No, that would be difficult for the automated builds (gump build). The version number is inside the jar file, in the MANIFEST.MF file. Dirk Henri Yandell wrote: The jar created by the 'ant dist' task creates a commons-pool.jar. Is there any kind of standard for Commons projects to include version numbers now? It then goes on to build zip/tars which do contain the version numbers. 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: dbcp bug
On Tue, 2003-08-19 at 01:24, KNOX, Liam, FM wrote: Noel I took the latest snap shot and this seems to work fine. Is there a plan for a new release in the near future? I am also interested in how dbcp deals with closed or 'stale' connections i.e. in the event of a db outage. Is it possible that stale connections could remain in the pool ? It is possible to configure a pool to verify the connection before handing it out (or at other times, if less critical). Connections that don't pass the verification test (usually a simple sql query) are removed from the pool. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl BasicMessageList.java
dgraham 2003/08/19 16:34:22
Modified:resources/src/java/org/apache/commons/resources/impl
BasicMessageList.java
Log:
Moved Comparator implementation to a constant variable to avoid creating
a new object on each call, removed hungarian notation on variables,
fixed variable scopes.
Revision ChangesPath
1.5 +35 -44
jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/BasicMessageList.java
Index: BasicMessageList.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/BasicMessageList.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- BasicMessageList.java 19 Apr 2003 18:46:43 - 1.4
+++ BasicMessageList.java 19 Aug 2003 23:34:22 - 1.5
@@ -87,6 +87,15 @@
public class BasicMessageList implements Serializable, MessageList {
/**
+ * Compares MessageItems.
+ */
+private static final Comparator actionItemComparator = new Comparator() {
+public int compare(Object o1, Object o2) {
+return ((MessageItem) o1).getOrder() - ((MessageItem) o2).getOrder();
+}
+};
+
+/**
* The accumulated set of codeMessage/code objects (represented
* as an ArrayList) for each property, keyed by property name.
*/
@@ -96,7 +105,7 @@
* The current number of the property/key being added. This is used
* to maintain the order messages are added.
*/
-private int iCount = 0;
+private int count = 0;
// - Public Methods
@@ -115,7 +124,7 @@
*/
public BasicMessageList(String globalMessageKey) {
super();
-setGlobalMessageKey(globalMessageKey);
+this.setGlobalMessageKey(globalMessageKey);
}
/**
@@ -165,7 +174,7 @@
if (item == null) {
list = new ArrayList();
-item = new MessageItem(list, iCount++);
+item = new MessageItem(list, this.count++);
messages.put(property, item);
} else {
@@ -179,8 +188,7 @@
// See interface for JavaDoc
public void add(Message message) {
-
-add(MessageList.GLOBAL_MESSAGE_KEY, message);
+this.add(MessageList.GLOBAL_MESSAGE_KEY, message);
}
@@ -208,14 +216,14 @@
// See interface for JavaDoc
public boolean isEmpty() {
-return (messages.isEmpty());
+return messages.isEmpty();
}
// See interface for JavaDoc
public Iterator get() {
-if (messages.size() == 0) {
-return (Collections.EMPTY_LIST.iterator());
+if (messages.isEmpty()) {
+return Collections.EMPTY_LIST.iterator();
}
ArrayList results = new ArrayList();
@@ -227,11 +235,7 @@
// Sort MessageItems based on the initial order the
// property/key was added to MessageList.
-Collections.sort(actionItems, new Comparator() {
-public int compare(Object o1, Object o2) {
-return ((MessageItem) o1).getOrder() - ((MessageItem)
o2).getOrder();
-}
-});
+Collections.sort(actionItems, actionItemComparator);
for (Iterator i = actionItems.iterator(); i.hasNext();) {
MessageItem ami = (MessageItem) i.next();
@@ -241,28 +245,21 @@
}
}
-return (results.iterator());
-
+return results.iterator();
}
// See interface for JavaDoc
public Iterator get(String property) {
MessageItem item = (MessageItem) messages.get(property);
-
-if (item == null) {
-return (Collections.EMPTY_LIST.iterator());
-} else {
-return (item.getList().iterator());
-}
-
+return (item == null)
+? Collections.EMPTY_LIST.iterator()
+: item.getList().iterator();
}
// See interface for JavaDoc
public Iterator properties() {
-
-return (messages.keySet().iterator());
-
+return messages.keySet().iterator();
}
// See interface for JavaDoc
@@ -275,8 +272,7 @@
total += ami.getList().size();
}
-return (total);
-
+return total;
}
// See interface for JavaDoc
@@ -284,12 +280,7 @@
MessageItem ami = (MessageItem) messages.get(property);
-if (ami == null) {
-return (0);
-} else {
-return (ami.getList().size());
-}
-
+return (ami == null) ? 0 : ami.getList().size();
Enhance performance by generating jar file with -0 option
Would you consider generating jar files with the -0 option to store files in the jar file without using ZIP compression? Although this typically doubles the jar file size, it increases class loading performance (except when used in applets which are presumably not that important here). For example the JDK rt.jar is produced that way. Compatibility: The -0 option was introduced in JDK 1.2 Also see http://java.sun.com/j2se/1.4/docs/tooldocs/solaris/jar.html Thanks. Wolfgang. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources MessageList.java
dgraham 2003/08/19 16:35:00 Modified:resources/src/java/org/apache/commons/resources MessageList.java Log: Fixed size() javadoc. Revision ChangesPath 1.4 +5 -5 jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/MessageList.java Index: MessageList.java === RCS file: /home/cvs/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/MessageList.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- MessageList.java 19 Apr 2003 18:46:43 - 1.3 +++ MessageList.java 19 Aug 2003 23:35:00 - 1.4 @@ -179,7 +179,7 @@ /** * Return the number of messages recorded for all properties (including * global messages). strongNOTE/strong - it is more efficient to call - * codeempty()/code if all you care about is whether or not there are + * codeisEmpty()/code if all you care about is whether or not there are * any messages at all. */ public int size(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS][patch] rename plus various others
I've got a patch for VFS. Here's the short list of changes: - file rename for local, ftp and sftp providers (instead of expensive copyFrom() call) - FileSystemException prints nested exceptions instead of hiding them - fixed unattached, cached children bug (see AbstractFileObject.detach()) - in some places, throw the actual FileSystemException instead of nesting within another FileSystemException - fix bug in FtpFileSystem where url-encoded usernames/passwords would be passed to the server still encoded - added a messy hack to fix when FTP servers shut down idle connection (see FtpFileSystem.getClient()) - remove leading slashes in paths passed to SftpFileObject - added ability to specify sftp known_hosts directory via vfs.sftp.known-hosts-dir sysprop (see SftpFileProvider) I wasn't sure how to send this patch -- at the moment it's all one txt file. If another format is desired, let me know. The list above is pretty vague. If any more info would be helpful about what I did or why, also let me know. thanks, +jeff The information in this email and subsequent attachments may contain confidential information that is intended solely for the attention and use of the named addressee(s). This message or any part thereof must not be disclosed, copied, distributed, or retained by any person without the authorization from the addressee. diff.zip Description: diff.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS][patch] rename plus various others
--- Jeff Barrett [EMAIL PROTECTED] wrote: [...] - FileSystemException prints nested exceptions instead of hiding them Is this safe for JDK's earlier that JDK1.4? A quick eyeball of the diff.txt makes me think otherwise. regards, Adam = -- Adam R. B. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VFS][patch] rename plus various others
Should be. I'm using jdk 1.3.1. What did you see that made you suspicious? +jeff -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 5:05 PM To: Jakarta Commons Developers List Subject: Re: [VFS][patch] rename plus various others --- Jeff Barrett [EMAIL PROTECTED] wrote: [...] - FileSystemException prints nested exceptions instead of hiding them Is this safe for JDK's earlier that JDK1.4? A quick eyeball of the diff.txt makes me think otherwise. regards, Adam = -- Adam R. B. Jack - 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: [VFS][patch] rename plus various others
Should be. I'm using jdk 1.3.1. What did you see that made you suspicious? I assumes the inherited throwable member data was part of JDK1.4 'cause' stuff. If you've tested it on JDK 1.3.1 great, and obviously not, so my bad. regards Adam = -- Adam R. B. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Sandbox Karma for Leo Sutic
+1. I hadn't thought a vote was needed. Thought Commons sandbox was open to all Jakarta commiters and that there's not actually even a need for the people on the project to vote someone on, a Commons committer may just add their name to any project. This is usually a bit impolite though, so not what happens in practice. Hen On Tue, 19 Aug 2003, Noel J. Bergman wrote: Leo Sutic is an active Avalon Committer, and has Jakarta Karma by virtue of Avalon having been incubated in Jakarta. He wishes to contribute to Attributes in the sandbox. See: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] pache.orgby=threadfrom=474441 +1 --- Noel - 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: [Attributes] Inherit and Develop
As far as I can see, Commons Attributes is *dead* in terms of development. Yep. Most of the folks who wanted to help out develop it (committers from QDox, Nanning, attrib4j etc) can't because its in the commons sandbox. It looks like those folks are getting together to develop something at codehaus.org instead. So you're most welcome to the commons-attributes project. So then Leo could contact them, and act as an interested Committer on the project until the others can earn their stripes, no? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] commons jars in ibiblio maven repo
Yep, that'd make sense. Having groupId=jakarta would certainly help. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ __matthewHawthorne [EMAIL PROTECTED] wrote on 20/08/2003 07:26:55 AM: This may be an obvious question, but... Wouldn't it make more sense to have all of the jakarta-commons jars in the maven repository on ibiblio.org under a jakarta-commons directory (groupId=jakarta)? I don't think that maven supports nested groups, but as the number of jars increase, it would be nice to have a more layered structure such as apache/jakarta/commons/*. 18 out of the 67 directories in my local repo have the commons- prefix. At a glance, it seems kind of flat and disorganized. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21182] - [dbcp] removing a webapp does not force connections closed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21182.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21182
[dbcp] removing a webapp does not force connections closed
--- Additional Comments From [EMAIL PROTECTED] 2003-08-19 22:22 ---
More info from Michael Holly (commons-user 11/08/2003)
I had much the same problem. Starting/Stopping webapps did not deal with
cleaning up the pool correctly.
Since I was trying to implement junit and other testing mechanisims I wanted
my build script to stop, build, and
start the the app, then test it. My problem was that the pools were being
treated as a quasi server/webapp resource.
For the current configurations I couldn't find one that would take ownership
of the pool. Then somebody told me
to create a Context listener and use it to clean up the pool when the webapp
shutdown occurs. After several
iterations I go this to work. I have checked it against my db through
several shutdown startup cycles and
it has yet to lose track of a connection.
Here is my Context Listener
/**
* The listener runs when the app is started and shutdown
*
* @author Michael Holly
* created Apr 18, 2003
*/
package net.talisen.tsr;
import javax.sql.DataSource;
import javax.naming.InitialContext;
import javax.naming.Context;
import javax.naming.NamingException;
import javax.naming.NamingEnumeration;
import org.apache.commons.dbcp.BasicDataSource;
import javax.servlet.*;
import org.apache.log4j.Logger;
import java.util.ResourceBundle;
import java.net.URL;
import java.net.MalformedURLException;
import java.io.*;
import java.util.*;
import org.apache.log4j.Logger;
import org.apache.log4j.Level;
import org.apache.log4j.PropertyConfigurator;
public final class ContextListener
implements ServletContextListener
{
//get a logger
Logger log = Logger.getLogger(ContextListener.class);
private InitialContext initialContext = null;
private Context namingContext = null;
private ServletContext context = null;
public void contextInitialized (ServletContextEvent servletContextEvent)
{
context = servletContextEvent.getServletContext ();
try
{
System.out.println( \n\n Intializing Context);
log.info(Initializing logging);
// configure the Log4j system
String file = new String( /WEB-INF/classes/log4j.properties );
URL url = context.getResource(file);
PropertyConfigurator.configure( url );
System.out.println(Log4j Properties @ + url.toString() );
log.info(Cataloging Context Resources);
initialContext = new InitialContext();
namingContext = (Context) initialContext.lookup(java:comp/env);
DataSource ds1 =
(DataSource)namingContext.lookup(jdbc/oracle_myapp);
DataSource ds2 =
(DataSource)namingContext.lookup(jdbc/oracle_company_db);
context.setAttribute(dataSource1, ds1);
context.setAttribute(dataSource2, ds2);
log.info(oracle_myapp connection pool cataloged);
log.info(oracle_company_db connection pool cataloged);
}
catch (NamingException ne)
{
log.error(Couldn't create context attribute: + ne.getMessage
());
ne.printStackTrace();
}
catch (Exception e)
{
log.error(Couldn't create context attribute: + e.getMessage ());
e.printStackTrace();
}
}
public void contextDestroyed (ServletContextEvent servletContextEvent)
{
DataSource ds1 = ((DataSource) context.getAttribute(dataSource1));
DataSource ds2 = ((DataSource) context.getAttribute(dataSource2));
try
{
log.info(Cleaning up Context Resources);
if (ds1 instanceof org.apache.commons.dbcp.BasicDataSource) {
log.info(Found oracle_tsr connection pool + ds1.toString());
((org.apache.commons.dbcp.BasicDataSource) ds1).close();
ds1 = null;
}
log.info(Removed oracle_myapp connection );
if (ds2 instanceof org.apache.commons.dbcp.BasicDataSource) {
log.info(Found oracle_talisen connection pool +
ds2.toString() );
((org.apache.commons.dbcp.BasicDataSource) ds2).close();
ds2 = null;
}
log.info(Removed oracle_company_db connection);
context.removeAttribute (dataSource1);
context.removeAttribute (dataSource2);
}
catch (Exception e)
{
log.error(Error destroying Context: + e.getMessage ());
e.printStackTrace();
}
finally
{
System.out.println(
###);
RE: [VFS][patch] rename plus various others
Yep, all good. Throwable is a member of FileSystemException. -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 5:38 PM To: Jakarta Commons Developers List Subject: RE: [VFS][patch] rename plus various others Should be. I'm using jdk 1.3.1. What did you see that made you suspicious? I assumes the inherited throwable member data was part of JDK1.4 'cause' stuff. If you've tested it on JDK 1.3.1 great, and obviously not, so my bad. regards Adam = -- Adam R. B. Jack - 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]
cvs commit: jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator - New directory
rleland 2003/08/19 18:19:26 jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [combo] Commons Core release?
I am not in favor of a core jar but I would like to note that including components into your jar is not unprecedented. If you look at Xalan, it includes all sorts of components in its jar. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 21:54 To: Jakarta Commons Developers List Subject: Re: [combo] Commons Core release? On Sun, 17 Aug 2003, Rodney Waldhoff wrote: On Fri, 15 Aug 2003, Henri Yandell wrote: On Fri, 15 Aug 2003, Rodney Waldhoff wrote: On Thu, 14 Aug 2003, Henri Yandell wrote: Forcing a user of three api's to grab dependencies for 12 other api's is going to kill combo dead in the water. An observation: a user of 3 APIs doesn't need to grab any external dependencies outside of those three APIs. If you never load or use the dependent classes, you never need to load their dependencies. It's very hard to know though. Not hard at all. Look for NoClassDefFound. Not very good when I'm trying to learn about and install something. I look at the dependency list and it says it needs 5 jars. What dependency list? The compile-time ant and/or maven descriptors? We don't have a formal or even conventional run-time dependency indication AFAIK, although maybe this suggests we need one. Yep. Maven one. Some kind of runtime would be good. Just thinking about Commons Core/Combo is a good idea in terms of discovering problems here. Currently I'm building BeanUtils 1.6.1 into my jar [I like the javadoc on my PDA as one blob] but Math [which I'd like to start building in] relies on BeanUtils 1.5. As more cross-dependency is added, complexity will increase, with the possibility of a 'combo' being impossible due to cyclics etc. One solution to stop this is to stop dependencies in Commons between projects. Which is obviously painful, we can't eat our own dogfood because it might get tricky. If anything, a hierarchy diagram showing the dependencies would be a nice result from this. We don't publish a 'you need this jar for this, this jar for this' list. Also, who wants to trust that? Actually I believe in several places we do (e.g,. http://jakarta.apache.org/commons/logging/userguide.html, http://jakarta.apache.org/commons/httpclient/sslguide.html). The STATUS files used to hold this information, probably many of them have not been maintained. Automating a build of this gets difficult I believe, plus you'd have to not run certain tests. It feels like a rather manual solution. Both maven and gump seem to automate this rather well. I presume that they have the compile-time dependencies available at test-time. I would be aiming not to have things like log4j available, and yet this means I can't run the tests for commons-logging log4j component else it'll fall over. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/legacy - New directory
rleland 2003/08/19 18:17:59 jakarta-commons/validator/legacy - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/legacy/1.0.2/api - New directory
rleland 2003/08/19 18:18:14 jakarta-commons/validator/legacy/1.0.2/api - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/legacy/1.0.2 - New directory
rleland 2003/08/19 18:18:07 jakarta-commons/validator/legacy/1.0.2 - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/legacy/1.0.2/api/org/apache - New directory
rleland 2003/08/19 18:19:12 jakarta-commons/validator/legacy/1.0.2/api/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/legacy/1.0.2/api/org - New directory
rleland 2003/08/19 18:19:05 jakarta-commons/validator/legacy/1.0.2/api/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator Arg.html Constant.html Field.html Form.html FormSet.html GenericTypeValidator.html GenericValidator.html Msg.html Validator.html ValidatorAction.html ValidatorException.html ValidatorResources.html ValidatorResourcesInitializer.html ValidatorResult.ResultStatus.html ValidatorResult.html ValidatorResults.html ValidatorUtil.html Var.html package-frame.html package-summary.html package-tree.html
rleland 2003/08/19 18:27:54 Added: validator/legacy/1.0.2/api allclasses-frame.html allclasses-noframe.html constant-values.html deprecated-list.html help-doc.html index-all.html index.html overview-tree.html package-list packages.html serialized-form.html stylesheet.css validator/legacy/1.0.2/api/org/apache/commons/validator Arg.html Constant.html Field.html Form.html FormSet.html GenericTypeValidator.html GenericValidator.html Msg.html Validator.html ValidatorAction.html ValidatorException.html ValidatorResources.html ValidatorResourcesInitializer.html ValidatorResult.ResultStatus.html ValidatorResult.html ValidatorResults.html ValidatorUtil.html Var.html package-frame.html package-summary.html package-tree.html Log: Place Validator 1.0.2 javadoc in CVS for reference. Revision ChangesPath 1.1 jakarta-commons/validator/legacy/1.0.2/api/allclasses-frame.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/allclasses-frame.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/allclasses-noframe.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/allclasses-noframe.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/constant-values.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/constant-values.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/deprecated-list.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/deprecated-list.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/help-doc.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/help-doc.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/index-all.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/index-all.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/index.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/index.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/overview-tree.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/overview-tree.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/package-list http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/package-list?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/packages.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/packages.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/serialized-form.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/serialized-form.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/stylesheet.css http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/stylesheet.css?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/Arg.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/Arg.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/Constant.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/Constant.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/Field.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/Field.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/Form.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/Form.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/FormSet.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/FormSet.html?rev=1.1 1.1 jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/GenericTypeValidator.html http://cvs.apache.org/viewcvs/jakarta-commons/validator/legacy/1.0.2/api/org/apache/commons/validator/GenericTypeValidator.html?rev=1.1 1.1
Re: [collections] Questions....
Hello,
Firstly, SingletonIterator and SingletonListIterator seem quite
similar.
Apart from the extra type of 'ListIterator', it appears that a
SingletonListIterator can do the job of a SingletonIterator in all
jobs.
Could just remove SingleIterator.
I was thinking can we eliminate those classes by methods returning
interface? It is always a good practice to use interface rather than
specifying concrete class. I mean just like singleton method of
java.util.Collections
Code should be like:
class Collections2 {
public ResetableIterator singletonIterator () { ... }
public ResetableListIterator singletonIterator () { ... }
}
It is possible to use just one concrete class for both methods above.
Given there is a few discussion of code review, I think every one is
busy maintaining the existing code base.
Takuya Murata
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16525] - BeanUtils.setProperty is over-zealous at converting types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525 BeanUtils.setProperty is over-zealous at converting types --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 02:23 --- I just ran into the same problem - my value is converted to a String unnecessarily by BeanUtils.setProperty(). Unfortunately, the calling code is not mine so I don't have an easy option of switching to copyProperty() instead. It seems to me, though, that there is a simple solution. The toString() conversion performed in this line from setProperty: newValue = getConvertUtils().convert(value.toString(), type); shouldn't be necessary. Although ConvertUtils.convert() wants a String value, it just passes it to a Converter that can take any Object as a value. Why not change ConvertUtils.convert() to accept an Object value and avoid having BeanUtils convert it to a String first? That way, converters will still get first crack at a conversion. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
Leo, I figure that you should go for it. I'd like to hear more about your plans. JSR 175 is the normative statement of what attributes must be in Java. How do your plans compare and contrast with JSR 175, nanning, Aspect4J, etc? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Questions....
While this is a good question, it's not the actual problem I'm trying to
point out. SingletonIterator or singletonIterator() is a redundant method
in 99% of its usage. Only if someone has if(instanceof ListIterator) {.. }
else if(instanceof Iterator) would it change the funcationality.
Using XxxUtils [which is what java.util.Collections effectively is in
Commons language] as factories is something we've considered moving
towards for a while.
The biggest problem is that you end up with large XxxUtils classes [or
XxxFactory, whatever] which are hard to understand and comprehend.
However, a widely spread API with lots of classes is also hard to
understand and comprehend. Maybe there's a magic ratio of classes to
methods? :)
Anyway, I'm always +1 to a good standard feel to the Collections.
Currently I'm trying to ensure I understand what every class in
Collections does and for some it is a bit hard to comprehend with the
current documentation.
Hen
On Wed, 20 Aug 2003, Takuya Murata wrote:
Hello,
Firstly, SingletonIterator and SingletonListIterator seem quite
similar.
Apart from the extra type of 'ListIterator', it appears that a
SingletonListIterator can do the job of a SingletonIterator in all
jobs.
Could just remove SingleIterator.
I was thinking can we eliminate those classes by methods returning
interface? It is always a good practice to use interface rather than
specifying concrete class. I mean just like singleton method of
java.util.Collections
Code should be like:
class Collections2 {
public ResetableIterator singletonIterator () { ... }
public ResetableListIterator singletonIterator () { ... }
}
It is possible to use just one concrete class for both methods above.
Given there is a few discussion of code review, I think every one is
busy maintaining the existing code base.
Takuya Murata
[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: [collections] Questions....
Hi,
So the question is do we really need SingletonIterator and such. If we
want to eliminate the number of methods or classes, then what about one
class for all of collections or iterators? I suppose the use of
singleton methods and classes is almost always to provide an object
matching a data type you want. Thus, we can have a class like
class Singleton implements List, SortedSet, Bag, Iterator, ListIterator
{
}
Although it is usually bad practice to aggregate several different
functionalities into one class, in this case, it might be fine.
Yes, this is in line with your proposal; we can use
SingletonListIterator for both Iterator and ListIterator. I think the
problem of this solution is users probably expect SingletonIterator
intuitively and might be puzzled why there is no such.
Takuya Murata
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Questions....
On Wed, 20 Aug 2003, Takuya Murata wrote: Yes, this is in line with your proposal; we can use SingletonListIterator for both Iterator and ListIterator. I think the problem of this solution is users probably expect SingletonIterator intuitively and might be puzzled why there is no such. Agreed. It is the logical name. So solution there is to remove SingletonListIterator and quietly make SingletonIterator a ListIterator? :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[http][patch] Make constants public
The attached patch to commons-http makes the constants defined
in BrowserDetector public and updates the licenses in all
three classes.
I thought I would be able to commit these myself, but it seems
that sandbox karma is not quite as automatic as is suggested
on the commons home page.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
Index: BrowserDetector.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/http/src/java/org/apache/commons/http/BrowserDetector.java,v
retrieving revision 1.1
diff -u -r1.1 BrowserDetector.java
--- BrowserDetector.java22 Feb 2002 18:14:31 - 1.1
+++ BrowserDetector.java20 Aug 2003 03:19:10 -
@@ -3,7 +3,7 @@
/*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001 The Apache Software Foundation. All rights
+ * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -11,7 +11,7 @@
* are met:
*
* 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
+ *notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
@@ -19,20 +19,20 @@
*distribution.
*
* 3. The end-user documentation included with the redistribution,
- *if any, must include the following acknowledgment:
- * This product includes software developed by the
+ *if any, must include the following acknowledgement:
+ * This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowledgment may appear in the software itself,
- *if and wherever such third-party acknowledgments normally appear.
+ *Alternately, this acknowlegement may appear in the software itself,
+ *if and wherever such third-party acknowlegements normally appear.
*
- * 4. The names Apache and Apache Software Foundation and
- *Apache Turbine must not be used to endorse or promote products
- *derived from this software without prior written permission. For
- *written permission, please contact [EMAIL PROTECTED]
+ * 4. The names Apache, The Jakarta Project, Commons, and Apache Software
+ *Foundation must not be used to endorse or promote products derived
+ *from this software without prior written permission. For written
+ *permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
- *Apache Turbine, nor may Apache appear in their name, without
- *prior written permission of the Apache Software Foundation.
+ *Apache nor may Apache appear in their names without prior
+ *written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
@@ -53,7 +53,7 @@
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
-
+
/**
* This class parses the user agent string and sets javasciptOK and
* cssOK following the rules described below. If you want to check
@@ -82,13 +82,13 @@
*/
public class BrowserDetector
{
-protected static final String MSIE = MSIE;
-protected static final String OPERA = Opera;
-protected static final String MOZILLA = Mozilla;
+public static final String MSIE = MSIE;
+public static final String OPERA = Opera;
+public static final String MOZILLA = Mozilla;
-protected static final String WINDOWS = Windows;
-protected static final String UNIX = Unix;
-protected static final String MACINTOSH = Macintosh;
+public static final String WINDOWS = Windows;
+public static final String UNIX = Unix;
+public static final String MACINTOSH = Macintosh;
/** The user agent string. */
private String userAgentString = ;
Index: HttpHeaderTokenizer.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/http/src/java/org/apache/commons/http/HttpHeaderTokenizer.java,v
retrieving revision 1.2
diff -u -r1.2 HttpHeaderTokenizer.java
--- HttpHeaderTokenizer.java11 Apr 2003 21:16:04 - 1.2
+++ HttpHeaderTokenizer.java20 Aug 2003 03:19:11 -
@@ -1,9 +1,59 @@
package org.apache.commons.http;
-/*
- * Copyright (c) 2003 The Apache Jakarta Project. All rights reserved.
+/*
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * reserved.
+ *
+ *
cvs commit: jakarta-commons/validator project.xml
rleland 2003/08/19 21:17:09 Modified:validator project.xml Log: Fix package so JavaDoc is generated properly Revision ChangesPath 1.16 +2 -2 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- project.xml 19 Aug 2003 01:21:14 - 1.15 +++ project.xml 20 Aug 2003 04:17:09 - 1.16 @@ -8,7 +8,7 @@ inceptionYear2002/inceptionYear gumpRepositoryIdjakarta/gumpRepositoryId - packageorg.apache.commons.validator.*/package + packageorg.apache.commons.validator/package shortDescriptionCommons Validator/shortDescription logo/images/logo.gif/logo @@ -190,7 +190,7 @@ reportmaven-pmd-plugin/report reportmaven-simian-plugin/report reportmaven-faq-plugin/report -reportmaven-multiproject-plugin/report + !-- reportmaven-html2xdoc-plugin/report -- /reports /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator maven.xml
rleland 2003/08/19 21:19:15
Modified:validator maven.xml
Log:
Enable html-xdoc for Validator 1.0.2 javadoc
For a documentation system you gotta dig into the
source code to get this to work. Sometimes
you can't see the trees for the Forrest
Revision ChangesPath
1.3 +4 -0 jakarta-commons/validator/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/jakarta-commons/validator/maven.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- maven.xml 5 Jun 2003 01:26:19 - 1.2
+++ maven.xml 20 Aug 2003 04:19:15 - 1.3
@@ -1,5 +1,9 @@
project default=java:jar
+ preGoal name=xdoc:jelly-transform
+attainGoal name=html2xdoc/
+ /preGoal
+
postGoal name=java:compile
copytodir=${maven.build.dir}/classes/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator project.properties
rleland 2003/08/19 21:19:53
Added: validator project.properties
Log:
Set directory for html conversion
Revision ChangesPath
1.1 jakarta-commons/validator/project.properties
Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S - Modeled after Turbine project.properties
#
# $Id: project.properties,v 1.1 2003/08/20 04:19:53 rleland Exp $
#
# Do not change this file. Please use build.properties in this directory
# to do site or installation specific changes to the project build.
# ---
#
# You can uncomment this if you're willing to use the unofficial
# Validator-specific jar repository at the Validator site. This will
# contain all the jars needed to build Validator, even if a jar
# is missing on ibiblio
#
#maven.repo.remote=http://www.ibiblio.org/maven/,http://jakarta.apache.org/commons/validator/repo
#maven.checkstyle.format = validator
# Include legacy javadoc in build
maven.html2xdoc.dir = legacy
# display the date on the site
maven.xdoc.date = left
# Display the version the web site is documenting
maven.xdoc.version = ${pom.currentVersion}
compile.debug = on
compile.optimize = off
compile.deprecation = on
maven.compile.deprecation = on
# ---
# N I G H T L Y B U I L D P R O P E R T I E S
# ---
validator.nightly.dist.dir = \
/www/jakarta.apache.org/builds/jakarta-commons/validator/nightly
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang STATUS.html
psteitz 2003/08/19 21:20:28 Modified:lang STATUS.html Log: Adding humble self as committer Revision ChangesPath 1.48 +2 -1 jakarta-commons/lang/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons/lang/STATUS.html,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- STATUS.html 19 Aug 2003 02:40:47 - 1.47 +++ STATUS.html 20 Aug 2003 04:20:27 - 1.48 @@ -158,6 +158,7 @@ lia href=mailto:[EMAIL PROTECTED]Steven Caswell/a/li lia href=mailto:[EMAIL PROTECTED]Robert Burrell Donkin/a/li lia href=mailto:[EMAIL PROTECTED]Gary Gregory/a/li +lia href=mailto:[EMAIL PROTECTED]Phil Steitz/a/li !-- New committers, add your name here -- /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Questions....
I think that the elimination of _unnecessary_ methods and classes is a
noble goal.
For example, In the SingletonIterator vs. SingletonListIterator
situation, as long as the logic to implement the extra methods specified
by java.util.ListIterator does not cause significant performance
overhead, it seems reasonable to use SingletonListIterator as a standard
Iterator also. (I'm pretty sure that's what is being suggested.)
However, I don't agree with elimination just for elimination's sake,
which is how I interpret the suggestion of defining a single class which
implements List, SortedSet, Bag, Iterator, ListIterator, etc. I find it
simpler to allow each class to perform a single task, and perform it
well, then to force it to perform the job of 5 classes. I don't see the
benefit of such a solution. In my opinion, smaller, simpler classes are
easier to write, easier to maintain, easier to test, and easier to use.
Agreements/Disagreements?
On Tue, 2003-08-19 at 20:28, Takuya Murata wrote:
Hi,
So the question is do we really need SingletonIterator and such. If we
want to eliminate the number of methods or classes, then what about one
class for all of collections or iterators? I suppose the use of
singleton methods and classes is almost always to provide an object
matching a data type you want. Thus, we can have a class like
class Singleton implements List, SortedSet, Bag, Iterator, ListIterator
{
}
Although it is usually bad practice to aggregate several different
functionalities into one class, in this case, it might be fine.
Yes, this is in line with your proposal; we can use
SingletonListIterator for both Iterator and ListIterator. I think the
problem of this solution is users probably expect SingletonIterator
intuitively and might be puzzled why there is no such.
Takuya Murata
-
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]
cvs commit: jakarta-commons/validator project.xml
rleland 2003/08/19 22:07:40 Modified:validator project.xml Log: Change logo Revision ChangesPath 1.17 +1 -1 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- project.xml 20 Aug 2003 04:17:09 - 1.16 +++ project.xml 20 Aug 2003 05:07:40 - 1.17 @@ -11,7 +11,7 @@ packageorg.apache.commons.validator/package shortDescriptionCommons Validator/shortDescription - logo/images/logo.gif/logo + logo/images/Validatorlogo.gif/logo description Commons Validator provides the building blocks for both client side validation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Questions....
So the question is do we really need SingletonIterator and such. If we
want to eliminate the number of methods or classes, then what about one
class for all of collections or iterators? I suppose the use of
singleton methods and classes is almost always to provide an object
matching a data type you want. Thus, we can have a class like
class Singleton implements List, SortedSet, Bag, Iterator, ListIterator
{
}
Although it is usually bad practice to aggregate several different
functionalities into one class, in this case, it might be fine.
Yes, this is in line with your proposal; we can use
SingletonListIterator for both Iterator and ListIterator. I think the
problem of this solution is users probably expect SingletonIterator
intuitively and might be puzzled why there is no such.
I don't know if such a class makes sense... The next() method should
return its contents on the first call, but return null for all
successive calls. Thus it could only be used as an Iterator once, which
doesn't seem very useful to me.
Rich
--
Rich Dougherty
http://www.rd.gen.nz/
pgp0.pgp
Description: PGP signature
DO NOT REPLY [Bug 19171] - SetCookie / DateParser failing to parse non-standard date format
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19171 SetCookie / DateParser failing to parse non-standard date format --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 08:27 --- Well, it depends. Is this cookie date set by a faulty web application? Then you should rather fix that application to use the standard date format. If however this is coming from the server *directly* we will need to support it of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Grabbing a header from the server's response
After sending a GET request to a server, how to I pick out the name/value of a specific header from the server's response? Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Grabbing a header from the server's response
Mark Castillo wrote: After sending a GET request to a server, how to I pick out the name/value of a specific header from the server's response? Call the getResponseHeader(String name) method (or one of its siblings) on the HttpMethod you used for the request, which is probably a GetMethod in this case. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Grabbing a header from the server's response
On 20/08/2003 9:34 AM, Mark Castillo [EMAIL PROTECTED] wrote: After sending a GET request to a server, how to I pick out the name/value of a specific header from the server's response? Thank you. Take a look at the getResponseHeader and associated methods in the GetMethod object (actually defined by the HttpMethod interface). Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Grabbing a header from the server's response
I do it like this, for example, to get the new URL from the location header: Header header = httpget.getResponseHeader(Location); String newuri = header.getValue(); Ross - get lined up at http://www.careerfish.com -Original Message- From: Mark Castillo [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 7:34 PM To: '[EMAIL PROTECTED]' Subject: Grabbing a header from the server's response After sending a GET request to a server, how to I pick out the name/value of a specific header from the server's response? Thank you. - 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]
