Re: [VFS] 1.0 roadmap (was: Recent changes)
Hi Rahul! We can continue building (like we have been, in the nightlies for many months), but we can't release those Yes, I am aware of. Just a ready made jar for download would be great. (including a source jar - if we only could use m2 for this ;-) ) Yup, for m1 primarily. extras/ is often used to indicate stuff that might not be available in the core component, but can be obtained/integrated separately. Not sure if having a Commons sandbox and a per component sandbox might be any confusing, but I'm fine with that (if you really can't live with extras/ :-) I think, in contrast to extras/ the sandbox/ much more indicates that this stuff will not be release for what ever reason. extras/ is something like say tomahawk for myfaces where both have its own release cycles. Said that, we can have extras/ later if we dont want to bloat the core with all the filesystems, but I think then we might go the per-filesystem-jar way, no? So, well, I can live with extras/ but I prefer the sandbox/ :-) Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [i18n] [Fwd: Re: Commons - I18N - adding timezones and filtering]
Hi Armin,
although I know it is tedious to get another pointer, but patches should go to
JIRA: http://issues.apache.org/jira/browse/SANDBOX, that way they don't het
lost. Note, that you have to create an account for yourself, before you're able
to create an issue for SANDBOX.
- Jörg
Armin Häberling wrote on Saturday, August 05, 2006 3:39 PM:
Hi
I've implemented two little extensions for the Commons-i18n project
(See the mail below and the attached patch).
I'd like to see your comments on this.
Regards
Armin Häberling
Original Message
Subject: Re: Commons - I18N - adding timezones and filtering
Date: Sat, 5 Aug 2006 14:49:56 +0200
From: Oliver Zeigermann [EMAIL PROTECTED]
To: Armin Häberling [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], Ralf Hauser [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Hi Armin!
Thanks a lot for your patch. Would you mind resinding your complete
patch to the commons developer mailing list? This way everyone can
have a look at it and see if it fits into commons i18n.
Thanks a lot in advance and cheers
Oliver
2006/8/4, Armin Häberling [EMAIL PROTECTED]:
Hi
I've implemented two little extensions for the commons I18N project:
1) Timezone independence:
Currently dates as message arguments are only displayed in the
default time zone returned by the method TimeZone.getDefault().
I extended the MessageManager.getText() so that one can also choose
in which timezone Date arguments can be displayed.
In the current implementation the message template must contain a
date or time format so that the message is formated with the right
timezone. That means the template it's now {0} will not work,
whereas it's now {o,time} will work.
2) filtering of message arguments:
You may want to include String in message arguments that are
untrusted (i.e. user input). But when you display such a message on
a html site it may contain a javascript attack or other nasty
things. Otherwise if you want to store the message in an sql table
there are also attacks possible. Cause of this the arguments should
be filtered depending on later use of the message. For this I
created a new Filter Interface and extended the LocalizedBundle so
that you can attach a specific filter which filters the message
arguments before formating it. I also did two simple implementations
of specific filters.
I've attached a little patch with my changes. Any comments are
welcome.
Regards
Armin Häberling
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Kris Nuttycombe as committer?
+1 (non-binding) Henri Yandell wrote on Friday, August 04, 2006 11:25 PM: I'd like to nominate Kris as a committer. Kris has been active on the developer mailing list concerning the pipeline component for over a year, and has been involved on other threads as well (notably digester). I think he's been around long enough to have picked up the way of doing things and it'll be good for pipeline (and ultimately commons). [ ] +1 [ ] -1 Vote ends Wednesday 9th August. 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: [VOTE] Andrew Shirley as committer?
+1 (non-binding) Henri Yandell wrote on Friday, August 04, 2006 11:25 PM: I'd like to propose Andrew Shirley as a committer. Andrew's been doing tons for the CLI component - answering user questions, commenting on jira issues and serving up patches and unit tests to both his issues and other peoples issues. The only reason I've hesitated until recently is because CLI didn't have a clear direction (now it does). [ ] +1 [ ] -1 Vote ends Wednesday 9th August. 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]
[jira] Created: (SCXML-14) Allowing the target of a transition to be omitted
Allowing the target of a transition to be omitted - Key: SCXML-14 URL: http://issues.apache.org/jira/browse/SCXML-14 Project: Commons SCXML Issue Type: Bug Environment: Windows, JDK 1.4.2 Reporter: Sitthichai Rernglertpricha Priority: Minor Attachments: patchfile Currently, the runtime throws a ModelException if the target of a transition is not specified. E.g. the following throws a ModelException since the target next=.../ is omitted within the transition element. state id='s' transitionfiltered=xxx assign name=data expr=value /transition /state However, based on the scxml specification at http://www.w3.org/TR/scxml/ at section 3.3, quote - If the target on a transition is omitted, then taking the transition has the effect of leaving the machine in the same state after invoking any executable content that is included in the transition. The attached patch can be applied to the ModelUpdater.java to fix the above problem. Basically, the change is in the updateTransition() method. If next variable is null, return immediately from the method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCXML-15) User of SCXMLExecutor does not have access to the current context data
User of SCXMLExecutor does not have access to the current context data -- Key: SCXML-15 URL: http://issues.apache.org/jira/browse/SCXML-15 Project: Commons SCXML Issue Type: Improvement Environment: Windows, JDK 1.4.2 Reporter: Sitthichai Rernglertpricha Priority: Minor Currently, SCXMLExecutor does not provide method for client to get local variables associated with the Context of the current state. All created Context are maintained in the SCInstance object within the SCXMLExecutor class, and currently the getSCInstance() of SCXMLExecutor does not have any protected or public qualifier. Hence getSCInstance() cannot only be accessed by SCXMLExecutor or classes within the org.apache.commons.scxml package. Can we change getSCInstance() method to be protected or public ? This allows the client to call getSCInstance().getContext() to return the Context associated with the current state or create a child class of SCXMLExecutor that return variables associated with the current context. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429299 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Author: olegk Date: Mon Aug 7 03:51:29 2006 New Revision: 429299 URL: http://svn.apache.org/viewvc?rev=429299view=rev Log: [HTTPCLIENT-574]: Subclasses do not have write access to StatusLine Contributed by Caleb Lyness caleb_lyness at yahoo.com Modified: jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java Modified: jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java?rev=429299r1=429298r2=429299view=diff == --- jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java (original) +++ jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java Mon Aug 7 03:51:29 2006 @@ -108,7 +108,7 @@ private HeaderGroup requestHeaders = new HeaderGroup(); /** The Status-Line from the response. */ -private StatusLine statusLine = null; +protected StatusLine statusLine = null; /** Response headers, if any. */ private HeaderGroup responseHeaders = new HeaderGroup(); @@ -172,7 +172,7 @@ private static final int RESPONSE_WAIT_TIME_MS = 3000; /** HTTP protocol version used for execution of this method. */ -private HttpVersion effectiveVersion = null; +protected HttpVersion effectiveVersion = null; /** Whether the execution of this method has been aborted */ private transient boolean aborted = false; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Query
Hi, We are migrating one of our projects from Websphere Application Server 5.1.1.4 to 6.1 which would also be an upgrade on JVM 1.4 to JVM 1.5. Our project uses the Apache common project jars listed below with their versions. I was unable to find the relevant information on the website which emphasizes on any problems/pain points that these versions of jars would cause if migrated from JDK 1.4 to 1.5. Common-beanutils.jar 1.6 Common-collections.jar 2.1 Common-digester.jar 1.5 Common-fileupload.jar1.0 Common-lang.jar 1.0 Common-logging.jar 1.0.3 Common-validator.jar 1.0.2 Struts.jar 1.1 Xerces1_4_3.jar 1.4.3 Junit3_7.jar 3.7 Jakarta-regexp-1.2.jar 1.2 Please advice at your earliest convenience. Thanks and Rgds, Nitin CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[nightly build] discovery io net proxy failed.
Failed build logs: http://people.apache.org/~psteitz/commons-nightlies//20060807/discovery.log http://people.apache.org/~psteitz/commons-nightlies//20060807/io.log http://people.apache.org/~psteitz/commons-nightlies//20060807/net.log http://people.apache.org/~psteitz/commons-nightlies//20060807/proxy.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-154) MathUtils addAndCheck and subAndCheck for long values
[
http://issues.apache.org/jira/browse/MATH-154?page=comments#action_12426209 ]
Brent Worden commented on MATH-154:
---
Can we change it to subtractAndCheck?
Also, it might be useful to add two additional methods to just check for
operation safety and not throw an exception. This would be useful in the RNG
methods Remi proposed where all that was needed was whether or not an operation
was valid. This would avoid creating an expensive exception for simple case
logic.
MathUtils addAndCheck and subAndCheck for long values
-
Key: MATH-154
URL: http://issues.apache.org/jira/browse/MATH-154
Project: Commons Math
Issue Type: Improvement
Affects Versions: Nightly Builds, 1.1 Final
Reporter: Remi Arntzen
Fix For: 1.2 Final
public static long addAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).add(BigInteger.valueOf(y);
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
public static long subAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).subtract(BigInteger.valueOf(y));
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-153) RandomDataImpl nextInt(int, int) nextLong(long, long)
[ http://issues.apache.org/jira/browse/MATH-153?page=comments#action_12426210 ] Brent Worden commented on MATH-153: --- I think we can avoid the overflow conditions simply by distributing the multiplication of the random value. With this, the method body would become: double r = rand.nextDouble(); return (int)((r * upper) + ((1.0 - r) * lower) + r); RandomDataImpl nextInt(int, int) nextLong(long, long) - Key: MATH-153 URL: http://issues.apache.org/jira/browse/MATH-153 Project: Commons Math Issue Type: Bug Affects Versions: Nightly Builds, 1.1 Final Reporter: Remi Arntzen Priority: Critical Fix For: 1.2 Final RandomDataImpl.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE) suffers from overflow errors. change return lower + (int) (rand.nextDouble() * (upper - lower + 1)); to return (int) (lower + (long) (rand.nextDouble()*((long) upper - lower + 1))); additional checks must be made for the nextlong(long, long) method. At first I thought about using MathUtils.subAndCheck(long, long) but there is only an int version avalible, and the problem is that subAndCheck internaly uses long values to check for overflow just as my previous channge proposes. The only thing I can think of is using a BigInteger to check for the number of bits required to express the difference. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jci] configuration
I am currently trying to figure out the configuration part of jci ...and at the moment I am really torn apart which way to go. Usually I am one of those that likes static typing ...which is what the plexus compiler API (and the javac implementation of jci) uses. Having a configuration class with setters like settings.setVerbose(boolean) ...but looking at the native eclipse compiler implementation (which is just using a map) settings.put(settings.OPTION, settings.OPTION_VALUE) I am really tempted to go that way. The interface would be so much easier and way more extensible. The compilers could pick the options they need and warn about options they don't understand. As very often the configuration does not come from a statically typed resource anyway (like a xml or properties file) the static API might not even that convenient at all. Opinions? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-220) Serialization/Deserialization doesn't work well with empty buffers.
Serialization/Deserialization doesn't work well with empty buffers.
---
Key: COLLECTIONS-220
URL: http://issues.apache.org/jira/browse/COLLECTIONS-220
Project: Commons Collections
Issue Type: Bug
Components: Buffer
Affects Versions: 3.2
Reporter: Jose Luis Huertas
Priority: Minor
Attachments: SerializationTest.java
When I serialize the queue to disk an it has elements, all works ok, but when I
serialize an empty queue I have some problems when I create a new object using
the serialized file.
When I deserialize the queue it has a 'buffer' with size 1 (with null content),
'tail' and 'head' fields are 0 (they are declared transient). So, when I try to
add a new object to the queue, the sentence:
Object[] tmp = new Object[((buffer.length - 1) * 2) + 1];
Is executed in the add() method to increase the buffer length, but the buffer
remains with the same size! (buffer.length = 1 -- (1 - 1) * 2 + 1 = 1). So,
the object is added and when the tail is going to be incremented, it is reset
to 0!!
private int increment(int index) {
index++;
if (index = buffer.length) {
index = 0;
}
return index;
}
So it is impossible to add new elements after an empty queue has been
serialized / deserialized.
I attach a simple TestCase where this is proved. The example works when you use
XMLEncoder to serialize the buffer but doesn't work if you use
ObjectOutputStream or XStream.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Next steps
i would like to start a discussion about the next steps of [compress]. Now that the first code has been checked in, i would like to figure out what we have to do for a 0.1 release. Ideas: - - simplify the interface as Mario suggested +1 - - write the delete-features - - add recursivly files to the archivers +0 ...let's better straighten out the interfaces first - - refactor and rename old methods and types in the legacy classes IMO not required - it's still in the sandbox - - rebuild java doc? You mean the site? Is this enough for a 0.1 release? I think there is no such thing ...we are trying to work towards a 1.0. Up until that it would probably just be 1.0-SNAPSHOT. Btw, i am not thinking that [compress] is a good name for this component- it does archiving aswell. I like compress - people figure out what it does ...you cannot expect to cover everything with a name ;-) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] mvn errors
snip/ Will look into that ...hope Peters next submission will fix that ...if it might come along some day - haven't heart from him for a while :-( cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Andrew Shirley as committer?
+1 Ciao, Mario Henri Yandell schrieb: I'd like to propose Andrew Shirley as a committer. Andrew's been doing tons for the CLI component - answering user questions, commenting on jira issues and serving up patches and unit tests to both his issues and other peoples issues. The only reason I've hesitated until recently is because CLI didn't have a clear direction (now it does). [ ] +1 [ ] -1 Vote ends Wednesday 9th August. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- mfg Mario Ivankovits - OPS EDV Vertriebsges.m.b.H. Software Engineering Michael-Bernhard-Gasse 10, A-1120 Wien Tel.: +43-1-8938810 Fax: +43-1-8938810/3700 E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Kris Nuttycombe as committer?
+1 Ciao, Mario Henri Yandell schrieb: I'd like to nominate Kris as a committer. Kris has been active on the developer mailing list concerning the pipeline component for over a year, and has been involved on other threads as well (notably digester). I think he's been around long enough to have picked up the way of doing things and it'll be good for pipeline (and ultimately commons). [ ] +1 [ ] -1 Vote ends Wednesday 9th August. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- mfg Mario Ivankovits - OPS EDV Vertriebsges.m.b.H. Software Engineering Michael-Bernhard-Gasse 10, A-1120 Wien Tel.: +43-1-8938810 Fax: +43-1-8938810/3700 E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429391 - in /jakarta/commons/proper/cli/trunk/xdocs: index.xml issue-tracking.xml
Author: bayard Date: Mon Aug 7 10:09:33 2006 New Revision: 429391 URL: http://svn.apache.org/viewvc?rev=429391view=rev Log: Applying James Ring's commons-dev posted patch for the issue tracking page; we moved from Bugzilla to JIRA Modified: jakarta/commons/proper/cli/trunk/xdocs/index.xml jakarta/commons/proper/cli/trunk/xdocs/issue-tracking.xml Modified: jakarta/commons/proper/cli/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/xdocs/index.xml?rev=429391r1=429390r2=429391view=diff == --- jakarta/commons/proper/cli/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/cli/trunk/xdocs/index.xml Mon Aug 7 10:09:33 2006 @@ -70,9 +70,7 @@ so prefix your email by [cli]. /p p -Issues may be reported via a href=issue-tracking.htmlASF Bugzilla/a. -Please remember that Bugzilla is shared between all commons components, -so prefix your issue by [cli]. +Issues may be reported via a href=issue-tracking.htmlASF JIRA/a. /p /section !-- == -- Modified: jakarta/commons/proper/cli/trunk/xdocs/issue-tracking.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/xdocs/issue-tracking.xml?rev=429391r1=429390r2=429391view=diff == --- jakarta/commons/proper/cli/trunk/xdocs/issue-tracking.xml (original) +++ jakarta/commons/proper/cli/trunk/xdocs/issue-tracking.xml Mon Aug 7 10:09:33 2006 @@ -23,19 +23,18 @@ !-- == -- section name=Issue tracking p - Commons CLI uses a href=http://issues.apache.org/bugzilla/;ASF Bugzilla/a for tracking issues. - To use Bugzilla you may need to a href=http://issues.apache.org/bugzilla/createaccount.cgi;create an account/a. + Commons CLI uses a href=http://issues.apache.org/jira/;ASF JIRA/a for tracking issues. + To use JIRA you may need to a href=https://issues.apache.org/jira/secure/Signup!default.jspa;create an account/a. /p p If you would like to report a bug, or raise an enhancement request with Commons CLI please do the following: ol - lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_status=NEEDINFOamp;product=Commonsamp;component=CLI;Search existing open bugs/a. + lia href=https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=trueamp;mode=hideamp;pid=12310463amp;resolution=-1amp;sorter/field=updatedamp;sorter/order=DESC;Search existing open bugs/a. If you find your issue listed then please add a comment with your details./li lia href=http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/;Search the mailing list archive/a. You may find your issue or idea has already been discussed./li - lia href=http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commonsamp;component=CLIamp;version=1.0%20Finalamp;short_desc=%5Bcli%5D%20%22Your%20subject%20heading%20here%22amp;comment=Please%20provide%20details%20here.%20Its%20best%20to%20submit%20patches%20that%20alter%0D%0Aexisting%20file%20content%20in%20%22unified%20diff%22%20format.%20%0D%0A%0D%0ASubmissions%20that%20provide%20new%20files%20can%20be%20supplied%20as%20direct%20file%0D%0Aattachments%20or%20archives%20in%20zip%20or%20tar.gz%20format.%20please%20be%20kind%20%0D%0Aenough%20to%20identify%20the%20format%20of%20the%20attached%20archive%20as%20bugzilla%0D%0Atends%20to%20strip%20these%20characterstics%20by%20removing%20the%20files%20extension.;Submit a bug report or enhancement request/a. - Please prefix all new issues with [cli] in the summary line. + lia href=http://issues.apache.org/jira/browse/CLI;Submit a bug report or enhancement request/a. /li /ol /p @@ -45,14 +44,6 @@ lithe more information you provide, the better we can help you/li litest cases are vital, particularly for any proposed enhancements/li lithe developers of Commons CLI are all unpaid volunteers/li - /ul -/p -p - You may also find these links useful: - ul - lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_status=NEEDINFOamp;product=Commonsamp;component=CLI;All Open CLI bugs/a/li - lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;bug_status=VERIFIEDamp;bug_status=CLOSEDamp;product=Commonsamp;component=CLI;All Closed CLI bugs/a/li - lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_status=NEEDINFOamp;bug_status=RESOLVEDamp;bug_status=VERIFIEDamp;bug_status=CLOSEDamp;product=Commonsamp;component=CLI;All CLI bugs/a/li /ul /p /section - To unsubscribe, e-mail:
Re: [cli][PATCH] Update issue-tracking section
Applied (JIRA's a good place for these). svn ci -m Applying James Ring's commons-dev posted patch for the issue tracking page; we moved from Bugzilla to JIRA xdocs/index.xml xdocs/issue-tracking.xml Sendingxdocs/index.xml Sendingxdocs/issue-tracking.xml Transmitting file data .. Committed revision 429391. On 7/25/06, James Ring [EMAIL PROTECTED] wrote: Hi all, Just a minor thing: the CLI website still lists Bugzilla as the place to submit bug reports. The attached patch amends that. Thanks! Regards, James -- James Ring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confluence and Jira client libraries
On Aug 1, 2006, at 3:43 PM, David Blevins wrote: On Aug 1, 2006, at 12:53 PM, Stephen Colebourne wrote: David Blevins wrote: I made a couple libraries for manipulating Confluence and Jira via their XML-RPC front-ends. Currently, I have them sitting here: http://svn.codehaus.org/swizzle/trunk/swizzle-confluence/ http://svn.codehaus.org/swizzle/trunk/swizzle-jira/ Examples: http://docs.codehaus.org/display/SWIZZLE/Swizzle+Confluence http://docs.codehaus.org/display/SWIZZLE/Swizzle+Jira I created these libraries by generating them with perl based on the XML-RPC defs for the respective xml-rpc services. I'm thinking here might be a better home than my little project at Codehaus simply because at commons there'd be like 100+ people who'd have access to improve the library as opposed to just me. So anyway, is this something people would like? As a general rule its pretty hard to get existing code accepted into commons. I've generally come to the opinion now that if the code is good enough and theres a buzz about it, then the users will find you wherever you're at. Generally the code still needs work. It's generated code, so it's still rough but by far the best option out there for people who want a java client to either confluence or jira. I had to create it to get some work I was doing done. Being the kind of guy I am I decided it was about time someone just created a java version of the entire API rather than just the part they needed, so I did. But now I'm sitting on a heap of code that is way more than I personally need. It works well enough, but to really use it you're going to want access to the source. Status change: i beefed up the jira code tremendously over the weekend. It's now far beyond an simple Java version of the xmlrpc api. I added all sorts of caching, indexing, autofilling of issue data from other parts of jira (full status, priority, component, version, and other data), support for getting issues objects via rss as an alternate to xmlrpc, and an extra program jirareport that's an executable jar you run and pass in a velocity template as an argument. Definitely much more at the finished code side of the spectrum now, so I'll consider it off the table. Thanks, David -David - 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: Query
The only one that jumps to mind is that if you're using the 'enum' package in Lang, you'll want to move to the 'enums' package (which will mean moving to Lang 2.1). I recently attempted to build all of Commons under Java 6.0, and I don't recall any big problems, just a handful of little things. As far as I know things happily build under 1.4 and 1.5 with no complaints. Hen On 8/7/06, Nitin Saxena01 [EMAIL PROTECTED] wrote: Hi, We are migrating one of our projects from Websphere Application Server 5.1.1.4 to 6.1 which would also be an upgrade on JVM 1.4 to JVM 1.5. Our project uses the Apache common project jars listed below with their versions. I was unable to find the relevant information on the website which emphasizes on any problems/pain points that these versions of jars would cause if migrated from JDK 1.4 to 1.5. Common-beanutils.jar 1.6 Common-collections.jar 2.1 Common-digester.jar 1.5 Common-fileupload.jar1.0 Common-lang.jar 1.0 Common-logging.jar 1.0.3 Common-validator.jar 1.0.2 Struts.jar 1.1 Xerces1_4_3.jar 1.4.3 Junit3_7.jar 3.7 Jakarta-regexp-1.2.jar 1.2 Please advice at your earliest convenience. Thanks and Rgds, Nitin CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - 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]
[lang] ExceptionUtilsTestCase should not depend on Java 1.4.x
Hi All: When I have the compiler set to Java 1.3.1, I get: Severity and DescriptionPathResourceLocation Creation Time Id The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1351153767000812 14290961 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1361153767000812 14290965 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1691153767000812 14290993 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 2691153767000812 14291025 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 3161153767000812 14291026 Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] ExceptionUtilsTestCase should not depend on Java 1.4.x
Just got to get a working 1.3 so I can confirm :) Pretty sad when the Sun 1.3 Linux dist fails to work due to glibc incompatibility of some kind. Hen On 8/7/06, Gary Gregory [EMAIL PROTECTED] wrote: Hi All: When I have the compiler set to Java 1.3.1, I get: Severity and DescriptionPathResourceLocation Creation Time Id The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1351153767000812 14290961 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1361153767000812 14290965 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1691153767000812 14290993 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 2691153767000812 14291025 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 3161153767000812 14291026 Gary - 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: Confluence and Jira client libraries
On Aug 4, 2006, at 10:18 AM, Henri Yandell wrote: I'm quite interested in the project btw - am doing Ruby xmlrpc at the moment to JIRA so already in the domain. Would be cool to use Swizzle to build the Commons Triage pages I've been scraping. I don't know what Commons Triage is, do you have a link to these pages? -David 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]
svn commit: r429413 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: builder/ exception/ math/ time/
Author: ggregory
Date: Mon Aug 7 10:57:25 2006
New Revision: 429413
URL: http://svn.apache.org/viewvc?rev=429413view=rev
Log:
Adds missing serialVersionUID to Serializable classes.
A note from
http://wiki.eclipse.org/index.php/FAQ_Why_does_the_Eclipse_compiler_create_a_different_serialVersionUID_from_javac%3F:
If you don’t explicitly define a serialVersionUID, the language requires that
the VM generate one, using some function of all field and method names in the
class. The problem is, the compiler generates some synthetic methods that you
never see in your source file, and there is no clear specification for how
these synthetic method names are generated. Any two compilers are likely to
generate different method names, and so the serialVersionUID will be different.
Bottom line: Always define the serialVersionUID explicitly in your source files.
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/StandardToStringStyle.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableError.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableRuntimeException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/JVMRandom.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/time/FastDateFormat.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/StandardToStringStyle.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/StandardToStringStyle.java?rev=429413r1=429412r2=429413view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/StandardToStringStyle.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/StandardToStringStyle.java
Mon Aug 7 10:57:25 2006
@@ -32,6 +32,8 @@
*/
public class StandardToStringStyle extends ToStringStyle {
+private static final long serialVersionUID = 1L;
+
/**
* pConstructor./p
*/
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java?rev=429413r1=429412r2=429413view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
Mon Aug 7 10:57:25 2006
@@ -1981,6 +1981,8 @@
*/
private static final class DefaultToStringStyle extends ToStringStyle {
+private static final long serialVersionUID = 1L;
+
/**
* pConstructor./p
*
@@ -2012,6 +2014,8 @@
*/
private static final class NoFieldNameToStringStyle extends ToStringStyle {
+private static final long serialVersionUID = 1L;
+
/**
* pConstructor./p
*
@@ -2044,6 +2048,8 @@
*/
private static final class ShortPrefixToStringStyle extends ToStringStyle {
+private static final long serialVersionUID = 1L;
+
/**
* pConstructor./p
*
@@ -2074,6 +2080,8 @@
*/
private static final class SimpleToStringStyle extends ToStringStyle {
+private static final long serialVersionUID = 1L;
+
/**
* pConstructor./p
*
@@ -2107,6 +2115,8 @@
* codeStandardToStringStyle/code to ensure its immutability./p
*/
private static final class MultiLineToStringStyle extends ToStringStyle {
+
+private static final long serialVersionUID = 1L;
/**
* pConstructor./p
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java?rev=429413r1=429412r2=429413view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
Mon Aug 7 10:57:25 2006
@@ -45,6 +45,8 @@
*/
public class NestableDelegate implements Serializable {
+private static final long
Re: Confluence and Jira client libraries
On 8/7/06, David Blevins [EMAIL PROTECTED] wrote: On Aug 4, 2006, at 10:18 AM, Henri Yandell wrote: I'm quite interested in the project btw - am doing Ruby xmlrpc at the moment to JIRA so already in the domain. Would be cool to use Swizzle to build the Commons Triage pages I've been scraping. I don't know what Commons Triage is, do you have a link to these pages? http://www.featheredblogs.org/commons/triage.html JIRA filters don't work well across many projects (you lose too many options), so this is just a list of the unversioned issues from Commons projects that have been cleaned up. Idea being that you can look at that page (or an email that'll get sent to the list) to see what issues need to be looked at. Hen Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429421 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums: Enum.java ValuedEnum.java
Author: ggregory
Date: Mon Aug 7 11:14:27 2006
New Revision: 429421
URL: http://svn.apache.org/viewvc?rev=429421view=rev
Log:
The Javadoc comment Lang version 1.0.1 serial compatibility is incorrect
since these classes came into existance in version 2.1.
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java?rev=429421r1=429420r2=429421view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
Mon Aug 7 11:14:27 2006
@@ -234,7 +234,11 @@
*/
public abstract class Enum implements Comparable, Serializable {
-/** Lang version 1.0.1 serial compatibility */
+/**
+ * Required for serialization support.
+ *
+ * @see java.io.Serializable
+ */
private static final long serialVersionUID = -487045951170455942L;
// After discussion, the default size for HashMaps is used, as the
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java?rev=429421r1=429420r2=429421view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
Mon Aug 7 11:14:27 2006
@@ -102,7 +102,11 @@
*/
public abstract class ValuedEnum extends Enum {
-/** Lang version 1.0.1 serial compatibility */
+/**
+ * Required for serialization support.
+ *
+ * @see java.io.Serializable
+ */
private static final long serialVersionUID = -7129650521543789085L;
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-235) nested exceptions are displayed incorrectly with JellyException
[
http://issues.apache.org/jira/browse/JELLY-235?page=comments#action_12426279 ]
Jesse Glick commented on JELLY-235:
---
On a related note: the logic for extracting a detail message from the cause is
not very helpful. Example: in my servlet error page I see
---%---
exception
javax.servlet.ServletException: file:/[].jelly:6:66: j:forEach
org/apache/commons/collections/iterators/ArrayIterator
[]
root cause
org.apache.commons.jelly.JellyTagException: file:/[].jelly:6:66:
j:forEach org/apache/commons/collections/iterators/ArrayIterator
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[.]
note The full stack trace of the root cause is available in the Apache
Tomcat/5.5.17 logs.
---%---
Hmm. Not very informative. What is wrong with ArrayIterator? Not of the right
type? Hard to guess. Need to go look at the server logs, where I see
---%---
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/collections/iterators/ArrayIterator
at
org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsIterator(ExpressionSupport.java:106)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:89)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
---%---
Now that immediately tells me what is going on. The crucial info is the
exception class name: NoClassDefFoundError.
The problem in Jelly is here:
---%---
public JellyException(Throwable cause, String fileName, String elementName, int
columnNumber, int lineNumber) {
this(cause.getLocalizedMessage(), cause, fileName, elementName,
columnNumber, lineNumber);
}
public JellyException(String reason, Throwable cause, String fileName, String
elementName, int columnNumber, int lineNumber) {
super( (reason==null?cause.getClass().getName():reason) );
//
---%---
A NCDFE has as its message (and, by default, also its localizedMessage) the
class name that could not be found. Since reason != null, that is used as the
detail message also for the JellyException. But this is not as informative as
it should be.
I would therefore recommend changing the code to e.g.
---%---
public JellyException(Throwable cause, String fileName, String elementName, int
columnNumber, int lineNumber) {
this(cause.toString(), cause, fileName, elementName, columnNumber,
lineNumber);
}
public JellyException(String reason, Throwable cause, String fileName, String
elementName, int columnNumber, int lineNumber) {
super( (reason==null?cause.toString():reason) );
//
---%---
This would ensure that by default, the exception detail message shown in the
web page includes *both* the detail message and class name of the original
exception.
nested exceptions are displayed incorrectly with JellyException
---
Key: JELLY-235
URL: http://issues.apache.org/jira/browse/JELLY-235
Project: Commons Jelly
Issue Type: Improvement
Components: core / taglib.core
Affects Versions: 1.0
Reporter: Kohsuke Kawaguchi
Attachments: JELLY.diff
JellyException has some built-in support for nested exceptions. In
particular, when it displays a stack trace, it tries to also displays the
nested exception, which is great.
What's not so great is that when JDK 1.4 added this on its own, both Jelly
and JDK try to display the nested exceptions, and you ended up seeing O(n^2)
stack traces for n-level nested exception.
Imagine a situation where N JellyExceptions are nested inside each other.
With the following current printStackTrace:
{code}
public void printStackTrace() {
super.printStackTrace();
if (cause != null) {
System.out.println(Root cause);
cause.printStackTrace();
}
}
{code}
Outer JellyException prints its stack trace first (in which JDK prints out
all the nested exceptions),
and then JellyException prints the stack trace of the inner JellyException.
Then this same step is repeatedly, causing an output like this:
{noformat}
JellyExpception 3
Caused by JellyException 2
Caused by JellyException 1
Root cause:
JellyException 2
Caused by JellyException 1
Root cause:
JellyException 1
{noformat}
See the attached patch for one possible fix.
Personally, I don't mind if JellyException choose to completely stop trying
to print out the nested exception on its own, and simply delegate everything
to JDK. This will make the output worse on JDK 1.3 and earlier, but the # of
people using those is shrinking every day.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more
svn commit: r429433 - in /jakarta/commons/sandbox/finder/trunk: project.xml src/java/org/apache/commons/finder/Finder.java src/java/org/apache/commons/finder/filters/EmptyFilter.java
Author: bayard Date: Mon Aug 7 12:08:27 2006 New Revision: 429433 URL: http://svn.apache.org/viewvc?rev=429433view=rev Log: Moving the dependency from IO 1.2 to IO 1.3-SNAPSHOT (do a maven jar:install in commons-io). Can't move to the nightlies as they're not there (io is failing, need to improve the script so it keeps the old snapshot around). Also changed to depend on 1.3's EmptyFilter to prove that the dependency move is working. Removed: jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/filters/EmptyFilter.java Modified: jakarta/commons/sandbox/finder/trunk/project.xml jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Finder.java Modified: jakarta/commons/sandbox/finder/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/sandbox/finder/trunk/project.xml?rev=429433r1=429432r2=429433view=diff == --- jakarta/commons/sandbox/finder/trunk/project.xml (original) +++ jakarta/commons/sandbox/finder/trunk/project.xml Mon Aug 7 12:08:27 2006 @@ -72,7 +72,7 @@ dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId - version1.2/version + version1.3-SNAPSHOT/version urlhttp://jakarta.apache.org/commons/io//url /dependency dependency Modified: jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Finder.java URL: http://svn.apache.org/viewvc/jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Finder.java?rev=429433r1=429432r2=429433view=diff == --- jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Finder.java (original) +++ jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Finder.java Mon Aug 7 12:08:27 2006 @@ -19,7 +19,7 @@ import java.util.Map; import org.apache.commons.finder.filters.CanReadFilter; import org.apache.commons.finder.filters.CanWriteFilter; -import org.apache.commons.finder.filters.EmptyFilter; +import org.apache.commons.io.filefilter.EmptyFileFilter; import org.apache.commons.finder.filters.HiddenFilter; import org.apache.commons.io.filefilter.DirectoryFileFilter; @@ -48,8 +48,8 @@ public static final String TIME = TIME; // size based tests -public static final IOFileFilter EMPTY = EmptyFilter.EMPTY; -public static final IOFileFilter NOT_EMPTY = EmptyFilter.NOT_EMPTY; +public static final IOFileFilter EMPTY = EmptyFileFilter.EMPTY; +public static final IOFileFilter NOT_EMPTY = EmptyFileFilter.NOT_EMPTY; public static final String SIZE = SIZE; // name based tests - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429439 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: ./ builder/ enum/ exception/ math/ mutable/ text/ time/
Author: ggregory
Date: Mon Aug 7 12:14:31 2006
New Revision: 429439
URL: http://svn.apache.org/viewvc?rev=429439view=rev
Log:
Javadoc comments for serialVersionUID.
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharSet.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/IllegalClassException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/IncompleteArgumentException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/NotImplementedException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/NullArgumentException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ObjectUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/SerializationException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/UnhandledException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/StandardToStringStyle.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableError.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableRuntimeException.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/DoubleRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/FloatRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/Fraction.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/IntRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/JVMRandom.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/LongRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/NumberRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableBoolean.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableByte.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableDouble.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableFloat.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableInt.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableLong.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableObject.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableShort.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/CompositeFormat.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrBuilder.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/time/FastDateFormat.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharRange.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharRange.java?rev=429439r1=429438r2=429439view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharRange.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharRange.java
Mon Aug 7 12:14:31 2006
@@ -31,7 +31,11 @@
*/
public final class CharRange implements Serializable {
-/** Serialization lock, Lang version 2.0. */
+/**
+ * Required for serialization support. Lang version 2.0.
+ *
+ * @see java.io.Serializable
+ */
private static final long serialVersionUID = 8270183163158333422L;
/** The first character, inclusive, in the range. */
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharSet.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharSet.java?rev=429439r1=429438r2=429439view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharSet.java
(original)
+++
svn commit: r429441 - /jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
Author: dennisl
Date: Mon Aug 7 12:19:12 2006
New Revision: 429441
URL: http://svn.apache.org/viewvc?rev=429441view=rev
Log:
Set EOL-style to native.
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
(contents, props changed)
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java?rev=429441r1=429440r2=429441view=diff
==
---
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
(original)
+++
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
Mon Aug 7 12:19:12 2006
@@ -1,172 +1,172 @@
-/*
- * Copyright 2001-2006 The Apache Software Foundation
- *
- * Licensed under the Apache License, Version 2.0 (the License);
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an AS IS BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.commons.net.ftp.parser;
-
-import java.text.ParseException;
-
-import org.apache.commons.net.ftp.FTPClientConfig;
-import org.apache.commons.net.ftp.FTPFile;
-
-/**
- * Implementation of FTPFileEntryParser and FTPFileListParser for Netware
Systems. Note that some of the proprietary
- * extensions for Novell-specific operations are not supported. See
- * a
href=http://www.novell.com/documentation/nw65/index.html?page=/documentation/nw65/ftp_enu/data/fbhbgcfa.html;http://www.novell.com/documentation/nw65/index.html?page=/documentation/nw65/ftp_enu/data/fbhbgcfa.html/a
- * for more details.
- *
- * @author a href=[EMAIL PROTECTED]Rory Winston/a
- * @see org.apache.commons.net.ftp.FTPFileEntryParser FTPFileEntryParser (for
usage instructions)
- * @version $Id$
- */
-public class NetwareFTPEntryParser extends ConfigurableFTPFileEntryParserImpl {
-
- /**
-* Default date format is e.g. Feb 22 2006
-*/
- private static final String DEFAULT_DATE_FORMAT = MMM dd ;
-
- /**
-* Default recent date format is e.g. Feb 22 17:32
-*/
- private static final String DEFAULT_RECENT_DATE_FORMAT = MMM dd HH:mm;
-
- /**
-* this is the regular expression used by this parser.
-* Example: d [-W---F--] SCION_VOL2512 Apr 13
23:12 VOL2
-*/
- private static final String REGEX = (d|-){1}\\s+ //
Directory/file flag
- + \\[(.*)\\]\\s+ // Attributes
- + (\\S+)\\s+ + (\\d+)\\s+ // Owner and
size
- + (\\S+\\s+\\S+\\s+((\\d+:\\d+)|(\\d{4}))) //
Long/short date format
- + \\s+(.*); // Filename
(incl. spaces)
-
- /**
-* The default constructor for a NetwareFTPEntryParser object.
-*
-* @exception IllegalArgumentException
-* Thrown if the regular expression is unparseable. Should not be seen
-* under normal conditions. It it is seen, this is a sign that
-* codeREGEX/code is not a valid regular expression.
-*/
- public NetwareFTPEntryParser() {
- this(null);
- }
-
- /**
-* This constructor allows the creation of an NetwareFTPEntryParser
object
-* with something other than the default configuration.
-*
-* @param config The [EMAIL PROTECTED] FTPClientConfig configuration}
object used to
-* configure this parser.
-* @exception IllegalArgumentException
-* Thrown if the regular expression is unparseable. Should not be seen
-* under normal conditions. It it is seen, this is a sign that
-* codeREGEX/code is not a valid regular expression.
-* @since 1.4
-*/
- public NetwareFTPEntryParser(FTPClientConfig config) {
- super(REGEX);
- configure(config);
- }
-
- /**
-* Parses a line of an NetwareFTP server file listing and converts it
into a
-* usable format in the form of an code FTPFile /code instance. If
the
-* file listing line doesn't describe a file, code null /code is
-* returned, otherwise a code FTPFile /code instance representing
the
-* files in the directory is returned.
-* p
-* p
-* Netware file permissions are
svn commit: r429442 - /jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
Author: dennisl
Date: Mon Aug 7 12:22:24 2006
New Revision: 429442
URL: http://svn.apache.org/viewvc?rev=429442view=rev
Log:
Remove the use of Java 1.5 specific metods.
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java?rev=429442r1=429441r2=429442view=diff
==
---
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
(original)
+++
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.java
Mon Aug 7 12:22:24 2006
@@ -142,11 +142,11 @@
// Now set the permissions (or at least a subset
thereof - full permissions would probably require
// subclassing FTPFile and adding extra metainformation
there)
- if (attrib.contains(R)) {
+ if (attrib.indexOf(R) != -1) {
f.setPermission(FTPFile.USER_ACCESS,
FTPFile.READ_PERMISSION,
true);
}
- if (attrib.contains(W)) {
+ if (attrib.indexOf(W) != -1) {
f.setPermission(FTPFile.USER_ACCESS,
FTPFile.WRITE_PERMISSION,
true);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[commons-net ftp] help! can I avoid oro.jar? (MalformedPatternException)
Hello, I am getting this error during a call to FTPFile[] f = FTPClient.listFiles(); Using commons-net-1.4.1 I googled and read that the oro.jar is missing. However my application is sensitive to download times and I dont wish to add the oro.jar if possible - I am not using regex here. Is there any way out? thanks, Anil === Exception in thread main java.lang.NoClassDefFoundError: org/apache/oro/text/regex/MalformedPatternException at org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createUnixFTPEntryParser(DefaultFTPFileEntryParserFactory.java:169) at org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:94) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2358) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2188) === Any help appreciated. thanks, anil __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-net ftp] help! can I avoid oro.jar? (MalformedPatternException)
I'm afraid it's the obvious one - check the code out and modify bits. Alternatively, take an oro jar and rip out the bits that are being used (maybe using Torsten's minijar). Hen On 8/7/06, Anil Philip [EMAIL PROTECTED] wrote: Hello, I am getting this error during a call to FTPFile[] f = FTPClient.listFiles(); Using commons-net-1.4.1 I googled and read that the oro.jar is missing. However my application is sensitive to download times and I dont wish to add the oro.jar if possible - I am not using regex here. Is there any way out? thanks, Anil === Exception in thread main java.lang.NoClassDefFoundError: org/apache/oro/text/regex/MalformedPatternException at org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createUnixFTPEntryParser(DefaultFTPFileEntryParserFactory.java:169) at org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:94) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2358) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2188) === Any help appreciated. thanks, anil __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429474 - in /jakarta/commons/proper/fileupload/trunk: src/java/org/apache/commons/fileupload/ src/java/org/apache/commons/fileupload/util/ src/test/org/apache/commons/fileupload/ xdocs/
Author: jochen
Date: Mon Aug 7 13:54:54 2006
New Revision: 429474
URL: http://svn.apache.org/viewvc?rev=429474view=rev
Log:
It is now possible to limit a files actual size, as opposed to the request size.
PR: FILEUPLOAD-88
Permitted-by: Andrey Aristarkhov, [EMAIL PROTECTED]
Added:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Closeable.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/LimitedInputStream.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/FileUploadTestCase.java
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/SizesTest.java
jakarta/commons/proper/fileupload/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java?rev=429474r1=429473r2=429474view=diff
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
Mon Aug 7 13:54:54 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2001-2005 The Apache Software Foundation
+ * Copyright 2001-2006 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -15,7 +15,6 @@
*/
package org.apache.commons.fileupload;
-import java.io.FilterInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.UnsupportedEncodingException;
@@ -27,8 +26,10 @@
import javax.servlet.http.HttpServletRequest;
-import org.apache.commons.fileupload.servlet.ServletRequestContext;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
+import org.apache.commons.fileupload.servlet.ServletRequestContext;
+import org.apache.commons.fileupload.util.Closeable;
+import org.apache.commons.fileupload.util.LimitedInputStream;
/**
@@ -150,11 +151,16 @@
/**
- * The maximum size permitted for an uploaded file. A value of -1 indicates
- * no maximum.
+ * The maximum size permitted for the complete request, as opposed to
+ * [EMAIL PROTECTED] #fileSizeMax}. A value of -1 indicates no maximum.
*/
private long sizeMax = -1;
+/**
+ * The maximum size permitted for a single uploaded file, as opposed
+ * to [EMAIL PROTECTED] #sizeMax}. A value of -1 indicates no maximum.
+ */
+private long fileSizeMax = -1;
/**
* The content encoding to use when reading part headers.
@@ -186,9 +192,11 @@
/**
- * Returns the maximum allowed upload size.
+ * Returns the maximum allowed size of a complete request, as opposed
+ * to [EMAIL PROTECTED] #getFileSizeMax()}.
*
- * @return The maximum allowed size, in bytes.
+ * @return The maximum allowed size, in bytes. The default value of
+ * -1 indicates, that there is no limit.
*
* @see #setSizeMax(long)
*
@@ -199,9 +207,11 @@
/**
- * Sets the maximum allowed upload size. If negative, there is no maximum.
+ * Sets the maximum allowed size of a complete request, as opposed
+ * to [EMAIL PROTECTED] #setFileSizeMax(long)}.
*
- * @param sizeMax The maximum allowed size, in bytes, or -1 for no maximum.
+ * @param sizeMax The maximum allowed size, in bytes. The default value of
+ * -1 indicates, that there is no limit.
*
* @see #getSizeMax()
*
@@ -210,6 +220,25 @@
this.sizeMax = sizeMax;
}
+/**
+ * Returns the maximum allowed size of a single uploaded file,
+ * as opposed to [EMAIL PROTECTED] #getSizeMax()}.
+ *
+ * @see #setFileSizeMax(long)
+ */
+public long getFileSizeMax() {
+ return fileSizeMax;
+}
+
+/**
+ * Sets the maximum allowed size of a single uploaded file,
+ * as opposed to [EMAIL PROTECTED] #getSizeMax()}.
+ *
+ * @see #getFileSizeMax()
+ */
+public void setFileSizeMax(long fileSizeMax) {
+ this.fileSizeMax = fileSizeMax;
+}
/**
* Retrieves the character encoding used when reading the headers of an
@@ -520,7 +549,7 @@
private class FileItemStreamImpl implements FileItemStream {
private final String contentType, fieldName, name;
private final boolean formField;
-
svn commit: r429476 - in /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload: FileUploadBase.java MultipartStream.java StreamUtil.java util/Streams.java
Author: jochen
Date: Mon Aug 7 14:01:10 2006
New Revision: 429476
URL: http://svn.apache.org/viewvc?rev=429476view=rev
Log:
Moved some new stuff to the util package.
Added:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
Removed:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/StreamUtil.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java?rev=429476r1=429475r2=429476view=diff
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
Mon Aug 7 14:01:10 2006
@@ -30,6 +30,7 @@
import org.apache.commons.fileupload.servlet.ServletRequestContext;
import org.apache.commons.fileupload.util.Closeable;
import org.apache.commons.fileupload.util.LimitedInputStream;
+import org.apache.commons.fileupload.util.Streams;
/**
@@ -334,7 +335,7 @@
item.getContentType(), item.isFormField(),
item.getName());
try {
-StreamUtil.copy(item.openStream(),
fileItem.getOutputStream(),
+Streams.copy(item.openStream(), fileItem.getOutputStream(),
true, buffer);
} catch (FileUploadIOException e) {
throw (FileUploadException) e.getCause();
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java?rev=429476r1=429475r2=429476view=diff
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Mon Aug 7 14:01:10 2006
@@ -22,6 +22,7 @@
import java.io.UnsupportedEncodingException;
import org.apache.commons.fileupload.util.Closeable;
+import org.apache.commons.fileupload.util.Streams;
/**
* p Low level API for processing file uploads.
@@ -519,7 +520,7 @@
throws MalformedStreamException,
IOException {
final InputStream istream = newInputStream();
-return (int) StreamUtil.copy(istream, output, false);
+return (int) Streams.copy(istream, output, false);
}
ItemInputStream newInputStream() {
Added:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java?rev=429476view=auto
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
(added)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
Mon Aug 7 14:01:10 2006
@@ -0,0 +1,132 @@
+package org.apache.commons.fileupload.util;
+
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
+
+import org.apache.commons.fileupload.FileItemStream;
+
+
+/** Utility class for working with streams.
+ */
+public class Streams {
+/**
+ * Copies the contents of the given [EMAIL PROTECTED] InputStream}
+ * to the given [EMAIL PROTECTED] OutputStream}. Shortcut for
+ * pre
+ * copy(pInputStream, pOutputStream, new byte[8192]);
+ * /pre
+ * @param pInputStream The input stream, which is being read.
+ * It is guaranteed, that [EMAIL PROTECTED] InputStream#close()} is called
+ * on the stream.
+ * @param pOutputStream The output stream, to which data should
+ * be written. May be null, in which case the input streams
+ * contents are simply discarded.
+ * @param pClose True guarantees, that [EMAIL PROTECTED]
OutputStream#close()}
+ * is called on the stream. False indicates, that only
+ * [EMAIL PROTECTED] OutputStream#flush()} should be called finally.
+ *
+ * @return Number of bytes, which have been copied.
+ */
+public static long copy(InputStream pInputStream,
+OutputStream pOutputStream,
Re: [commons-net ftp] help! can I avoid oro.jar? (MalformedPatternException)
Anil At the moment, you need oro in the classpath as it is used internally by the FTP parser. A later version of [net] will probbaly use the JDK 1.4+ regex facilities and preclude this, but for now, you do need it. Thanks Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Hello, I am getting this error during a call to FTPFile[] f = FTPClient.listFiles(); Using commons-net-1.4.1 I googled and read that the oro.jar is missing. However my application is sensitive to download times and I dont wish to add the oro.jar if possible - I am not using regex here. Is there any way out? thanks, Anil === Exception in thread main java.lang.NoClassDefFoundError: org/apache/oro/text/regex/MalformedPatternException at org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createUnixFTPEntryParser(DefaultFTPFileEntryParserFactory.java:169) at org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:94) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2358) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2188) === Any help appreciated. thanks, anil __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (COLLECTIONS-85) ReferenceMap clears bindings too early
[ http://issues.apache.org/jira/browse/COLLECTIONS-85?page=all ] Stephen Colebourne closed COLLECTIONS-85. - Fix Version/s: (was: 3.3) Resolution: Invalid ReferenceMap clears bindings too early -- Key: COLLECTIONS-85 URL: http://issues.apache.org/jira/browse/COLLECTIONS-85 Project: Commons Collections Issue Type: Bug Components: Map Affects Versions: 3.1 Environment: Operating System: Windows XP Platform: Other Reporter: Eric Bodden Attachments: LORTest - Commons Map.zip Hello. This week I had to debug some small example program we are currently working on and it really took me a long time to find the actual problem because apprently there seems to be a bug in the implementation of ReferenceMap, which was really very unexpected for me. To me this seems very critical because I reckon that the ReferenceMap is in wide use. Hence I am describing my findings in detail. The code is AspectJ code, but I also provide the bytecode. The puspose of the code is to detect the so-called lock order reversal pattern, a temporal event pattern which gives indication of potentially unsafe locking. It tries to detect patterns where a thread t1 tries to acquire locks in the order l1 l2 and another thread t2 tries to do so in the order r2 r1. When you compile the attached code with the AspectBench compiler (www. aspectbench.org) and then execute java LORTest, depending on the map implementation you choose, one of the following traces is produced: - log: your commons impl. (Reference identity map with weak key and values) - log_jre: the JRE impl. (hash map with weak keys, no identity map, but does not matter since the keys are threads, which do not implement equals(...)) (Both logs are also in the tarball.) In log_jre you see that the LOR is detected (at the bottom). That works as follows: Whenever a lock is taken, the relationship (thread,lock) is put into a first (weak) map (see logging points Xa). Also, for all such relations which are contained already, we put a reference to a pair (thread,(lock1,lock2)) into a second map (logging points Xb). This represents the information thread took first lock1 then lock2. As log shows, the weak map by commons is looses all the sudden some bindings. (Compare to log_jre.) This seems really buggy, since subsequent logging output shows that the threads and locked resources still exist! For me this is fully deterministically reproducable. I am using Windows XP with this JRE: java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) You can compile the code (using the AspectBench compiler) with compile.bat or you can just run it with run.bat, if you like. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confluence and Jira client libraries
On Aug 7, 2006, at 11:06 AM, Henri Yandell wrote: On 8/7/06, David Blevins [EMAIL PROTECTED] wrote: On Aug 4, 2006, at 10:18 AM, Henri Yandell wrote: I'm quite interested in the project btw - am doing Ruby xmlrpc at the moment to JIRA so already in the domain. Would be cool to use Swizzle to build the Commons Triage pages I've been scraping. I don't know what Commons Triage is, do you have a link to these pages? http://www.featheredblogs.org/commons/triage.html JIRA filters don't work well across many projects (you lose too many options), so this is just a list of the unversioned issues from Commons projects that have been cleaned up. Idea being that you can look at that page (or an email that'll get sent to the list) to see what issues need to be looked at. Well, you can get issues either via the xmlrpc or rss features of Jira. From there, you're one Velocity template away. Try this: $ wget http://repository.codehaus.org/org/codehaus/swizzle/swizzle- jirareport/1.0/swizzle-jirareport-1.0-nodep.jar $ java -jar swizzle-jirareport-1.0-nodep.jar http://svn.codehaus.org/ swizzle/tags/swizzle-jirareport-1.0/src/test/resources/jirarss.vm -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] A little design help please re DBCP-100
You might want to look at [collections] ExtendedProperties where I just fixed a similar issue. I made the instance methods work against a new instance variable, and subclasses could still alter the static one, which now acts as a default. Stephen Phil Steitz wrote: As stated in the bug report: SharedPoolDataSource.getPooledConnectionAndInfo() is synchronized _instance_ method, but it accesses SharedPoolDataSource.userKeys which is a _static_ variable, so if you have more than one instance of SharedPoolDataSource (as we do) access to the map would not be properly synchronized. So either map should be made instance variable, or the method should be synchronized on the class, not instance. I would very much appreciate comments on the options to fix this, including WONTFIX, but I don't like that option. I have coded the change to synchronize the method on the class (or more precisely, to make its body synchronized on the class, since it can't be static), but am hesitant to make that change. Any better ideas? Any recollections / rationale for why the map is static? Thanks! Phil - 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]
Is anybody using commons-i18n?
Hi, I was considering using commons-i18n for my project to solve internationalization. I know the project is in the sandbox and more or less abandoned, but is anybody actually using it? It seems tha the documentation on the site is not consistent with the state of the repo. For example, the page at http://jakarta.apache.org/commons/sandbox/i18n/quickstart.html suggests to use ResourceBundleMessageProvider.install() function which i can't find in the checked-out code. The ResourceBundleMessageProvider.install() call shows up in the jar available for download at http://cvs.apache.org/repository/commons-i18n/distributions/ Am i missing something? is this project totally inconsistent and dead? Is there a better way to do what it used to do? I'm looking to have multiple modules of my app each use their own message bundles, and i was hoping to avoid the pain of writing my own ResourceBundle manager. I'm trying to find the easiest off-the-shelf way of generating error messages (where i can pass parameters). any other suggestions? There's an ICU library from IBM, but that appears to be overkill for what i'm trying to do. thanks -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bug report
I found a bug of the class Flat3Map of Commons Collections ver.3.2. The method Flat3Map#remove(Object key) doesn't reutrns removed value when the size is equals or less then 3. -- Hiroshi Ikeda [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429507 - in /jakarta/commons/proper/lang/trunk/src: java/org/apache/commons/lang/text/StrSubstitutor.java test/org/apache/commons/lang/text/StrSubstitutorTest.java
Author: scolebourne
Date: Mon Aug 7 16:06:41 2006
New Revision: 429507
URL: http://svn.apache.org/viewvc?rev=429507view=rev
Log:
Give more power to StrSubstitutor subclasses
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrSubstitutor.java
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrSubstitutorTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrSubstitutor.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrSubstitutor.java?rev=429507r1=429506r2=429507view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrSubstitutor.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrSubstitutor.java
Mon Aug 7 16:06:41 2006
@@ -126,8 +126,8 @@
* Replaces all the occurrences of variables in the given source object
with
* their matching values from the map.
*
- * @param source the source text containing the variables to substitute
- * @param valueMap the map with the values
+ * @param source the source text containing the variables to substitute,
null returns null
+ * @param valueMap the map with the values, may be null
* @return the result of the replace operation
*/
public static String replace(Object source, Map valueMap) {
@@ -139,11 +139,12 @@
* their matching values from the map. This method allows to specifiy a
* custom variable prefix and suffix
*
- * @param source the source text containing the variables to substitute
- * @param valueMap the map with the values
- * @param prefix the prefix of variables
- * @param suffix the suffix of variables
+ * @param source the source text containing the variables to substitute,
null returns null
+ * @param valueMap the map with the values, may be null
+ * @param prefix the prefix of variables, not null
+ * @param suffix the suffix of variables, not null
* @return the result of the replace operation
+ * @throws IllegalArgumentException if the prefix or suffix is null
*/
public static String replace(Object source, Map valueMap, String prefix,
String suffix) {
return new StrSubstitutor(valueMap, prefix, suffix).replace(source);
@@ -153,7 +154,7 @@
* Replaces all the occurrences of variables in the given source object
with
* their matching values from the system properties.
*
- * @param source the source text containing the variables to substitute
+ * @param source the source text containing the variables to substitute,
null returns null
* @return the result of the replace operation
*/
public static String replaceSystemProperties(Object source) {
@@ -365,14 +366,20 @@
//---
/**
- * Main method for substituting variables.
+ * Internal method that substitutes the variables.
+ * p
+ * Most users of this class do not need to call this method. This method
will
+ * be called automatically by another (public) method.
+ * p
+ * Writers of subclasses can override this method if they need access to
+ * the substitution process at the start or end.
*
* @param buf the string builder to substitute into, not null
* @param offset the start offset within the builder, must be valid
* @param length the length within the builder to be processed, must be
valid
* @return true if altered
*/
-private boolean substitute(StrBuilder buf, int offset, int length) {
+protected boolean substitute(StrBuilder buf, int offset, int length) {
return substitute(buf, offset, length, null) 0;
}
@@ -439,7 +446,7 @@
priorVariables.add(varName);
// resolve the variable
-String varValue = resolveVariable(varName);
+String varValue = resolveVariable(varName, buf,
startPos, endPos);
if (varValue != null) {
// recursive replace
int varLen = varValue.length();
@@ -486,21 +493,28 @@
}
/**
- * Resolves the specified variable. This method is called whenever a
variable
- * reference is detected in the source text. It is passed the variable's
name
- * and must return the corresponding value. This implementation accesses
the
- * value map using the variable's name as key. Derived classes may override
- * this method to implement a different strategy for resolving variables.
- *
- * @param varName the name of the variable
+ * Internal method
svn commit: r429516 - in /jakarta/commons/proper/scxml/trunk/src: main/java/org/apache/commons/scxml/io/ModelUpdater.java test/java/org/apache/commons/scxml/SCXMLExecutorTest.java test/java/org/apache
Author: rahul
Date: Mon Aug 7 16:53:33 2006
New Revision: 429516
URL: http://svn.apache.org/viewvc?rev=429516view=rev
Log:
Allow the target of a transition to be omitted.
Variant of patch by: Sitthichai Rernglertpricha sitthichai_rernglertpricha AT
yahoo DOT com
Also added a test case to ensure stay, self and regular transition behavior.
SCXML-14
Added:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/transitions-02.xml
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java?rev=429516r1=429515r2=429516view=diff
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
Mon Aug 7 16:53:33 2006
@@ -224,6 +224,9 @@
private static void updateTransition(final Transition t,
final Map targets) throws ModelException {
String next = t.getNext();
+if (next == null) { // stay transition
+return;
+}
TransitionTarget tt = t.getTarget();
if (tt == null) {
tt = (TransitionTarget) targets.get(next);
Modified:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java?rev=429516r1=429515r2=429516view=diff
==
---
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
Mon Aug 7 16:53:33 2006
@@ -46,7 +46,7 @@
// Test data
private URL microwave01jsp, microwave02jsp, microwave01jexl,
-microwave02jexl, transitions01, send02;
+microwave02jexl, transitions01, transitions02, send02;
private SCXMLExecutor exec;
/**
@@ -63,6 +63,8 @@
getResource(org/apache/commons/scxml/env/jexl/microwave-02.xml);
transitions01 = this.getClass().getClassLoader().
getResource(org/apache/commons/scxml/transitions-01.xml);
+transitions02 = this.getClass().getClassLoader().
+getResource(org/apache/commons/scxml/transitions-02.xml);
send02 = this.getClass().getClassLoader().
getResource(org/apache/commons/scxml/send-02.xml);
}
@@ -72,7 +74,7 @@
*/
public void tearDown() {
microwave01jsp = microwave02jsp = microwave01jexl = microwave02jexl =
-transitions01 = send02 = null;
+transitions01 = transitions02 = send02 = null;
}
/**
@@ -118,6 +120,27 @@
next()).getId());
currentStates = SCXMLTestHelper.fireEvent(exec, twenty_two.done);
assertEquals(3, exec.getCurrentStatus().getStates().size());
+} catch (Exception e) {
+fail(e.getMessage());
+}
+}
+
+public void testSCXMLExecutorTransitions02Sample() {
+exec = SCXMLTestHelper.getExecutor(transitions02);
+assertNotNull(exec);
+try {
+Set currentStates = SCXMLTestHelper.fireEvent(exec, ten.stay);
+assertEquals(1, currentStates.size());
+assertEquals(ten, ((State)currentStates.iterator().
+next()).getId());
+currentStates = SCXMLTestHelper.fireEvent(exec, ten.self);
+assertEquals(1, currentStates.size());
+assertEquals(ten, ((State)currentStates.iterator().
+next()).getId());
+currentStates = SCXMLTestHelper.fireEvent(exec, ten.done);
+assertEquals(1, currentStates.size());
+assertEquals(twenty, ((State)currentStates.iterator().
+next()).getId());
} catch (Exception e) {
fail(e.getMessage());
}
Added:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/transitions-02.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/transitions-02.xml?rev=429516view=auto
==
---
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/transitions-02.xml
(added)
+++
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/transitions-02.xml
[jira] Resolved: (SCXML-14) Allowing the target of a transition to be omitted
[ http://issues.apache.org/jira/browse/SCXML-14?page=all ] Rahul Akolkar resolved SCXML-14. Fix Version/s: 0.6 Resolution: Fixed Thanks, fixed in r429516: http://svn.apache.org/viewvc?rev=429516view=rev and should be available from the 08072006 nightlies: http://people.apache.org/builds/jakarta-commons/nightly/commons-scxml/ Allowing the target of a transition to be omitted - Key: SCXML-14 URL: http://issues.apache.org/jira/browse/SCXML-14 Project: Commons SCXML Issue Type: Bug Environment: Windows, JDK 1.4.2 Reporter: Sitthichai Rernglertpricha Assigned To: Rahul Akolkar Priority: Minor Fix For: 0.6 Attachments: patchfile Currently, the runtime throws a ModelException if the target of a transition is not specified. E.g. the following throws a ModelException since the target next=.../ is omitted within the transition element. state id='s' transitionfiltered=xxx assign name=data expr=value /transition /state However, based on the scxml specification at http://www.w3.org/TR/scxml/ at section 3.3, quote - If the target on a transition is omitted, then taking the transition has the effect of leaving the machine in the same state after invoking any executable content that is included in the transition. The attached patch can be applied to the ModelUpdater.java to fix the above problem. Basically, the change is in the updateTransition() method. If next variable is null, return immediately from the method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCXML-15) User of SCXMLExecutor does not have access to the current context data
[ http://issues.apache.org/jira/browse/SCXML-15?page=comments#action_12426373 ] Rahul Akolkar commented on SCXML-15: Do any of the following avenues work? If not, please post your usecase to help us better understand the need for this improvement request. Generally speaking, communication between the state machine and its environment is best achieved via the root context on the executor. One can avail of: a) Read access on the root context b) Datamodel child of root scxml element (also available via root context) Similarly, SCXML provides mechanisms for exporting values in the current Context to external processes, namely via: c) Passing the EventDispatcher a namelist onsend() d) Passing an invoked process params The constrained access as of now is actually much beneficial from a modeling and tooling perspective since it offers well-defined hooks to work with. Leaving this issue open for now. User of SCXMLExecutor does not have access to the current context data -- Key: SCXML-15 URL: http://issues.apache.org/jira/browse/SCXML-15 Project: Commons SCXML Issue Type: Improvement Environment: Windows, JDK 1.4.2 Reporter: Sitthichai Rernglertpricha Assigned To: Rahul Akolkar Priority: Minor Fix For: 0.6 Currently, SCXMLExecutor does not provide method for client to get local variables associated with the Context of the current state. All created Context are maintained in the SCInstance object within the SCXMLExecutor class, and currently the getSCInstance() of SCXMLExecutor does not have any protected or public qualifier. Hence getSCInstance() cannot only be accessed by SCXMLExecutor or classes within the org.apache.commons.scxml package. Can we change getSCInstance() method to be protected or public ? This allows the client to call getSCInstance().getContext() to return the Context associated with the current state or create a child class of SCXMLExecutor that return variables associated with the current context. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-15) User of SCXMLExecutor does not have access to the current context data
[ http://issues.apache.org/jira/browse/SCXML-15?page=all ] Rahul Akolkar updated SCXML-15: --- Fix Version/s: 0.6 User of SCXMLExecutor does not have access to the current context data -- Key: SCXML-15 URL: http://issues.apache.org/jira/browse/SCXML-15 Project: Commons SCXML Issue Type: Improvement Environment: Windows, JDK 1.4.2 Reporter: Sitthichai Rernglertpricha Assigned To: Rahul Akolkar Priority: Minor Fix For: 0.6 Currently, SCXMLExecutor does not provide method for client to get local variables associated with the Context of the current state. All created Context are maintained in the SCInstance object within the SCXMLExecutor class, and currently the getSCInstance() of SCXMLExecutor does not have any protected or public qualifier. Hence getSCInstance() cannot only be accessed by SCXMLExecutor or classes within the org.apache.commons.scxml package. Can we change getSCInstance() method to be protected or public ? This allows the client to call getSCInstance().getContext() to return the Context associated with the current state or create a child class of SCXMLExecutor that return variables associated with the current context. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] 1.0 roadmap (was: Recent changes)
On 8/7/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Rahul! We can continue building (like we have been, in the nightlies for many months), but we can't release those Yes, I am aware of. Just a ready made jar for download would be great. (including a source jar - if we only could use m2 for this ;-) ) snip/ Said that, we can have extras/ later if we dont want to bloat the core with all the filesystems, but I think then we might go the per-filesystem-jar way, no? snap/ m2 would be convenient, but it would also be a distraction. So, depends how soon we want to go for the first release (sooner the better?). So, well, I can live with extras/ but I prefer the sandbox/ :-) snip/ sandbox/ it is then and we'll need to mod Phil's nightly script to make a new run in vfs/trunk/sandbox each night. -Rahul Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429518 - /jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/invoke/InvokeTest.java
Author: rahul Date: Mon Aug 7 17:06:39 2006 New Revision: 429518 URL: http://svn.apache.org/viewvc?rev=429518view=rev Log: Unused imports. Modified: jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/invoke/InvokeTest.java Modified: jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/invoke/InvokeTest.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/invoke/InvokeTest.java?rev=429518r1=429517r2=429518view=diff == --- jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/invoke/InvokeTest.java (original) +++ jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/invoke/InvokeTest.java Mon Aug 7 17:06:39 2006 @@ -24,7 +24,6 @@ import junit.textui.TestRunner; import org.apache.commons.scxml.SCXMLExecutor; -import org.apache.commons.scxml.SCXMLTestHelper; import org.apache.commons.scxml.env.SimpleDispatcher; import org.apache.commons.scxml.env.SimpleErrorHandler; import org.apache.commons.scxml.env.SimpleErrorReporter; @@ -33,7 +32,7 @@ import org.apache.commons.scxml.io.SCXMLDigester; import org.apache.commons.scxml.model.SCXML; import org.apache.commons.scxml.model.State; -import org.apache.commons.scxml.model.TransitionTarget; + /** * Unit tests [EMAIL PROTECTED] org.apache.commons.scxml.SCXMLExecutor}. * Testing invoke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JEXL] 1.1 now? (was: Re: [jira] Resolved: (JEXL-17) snip/)
On 8/6/06, Dion Gillard [EMAIL PROTECTED] wrote: Cool. I think it's time for a JEXL 1.1 release. snip/ Yup. I'll try to chase down the JIRA roadmap and miscellaneous action items within a week or so. I may be able to cut a RC over the weekend if those get done, unless you want to RM it? The only deterrant has been JDK 1.2 (I don't even have it on any of my machines). JEXL's still 1.2, right? -Rahul On 8/7/06, Rahul Akolkar (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/JEXL-17?page=all ] Rahul Akolkar resolved JEXL-17. --- snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] configuration
On 8/7/06, Torsten Curdt [EMAIL PROTECTED] wrote: I am currently trying to figure out the configuration part of jci ...and at the moment I am really torn apart which way to go. Usually I am one of those that likes static typing ...which is what the plexus compiler API (and the javac implementation of jci) uses. Having a configuration class with setters like settings.setVerbose(boolean) ...but looking at the native eclipse compiler implementation (which is just using a map) settings.put(settings.OPTION, settings.OPTION_VALUE) snip/ Its a very eclipsy thing to do, OSGi bundles and services pass java.util.Dictionary instances around (that API has been around for a while) for the very reasons you state below. Standard property keys are defined by the framework (all keys are Strings). I am really tempted to go that way. The interface would be so much easier and way more extensible. The compilers could pick the options they need and warn about options they don't understand. As very often the configuration does not come from a statically typed resource anyway (like a xml or properties file) the static API might not even that convenient at all. Opinions? snap/ Not a bad idea, just needs lot of Javadocs. -Rahul cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JEXL] 1.1 now? (was: Re: [jira] Resolved: (JEXL-17) snip/)
On 8/8/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/6/06, Dion Gillard [EMAIL PROTECTED] wrote: Cool. I think it's time for a JEXL 1.1 release. snip/ Yup. I'll try to chase down the JIRA roadmap and miscellaneous action items within a week or so. I may be able to cut a RC over the weekend if those get done, unless you want to RM it? The only deterrant has been JDK 1.2 (I don't even have it on any of my machines). JEXL's still 1.2, right? I think it has been, but like you said finding a JDK 1.2 download is hard these days. And, 1.0 was built using 1.3. From the manifest: Build-Jdk: 1.3.1_07 I'm ok with a 1.3 build. -Rahul On 8/7/06, Rahul Akolkar (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/JEXL-17?page=all ] Rahul Akolkar resolved JEXL-17. --- snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ If you even dream of beating me you'd better wake up and apologize - Muhammad Ali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JEXL-18) Whitespace normalization in Jelly is wrong
Whitespace normalization in Jelly is wrong -- Key: JEXL-18 URL: http://issues.apache.org/jira/browse/JEXL-18 Project: Commons JEXL Issue Type: Bug Reporter: Kohsuke Kawaguchi In XML, the convention is to only remove ignorable whitespaces. Ignorable whitespaces are defined as a text block that entirely consist of whitespaces, surrounded by tags. So the following text are ignorable whitespaces: foo bar// text between two start tags foo /foo // text between start and end tag (Technically speaking, they are ignorable only when DTD says so, but those are nevertheless people usually consider them pseudo-ignorable even if there's no DTD.) But the following text are never ignorable whitespaces: foo x bar foo y /foo Jelly agressively trims off whitespaces, even if they are not ignorable. So in the above cases, it becomes: fooxbar fooy/foo Such mode of whitespace normalization is not seen anywhere else, and IMHO it is confusing. It is sometimes even harmful, for example because the following text: p some text bhere/b/p ... becomes: psome textbhere/b/p and you end up losing the significant space character between 'text' and 'here'. As an example of proper whitespace stripping, consult XSLT (http://www.w3.org/TR/1999/REC-xslt-19991116#strip) I do realize that one can control the whitespace stripping behavior by using TagSupport.setEscapeText(boolean), but nevertheless I thought I would file a bug to see if the development team is willing to consider this change. I also do realize that this has some non-trivial compatibility implications. If you are willing to fix this, I have already patched Jelly locally, so I'm happy to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JEXL-18) Whitespace normalization in Jelly is wrong
[ http://issues.apache.org/jira/browse/JEXL-18?page=comments#action_12426389 ] Kohsuke Kawaguchi commented on JEXL-18: --- D'oh! This is supposed to be filed against Jelly, not Jexl. But I don't seem to be able to reassign it, or even just to close it. If whoever with enough karma can reassign this to Jelly or just close it, that would be appreciated. Whitespace normalization in Jelly is wrong -- Key: JEXL-18 URL: http://issues.apache.org/jira/browse/JEXL-18 Project: Commons JEXL Issue Type: Bug Reporter: Kohsuke Kawaguchi In XML, the convention is to only remove ignorable whitespaces. Ignorable whitespaces are defined as a text block that entirely consist of whitespaces, surrounded by tags. So the following text are ignorable whitespaces: foo bar// text between two start tags foo /foo // text between start and end tag (Technically speaking, they are ignorable only when DTD says so, but those are nevertheless people usually consider them pseudo-ignorable even if there's no DTD.) But the following text are never ignorable whitespaces: foo x bar foo y /foo Jelly agressively trims off whitespaces, even if they are not ignorable. So in the above cases, it becomes: fooxbar fooy/foo Such mode of whitespace normalization is not seen anywhere else, and IMHO it is confusing. It is sometimes even harmful, for example because the following text: p some text bhere/b/p ... becomes: psome textbhere/b/p and you end up losing the significant space character between 'text' and 'here'. As an example of proper whitespace stripping, consult XSLT (http://www.w3.org/TR/1999/REC-xslt-19991116#strip) I do realize that one can control the whitespace stripping behavior by using TagSupport.setEscapeText(boolean), but nevertheless I thought I would file a bug to see if the development team is willing to consider this change. I also do realize that this has some non-trivial compatibility implications. If you are willing to fix this, I have already patched Jelly locally, so I'm happy to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-net ftp] help! can I avoid oro.jar? (MalformedPatternException)
In message [EMAIL PROTECTED], Anil Philip wr ites: I googled and read that the oro.jar is missing. However my application is sensitive to download times and I dont wish to add the oro.jar if possible - I am not using regex here. Is there any way out? The oro jar 77k in size (a good deal smaller than all of the JavaScript support libraries that get loaded in Web pages these days) Usually, if you're sensitive to the size of a jar file, you repackage your application to use only the essential classes. There's nothing preventing you from removing unused classes from the commons-net (based on your commons-user email) and oro jars. However, the oro classes are used by the FTP listing parser. All that said, if you do a checkout of the trunk of the oro svn repository and compile the source with 'ant jar' you will find a number of jars, two of which will be jakarta-oro-core-2.1-dev-1.jar and jakarta-oro-perl5-2.1-dev-1.jar. I do not believe commons-net uses anything outside of that. The first jar is 12k in size and the second is 28k. You can make the second one smaller by removing the org/apache/oro/text/perl classes and the first one smaller by removing the classes with 'Engine' in their names. Based on your commons-net email, you appear to be using only FTP. I'd suggest removing the bsd, nntp, ntp, pop3, smtp, and tftp packages from that jar and creating a new jar including all of your app dependencies to avoid multiple downloads since you're concerned about download times. However, since you mentioned in your commons-user email that you're using Java WebStart, downloads are a one time cost because of the application caching. Also, with the caching mechanism, it's better to use separate jars so that individual jars can be updated without requiring the entire application to be redownloaded. daniel -#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/ In distant lands, I hear the call of my home. # s a v a r e s e Yet my work is not done. My journey's just begun.-software research -- http://www.sleepandthetraveller.com/ # http://www.savarese.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (JELLY-236) Whitespace normalization in Jelly is wrong
[ http://issues.apache.org/jira/browse/JELLY-236?page=all ] dion gillard moved JEXL-18 to JELLY-236: Project: Commons Jelly (was: Commons JEXL) Key: JELLY-236 (was: JEXL-18) Whitespace normalization in Jelly is wrong -- Key: JELLY-236 URL: http://issues.apache.org/jira/browse/JELLY-236 Project: Commons Jelly Issue Type: Bug Reporter: Kohsuke Kawaguchi In XML, the convention is to only remove ignorable whitespaces. Ignorable whitespaces are defined as a text block that entirely consist of whitespaces, surrounded by tags. So the following text are ignorable whitespaces: foo bar// text between two start tags foo /foo // text between start and end tag (Technically speaking, they are ignorable only when DTD says so, but those are nevertheless people usually consider them pseudo-ignorable even if there's no DTD.) But the following text are never ignorable whitespaces: foo x bar foo y /foo Jelly agressively trims off whitespaces, even if they are not ignorable. So in the above cases, it becomes: fooxbar fooy/foo Such mode of whitespace normalization is not seen anywhere else, and IMHO it is confusing. It is sometimes even harmful, for example because the following text: p some text bhere/b/p ... becomes: psome textbhere/b/p and you end up losing the significant space character between 'text' and 'here'. As an example of proper whitespace stripping, consult XSLT (http://www.w3.org/TR/1999/REC-xslt-19991116#strip) I do realize that one can control the whitespace stripping behavior by using TagSupport.setEscapeText(boolean), but nevertheless I thought I would file a bug to see if the development team is willing to consider this change. I also do realize that this has some non-trivial compatibility implications. If you are willing to fix this, I have already patched Jelly locally, so I'm happy to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-236) Whitespace normalization in Jelly is wrong
[ http://issues.apache.org/jira/browse/JELLY-236?page=comments#action_12426391 ] dion gillard commented on JELLY-236: How does this affect trim()? Whitespace normalization in Jelly is wrong -- Key: JELLY-236 URL: http://issues.apache.org/jira/browse/JELLY-236 Project: Commons Jelly Issue Type: Bug Reporter: Kohsuke Kawaguchi In XML, the convention is to only remove ignorable whitespaces. Ignorable whitespaces are defined as a text block that entirely consist of whitespaces, surrounded by tags. So the following text are ignorable whitespaces: foo bar// text between two start tags foo /foo // text between start and end tag (Technically speaking, they are ignorable only when DTD says so, but those are nevertheless people usually consider them pseudo-ignorable even if there's no DTD.) But the following text are never ignorable whitespaces: foo x bar foo y /foo Jelly agressively trims off whitespaces, even if they are not ignorable. So in the above cases, it becomes: fooxbar fooy/foo Such mode of whitespace normalization is not seen anywhere else, and IMHO it is confusing. It is sometimes even harmful, for example because the following text: p some text bhere/b/p ... becomes: psome textbhere/b/p and you end up losing the significant space character between 'text' and 'here'. As an example of proper whitespace stripping, consult XSLT (http://www.w3.org/TR/1999/REC-xslt-19991116#strip) I do realize that one can control the whitespace stripping behavior by using TagSupport.setEscapeText(boolean), but nevertheless I thought I would file a bug to see if the development team is willing to consider this change. I also do realize that this has some non-trivial compatibility implications. If you are willing to fix this, I have already patched Jelly locally, so I'm happy to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-net ftp] help! can I avoid oro.jar? (MalformedPatternException)
Thank you for your reply which I shall apply - it is an honor to hear from you. - Anil --- Daniel F. Savarese [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Anil Philip wr ites: I googled and read that the oro.jar is missing. However my application is sensitive to download times and I dont wish to add the oro.jar if possible - I am not using regex here. Is there any way out? The oro jar 77k in size (a good deal smaller than all of the JavaScript support libraries that get loaded in Web pages these days) Usually, if you're sensitive to the size of a jar file, you repackage your application to use only the essential classes. There's nothing preventing you from removing unused classes from the commons-net (based on your commons-user email) and oro jars. However, the oro classes are used by the FTP listing parser. All that said, if you do a checkout of the trunk of the oro svn repository and compile the source with 'ant jar' you will find a number of jars, two of which will be jakarta-oro-core-2.1-dev-1.jar and jakarta-oro-perl5-2.1-dev-1.jar. I do not believe commons-net uses anything outside of that. The first jar is 12k in size and the second is 28k. You can make the second one smaller by removing the org/apache/oro/text/perl classes and the first one smaller by removing the classes with 'Engine' in their names. Based on your commons-net email, you appear to be using only FTP. I'd suggest removing the bsd, nntp, ntp, pop3, smtp, and tftp packages from that jar and creating a new jar including all of your app dependencies to avoid multiple downloads since you're concerned about download times. However, since you mentioned in your commons-user email that you're using Java WebStart, downloads are a one time cost because of the application caching. Also, with the caching mechanism, it's better to use separate jars so that individual jars can be updated without requiring the entire application to be redownloaded. daniel -#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/ In distant lands, I hear the call of my home. # s a v a r e s e Yet my work is not done. My journey's just begun.- software research -- http://www.sleepandthetraveller.com/ # http://www.savarese.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] for good news go to http://members.tripod.com/~goodnewsforyou/goodnews.html __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] 1.0 roadmap (was: Recent changes)
Hi Rahul! m2 would be convenient, but it would also be a distraction. ;-) Its just with m2 I did this kind of stuff already, no clue with m1 - but yea, its time to learn again. Torsten pointed out a project where we can borrow this stuff, or are you familiar enough with m1? So, depends how soon we want to go for the first release (sooner the better?). Now that you did all the compress stuff, we should really try to release before compress ;-) I'd restart the release cycle as soon as we setup the sandbox/ stuff and the nightly works with it. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-236) Whitespace normalization in Jelly is wrong
[ http://issues.apache.org/jira/browse/JELLY-236?page=comments#action_12426439 ] dion gillard commented on JELLY-236: No, I mean o.a.c.j.TagSupport#setTrim(boolean) which almost all Tags extend at some point. Whitespace normalization in Jelly is wrong -- Key: JELLY-236 URL: http://issues.apache.org/jira/browse/JELLY-236 Project: Commons Jelly Issue Type: Bug Reporter: Kohsuke Kawaguchi In XML, the convention is to only remove ignorable whitespaces. Ignorable whitespaces are defined as a text block that entirely consist of whitespaces, surrounded by tags. So the following text are ignorable whitespaces: foo bar// text between two start tags foo /foo // text between start and end tag (Technically speaking, they are ignorable only when DTD says so, but those are nevertheless people usually consider them pseudo-ignorable even if there's no DTD.) But the following text are never ignorable whitespaces: foo x bar foo y /foo Jelly agressively trims off whitespaces, even if they are not ignorable. So in the above cases, it becomes: fooxbar fooy/foo Such mode of whitespace normalization is not seen anywhere else, and IMHO it is confusing. It is sometimes even harmful, for example because the following text: p some text bhere/b/p ... becomes: psome textbhere/b/p and you end up losing the significant space character between 'text' and 'here'. As an example of proper whitespace stripping, consult XSLT (http://www.w3.org/TR/1999/REC-xslt-19991116#strip) I do realize that one can control the whitespace stripping behavior by using TagSupport.setEscapeText(boolean), but nevertheless I thought I would file a bug to see if the development team is willing to consider this change. I also do realize that this has some non-trivial compatibility implications. If you are willing to fix this, I have already patched Jelly locally, so I'm happy to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429582 - /jakarta/commons/proper/commons-build/trunk/commons_nightly.sh
Author: psteitz Date: Mon Aug 7 22:12:35 2006 New Revision: 429582 URL: http://svn.apache.org/viewvc?rev=429582view=rev Log: Fixed log url path spec. Modified: jakarta/commons/proper/commons-build/trunk/commons_nightly.sh Modified: jakarta/commons/proper/commons-build/trunk/commons_nightly.sh URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/commons_nightly.sh?rev=429582r1=429581r2=429582view=diff == --- jakarta/commons/proper/commons-build/trunk/commons_nightly.sh (original) +++ jakarta/commons/proper/commons-build/trunk/commons_nightly.sh Mon Aug 7 22:12:35 2006 @@ -42,7 +42,7 @@ ant_build=/home/psteitz/build # Ant build directory maven_snapshot_host=people.apache.org # Maven snapshot host maven_snapshot_directory=/www/people.apache.org/repo/m1-snapshot-repository -log_url=http://people.apache.org/~psteitz/commons-nightlies/ +log_url=http://people.apache.org/~psteitz/commons-nightlies [EMAIL PROTECTED] #== # Process maven components in $components list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429592 - /jakarta/commons/proper/commons-build/trunk/commons_nightly.sh
Author: psteitz
Date: Mon Aug 7 22:56:53 2006
New Revision: 429592
URL: http://svn.apache.org/viewvc?rev=429592view=rev
Log:
Capture unit test logs when maven builds fail.
Modified:
jakarta/commons/proper/commons-build/trunk/commons_nightly.sh
Modified: jakarta/commons/proper/commons-build/trunk/commons_nightly.sh
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/commons_nightly.sh?rev=429592r1=429591r2=429592view=diff
==
--- jakarta/commons/proper/commons-build/trunk/commons_nightly.sh (original)
+++ jakarta/commons/proper/commons-build/trunk/commons_nightly.sh Mon Aug 7
22:56:53 2006
@@ -100,8 +100,12 @@
# Make files group writable
ssh $maven_snapshot_host chmod -R g+w
${maven_snapshot_directory}/commons-$component
-else # build failed - add to failure list
+else # build failed - add to failure list and capture unit test logs
[EMAIL PROTECTED]
+ echo Test Reports $log_location/$component.log
+ for i in target/test-reports/*.txt; do
+cat $i $log_location/$component.log
+ done
fi
# Cleanup
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
