RE: UUID Reuse proposal
Thanks for the positive response to adapting a UUID class in commons lang. [The Axis list has responded with favoring option 2 which is basically to not make changes at this time, but has no problem with use of the UUID code from Axis in the commons.] I'm looking for direction on next steps - I believe after answering the following questions; I would create an enhancement in bugzilla and attach patches or sources? I think at this time there are two questions to resolve: ~1) Where to place the UUID code. I personally prefer a package and separate classes as Phil Steitz suggests: I do like the idea of lang providing a home for IdentifierUtils suitably named and packaged. There are really multiple types here: * UUID (pseudo) standard, non-random, non-secure * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils) * Random, secure, not guaranteed unique (e.g. Tomcat session IDs) * Part random, secure, guaranteed unique (what Tomcat really needs ;-) * Bounded sequential(e.g. Betwixt's io identifiers) * Cyclic I believe the alternative is to add the UUID code to the existing IdentifierUtils.java. (As a user of the library I believe it would be much easier to locate and so more valuable to have in a suitably named package of IdentifierUtils.) ~2) Which UUID implementation to use: Tim Anderson suggested using: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone know if there are any issues with the license on this. It seems it would be okay as long as this license information were included along with the apache license in the source. (Would we also need an additional UUID-License.txt? I'm not sure how to interpret item 2 of license) The alternative is to use the Axis UUID and add features such as those in Tyrex's later. If a real issue exists I could try contacting them so find a suitable solution. The license is inlined here: ### /** * Redistribution and use of this software and associated documentation * (Software), with or without modification, are permitted provided * that the following conditions are met: * * 1. Redistributions of source code must retain copyright *statements and notices. Redistributions must also contain a *copy of this document. * * 2. Redistributions in binary form must reproduce the *above copyright notice, this list of conditions and the *following disclaimer in the documentation and/or other *materials provided with the distribution. * * 3. The name Exolab must not be used to endorse or promote *products derived from this Software without prior written *permission of Intalio. For written permission, *please contact [EMAIL PROTECTED] * * 4. Products derived from this Software may not be called Exolab *nor may Exolab appear in their names without prior written *permission of Intalio. Exolab is a registered *trademark of Intalio. * * 5. Due credit should be given to the Exolab Project *(http://www.exolab.org/). * * THIS SOFTWARE IS PROVIDED BY INTALIO AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT * NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL * INTALIO OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. * * Copyright 1999-2001 (C) Intalio Inc. All Rights Reserved. ### - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UUID Reuse proposal
Tim Reilly wrote: Thanks for the positive response to adapting a UUID class in commons lang. [The Axis list has responded with favoring option 2 which is basically to not make changes at this time, but has no problem with use of the UUID code from Axis in the commons.] I'm looking for direction on next steps - I believe after answering the following questions; I would create an enhancement in bugzilla and attach patches or sources? Yes. I would start by patching IdentifierUtils (see below) to add some additional methods, assuming that there are no objections to this approach. I think at this time there are two questions to resolve: ~1) Where to place the UUID code. I personally prefer a package and separate classes as Phil Steitz suggests: I do like the idea of lang providing a home for IdentifierUtils suitably named and packaged. There are really multiple types here: * UUID (pseudo) standard, non-random, non-secure * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils) * Random, secure, not guaranteed unique (e.g. Tomcat session IDs) * Part random, secure, guaranteed unique (what Tomcat really needs ;-) * Bounded sequential(e.g. Betwixt's io identifiers) * Cyclic I believe the alternative is to add the UUID code to the existing IdentifierUtils.java. 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 user of the library I believe it would be much easier to locate and so more valuable to have in a suitably named package of IdentifierUtils.) ~2) Which UUID implementation to use: Tim Anderson suggested using: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone know if there are any issues with the license on this. It seems it would be okay as long as this license information were included along with the apache license in the source. (Would we also need an additional UUID-License.txt? I'm not sure how to interpret item 2 of license) The alternative is to use the Axis UUID and add features such as those in Tyrex's later. If a real issue exists I could try contacting them so find a suitable solution. I don't know about the license, but as I said above, I like the tyrex impl better. In any case, making the implementation threadsafe would be a good idea, as would (IMHO) allowing the node ID to be read from a properties file. I would also be interested in others' opinions on the value of the UUID standard, especially minus the MAC address. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/httpclient/xdocs authentication.xml
Please don't forget the changelog... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [net][patch] jdk 1.4 specific call inVMSFTPEntryParser.java
Hi Apologies, I've missed this thread as I've been on vacation for the last week. Here's the patch as an attchment. Hopefully this should do the trick. Best regards Rory -Original Message- From: Daniel F. Savarese [mailto:[EMAIL PROTECTED] Sent: 15 August 2003 18:43 To: 'Jakarta Commons Developers List' Subject: Re: [net][patch] jdk 1.4 specific call in VMSFTPEntryParser.java In message [EMAIL PROTECTED], Daniel F. Savar ese writes: In message [EMAIL PROTECTED], R ory Winston writes: I've cleaned up a bit (applied my changes to a fresh checkout) and generated a diff file. I've taken out the XHDR addition for now, as XOVER seems to be the preferred mechanism for this kind of thing. The functionality added is: This is great, but I'm having trouble applying the patch because of formatting issues (I believe lines longer than around 79 columns were split in two with newlines by your email client). Could you resubmit the patch as an attachment of some sort that will preserve the patch intact? My email reception got knocked offline for a couple of days so I may have missed some mail. Was a new patch ever submitted? I can't find one in the archives. I'd like to get the patch applied before voting on a release, but if it doesn't make it in before then it's not the end of the world. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Modeler] Logo image?
Howdy, Is there a modeler logo image? I can't find it and I'm annoyed at the broken image icon at http://jakarta.apache.org/commons/modeler/. If anyone cares to contribute one, that'd be great, as my graphical talents are negligible ;) Otherwise, I'll draw something up... Thanks, Yoav Shapira Millennium ChemInformatics 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]
cvs commit: jakarta-commons/modeler project.xml
yoavs 2003/08/18 07:04:32 Modified:modeler project.xml Log: Updated developers Revision ChangesPath 1.6 +5 -5 jakarta-commons/modeler/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/modeler/project.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- project.xml 12 Aug 2003 13:18:14 - 1.5 +++ project.xml 18 Aug 2003 14:04:32 - 1.6 @@ -16,16 +16,16 @@ developers developer nameCraig McClanahan/name - id/id - email/email - organization/organization + idcraigmcc/id + email[EMAIL PROTECTED]/email + organizationApache/organization /developer developer nameYoav Shapira/name - id/id + idyoavs/id email[EMAIL PROTECTED]/email - organization/organization + organizationApache/organization /developer /developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dbcp bug
Hi
I've been trying to use commons-dbcp within in our existing infrastructure
and have come across a problem.
The code below simply excutes a stored proc on Sybase which returns no
values. This causes a NullPointerException due the DelegatingResultSet.close
calling close on the null underlying ResultSet when the statement is closed.
Its quite interesting that commenting out the bold line actually stops the
exception occuring !!
Is this a bug ??
Cheers
Liam
// code
public class DataSourceTest {
public static void main(String[] args) throws Exception {
System.out.println(Loading underlying JDBC driver.);
Class.forName(com.sybase.jdbc2.jdbc.SybDriver);
ObjectPool connectionPool = new GenericObjectPool(null,10);
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(jdbc:sybase:Tds:lon0658xus.fm.rbsgrp.net:205
0/finesse_test1,finessedbo,finessedbo);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory,connectionPool,null,null,false,t
rue);
DataSource dataSource = new PoolingDataSource(connectionPool);
System.out.println(Done.);
Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
System.out.println(Creating connection.);
conn = dataSource.getConnection();
System.out.println(Creating callable statement.);
stmt = conn.prepareCall(TruncateDb);
System.out.println(Executing callable statement.);
stmt.execute();
rs = stmt.getResultSet();
} catch(SQLException e) {
e.printStackTrace();
} finally {
try {
System.out.println(Closing Statement.);
stmt.close(); } catch(Exception e) { e.printStackTrace();}
try {
conn.commit();
conn.close();
} catch(Exception e) { e.printStackTrace();}
}
}
}
// output
Loading underlying JDBC driver.
Done.
Creating connection.
Creating callable statement.
Executing callable statement.
Closing Statement.
java.lang.NullPointerException
at
org.apache.commons.dbcp.DelegatingResultSet.close(DelegatingResultSet.java:1
32)
at
org.apache.commons.dbcp.DelegatingCallableStatement.close(DelegatingCallable
Statement.java:140)
at dbcp.DataSourceTest.main(DataSourceTest.java:48)
***
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]
Re: [CLI] 2.0 Proposal
Hi Rob, Months ago, I suggested using [functor] for such a purpose. Don't know if you remember. Here's a quick link: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=104730670828791w=2 And you may still provide standard type checkers and converters using the proposed framework. I understand that [functor] would add another dependency to [CLI]. But it could easily become a soft dependency (required to build but not necessarily to run). The main problem is (IMHO) that [functor] is still in the sandbox and thus there's no official binary release (yet). Regards, Herve On Tue, 12 Aug 2003, Rob Oxspring wrote: I'd envisaged the conversion String-Integer to be handled by some IntegerValidator class attached to the Argument. If this pattern is chosen then I'm not sure how practical overloaded methods would be - the range of types that could be returned would be infinite and we'd have to think about where to draw the line before the number of convenience methods grows too big. I guess the sensible place to draw that line would be for the Java primitives as anything else can easily be cast from an Object anyway. Of course this is ignoring the fact that an XML configuration would have the full knowledge of which types were needed where. To be honest though I really need to think about the xml2cli thing. I like the idea in principle but I'm really struggling to get a handle on what input would be supplied, what might be generated and how the client code would interact with cli to respond to the chosen options. The end points are still to blurry in my head to see what transformation is needed. But I'll switch the xml stuff to a new thread. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pool] Jar does not contain version number
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]
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]
[jira] Commented: (JELLY-64) Current Jelly doesn't compile with maven b10
The following comment has been added to this issue:
Author: David Eric Pugh
Created: Mon, 18 Aug 2003 11:53 AM
Body:
I am not sure what you meant by your last comment. I removed the inhertance but it
wasn't able to run all the unit tests, however using the ant build.xml seemed to
work.. Is ant or maven the way to build jelly?
Seems like it should be maven...
Eric
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-64
Here is an overview of the issue:
-
Key: JELLY-64
Summary: Current Jelly doesn't compile with maven b10
Type: Bug
Status: Unassigned
Priority: Critical
Time Spent: Unknown
Remaining: 2 hours
Project: jelly
Assignee:
Reporter: Paul Libbrecht
Created: Fri, 25 Jul 2003 6:47 AM
Updated: Fri, 25 Jul 2003 6:47 AM
Environment: Whichever JDK but maven 1.0b10
Description:
The project.xml files of jelly and its taglibs are somewhat old.
Aside of the fact that they don't validate, they also don't compile as they don't
contain a sourceDirectory child of build.
Also tests are not run as they don't contain a unitTestSourceDirectory...
The following should be added at least in all project.xml, I would like it if these
project.xml were valid also...
sourceDirectory${basedir}/src/java/sourceDirectory
unitTestSourceDirectory${basedir}/src/test/unitTestSourceDirectory
Also, unit-tests fail currently (the missing-tag unit-test fails).
Paul
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-51) can't get jellyswing example to work
The following comment has been added to this issue: Author: David Eric Pugh Created: Mon, 18 Aug 2003 11:58 AM Body: I tried the demo:swing target, and it worked fine for me. This is with maven Beta 10 and CVS head of jelly. I think it could be closed...? Eric Pugh - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-51 Here is an overview of the issue: - Key: JELLY-51 Summary: can't get jellyswing example to work Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 1 hour Project: jelly Components: taglib.swing Assignee: Reporter: Ralf Hauser Created: Thu, 15 May 2003 3:03 AM Updated: Thu, 15 May 2003 3:03 AM Environment: downloaded commons-jelly-1.0-beta-3, maven-1.0-beta-9, using win2k and j2sdk1.4.1_02 Description: Downloaded example.jelly as described in http://jakarta.apache.org/commons/sandbox/jelly/jellyswing.html. Installed maven such that when I type maven -h everything looks fine. Typed maven demo:swing and got __ __ | \/ |__ Jakarta _ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-beta-9-SNAPSHOT java.lang.NullPointerException at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 376) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:357) at org.apache.maven.cli.App.doMain(App.java:524) at org.apache.maven.cli.App.main(App.java:1080) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:543) at com.werken.forehead.Forehead.main(Forehead.java:573) Total time: 3 seconds Somehow this doesn't surprise me: how shall maven learn about example.jelly (albeit it is in the current working directory from which I started maven...) - there is no -f option or alike where I had to tell maven where to look for it... Any hints would be highly appreciated - many thanks in advance! Ralf P.S.: I am getting a similar error when just calling maven on its own - perhaps there is another cause for the problem (http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-427)? - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-71) Confusing documentation
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-71 Here is an overview of the issue: - Key: JELLY-71 Summary: Confusing documentation Type: Bug Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.swing Assignee: Reporter: David Eric Pugh Created: Mon, 18 Aug 2003 12:04 PM Updated: Mon, 18 Aug 2003 12:04 PM Environment: Maven cvs head and jelly cvs head on windows Description: The documentation http://jakarta.apache.org/commons/jelly/tutorial.html I found confusing for the jelly swing section. I kept typing maven demo:swing and it didn't work. I tried it and then it did, the key was to be in /src/jelly-tags/swing as the goals are provided by the maven.xml file there. I have attached a patch that updates the documentation a bit. Eric - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-71) Confusing documentation
The following issue has been updated: Updater: David Eric Pugh (mailto:[EMAIL PROTECTED]) Date: Mon, 18 Aug 2003 12:04 PM Comment: Here is the documentation patch! Hope others aren't confused in the future. Changes: Attachment changed to jelly.patch - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-71page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-71 Here is an overview of the issue: - Key: JELLY-71 Summary: Confusing documentation Type: Bug Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.swing Assignee: Reporter: David Eric Pugh Created: Mon, 18 Aug 2003 12:04 PM Updated: Mon, 18 Aug 2003 12:04 PM Environment: Maven cvs head and jelly cvs head on windows Description: The documentation http://jakarta.apache.org/commons/jelly/tutorial.html I found confusing for the jelly swing section. I kept typing maven demo:swing and it didn't work. I tried it and then it did, the key was to be in /src/jelly-tags/swing as the goals are provided by the maven.xml file there. I have attached a patch that updates the documentation a bit. Eric - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JELLY] JMS taglib examples?
Hi, Does anyone have any example code for the jms taglib? I tried to build it, and it failed on the JMS api. I swapped in j2ee.jar and it compiled, however I am not sure how to actually go about using the taglib. Thanks, Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] 2.0 Proposal
Hi Herve, I'd forgotten where the suggestion came from but the idea of linking in [functor] is still in my head :). I was thinking about setting up a Validator interface with a single method: void validate(List values) throws ValidationException; and allow Arguments to have an attached Validator instance. When the Argument's validate method is called it would delegate to any validator object which would be permitted to transform the String values into other Objects and would throw a ValidationException on failure. I was thinking of supplying a selection of standard validators (Integer, File, Date?, Class?,...) and then adding a couple of adapters along the lines of: UnaryPredicateValidator - wraps a UnaryPredicate and throws ValidationException if any of the values result in false. UnaryFunctionValidator - wraps a UnaryFunction and tranforms the values accordingly. Any failure would result in a ValidationException. I guess the a wrapper for UnaryProcedure might be an option too but I haven't looked into the functor classes for a while. Done this way I believe the [functor] dependancy can be completely optional, at least until [fuctors] is promoted and released. It also means that clients can write custom validators without having to delve into [functors], but have the flexibility to plug in any in-house functors they already have too. It doesn't provide as much for [functor] to borrow but once it's released we could maybe harden the dependancy and factor out some functors to donate back.. Does this cover the usecases you have in mind? It doesn't feature the pre and post varients but I'm not seeing a usecase for those at the moment anyway (always happy to be proved wrong though). Thoughts? Rob Herve Quiroz wrote: Hi Rob, Months ago, I suggested using [functor] for such a purpose. Don't know if you remember. Here's a quick link: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=104730670828791w=2 And you may still provide standard type checkers and converters using the proposed framework. I understand that [functor] would add another dependency to [CLI]. But it could easily become a soft dependency (required to build but not necessarily to run). The main problem is (IMHO) that [functor] is still in the sandbox and thus there's no official binary release (yet). Regards, Herve On Tue, 12 Aug 2003, Rob Oxspring wrote: I'd envisaged the conversion String-Integer to be handled by some IntegerValidator class attached to the Argument. If this pattern is chosen then I'm not sure how practical overloaded methods would be - the range of types that could be returned would be infinite and we'd have to think about where to draw the line before the number of convenience methods grows too big. I guess the sensible place to draw that line would be for the Java primitives as anything else can easily be cast from an Object anyway. Of course this is ignoring the fact that an XML configuration would have the full knowledge of which types were needed where. To be honest though I really need to think about the xml2cli thing. I like the idea in principle but I'm really struggling to get a handle on what input would be supplied, what might be generated and how the client code would interact with cli to respond to the chosen options. The end points are still to blurry in my head to see what transformation is needed. But I'll switch the xml stuff to a new thread. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] NotifyingCollections - the wrapping problem
Guys,
Sorry I haven't had a chance to read this thread - I've been on the
road since thursday. I'll be back in the real world tomorrow and i'll
get back to you all then.
- Neil
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
From: Chuck Daniels [EMAIL PROTECTED]
sc.add();
Sends event OK - BUT eventCollection == oc.
This is a problem, as if the listener then uses the collection,
it will not
be synchronized. Big problem.
I don't think this will actually be a problem. If calls to sc are
synchronized, then anything that the listener does to the backing
collection
(oc in this case) is still within the context of the synchronized
call on
sc. Therefore, access to the backing collection is indirectly
synchronized.
Or am I missing something here?
Intruiging. Yes, you are probably correct, so long as the listener
operates
in the same thread in a normal fashion. I was thinking of trying to
spot if
the ObservedCollection was being decorated and inform it, but maybe
thats
over zealous, and javadoc will do.
Stephen
- Original Message -
From: Michael Heuer [EMAIL PROTECTED]
To: Jakarta Commons Developers List
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, August 14, 2003 11:02 PM
Subject: Re: [collections] NotifyingCollections - capturing rich
non-uniform
data
On Thu, 14 Aug 2003, Stephen Colebourne wrote:
snip
The biggest problem with all this is that the collection
returned by
getSource() on the event. If the observed collection is
wrapped (eg. by
a
SyncronizedCollection) then getSource() SHOULD return the
wrapped
collection, but it can't as it doesn't know about it. This
problem
applies
to all designs so far.
Is this also a problem? It's general to all of the delegation
implementations.
private boolean heardChange = false;
public void testChangeToBackingCollection()
{
Collection c = new ArrayList();
ObservableCollection oc =
CollectionUtils.observableCollection(c);
oc.addListener(new CollectionListener()
{
public void changed(CollectionEvent e) { heardChange =
true; }
});
c.add(hello);
assertTrue(heardChange == true, heardChange == true);
}
I don't think it's possible to make this test pass -- just a
shortcoming of the wrapper design. That's why I was looking
into
aspect-based implementations.
michael
-
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]
-
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]
[VFS] Warning Verbosity
Hi, Can I ask (again) for some sort of help for the verbosity problem we have with our ant tasks that use dynamic VFS configuration? Basically we get way too many reports... http://gump.chalko.com/krysalis-version-antlib.html BTW: We can't use a single VFS FileSystem 'cos these are separate tasks. regards Adam = -- Adam R. B. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] 2.0 Proposal
Rob, Basically, the Pre- and Post- stuff were to allow the automation of some task(s). I had submitted the example of setting system properties according to command line arguments. Quick link: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=104697467907519w=2 To summarize, (post) predicate stuff was to validate arguments. The difference between PostPredicate and Predicate was necessary before the option groups were implemented. Now we just need what I called Predicate. PostProcesses were used for 2 different goals: automatic conversion (function) and automatic method invocation (procedure). I see that with your scheme, the Validator thing replaces both the Predicate and the PostProcess (function) stuff, which is nice (type checking and conversion at once). Still left is the ability to specify a task to be performed automatically right after the command line has been parsed correctly (such as affecting the system properties according to command line arguments). But in fact, one could just use your Validator thing to perform such a task. Then the only problem (if I go hair-splitting) is the name Validator. So xxxValidator classes should implement a Function (or similar) interface (but still be called xxxValidator). The valid(List values) method would become process(List value) or evaluate(List value) as it is in [functor]. Also, the according OptionBuilder method should be something more like: withArgumentProcess(Function function) This way, we may handle everything from one single method. Herve. On Mon, 18 Aug 2003, Rob Oxspring wrote: Hi Herve, I'd forgotten where the suggestion came from but the idea of linking in [functor] is still in my head :). I was thinking about setting up a Validator interface with a single method: void validate(List values) throws ValidationException; and allow Arguments to have an attached Validator instance. When the Argument's validate method is called it would delegate to any validator object which would be permitted to transform the String values into other Objects and would throw a ValidationException on failure. I was thinking of supplying a selection of standard validators (Integer, File, Date?, Class?,...) and then adding a couple of adapters along the lines of: UnaryPredicateValidator - wraps a UnaryPredicate and throws ValidationException if any of the values result in false. UnaryFunctionValidator - wraps a UnaryFunction and tranforms the values accordingly. Any failure would result in a ValidationException. I guess the a wrapper for UnaryProcedure might be an option too but I haven't looked into the functor classes for a while. Done this way I believe the [functor] dependancy can be completely optional, at least until [fuctors] is promoted and released. It also means that clients can write custom validators without having to delve into [functors], but have the flexibility to plug in any in-house functors they already have too. It doesn't provide as much for [functor] to borrow but once it's released we could maybe harden the dependancy and factor out some functors to donate back.. Does this cover the usecases you have in mind? It doesn't feature the pre and post varients but I'm not seeing a usecase for those at the moment anyway (always happy to be proved wrong though). Thoughts? Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/pool project.xml
mpoeschl2003/08/18 12:59:57 Modified:pool project.xml Log: use collections-2.1 and junit-3.8.1 Revision ChangesPath 1.13 +2 -2 jakarta-commons/pool/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/pool/project.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- project.xml 11 Aug 2003 11:47:41 - 1.12 +++ project.xml 18 Aug 2003 19:59:57 - 1.13 @@ -92,12 +92,12 @@ dependencies dependency idcommons-collections/id - version2.0/version + version2.1/version /dependency dependency idjunit/id - version3.7/version + version3.8.1/version /dependency !-- these two are required by maven -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jexl] dotted property names in expressions
Hi,
There is a problem with jexl when testing dotted property names for
emptiness. I am using it from jelly through maven:
maven -Ddotted.property.name=foo goal
inside the goal:
j:if test=${empty(dotted.property.name)}
echo Empty property /echo
/j:if
j:set var=littlename value=${dotted.property.name}/
j:if test=${empty(littlename)}
echo Empty little property /echo
/j:if
Only the first echo happens.
If I get more time to get the code from CVS working in eclipse and to
get my head around Jexl internals, I'll write a unit test.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: UUID Reuse proposal
On the general topic of Java packaging and not to consider until the far 3.0 future ;-) I think that we have a bit of package inflation already. From my POV, commons-lang extends java.lang and all of its stuff should just go in o.a.c.lang. But that's just me. I think that when you consider that packages are namespaces, I do not think that we need to keep all of what now makes up lang in separate namespaces. Just as an example, I find the use of a lang.builder package an odd choice rather than putting it all in lang. What do all the builder classes have in common? The only thing I can think of is that they provide the same kind of implementations to provide their services. Hardly worth a separate namespace, IMHO again. Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 00:06 To: Jakarta Commons Developers List Subject: Re: UUID Reuse proposal Tim Reilly wrote: Thanks for the positive response to adapting a UUID class in commons lang. [The Axis list has responded with favoring option 2 which is basically to not make changes at this time, but has no problem with use of the UUID code from Axis in the commons.] I'm looking for direction on next steps - I believe after answering the following questions; I would create an enhancement in bugzilla and attach patches or sources? Yes. I would start by patching IdentifierUtils (see below) to add some additional methods, assuming that there are no objections to this approach. I think at this time there are two questions to resolve: ~1) Where to place the UUID code. I personally prefer a package and separate classes as Phil Steitz suggests: I do like the idea of lang providing a home for IdentifierUtils suitably named and packaged. There are really multiple types here: * UUID (pseudo) standard, non-random, non-secure * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils) * Random, secure, not guaranteed unique (e.g. Tomcat session IDs) * Part random, secure, guaranteed unique (what Tomcat really needs ;-) * Bounded sequential(e.g. Betwixt's io identifiers) * Cyclic I believe the alternative is to add the UUID code to the existing IdentifierUtils.java. 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 user of the library I believe it would be much easier to locate and so more valuable to have in a suitably named package of IdentifierUtils.) ~2) Which UUID implementation to use: Tim Anderson suggested using: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone know if there are any issues with the license on this. It seems it would be okay as long as this license information were included along with the apache license in the source. (Would we also need an additional UUID- License.txt? I'm not sure how to interpret item 2 of license) The alternative is to use the Axis UUID and add features such as those in Tyrex's later. If a real issue exists I could try contacting them so find a suitable solution. I don't know about the license, but as I said above, I like the tyrex impl better. In any case, making the implementation threadsafe would be a good idea, as would (IMHO) allowing the node ID to be read from a properties file. I would also be interested in others' opinions on the value of the UUID standard, especially minus the MAC address. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/time DateUtils.java
ggregory2003/08/18 14:52:39
Modified:lang/src/java/org/apache/commons/lang/time DateUtils.java
Log:
Removed: The private field DateUtils.dateFormats is never read locally.
Revision ChangesPath
1.16 +1 -11
jakarta-commons/lang/src/java/org/apache/commons/lang/time/DateUtils.java
Index: DateUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/DateUtils.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- DateUtils.java18 Aug 2003 02:22:25 - 1.15
+++ DateUtils.java18 Aug 2003 21:52:39 - 1.16
@@ -53,8 +53,6 @@
*/
package org.apache.commons.lang.time;
-import java.text.DateFormat;
-import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
@@ -111,14 +109,6 @@
{Calendar.MONTH, DateUtils.SEMI_MONTH},
{Calendar.YEAR},
{Calendar.ERA}};
-
-private static DateFormat[] dateFormats = {
-//3/31/92 10:00:07 PST
-new SimpleDateFormat(M/dd/yy h:mm:ss z),
-//January 23, 1987 10:05pm
-new SimpleDateFormat(MMM d, h:mm a),
-//22:00 GMT
-new SimpleDateFormat(h:mm z)};
/**
* A week range, starting on Sunday.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] private field DateUtils.dateFormats is never read locally
He's dead Jim. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, August 17, 2003 19:15 To: Jakarta Commons Developers List Subject: Re: [lang] private field DateUtils.dateFormats is never read locally +1 to killing it. On Sun, 17 Aug 2003, Gary Gregory wrote: Hello, The private field DateUtils.dateFormats is never read locally. Is this work in progress or shall we/I delete it? Removing it does not break any tests. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus - New directory
rdonkin 2003/08/18 14:54:31 jakarta-commons/xdocs/stylesheets/menus - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus about.xml
rdonkin 2003/08/18 14:55:56 Added: xdocs/stylesheets/menus about.xml Log: Split menus into separate xml fragment files. Hopefully this should allow mavenized projects to include there entities within their navigation bar. Revision ChangesPath 1.1 jakarta-commons/xdocs/stylesheets/menus/about.xml Index: about.xml === !-- The 'About Us' menu element -- menu name=About Us item name=Home href=http://jakarta.apache.org/commons/index.html; / item name=Contributors href=http://jakarta.apache.org/commons/contributors.html/ item name=License href=http://jakarta.apache.org/commons/license.html/ /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus community.xml
rdonkin 2003/08/18 14:56:14 Added: xdocs/stylesheets/menus community.xml Log: Split menus into separate xml fragment files. Hopefully this should allow mavenized projects to include there entities within their navigation bar. Revision ChangesPath 1.1 jakarta-commons/xdocs/stylesheets/menus/community.xml Index: community.xml === !-- The Community menu element -- menu name=Community item name=Get Involved href=http://jakarta.apache.org/site/getinvolved.html/ item name=Mailing Lists href=http://jakarta.apache.org/site/mail.html/ item name=Access CVS Repositories href=http://jakarta.apache.org/site/cvsindex.html/ item name=Wiki href=http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaCommonsProjectPages/ /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus components.xml
rdonkin 2003/08/18 14:56:29 Added: xdocs/stylesheets/menus components.xml Log: Split menus into separate xml fragment files. Hopefully this should allow mavenized projects to include there entities within their navigation bar. Revision ChangesPath 1.1 jakarta-commons/xdocs/stylesheets/menus/components.xml Index: components.xml === !-- The Components Repository menu element -- menu name=Components Repository item name=BeanUtils href=http://jakarta.apache.org/commons/beanutils.html/ item name=Betwixt href=http://jakarta.apache.org/commons/betwixt/index.html/ item name=CLI href=http://jakarta.apache.org/commons/cli/index.html/ item name=Codec href=http://jakarta.apache.org/commons/codec/index.html/ item name=Collections href=http://jakarta.apache.org/commons/collections.html/ item name=DBCP href=http://jakarta.apache.org/commons/dbcp/ item name=Digester href=http://jakarta.apache.org/commons/digester.html/ item name=Discovery href=http://jakarta.apache.org/commons/discovery.html/ item name=EL href=http://jakarta.apache.org/commons/el.html/ item name=FileUpload href=http://jakarta.apache.org/commons/fileupload/index.html/ item name=HttpClient href=http://jakarta.apache.org/commons/httpclient/index.html/ item name=Jelly href=http://jakarta.apache.org/commons/jelly/index.html/ item name=Jexl href=http://jakarta.apache.org/commons/jexl.html/ item name=JXPath href=http://jakarta.apache.org/commons/jxpath/index.html/ item name=Lang href=http://jakarta.apache.org/commons/lang.html/ item name=Latka href=http://jakarta.apache.org/commons/latka/index.html/ item name=Logging href=http://jakarta.apache.org/commons/logging.html/ item name=Modeler href=http://jakarta.apache.org/commons/modeler.html/ item name=Net href=http://jakarta.apache.org/commons/net/index.html/ item name=Pool href=http://jakarta.apache.org/commons/pool/ item name=Validator href=http://jakarta.apache.org/commons/validator/index.html/ /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus information.xml
rdonkin 2003/08/18 14:56:49 Added: xdocs/stylesheets/menus information.xml Log: Split menus into separate xml fragment files. Hopefully this should allow mavenized projects to include there entities within their navigation bar. Revision ChangesPath 1.1 jakarta-commons/xdocs/stylesheets/menus/information.xml Index: information.xml === !-- The Information menu element -- menu name=Information item name=Overview href=http://jakarta.apache.org/commons/index.html/ item name=Components href=http://jakarta.apache.org/commons/components.html/ item name=On Volunteering href=http://jakarta.apache.org/commons/volunteering.html/ item name=On Contributing Patches href=http://jakarta.apache.org/commons/patches.html/ !-- Yet to come? item name=Guidelines href=http://jakarta.apache.org/commons/guidelines.html/ item name=News href=http://jakarta.apache.org/commons/news.html/ -- !-- deprecated? item name=Commons Proper href=http://jakarta.apache.org/commons/commons.html/ item name=Sandbox href=http://jakarta.apache.org/commons/sandbox.html/ -- /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus related.xml
rdonkin 2003/08/18 14:57:24 Added: xdocs/stylesheets/menus related.xml Log: Split menus into separate xml fragment files. Hopefully this should allow mavenized projects to include there entities within their navigation bar. Revision ChangesPath 1.1 jakarta-commons/xdocs/stylesheets/menus/related.xml Index: related.xml === menu name=Related item name='[EMAIL PROTECTED]' href='http://db.apache.org/commons/'/ item name='[EMAIL PROTECTED]' href='http://xml.apache.org/commons/'/ /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus sandbox.xml
rdonkin 2003/08/18 14:57:40 Added: xdocs/stylesheets/menus sandbox.xml Log: Split menus into separate xml fragment files. Hopefully this should allow mavenized projects to include there entities within their navigation bar. Revision ChangesPath 1.1 jakarta-commons/xdocs/stylesheets/menus/sandbox.xml Index: sandbox.xml === menu name=Sandbox Components item name=Attributes href=http://jakarta.apache.org/commons/sandbox/attributes/index.html/ item name=Cache href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cache// item name=Clazz href=http://jakarta.apache.org/commons/sandbox/clazz// item name=Configuration href=http://jakarta.apache.org/commons/sandbox/configuration/index.html/ item name=Daemon href=http://jakarta.apache.org/commons/sandbox/daemon/index.html/ item name=DbUtils href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/dbutils// item name=Functor href=http://jakarta.apache.org/commons/sandbox/functor// item name=HiveMind href=http://jakarta.apache.org/commons/sandbox/hivemind// item name=IO href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/io// item name=JJar href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jjar// item name=Math href=http://jakarta.apache.org/commons/sandbox/math/index.html/ item name=Messenger href=http://jakarta.apache.org/commons/sandbox/messenger/index.html/ item name=Resources href=http://jakarta.apache.org/commons/sandbox/resources/index.html/ item name=Scaffold href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/scaffold// item name=SQL href=http://jakarta.apache.org/commons/sandbox/sql/index.html/ item name=ThreadPool href=http://jakarta.apache.org/commons/sandbox/threadpool/index.html/ item name=VFS href=http://jakarta.apache.org/commons/sandbox/vfs/index.html/ item name=Workflow href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/workflow// /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus translations.xml
rdonkin 2003/08/18 14:57:53 Added: xdocs/stylesheets/menus translations.xml Log: Split menus into separate xml fragment files. Hopefully this should allow mavenized projects to include there entities within their navigation bar. Revision ChangesPath 1.1 jakarta-commons/xdocs/stylesheets/menus/translations.xml Index: translations.xml === menu name=Translations (Web) item name=Japanese href=http://jakarta.terra-intl.com/commons// /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets/menus view.xml
rdonkin 2003/08/18 14:58:07 Added: xdocs/stylesheets/menus view.xml Log: Split menus into separate xml fragment files. Hopefully this should allow mavenized projects to include there entities within their navigation bar. Revision ChangesPath 1.1 jakarta-commons/xdocs/stylesheets/menus/view.xml Index: view.xml === menu name=View CVS item name=Components href=http://cvs.apache.org/viewcvs/jakarta-commons// item name=Sandbox href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox// /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] ASF license spelling error nit
FYI, Please note that the [lang] and [codec] LICENSE.txt and all .java file headers have been updated to correct the following spelling error: acknowlegement is not spelled correctly; it should be acknowledgement (missing d). Gary
Re: [VOTE RESULT] New committer - Phil Steitz
Account created, password sent, commit privs granted. Brian On Sun, 17 Aug 2003, Mark R. Diggory wrote: Revised results (not that it really matters after 5 votes! :-) but...) 7 +1's Steven Caswell, Noel Bergman, Tim O'Brien, Yoav Shapira, Mark Diggory, Juozas Baliuka, Henri Yandell 1 +0's Gary Gregory, Stephen Colebourne wrote: Welcome Phil! This mail is cross posted to Jakarta PMC and root to expedite the new committer process. - Vote thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg23841.html Result: 4 +1 (Stephen Colebourne, Henri YandellYoav Shapira, Noel J. Bergman) 1 +0 (Gary Gregory) no -0/-1 Requested username: psteitz Name: Phil Steitz Email: [EMAIL PROTECTED] Projects: JakartaCommons and JakartaCommonsSandbox - Stephen (scolebourne) - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, August 14, 2003 9:10 AM Subject: [VOTE] New committer - Phil Steitz I would like to nominate Phil Steitz as an Apache Jakarta Commons committer. Phil has provided sterling efforts in patches, discussion and quality control for [lang] version 2.0. He has also put much energy into [math], and expressed an interest in other subprojects. I believe he would be a valuable addition to the committers. Votes please, closing Sunday 17th midnight GMT Stephen [ ] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - 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: [lang] RC3 released
Updated Javadoc in - CharSetUtils - StringUtils - WordUtils Removed method from CharSetUtils that was deprecated, but not in 1.0.1. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.apache.org/~bayard/commons-lang-2.0-rc3/ Changes I know of: Some javadoc WordWrapUtils fixed, renamed to WordUtils and with some of StringUtils code All .zip files should have text files in DOS CRLF format I'm sure there were other ones though. Let's give these a couple of days to see if anyone has any problems with them. 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: [lang] Package structure [was UUID Reuse proposal]
Matthew pretty much describes the thinking in [lang] and what I do. I dislike large packages, especially in OSS. One way to learn a library is to browse the packages. By keeping related things together you can learn the API one package at a time, or dismiss a package if it is unimportant to you. The danger is actually elsewhere for [lang], and that is one of including too much. We have already kicked out the functor package to the much better planned [functor]. Also math has been kicked out to [math], with just very basic lang level functions remaining. The reflect subpackage really ought to go the same way (and I will probably propose this sometime soon). Stephen - Original Message - From: __matthewHawthorne [EMAIL PROTECTED] I think that the creation of multiple small packages is more of a practical exercise than a theoretical one. For example, if [lang] contained 500 classes which all, in some way or another, were extensions to java.lang... it may make sense from a certain standpoint to throw them all in the root package. However, in practice, it seems easier to break up the classes into smaller sets, where it can be determined that set A depends on set B, one group of developers is working on set C while another works on set D, set A needs a certain type of test data while set C needs another, etc. I don't see packages as namespaces so much as functional groups; they help to maintain order of depencencies, tests, developers, etc. I also find some APIs with large packages difficult to browse (everyone seems to have a *.util package with millions of classes in it), but that may just be a personal preference. Any thoughts? Gary Gregory wrote: On the general topic of Java packaging and not to consider until the far 3.0 future ;-) I think that we have a bit of package inflation already. From my POV, commons-lang extends java.lang and all of its stuff should just go in o.a.c.lang. But that's just me. I think that when you consider that packages are namespaces, I do not think that we need to keep all of what now makes up lang in separate namespaces. Just as an example, I find the use of a lang.builder package an odd choice rather than putting it all in lang. What do all the builder classes have in common? The only thing I can think of is that they provide the same kind of implementations to provide their services. Hardly worth a separate namespace, IMHO again. Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 00:06 To: Jakarta Commons Developers List Subject: Re: UUID Reuse proposal Tim Reilly wrote: Thanks for the positive response to adapting a UUID class in commons lang. [The Axis list has responded with favoring option 2 which is basically to not make changes at this time, but has no problem with use of the UUID code from Axis in the commons.] I'm looking for direction on next steps - I believe after answering the following questions; I would create an enhancement in bugzilla and attach patches or sources? Yes. I would start by patching IdentifierUtils (see below) to add some additional methods, assuming that there are no objections to this approach. I think at this time there are two questions to resolve: ~1) Where to place the UUID code. I personally prefer a package and separate classes as Phil Steitz suggests: I do like the idea of lang providing a home for IdentifierUtils suitably named and packaged. There are really multiple types here: * UUID (pseudo) standard, non-random, non-secure * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils) * Random, secure, not guaranteed unique (e.g. Tomcat session IDs) * Part random, secure, guaranteed unique (what Tomcat really needs ;-) * Bounded sequential(e.g. Betwixt's io identifiers) * Cyclic I believe the alternative is to add the UUID code to the existing IdentifierUtils.java. 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 user of the library I believe it would be much easier to locate and so more valuable to have in a suitably named package of IdentifierUtils.) ~2) Which UUID implementation to use: Tim Anderson suggested using: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone know if there are any issues with the license on this. It seems it would be okay as long as this license information were included along with the apache license in the source. (Would we also need an additional UUID- License.txt? I'm not sure how to interpret item 2 of license) The alternative is to use the Axis UUID and add features such as those in
Re: [lang] RC3 util package UUID issue
The discussion over UUID makes me nervous. It has been suggested that UUID, together with the rest of the id stuff goes into a new identifier subpackage. This makes sense. However, it is unreasonable of us to release a new package, and then deprecate it in the next release (2.1). It also raises the question of whether the other two util package classes (BitField and Validate) should be in the main lang package instead. (What does util mean?) Solutions: 1) Release as is, we can't predict the future 2) Don't release entire util subpackage 3) Delete util subpackage. Move BitField and Validate to main lang package. Create identifier subpackage for ids. Release 2.0. 4) Delete util subpackage. Move BitField and Validate to main lang package. Release 2.0 without ids. IMHO #1 may tie us to a util subpackage, which I don't like, so #2 is better. #3 is good, but I prefer #4 overall while ids are up in the air - it gives us more design flexibility. Stephen (who is now getting very tired of 2.0...) - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.apache.org/~bayard/commons-lang-2.0-rc3/ Changes I know of: Some javadoc WordWrapUtils fixed, renamed to WordUtils and with some of StringUtils code All .zip files should have text files in DOS CRLF format I'm sure there were other ones though. Let's give these a couple of days to see if anyone has any problems with them. 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]
DO NOT REPLY [Bug 15542] - No Javadoc for HelpFormatter!
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=15542. 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=15542 No Javadoc for HelpFormatter! [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 00:40 --- JavaDoc seems fairly complete and accurate, closing bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/xdocs tasks.xml
dgraham 2003/08/18 17:39:20 Modified:validator/xdocs tasks.xml Log: Added deprecation notes and more TODOs. Revision ChangesPath 1.3 +153 -0jakarta-commons/validator/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons/validator/xdocs/tasks.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- tasks.xml 18 Aug 2003 23:34:36 - 1.2 +++ tasks.xml 19 Aug 2003 00:39:20 - 1.3 @@ -16,6 +16,9 @@ subsection name=High priority ul + li + Remove deprecated functionality after 1.1.1 release. + /li /ul /subsection @@ -46,18 +49,168 @@ section name='Completed' subsection name='Since 1.0.2 Release' ul + li + Move Digester rule configuration to XML file and remove ValidatorResourcesInitializer. + ValidatorResources now knows how to initialize itself. + /li + li + Clean up scopes of methods and variables. + /li + li + Make Arg system more flexible to allow any number of args in a message. + /li + li + Validate vaildation.xml files while initializing a Validator to alert developers to configuration + errors. + /li /ul /subsection /section section name='Deprecated' subsection name='Since 1.0.2 Release' + pSee the javadoc for details and replacements./p ul +li + The lt;arg0-3gt; elements have been replaced with a single lt;arggt; element + with a new codeposition/code attribute. Setting position to 0 is the equivalent + of an lt;arg0gt; element. + /li + li + codeArg.getResource()/code + /li + li + codeCreditCardValidator.isValidPrefix()/code + /li + li + codeField.ARG_DEFAULT/code + /li + li + codeField.hDependencies/code + /li + li + codeField.hArg0 - Field.hArg3/code + /li + li + codeField.addArg0() - Field.addArg3()/code + /li + li + codeField.getArg0() - Field.getArg3()/code + /li + li + codeField.addVarParam()/code + /li + li + codeField.process()/code + /li + li + codeField.processMessageComponents()/code + /li + li + codeField.getDependencies()/code + /li + li + codeForm.getFieldMap()/code + /li + li + codeForm.process()/code + /li + li + codeFormSet.addConstant()/code + /li + li + codeFormSet.addConstantParam()/code + /li + li + codeFormSet.getForm(Object)/code + /li + li + codeFormSet.process()/code + /li + li + codeGenericValidator.REGEXP_DELIM/code + /li + li + codeGenericValidator.validateCreditCardLuhnCheck()/code + /li + li + codeGenericValidator.validateCreditCardPrefixCheck()/code + /li + li + codeGenericValidator.getDelimittedRegExp()/code + /li + li + codeValidator.BEAN_KEY/code + /li + li + codeValidator.VALIDATOR_ACTION_KEY/code + /li + li + codeValidator.FIELD_KEY/code + /li + li + codeValidator.VALIDATOR_KEY/code + /li + li + codeValidator.LOCALE_KEY/code + /li + li + codeValidator.hResources/code + /li + li + codeValidator.addResource()/code + /li + li + codeValidator.getResource()/code + /li + li + codeValidatorAction.process()/code + /li + li + codeValidatorAction.getDependencies()/code + /li
cvs commit: jakarta-commons/latka/src/java/org/apache/commons/latka/http RequestImpl.java
yoavs 2003/08/18 17:43:42
Modified:latka/src/java/org/apache/commons/latka/http
RequestImpl.java
Log:
Applied misc JavaDoc corrections for bug 12916.
Revision ChangesPath
1.38 +8 -9
jakarta-commons/latka/src/java/org/apache/commons/latka/http/RequestImpl.java
Index: RequestImpl.java
===
RCS file:
/home/cvs/jakarta-commons/latka/src/java/org/apache/commons/latka/http/RequestImpl.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- RequestImpl.java 8 Jul 2003 15:46:43 - 1.37
+++ RequestImpl.java 19 Aug 2003 00:43:42 - 1.38
@@ -189,9 +189,8 @@
}
/**
- * Returns a constant representing the http method
- * (get, post, etc.) being used by this request. See
- * the Request interface for available constants.
+ * Returns the object implementing the HttpMethod
+ * (get, post, etc.) for this request.
*
* @return the underlying HttpMethod object representing the request/
* response pair.
@@ -319,7 +318,7 @@
// is enabled, HTTPClient may return a path
// that is different from the initial request.
// HTTPClient will not follow redirects to another
-// host or port; in that event, it will always
+// host, port, or protocol; in that event, it will always
// return a 301 or 302.
_session.setReferer(new URL(_targetURL.getProtocol(), _host, _port,
_httpMethod.getPath()));
@@ -556,7 +555,7 @@
return _method;
}
-/** Getter for property pproxy.
+/** Getter for property proxy.
* @return Value of property proxy.
*/
public Proxy getProxy() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12916] - [PATCH] Fix javadoc in RequestImpl.java
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=12916. 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=12916 [PATCH] Fix javadoc in RequestImpl.java [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 00:46 --- JavaDoc fixes applies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18689] - Tests for dependent validators + Refactoring
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=18689. 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=18689 Tests for dependent validators + Refactoring [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 00:47 --- I believe these refactorings are completed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/net package.html
yoavs 2003/08/18 17:50:05 Modified:codec/src/java/org/apache/commons/codec/net package.html Log: Added description of contents of package. Revision ChangesPath 1.2 +7 -0 jakarta-commons/codec/src/java/org/apache/commons/codec/net/package.html Index: package.html === RCS file: /home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/net/package.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- package.html 14 Aug 2003 07:41:09 - 1.1 +++ package.html 19 Aug 2003 00:50:05 - 1.2 @@ -1,5 +1,12 @@ html body Network related encoding and decoding. + p + Currently, the only codec in this package is URLCodec, which + implements encoding and decoding for www-form-urlencoded, + also known as URL-Encoding. The source for URLCodec provides + detailed comments. + p + Ideas for other net codec are encouraged ;) /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17157] - SimpleFileLog class
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=17157. 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=17157 SimpleFileLog class --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 00:55 --- -1 On this addition. Commons-logging should really stay away from implementations are much as possible -- log4j, avalon, jdk1.4 all have this feature. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20670] - dead link to development-process.html
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=20670. 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=20670 dead link to development-process.html [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 00:59 --- No longer relevant: developer process link now points to commons-charter. Not ideal, but not too bad ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] RC3 util package UUID issue
On Tue, 19 Aug 2003, Stephen Colebourne wrote: The discussion over UUID makes me nervous. It has been suggested that UUID, together with the rest of the id stuff goes into a new identifier subpackage. This makes sense. However, it is unreasonable of us to release a new package, and then deprecate it in the next release (2.1). It also raises the question of whether the other two util package classes (BitField and Validate) should be in the main lang package instead. (What does util mean?) Solutions: 1) Release as is, we can't predict the future 2) Don't release entire util subpackage 3) Delete util subpackage. Move BitField and Validate to main lang package. Create identifier subpackage for ids. Release 2.0. 4) Delete util subpackage. Move BitField and Validate to main lang package. Release 2.0 without ids. Non-binding vote of course, but I think this is the best way to go. A package lang.util doesn't make all that much sense, and it'd be nice to get 2.0 out. michael IMHO #1 may tie us to a util subpackage, which I don't like, so #2 is better. #3 is good, but I prefer #4 overall while ids are up in the air - it gives us more design flexibility. Stephen (who is now getting very tired of 2.0...) - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.apache.org/~bayard/commons-lang-2.0-rc3/ Changes I know of: Some javadoc WordWrapUtils fixed, renamed to WordUtils and with some of StringUtils code All .zip files should have text files in DOS CRLF format I'm sure there were other ones though. Let's give these a couple of days to see if anyone has any problems with them. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] RC3 util package UUID issue
On Tue, 19 Aug 2003, Stephen Colebourne wrote: The discussion over UUID makes me nervous. Yeah. Hard to hang onto. It has been suggested that UUID, together with the rest of the id stuff goes into a new identifier subpackage. This makes sense. However, it is unreasonable of us to release a new package, and then deprecate it in the next release (2.1). It also raises the question of whether the other two util package classes (BitField and Validate) should be in the main lang package instead. (What does util mean?) Solutions: 1) Release as is, we can't predict the future Sometimes there are hints? 2) Don't release entire util subpackage -1. Good reason why util is a bad name, 2 classes are held up by one with absolutely nothing in common. 3) Delete util subpackage. Move BitField and Validate to main lang package. Create identifier subpackage for ids. Release 2.0. 4) Delete util subpackage. Move BitField and Validate to main lang package. Release 2.0 without ids. +1. IMHO #1 may tie us to a util subpackage, which I don't like, so #2 is better. #3 is good, but I prefer #4 overall while ids are up in the air - it gives us more design flexibility. Me too. RC4 coming up I think. (who is now getting very tired of 2.0...) Let's call it 2.x! Numbers are so limiting. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator project.xml
rleland 2003/08/18 18:21:14 Modified:validator project.xml Log: Add reports to build. Revision ChangesPath 1.15 +30 -1 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- project.xml 18 Aug 2003 05:03:00 - 1.14 +++ project.xml 19 Aug 2003 01:21:14 - 1.15 @@ -15,7 +15,7 @@ description Commons Validator provides the building blocks for both client side validation -and server side data validation. It may be used standalone on with a framework like +and server side data validation. It may be used standalone or with a framework like Struts. /description urlhttp://jakarta.apache.org/commons/validator//url @@ -163,5 +163,34 @@ /build + + reports +!-- + | + | These should all be completely self contained. You should be able + | to generate each of them individually without needing the final + | xdoc transformation. + | + | Each report plugin with it's POM and plugin.jelly logic should + | contain everything needed to produced the report. + | +-- + +reportmaven-jdepend-plugin/report +reportmaven-checkstyle-plugin/report +reportmaven-changes-plugin/report +reportmaven-changelog-plugin/report +reportmaven-file-activity-plugin/report +reportmaven-developer-activity-plugin/report +reportmaven-javadoc-plugin/report +reportmaven-jxr-plugin/report +reportmaven-junit-report-plugin/report +reportmaven-tasklist-plugin/report +reportmaven-jellydoc-plugin/report +reportmaven-pmd-plugin/report +reportmaven-simian-plugin/report +reportmaven-faq-plugin/report +reportmaven-multiproject-plugin/report + /reports /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] RC3 util package UUID issue
--- Stephen Colebourne [EMAIL PROTECTED] wrote: The discussion over UUID makes me nervous. It has been suggested that UUID, together with the rest of the id stuff goes into a new identifier subpackage. This makes sense. However, it is unreasonable of us to release a new package, and then deprecate it in the next release (2.1). It also raises the question of whether the other two util package classes (BitField and Validate) should be in the main lang package instead. (What does util mean?) Solutions: 1) Release as is, we can't predict the future 2) Don't release entire util subpackage 3) Delete util subpackage. Move BitField and Validate to main lang package. Create identifier subpackage for ids. Release 2.0. 4) Delete util subpackage. Move BitField and Validate to main lang package. Release 2.0 without ids. +1 Phil IMHO #1 may tie us to a util subpackage, which I don't like, so #2 is better. #3 is good, but I prefer #4 overall while ids are up in the air - it gives us more design flexibility. Stephen (who is now getting very tired of 2.0...) - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.apache.org/~bayard/commons-lang-2.0-rc3/ Changes I know of: Some javadoc WordWrapUtils fixed, renamed to WordUtils and with some of StringUtils code All .zip files should have text files in DOS CRLF format I'm sure there were other ones though. Let's give these a couple of days to see if anyone has any problems with them. 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] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22536] New: - maven xdocs/tasks.xml
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=22536. 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=22536 maven xdocs/tasks.xml Summary: maven xdocs/tasks.xml Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Betwixt AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] section name='Symantic Changes' Symantic should be spelled Semantic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] RC3 util package UUID issue
in-line comment -Original Message- From: Michael Heuer [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 18:00 To: Jakarta Commons Developers List Subject: Re: [lang] RC3 util package UUID issue On Tue, 19 Aug 2003, Stephen Colebourne wrote: The discussion over UUID makes me nervous. It has been suggested that UUID, together with the rest of the id stuff goes into a new identifier subpackage. This makes sense. However, it is unreasonable of us to release a new package, and then deprecate it in the next release (2.1). It also raises the question of whether the other two util package classes (BitField and Validate) should be in the main lang package instead. (What does util mean?) Solutions: 1) Release as is, we can't predict the future 2) Don't release entire util subpackage 3) Delete util subpackage. Move BitField and Validate to main lang package. Create identifier subpackage for ids. Release 2.0. 4) Delete util subpackage. Move BitField and Validate to main lang package. Release 2.0 without ids. Non-binding vote of course, but I think this is the best way to go. A package lang.util doesn't make all that much sense, and it'd be nice to get 2.0 out. Michael Names are important and as far as package names, I've always felt that naming a package util was a cop out: When see lang.util I /would like/ to think Common useful stuff that the rest of lang re-uses. But that does not make much sense, because such code should really be in the root .lang with sub-packages reusing .lang. (Guideline I like: It is ok for sub-packages to import from above but not the other way around) +, when I actually look in a lot of .util type of packages, (not a flame, but constructive criticism) like lang.util I feel like Well, here's a bunch of unrelated stuff (Validate, Ids) that was lumped under the rug over here. So, to make a long story short: +1 on (4). IMHO #1 may tie us to a util subpackage, which I don't like, so #2 is better. #3 is good, but I prefer #4 overall while ids are up in the air - it gives us more design flexibility. Stephen (who is now getting very tired of 2.0...) - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.apache.org/~bayard/commons-lang-2.0-rc3/ Changes I know of: Some javadoc WordWrapUtils fixed, renamed to WordUtils and with some of StringUtils code All .zip files should have text files in DOS CRLF format I'm sure there were other ones though. Let's give these a couple of days to see if anyone has any problems with them. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17157] - SimpleFileLog class
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=17157. 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=17157 SimpleFileLog class [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 02:13 --- I'm also -1. commons-logging is not and should not be in the business of providing robust logging *implementations* -- it is designed to be a wrapper around existing logging technologies. Had I to do it over again, I probably would have argued against including even SimpleLog in the basic package. Besides, all you have to do is redirect where System.err writes to and you've accomplished what this bug report wants. You can look at what recent versions of Tomcat do in this regard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/util UtilTestSuite.java BitFieldTest.java ValidateTest.java
bayard 2003/08/18 19:32:16
Modified:lang/src/java/org/apache/commons/lang/util package.html
lang/src/test/org/apache/commons/lang LangTestSuite.java
lang/src/test/org/apache/commons/lang/util
UtilTestSuite.java
Added: lang/src/java/org/apache/commons/lang BitField.java
Validate.java
lang/src/test/org/apache/commons/lang BitFieldTest.java
ValidateTest.java
Removed: lang/src/java/org/apache/commons/lang/util BitField.java
Validate.java
lang/src/test/org/apache/commons/lang/util BitFieldTest.java
ValidateTest.java
Log:
Moved BitField and Validate from the util package up to the main package.
Revision ChangesPath
1.1
jakarta-commons/lang/src/java/org/apache/commons/lang/BitField.java
Index: BitField.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2002-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*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
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements normally appear.
*
* 4. The names 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
*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
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.lang;
/**
* pManage operations dealing with bit-mapped fields./p
*
* @author Apache Jakarta POI
* @author Scott Sanders (sanders at apache dot org)
* @author Marc Johnson (mjohnson at apache dot org)
* @author Andrew C. Oliver (acoliver at apache dot org)
* @author Stephen Colebourne
* @author Pete Gieser
* @since 2.0
* @version $Id: BitField.java,v 1.1 2003/08/19 02:32:15 bayard Exp $
*/
public class BitField {
private final int _mask;
private final int _shift_count;
/**
* pCreate a BitField instance./p
*
* @param mask the mask specifying which bits apply to this
* BitField. Bits that are set in this mask are the bits
* that this BitField operates on
*/
public BitField(final int mask) {
_mask = mask;
int count = 0;
int bit_pattern = mask;
if (bit_pattern != 0) {
while ((bit_pattern 1) == 0) {
count++;
bit_pattern = 1;
}
}
_shift_count = count;
}
/**
* pObtain the value for the specified BitField,
Re: [lang] RC3 util package UUID issue
With 4 +1's, I've moved BitField and Validate up to the main package and have added the util package to my list of directories I remove before tagging. Ignoring whether we call it id, identifiers or whatever as simply removing util from builds matches my needs. Hen On Tue, 19 Aug 2003, Stephen Colebourne wrote: The discussion over UUID makes me nervous. It has been suggested that UUID, together with the rest of the id stuff goes into a new identifier subpackage. This makes sense. However, it is unreasonable of us to release a new package, and then deprecate it in the next release (2.1). It also raises the question of whether the other two util package classes (BitField and Validate) should be in the main lang package instead. (What does util mean?) Solutions: 1) Release as is, we can't predict the future 2) Don't release entire util subpackage 3) Delete util subpackage. Move BitField and Validate to main lang package. Create identifier subpackage for ids. Release 2.0. 4) Delete util subpackage. Move BitField and Validate to main lang package. Release 2.0 without ids. IMHO #1 may tie us to a util subpackage, which I don't like, so #2 is better. #3 is good, but I prefer #4 overall while ids are up in the air - it gives us more design flexibility. Stephen (who is now getting very tired of 2.0...) - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.apache.org/~bayard/commons-lang-2.0-rc3/ Changes I know of: Some javadoc WordWrapUtils fixed, renamed to WordUtils and with some of StringUtils code All .zip files should have text files in DOS CRLF format I'm sure there were other ones though. Let's give these a couple of days to see if anyone has any problems with them. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang AllLangTestSuite.java
bayard 2003/08/18 19:38:56 Modified:lang/src/test/org/apache/commons/lang AllLangTestSuite.java Log: Removed UtilTestSuite Revision ChangesPath 1.3 +1 -3 jakarta-commons/lang/src/test/org/apache/commons/lang/AllLangTestSuite.java Index: AllLangTestSuite.java === RCS file: /home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/AllLangTestSuite.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- AllLangTestSuite.java 18 Aug 2003 02:22:25 - 1.2 +++ AllLangTestSuite.java 19 Aug 2003 02:38:56 - 1.3 @@ -63,7 +63,6 @@ import org.apache.commons.lang.exception.ExceptionTestSuite; import org.apache.commons.lang.math.MathTestSuite; import org.apache.commons.lang.time.TimeTestSuite; -import org.apache.commons.lang.util.UtilTestSuite; /** * Test suite for [lang]. @@ -99,7 +98,6 @@ suite.addTest(ExceptionTestSuite.suite()); suite.addTest(MathTestSuite.suite()); suite.addTest(TimeTestSuite.suite()); -suite.addTest(UtilTestSuite.suite()); return suite; } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang RELEASE-NOTES.txt
bayard 2003/08/18 19:39:59 Modified:lang RELEASE-NOTES.txt Log: Moved BitField and Validate. Will rebuild the jardiff later. Revision ChangesPath 1.26 +3 -6 jakarta-commons/lang/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt === RCS file: /home/cvs/jakarta-commons/lang/RELEASE-NOTES.txt,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- RELEASE-NOTES.txt 19 Aug 2003 00:21:46 - 1.25 +++ RELEASE-NOTES.txt 19 Aug 2003 02:39:59 - 1.26 @@ -32,6 +32,7 @@ lang package: ArrayUtils +BitField BooleanUtils CharRange (previously package scoped) ClassUtils @@ -43,6 +44,7 @@ NullArgumentException SerializationException UnhandledException +Validate math sub-package: @@ -62,11 +64,6 @@ FastDateFormat DateUtils StopWatch - -util sub-package: -BitField -IdentifierUtils -Validate Since the release of the 1.0 package the following classes have been changed: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang STATUS.html
bayard 2003/08/18 19:40:47 Modified:lang STATUS.html Log: Moved BitField/Validate Revision ChangesPath 1.47 +3 -8 jakarta-commons/lang/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons/lang/STATUS.html,v retrieving revision 1.46 retrieving revision 1.47 diff -u -r1.46 -r1.47 --- STATUS.html 18 Aug 2003 02:38:02 - 1.46 +++ STATUS.html 19 Aug 2003 02:40:47 - 1.47 @@ -28,6 +28,7 @@ listrongMain package/strong - A package for the manipulation of basic Java classes ul listrongArrayUtils/strong - Helper for manipulating arrays./li + listrongBitField/strong - A class to assist with manipulating bits./li listrongBooleanUtils/strong - Helper for boolean and java.lang.Boolean./li listrongCharRange/strong - A range of characters./li listrongCharSetUtils/strong - Methods for dealing with CharSets, which are sets of characters such as [a-z] and [abcdez]./li @@ -39,6 +40,7 @@ listrongStringUtils/strong - Helper for java.lang.String./li listrongSystemUtils/strong - Utility class defining the Java system properties./li listrongWordUtils/strong - Utility for working with words./li + listrongValidate/strong - A class to simplify method argument validation./li /ul/li listrongBuilder package/strong - A package for the creation of equals, hashCode, compareTo and toString methods. @@ -80,13 +82,6 @@ !--listrongDurationFormatUtils/strong - Formats durations, represented by milliseconds./li-- listrongFastDateFormat/strong - Optimised version of SimpleDateFormat./li listrongStopWatch/strong - Records durations, represented by milliseconds./li -/ul/li - -listrongUtil package/strong - A package for common useful utilities. -ul - listrongBitField/strong - A class to assist with manipulating bits./li - listrongIdentifierUtils/strong - Implementation of various identifier factories./li - listrongValidate/strong - A class to simplify method argument validation./li /ul/li /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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]
HttpClient slowness
We're noticing around a 150ms overhead and ALL calls (GETs, POSTs, etc) when using HTTPClient (tried everything between 2.0 alpha 3 and 2.0 RC1). The strange thing is that sometimes those overheads drop down to 5ms, which is much better and what we expect. Unfortunately, we haven't been able to pinpoint _why_ those drops take place yet. We've played with various app servers (Resin 2.x and Tomcat 4.1.x), using various connectors and connection pools, and nothing seems to help out here. We're using HTTP 1.1 and keep alives, and the server and client are on the same machine so network latency is not an issue. If I use nogoop's HTTP Client or even the JDK's URLConnection, I can get responses back around 5ms like I'd expect. Has anyone experienced something like this? Any thoughts as to what is going on with HTTPClient? -Pat
Re: HttpClient slowness
Hi Pat, There are a couple of possibilities. Most likely one of the following is happening: - You are experiencing a known slowdown due to HttpConnection.isStale(). This causes a constant slowdown for every method execution. This is to ensure that a connection is still open before it is used. It seems to effect some platforms more than others. It can be disabled in each of the two connections managers by setting connectionStaleCheckingEnabled to false. - You are using a 1.4.0_xx JVM. There is a known bug in 1.4.0 JVMs using socket timeouts. http://developer.java.sun.com/developer/bugParade/bugs/4512028.html - You are using HTTPS in a pre 1.4 JVM. Again HttpConnection.isStale() is the culprit. Sun JVMs 1.4 force the connection to be closed after calling isStale(). This means connections must be opened for each method execution. Mike On Monday, August 18, 2003, at 07:42 PM, Patrick Lightbody wrote: We're noticing around a 150ms overhead and ALL calls (GETs, POSTs, etc) when using HTTPClient (tried everything between 2.0 alpha 3 and 2.0 RC1). The strange thing is that sometimes those overheads drop down to 5ms, which is much better and what we expect. Unfortunately, we haven't been able to pinpoint _why_ those drops take place yet. We've played with various app servers (Resin 2.x and Tomcat 4.1.x), using various connectors and connection pools, and nothing seems to help out here. We're using HTTP 1.1 and keep alives, and the server and client are on the same machine so network latency is not an issue. If I use nogoop's HTTP Client or even the JDK's URLConnection, I can get responses back around 5ms like I'd expect. Has anyone experienced something like this? Any thoughts as to what is going on with HTTPClient? -Pat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|FIXED | Version|Nightly Builds |2.0 Alpha 3 --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 03:46 --- I received the following expiry date in SetCookie which DateParser v1.3 (from rc1) cannot handle: expires=Mon, 18-08-2013 16:19:55 GMT It uses numeric month value instead of the abbreviated form. It is, I'm not sure if it is related, from a Microsoft-IIS/5.0 server. Is it possible to add EEE, dd-MM- HH:mm:ss z to DATE_PATTERNS? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
