[jira] Updated: (MATH-153) RandomDataImpl nextInt(int, int) nextLong(long, long)
[ http://issues.apache.org/jira/browse/MATH-153?page=all ] Remi Arntzen updated MATH-153: -- Attachment: Test.diff > 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 > > Attachments: diff.txt, Test.diff > > > 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]
Re: [JEXL] JIRA roadmap, one unscheduled ticket
I'll have a look at it tonight/tomorrow and make the changes. On 8/9/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: On 8/9/06, Dion Gillard <[EMAIL PROTECTED]> wrote: > My last comments on it were that structurally, the patch is in an > inappropriate, but working, spot, and that JEXL doesn't easily allow > the factories to plug these sorts of things in. > > I'd put it on the 2.0 list. > Done. One related item that remains is to alter the changes report to include JIRA bug IDs rather than bugzilla IDs. I'm at a conference, and on little dev time the next couple of days. -Rahul > On 8/9/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > I've created the JIRA roadmap for [jexl]. I've removed the "Nightly > > Build" version per growing Commons convention -- credit/blame goes to > > Hen -- (and edited 3 issues that refered to it). > > > > One unscheduled ticket remains: > > > > https://issues.apache.org/jira/browse/JEXL-13 > > > > My Velocity is rudimentary. Comments on that one? > > > > -Rahul > > - 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] Commented: (VFS-77) VFS cannot determine file type of root for FTP, prevents listing of children at root
[ http://issues.apache.org/jira/browse/VFS-77?page=comments#action_12426836
]
Mario Ivankovits commented on VFS-77:
-
Could you please try the next nightly, then the message "Object didnt extend
from AbstractFileObject. Object "{0}" " should show the correct object class
name instead of {0}.
Though, I think it will be "null" which means that you have no permission to
list the root directory of your ftp server - is this true?
If so, this is a enhancement which needs to be adressed.
Ciao,
Mario
> VFS cannot determine file type of root for FTP, prevents listing of children
> at root
>
>
> Key: VFS-77
> URL: http://issues.apache.org/jira/browse/VFS-77
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds
> Environment: Windows, Eclipse, Java 1.5
> commons-vfs-20060808.zip
> commons-net-1.4.1.jar, etc. (not sure one of the dependencies is the real
> problem)
>Reporter: Ben Ashpole
>
> The following example, adapted from
> http://jakarta.apache.org/commons/vfs/api.html, throws the below exception
> for the given, valid FTP site. Please let me know if this issue can be
> replicated!
> FileSystemManager fsManager = VFS.getManager();
> FileObject f = fsManager.resolveFile("ftp://ftp.uspto.gov/";);
> FileObject[] children = f.getChildren(); // exception thrown here
> System.out.println("Children of "+f.getName().getURI());
> for(int i = 0; i {
> System.out.println(children[i].getName().getBaseName());
> }
> Exception in thread "main" org.apache.commons.vfs.FileSystemException: Could
> not determine the type of file "ftp://ftp.uspto.gov/";.
> at
> org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1281)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject.java:410)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.getChildren(AbstractFileObject.java:523)
> at com.bashpole.reflectorGadget.reflectionGroup.Ftp.test(Ftp.java:55)
> at com.bashpole.reflectorGadget.reflectionGroup.Ftp.main(Ftp.java:24)
> Caused by: org.apache.commons.vfs.FileSystemException: Object didnt extend
> from AbstractFileObject. Object "{0}"
> at
> org.apache.commons.vfs.util.FileObjectUtils.getAbstractFileObject(FileObjectUtils.java:50)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:174)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.doAttach(FtpFileObject.java:166)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1267)
> ... 4 more
--
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: r429968 - /jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/util/FileObjectUtils.java
Author: imario
Date: Tue Aug 8 22:20:42 2006
New Revision: 429968
URL: http://svn.apache.org/viewvc?rev=429968&view=rev
Log:
add object class name to error message
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/util/FileObjectUtils.java
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/util/FileObjectUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/util/FileObjectUtils.java?rev=429968&r1=429967&r2=429968&view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/util/FileObjectUtils.java
(original)
+++
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/util/FileObjectUtils.java
Tue Aug 8 22:20:42 2006
@@ -47,7 +47,7 @@
return (AbstractFileObject) searchObject;
}
-throw new
FileSystemException("vfs.util/find-abstract-file-object.error");
+throw new
FileSystemException("vfs.util/find-abstract-file-object.error",
fileObject==null?"null":fileObject.getClass().getName());
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] 1.0 roadmap (was: Recent changes)
Hi! > Therefore IMO, the way to think of this is as if there were two > components, vfs and vfs-sandbox, the latter depending on the former > for the "core" API Yes, I see it the same way. I am fine with this. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JEXL] JIRA roadmap, one unscheduled ticket
On 8/9/06, Dion Gillard <[EMAIL PROTECTED]> wrote: My last comments on it were that structurally, the patch is in an inappropriate, but working, spot, and that JEXL doesn't easily allow the factories to plug these sorts of things in. I'd put it on the 2.0 list. Done. One related item that remains is to alter the changes report to include JIRA bug IDs rather than bugzilla IDs. I'm at a conference, and on little dev time the next couple of days. -Rahul On 8/9/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > I've created the JIRA roadmap for [jexl]. I've removed the "Nightly > Build" version per growing Commons convention -- credit/blame goes to > Hen -- (and edited 3 issues that refered to it). > > One unscheduled ticket remains: > > https://issues.apache.org/jira/browse/JEXL-13 > > My Velocity is rudimentary. Comments on that one? > > -Rahul > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JEXL-13) [jexl] Make JEXL allow for an Uberspect plugin
[ http://issues.apache.org/jira/browse/JEXL-13?page=all ] Rahul Akolkar updated JEXL-13: -- Bugzilla Id: (was: 38320) Fix Version/s: 2.0 Updating fix version per last comment. > [jexl] Make JEXL allow for an Uberspect plugin > -- > > Key: JEXL-13 > URL: http://issues.apache.org/jira/browse/JEXL-13 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.0 > Environment: Operating System: All > Platform: All >Reporter: Doug Rand >Priority: Minor > Fix For: 2.0 > > Attachments: jexl-patch.txt, patch.txt > > > Unlike Velocity, JEXL does not allow for the Uberspect object to be replaced > at > runtime. By allowing replacement JEXL can be extended for Java 1.5 or other > desireable functionality. I have a patch available for this. -- 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: [JEXL] JIRA roadmap, one unscheduled ticket
My last comments on it were that structurally, the patch is in an inappropriate, but working, spot, and that JEXL doesn't easily allow the factories to plug these sorts of things in. I'd put it on the 2.0 list. On 8/9/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: I've created the JIRA roadmap for [jexl]. I've removed the "Nightly Build" version per growing Commons convention -- credit/blame goes to Hen -- (and edited 3 issues that refered to it). One unscheduled ticket remains: https://issues.apache.org/jira/browse/JEXL-13 My Velocity is rudimentary. Comments on that one? -Rahul - 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]
[JEXL] JIRA roadmap, one unscheduled ticket
I've created the JIRA roadmap for [jexl]. I've removed the "Nightly Build" version per growing Commons convention -- credit/blame goes to Hen -- (and edited 3 issues that refered to it). One unscheduled ticket remains: https://issues.apache.org/jira/browse/JEXL-13 My Velocity is rudimentary. Comments on that one? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JEXL-3) [JEXL] Static method resolution and changes to context
[ http://issues.apache.org/jira/browse/JEXL-3?page=all ] Rahul Akolkar updated JEXL-3: - Bugzilla Id: (was: 39193) Fix Version/s: 2.0 I agree that the VariableResolver style API is much better than get/set vars. This has to be moved to a major release (if this change is to be made). Therefore, updating fix version to 2.0. > [JEXL] Static method resolution and changes to context > -- > > Key: JEXL-3 > URL: http://issues.apache.org/jira/browse/JEXL-3 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: dion gillard > Fix For: 2.0 > > Attachments: jexl-patch.zip > > > From: Guido Anzuoni <[EMAIL PROTECTED]> > Here I will try to explain may changes to see if you agree to include in the > trunk. > 1. UberspectImpl > I need to include static methods resolution in expressions (e.g. > System.currentTimeMillis()). I patched the class to allow it. > 2. JexlContext > Resolving vars using a Map is not enough flexible for my needs. I have > modified > it to have a single method > public Object resolveVariable(String var); > This allows me for better flexibility in the resolution process. > I have implemented a JextContext based on a java.util.Map, an extensible > JexlContext and a delegating JexlContext. > The extensible resolver is abstract and has a "parent" context to which > delegates in the case local resolution failes. > Delegating implementation extends the extensible context and uses another > JexlContext for local resolution. > More, I have removed any reference to JexlContex.getVars() in the code. > If you wish I can send the modified classes to better evaluate my changes. -- 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: (JEXL-10) [jexl] Make possible checking for unresolved variables
[ http://issues.apache.org/jira/browse/JEXL-10?page=all ] Rahul Akolkar updated JEXL-10: -- Bugzilla Id: (was: 31188) Fix Version/s: 2.0 Update fix version per earlier comment. > [jexl] Make possible checking for unresolved variables > -- > > Key: JEXL-10 > URL: http://issues.apache.org/jira/browse/JEXL-10 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: Paul Libbrecht >Priority: Minor > Fix For: 2.0 > > > Currently jexl is quite tolerant with undefined variable... > I think it would make sense to allow a switch that would throw an exception > everytime a variable is > requested but not defined. > This seems to be what was done at: > http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons- > [EMAIL PROTECTED]&msgId=1231239 > I haven't checked how the patch can apply... but I think it's an important > feature. > paul -- 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: (JEXL-11) [jexl] Don't make null convertible into anything
[ http://issues.apache.org/jira/browse/JEXL-11?page=all ] Rahul Akolkar updated JEXL-11: -- Bugzilla Id: (was: 31189) Fix Version/s: 2.0 Update fix version per earlier comment. > [jexl] Don't make null convertible into anything > > > Key: JEXL-11 > URL: http://issues.apache.org/jira/browse/JEXL-11 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: Paul Libbrecht >Priority: Minor > Fix For: 2.0 > > > Currently JEXL is very tolerant with null (and unresolved variables)... > I am unsure now but I think null will become false if the output of a test, > null will become the empty > string if concatenated to a string, null will become the number zero when > added. Moreover, > invoking a method on null gives you... null... > I would love a switch that just disables all this (I think this would impact > quite a lot) allowing my jexl > snippets to be quite more predictable! > paul -- 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: (JEXL-15) [jexl] Needs definable functions
[ http://issues.apache.org/jira/browse/JEXL-15?page=all ]
Rahul Akolkar updated JEXL-15:
--
Bugzilla Id: (was: 31186)
Fix Version/s: 2.0
Update fix version per earlier comment.
> [jexl] Needs definable functions
>
>
> Key: JEXL-15
> URL: http://issues.apache.org/jira/browse/JEXL-15
> Project: Commons JEXL
> Issue Type: Improvement
> Environment: Operating System: other
> Platform: Other
>Reporter: Paul Libbrecht
>Priority: Minor
> Fix For: 2.0
>
>
> Currently, in Jexl, the only way to add a functionality is to define a
> variable.
> Typically this is done in a separate environment... e.g. in jelly's j:new,
> j:set or...
> Using this, one can define, say, "a" then invoke "a.doSomething(withThat)".
> It would be nice to allow adding methods, e.g. "doSomething" to be invoked
> without any object.
> This way I could just say "doSomething".
> Examples of usage include:
> - add some mathematical functions to make jexl full featured mathematically
> (e.g. "abs", "exp",
> "atan")
> - add some "general purpose utilitites" (e.g. "tokenize(aString)",
> "toString(xx)", or
> "relativeUrl(baseUrl, relPath)")
> - thereby become more compatible with JSP (i've been told)
> This should promote general usage of such functions availability.
> In some situations this would help a lot. For example in maven where I too
> often still see
> srcFile="${baseDIr+pathToResource}" which prevents any overridability.
> (e.g. the cvs-usage.xml page in the xdoc plugin)
> paul
--
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: (JEXL-16) allowing quote escaping
[ http://issues.apache.org/jira/browse/JEXL-16?page=all ] Rahul Akolkar updated JEXL-16: -- Fix Version/s: 2.0 Affects Version/s: 1.0 Any grammar changes will not happen before 2.0, updating fix version. > allowing quote escaping > --- > > Key: JEXL-16 > URL: http://issues.apache.org/jira/browse/JEXL-16 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.0 > Environment: windows/linux using commons-jexl from commons-scxml >Reporter: Nestor Urquiza > Fix For: 2.0 > > > There is a need for jexl to support escaping since otherwise you cannot use > the apostrophe within a string like in > "I'm just trying to use apostrophe as punctuation mark" > which right now fails while using jexl . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JEXL-7) [jexl] Unable to reference statics
[ http://issues.apache.org/jira/browse/JEXL-7?page=all ] Rahul Akolkar resolved JEXL-7. -- Resolution: Fixed > [jexl] Unable to reference statics > -- > > Key: JEXL-7 > URL: http://issues.apache.org/jira/browse/JEXL-7 > Project: Commons JEXL > Issue Type: Bug > Environment: Operating System: Windows XP > Platform: PC >Reporter: Sean Ferguson > Fix For: 1.1 > > > When using Jexl, I am unable to reference anything static. That includes for > example Character.isLowerCase() or anything else that is static. Even if I > get > a reference to the class, it cannot reference the static methods. -- 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] Reopened: (JEXL-7) [jexl] Unable to reference statics
[ http://issues.apache.org/jira/browse/JEXL-7?page=all ] Rahul Akolkar reopened JEXL-7: -- Re-opening, to resolve correctly. > [jexl] Unable to reference statics > -- > > Key: JEXL-7 > URL: http://issues.apache.org/jira/browse/JEXL-7 > Project: Commons JEXL > Issue Type: Bug > Environment: Operating System: Windows XP > Platform: PC >Reporter: Sean Ferguson > Fix For: 1.1 > > > When using Jexl, I am unable to reference anything static. That includes for > example Character.isLowerCase() or anything else that is static. Even if I > get > a reference to the class, it cannot reference the static methods. -- 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: (JEXL-7) [jexl] Unable to reference statics
[ http://issues.apache.org/jira/browse/JEXL-7?page=all ] Rahul Akolkar updated JEXL-7: - Bugzilla Id: (was: 22193) Fix Version/s: 1.1 Affects Version/s: (was: Nightly Builds) > [jexl] Unable to reference statics > -- > > Key: JEXL-7 > URL: http://issues.apache.org/jira/browse/JEXL-7 > Project: Commons JEXL > Issue Type: Bug > Environment: Operating System: Windows XP > Platform: PC >Reporter: Sean Ferguson > Fix For: 1.1 > > > When using Jexl, I am unable to reference anything static. That includes for > example Character.isLowerCase() or anything else that is static. Even if I > get > a reference to the class, it cannot reference the static methods. -- 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: (JEXL-12) [JEXL] Implement short-circuit boolean evaluation
[ http://issues.apache.org/jira/browse/JEXL-12?page=all ] Rahul Akolkar updated JEXL-12: -- Bugzilla Id: (was: 29550) Fix Version/s: 1.0 Affects Version/s: (was: Nightly Builds) > [JEXL] Implement short-circuit boolean evaluation > - > > Key: JEXL-12 > URL: http://issues.apache.org/jira/browse/JEXL-12 > Project: Commons JEXL > Issue Type: Improvement > Environment: Operating System: All > Platform: All >Reporter: Matthew Firth >Priority: Minor > Fix For: 1.0 > > Attachments: short-circuit-eval.patch > > > The current implementation of ASTAndNode and ASTOrNode will evaluation both > sides of an expression before returning a result. I think most developers > these days seem to expect the RHS of an AND/OR expression to be ignored if > the > LHS is sufficient to determine the result > (e.g. if A=>true, "A or B"=>true, regardless of B). > The patches appear to be trivial - if a committer is interested & thinks it > worthwhile I'll create them. > (btw, the old Turbo Pascal compiler described this optimisation as "short > circuit boolean evaluation"; I'm not sure if that is a common name for it.) -- 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: (JEXL-17) ExpressionFactory.createNewExpression should throw an Exception in case of a parsing error, not Error
[ http://issues.apache.org/jira/browse/JEXL-17?page=all ] Rahul Akolkar updated JEXL-17: -- Fix Version/s: 1.1 Affects Version/s: 1.0 (was: Nightly Builds) > ExpressionFactory.createNewExpression should throw an Exception in case of a > parsing error, not Error > - > > Key: JEXL-17 > URL: http://issues.apache.org/jira/browse/JEXL-17 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Kohsuke Kawaguchi > Fix For: 1.1 > > Attachments: JEXL-17.diff > > > When ExpressionFactory.createNewExpression(...) takes an syntactically > incorrect expression, JEXL throws TokenMgrError. However, typical callers > (such as Jelly) don't expect such syntax error to be a java.lang.Error, so it > fails to catch it. > A typical outcome is therefore the thread to die completely, and even worse > the stack trace doesn't report neither what was the expression that was being > parsed, nor does it report any contextual information (again in case of > Jelly, that would be where in the jelly script this error happened.) > This makes the error diagnosis unnecessarily hard. I believe the proper thing > to do is to wrap such an exception into java.lang.Exception or its sub-class, > allowing the caller to catch it. -- 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: (VFS-77) VFS cannot determine file type of root for FTP, prevents listing of children at root
VFS cannot determine file type of root for FTP, prevents listing of children at
root
Key: VFS-77
URL: http://issues.apache.org/jira/browse/VFS-77
Project: Commons VFS
Issue Type: Bug
Affects Versions: Nightly Builds
Environment: Windows, Eclipse, Java 1.5
commons-vfs-20060808.zip
commons-net-1.4.1.jar, etc. (not sure one of the dependencies is the real
problem)
Reporter: Ben Ashpole
The following example, adapted from
http://jakarta.apache.org/commons/vfs/api.html, throws the below exception for
the given, valid FTP site. Please let me know if this issue can be replicated!
FileSystemManager fsManager = VFS.getManager();
FileObject f = fsManager.resolveFile("ftp://ftp.uspto.gov/";);
FileObject[] children = f.getChildren(); // exception thrown here
System.out.println("Children of "+f.getName().getURI());
for(int i = 0; iftp://ftp.uspto.gov/";.
at
org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1281)
at
org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject.java:410)
at
org.apache.commons.vfs.provider.AbstractFileObject.getChildren(AbstractFileObject.java:523)
at com.bashpole.reflectorGadget.reflectionGroup.Ftp.test(Ftp.java:55)
at com.bashpole.reflectorGadget.reflectionGroup.Ftp.main(Ftp.java:24)
Caused by: org.apache.commons.vfs.FileSystemException: Object didnt extend from
AbstractFileObject. Object "{0}"
at
org.apache.commons.vfs.util.FileObjectUtils.getAbstractFileObject(FileObjectUtils.java:50)
at
org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:174)
at
org.apache.commons.vfs.provider.ftp.FtpFileObject.doAttach(FtpFileObject.java:166)
at
org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1267)
... 4 more
--
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: [JEXL] 1.1 now? (was: Re: [jira] Resolved: (JEXL-17) )
On 8/8/06, Dion Gillard <[EMAIL PROTECTED]> wrote: As far as JEXL's grammar goes, variables can't contain a '-', as that's used for negation and subtraction. So, in JEXL 1.x the grammar does not support this feature, and from a JEXL perspective, it's not a bug, it's how the expression language is defined. Yup, making sure there wasn't more to it in the context of plugin.properties. Its unlikely that any EL parser (which uses - in its arithmetic sense) can support this, even if we wanted. -Rahul On 8/9/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On 8/8/06, Lukas Theussl <[EMAIL PROTECTED]> wrote: > > I am not familiar with jexl but has the bug that's causing us [1] ever > > been fixed? > > > > > I am not familiar with whats being done under the covers with > plugins.properties, what will help is either a JEXL test case or > pointing to usage via specific lines in some repository. Then, I can > make an attempt to see whats up. > > Dion - Any further comments beyond what you've said on MAVEN-410 [1] ? > > -Rahul > > > > -Lukas > > > > [1] http://jira.codehaus.org/browse/MAVEN-410 > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JEXL] 1.1 now? (was: Re: [jira] Resolved: (JEXL-17) )
As far as JEXL's grammar goes, variables can't contain a '-', as that's used for negation and subtraction. So, in JEXL 1.x the grammar does not support this feature, and from a JEXL perspective, it's not a bug, it's how the expression language is defined. On 8/9/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: On 8/8/06, Lukas Theussl <[EMAIL PROTECTED]> wrote: > I am not familiar with jexl but has the bug that's causing us [1] ever > been fixed? > I am not familiar with whats being done under the covers with plugins.properties, what will help is either a JEXL test case or pointing to usage via specific lines in some repository. Then, I can make an attempt to see whats up. Dion - Any further comments beyond what you've said on MAVEN-410 [1] ? -Rahul > -Lukas > > [1] http://jira.codehaus.org/browse/MAVEN-410 > > - 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] Updated: (SANDBOX-161) CSVPrinter#escapeAndQuote(String) doesn't adhere to CSV standard
[ http://issues.apache.org/jira/browse/SANDBOX-161?page=all ]
Daniel Gredler updated SANDBOX-161:
---
Attachment: commons-csv-patch-standard-escaping.txt
Attaching a patch to fix this... a couple of notes:
- I would talk to whoever initially wrote this code before applying; the
non-standard escape mechanism was very intentional, and I still don't
understand why.
- One of the unit tests checked all sorts of non-standard backslash-escaping
corner cases; it no longer applied, so I removed it.
- The patch makes a couple of trivial fixes to some typos and smelly
one-liners... sorry, I couldn't help myself!
- I tried to format my code so that it matches the surrounding code, but it
looks like there are multiple styles used throughout. What's up with that?
Anyways, check it out and let me know what you think!
> CSVPrinter#escapeAndQuote(String) doesn't adhere to CSV standard
>
>
> Key: SANDBOX-161
> URL: http://issues.apache.org/jira/browse/SANDBOX-161
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Affects Versions: Nightly Builds
>Reporter: Daniel Gredler
> Attachments: commons-csv-patch-standard-escaping.txt
>
>
> All the descriptions of the CSV format that I've seen state that:
> - Double quotes (") are escaped using two double quotes (""), rather than a
> backslash (\").
> - Embedded line breaks are allowed and don't need to be escaped... just
> enclose the field in double quotes.
> - Because backslashes are not used to escape double quotes or line breaks,
> the backslashes themselves do not need to be escaped.
> CSVPrinter#escapeAndQuote(String) breaks these rules. Why?
> http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm
> http://en.wikipedia.org/wiki/Comma-separated_values
--
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: [lang] VariableFormatter - pre 2.2
Almost done on text package - StrSubstitutor needs replace methods taking a StringBuffer (as adding them later causes overloading issues as per StringBuffer itself from JDK1.3 to 1.4) Stephen Henri Yandell wrote: On 8/4/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: Henri Yandell wrote: > On 8/2/06, Tom Schindl <[EMAIL PROTECTED]> wrote: > >> Well I'd love to see this method in 2.2 because I think it does make any >> API visible to the user and doesn't bloat the >> interface with too many new methods. >> >> Any other thoughts? > > > Just that now that Attributes 2.2 is out, I'm ready to start cutting > Lang 2.2 release candidates and want to put this one to bed :) I'm away next two weekends. VariableFormatter needs to be extracted as an abstract class StrLookup - like StrMatcher. And the resolveVariable method needs altering to have a more subclass friendly API (see other thread). So, if you feel like coding... Before 2.2? Or for what Tom wants? 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: r429884 - in /jakarta/commons/proper/lang/trunk/src: java/org/apache/commons/lang/text/VariableFormatter.java test/org/apache/commons/lang/text/TextTestSuite.java test/org/apache/commons/l
Author: scolebourne Date: Tue Aug 8 16:35:31 2006 New Revision: 429884 URL: http://svn.apache.org/viewvc?rev=429884&view=rev Log: VariableFormatter became StrSubstitutor Removed: jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/VariableFormatterTest.java Modified: jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/TextTestSuite.java Modified: jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/TextTestSuite.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/TextTestSuite.java?rev=429884&r1=429883&r2=429884&view=diff == --- jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/TextTestSuite.java (original) +++ jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/TextTestSuite.java Tue Aug 8 16:35:31 2006 @@ -55,7 +55,6 @@ suite.addTest(StrMatcherTest.suite()); suite.addTest(StrSubstitutorTest.suite()); suite.addTest(StrTokenizerTest.suite()); -suite.addTestSuite(VariableFormatterTest.class); return suite; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429881 - in /jakarta/commons/proper/lang/trunk/src: java/org/apache/commons/lang/text/ test/org/apache/commons/lang/text/
Author: scolebourne
Date: Tue Aug 8 16:28:45 2006
New Revision: 429881
URL: http://svn.apache.org/viewvc?rev=429881&view=rev
Log:
Create StrLookup by extraction from StrSubstitutor
Added:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrLookup.java
(with props)
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrLookupTest.java
(with props)
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
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/TextTestSuite.java
Added:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrLookup.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrLookup.java?rev=429881&view=auto
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrLookup.java
(added)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrLookup.java
Tue Aug 8 16:28:45 2006
@@ -0,0 +1,160 @@
+/*
+ * Copyright 2005-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.lang.text;
+
+import java.util.Map;
+
+/**
+ * Lookup a String key to a String value.
+ *
+ * This class represents the simplest form of a string to string map.
+ * It has a benefit over a map in that it can create the result on
+ * demand based on the key.
+ *
+ * This class comes complete with various factory methods.
+ * If these do not suffice, you can subclass and implement your own matcher.
+ *
+ * For example, it would be possible to implement a lookup that used the
+ * key as a primary key, and looked up the value on demand from the database
+ *
+ * @author Stephen Colebourne
+ * @since 2.2
+ * @version $Id: $
+ */
+public abstract class StrLookup {
+
+/**
+ * Lookup that always returns null.
+ */
+private static final StrLookup NONE_LOOKUP;
+/**
+ * Lookup that uses System properties.
+ */
+private static final StrLookup SYSTEM_PROPERTIES_LOOKUP;
+static {
+NONE_LOOKUP = new MapStrLookup(null);
+StrLookup lookup = null;
+try {
+lookup = new MapStrLookup(System.getProperties());
+} catch (SecurityException ex) {
+lookup = NONE_LOOKUP;
+}
+SYSTEM_PROPERTIES_LOOKUP = lookup;
+}
+
+//---
+/**
+ * Returns a lookup which always returns null.
+ *
+ * @return a lookup that always returns null, not null
+ */
+public static StrLookup noneLookup() {
+return NONE_LOOKUP;
+}
+
+/**
+ * Returns a lookup which uses [EMAIL PROTECTED] System#getProperties()
System properties}
+ * to lookup the key to value.
+ *
+ * If a security manager blocked access to system properties, then null
will
+ * be returned from every lookup.
+ *
+ * If a null key is used, this lookup will throw a NullPointerException.
+ *
+ * @return a lookup using system properties, not null
+ */
+public static StrLookup systemPropertiesLookup() {
+return SYSTEM_PROPERTIES_LOOKUP;
+}
+
+/**
+ * Returns a lookup which looks up values using a map.
+ *
+ * If the map is null, then null will be returned from every lookup.
+ * The map result object is converted to a string using toString().
+ *
+ * @param map the map of keys to values, may be null
+ * @return a lookup using the map, not null
+ */
+public static StrLookup mapLookup(Map map) {
+return new MapStrLookup(map);
+}
+
+//---
+/**
+ * Constructor.
+ */
+protected StrLookup() {
+super();
+}
+
+/**
+ * Looks up a String key to a String value.
+ *
+ * The internal implementation may use any mechanism to return the value.
+ * The simplest implementation is to use a Map. However, virtually any
+ * implementation is possible.
+ *
+ * For example, it would be possible to implement a lookup that used the
+ * key as a primary key, and l
svn commit: r429877 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrMatcher.java
Author: scolebourne
Date: Tue Aug 8 16:25:52 2006
New Revision: 429877
URL: http://svn.apache.org/viewvc?rev=429877&view=rev
Log:
Javadoc
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrMatcher.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrMatcher.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrMatcher.java?rev=429877&r1=429876&r2=429877&view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrMatcher.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrMatcher.java
Tue Aug 8 16:25:52 2006
@@ -21,12 +21,12 @@
* A matcher class that can be queried to determine if a character array
* portion matches.
*
- * This class comes complete with various constants and factory methods.
+ * This class comes complete with various factory methods.
* If these do not suffice, you can subclass and implement your own matcher.
*
* @author Stephen Colebourne
* @since 2.2
- * @version $Id$
+ * @version $Id: StrMatcher.java 232652 2005-08-14 21:45:47Z scolebourne $
*/
public abstract class StrMatcher {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429876 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
Author: scolebourne
Date: Tue Aug 8 16:24:49 2006
New Revision: 429876
URL: http://svn.apache.org/viewvc?rev=429876&view=rev
Log:
Rename variable for JDK1.5 compliance
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java?rev=429876&r1=429875&r2=429876&view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
Tue Aug 8 16:24:49 2006
@@ -144,9 +144,9 @@
}
List list = Enum.getEnumList(enumClass);
for (Iterator it = list.iterator(); it.hasNext();) {
-ValuedEnum enum = (ValuedEnum) it.next();
-if (enum.getValue() == value) {
-return enum;
+ValuedEnum enumeration = (ValuedEnum) it.next();
+if (enumeration.getValue() == value) {
+return enumeration;
}
}
return null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429857 - /jakarta/commons/proper/httpclient/trunk/project.xml
Author: olegk Date: Tue Aug 8 15:18:44 2006 New Revision: 429857 URL: http://svn.apache.org/viewvc?rev=429857&view=rev Log: Fix for [HTTPCLIENT-595]: Fix junit scope in maven pom Contributed by Carlos Sanchez Modified: jakarta/commons/proper/httpclient/trunk/project.xml Modified: jakarta/commons/proper/httpclient/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/project.xml?rev=429857&r1=429856&r2=429857&view=diff == --- jakarta/commons/proper/httpclient/trunk/project.xml (original) +++ jakarta/commons/proper/httpclient/trunk/project.xml Tue Aug 8 15:18:44 2006 @@ -321,6 +321,9 @@ junit 3.8.1 http://www.junit.org/ + +test + commons-logging - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429852 - in /jakarta/commons/proper/httpclient/trunk: ./ src/java/org/apache/commons/httpclient/protocol/ src/test/org/apache/commons/httpclient/
Author: olegk
Date: Tue Aug 8 15:14:36 2006
New Revision: 429852
URL: http://svn.apache.org/viewvc?rev=429852&view=rev
Log:
Fix for [HTTPCLIENT-593]: ProtocolSocketFactory equals and hashCode don't
support subclassing
Contributed by Chris Audley
Reviewed by Oleg Kalnichevski, Ortwin Glück and Roland Weber
Modified:
jakarta/commons/proper/httpclient/trunk/release_notes.txt
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/DefaultProtocolSocketFactory.java
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/TestEquals.java
Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/release_notes.txt?rev=429852&r1=429851&r2=429852&view=diff
==
--- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original)
+++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Tue Aug 8
15:14:36 2006
@@ -1,6 +1,10 @@
---
Changes since Release 3.1 Alpha 1:
+* [HTTPCLIENT-593] - Fixed problem with #equals() and #hashCode() methods in
subclasses of
+ DefaultProtocolSocketFactory and SSLProtocolSocketFactory
+ Contributed by Chris Audley
+
* [HTTPCLIENT-594] - HttpMethodBase#aborted variable was declared transient
instead of volatile
by mistake.
Contributed by Oleg Kalnichevski
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/DefaultProtocolSocketFactory.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/DefaultProtocolSocketFactory.java?rev=429852&r1=429851&r2=429852&view=diff
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/DefaultProtocolSocketFactory.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/DefaultProtocolSocketFactory.java
Tue Aug 8 15:14:36 2006
@@ -143,14 +143,14 @@
* All instances of DefaultProtocolSocketFactory are the same.
*/
public boolean equals(Object obj) {
-return ((obj != null) &&
obj.getClass().equals(DefaultProtocolSocketFactory.class));
+return ((obj != null) && obj.getClass().equals(getClass()));
}
/**
* All instances of DefaultProtocolSocketFactory have the same hash code.
*/
public int hashCode() {
-return DefaultProtocolSocketFactory.class.hashCode();
+return getClass().hashCode();
}
}
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java?rev=429852&r1=429851&r2=429852&view=diff
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java
Tue Aug 8 15:14:36 2006
@@ -168,14 +168,14 @@
* All instances of SSLProtocolSocketFactory are the same.
*/
public boolean equals(Object obj) {
-return ((obj != null) &&
obj.getClass().equals(SSLProtocolSocketFactory.class));
+return ((obj != null) && obj.getClass().equals(getClass()));
}
/**
* All instances of SSLProtocolSocketFactory have the same hash code.
*/
public int hashCode() {
-return SSLProtocolSocketFactory.class.hashCode();
+return getClass().hashCode();
}
}
Modified:
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/TestEquals.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/TestEquals.java?rev=429852&r1=429851&r2=429852&view=diff
==
---
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/TestEquals.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/TestEquals.java
Tue Aug 8 15:14:36 2006
@@ -86,6 +86,21 @@
}
+public void testProtocolSocketFactorySublass() {
+ProtocolSocketFactory factory1 = new DefaultProtocolSocketFactory();
+ProtocolSocketFactory factory2 = new DefaultProtocolSocketFactory() {};
+
+Protocol protocolA
svn commit: r429849 - in /jakarta/commons/proper/httpclient/trunk: release_notes.txt src/java/org/apache/commons/httpclient/HttpMethodBase.java
Author: olegk Date: Tue Aug 8 15:06:09 2006 New Revision: 429849 URL: http://svn.apache.org/viewvc?rev=429849&view=rev Log: Fix for [HTTPCLIENT-594]: HttpMethodBase#aborted variable mistakenly declared transient instead of volatile Contributed by Oleg Kalnichevski Reviewed by Ortwin Glück and Roland Weber Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/release_notes.txt?rev=429849&r1=429848&r2=429849&view=diff == --- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original) +++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Tue Aug 8 15:06:09 2006 @@ -1,3 +1,10 @@ +--- +Changes since Release 3.1 Alpha 1: + +* [HTTPCLIENT-594] - HttpMethodBase#aborted variable was declared transient instead of volatile + by mistake. + Contributed by Oleg Kalnichevski + Release 3.1 Alpha 1 --- New features: 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=429849&r1=429848&r2=429849&view=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 Tue Aug 8 15:06:09 2006 @@ -175,7 +175,7 @@ protected HttpVersion effectiveVersion = null; /** Whether the execution of this method has been aborted */ -private transient boolean aborted = false; +private volatile boolean aborted = false; /** Whether the HTTP request has been transmitted to the target * server it its entirety */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-275) Add a pair of StringUtils.substringsBetween;String[] methods
Add a pair of StringUtils.substringsBetween;String[] methods Key: LANG-275 URL: http://issues.apache.org/jira/browse/LANG-275 Project: Commons Lang Issue Type: Wish Reporter: Henri Yandell Priority: Minor I found myself wanting a version of substringBetween(String, String, String) that would return a String[] of the ones between and not just the single String for the first match. -- 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/8/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: 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? Thats [jci]. Even with m2, we will need magic to keep smb/webdav out of the release (if it was just the [compress] bits, we'd be done by now). Therefore IMO, the way to think of this is as if there were two components, vfs and vfs-sandbox, the latter depending on the former for the "core" API (which is why I mentioned another build run in vfs/trunk/sandbox in the nightlies script). -Rahul > 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]
Re: [JEXL] 1.1 now? (was: Re: [jira] Resolved: (JEXL-17) )
On 8/8/06, Lukas Theussl <[EMAIL PROTECTED]> wrote: I am not familiar with jexl but has the bug that's causing us [1] ever been fixed? I am not familiar with whats being done under the covers with plugins.properties, what will help is either a JEXL test case or pointing to usage via specific lines in some repository. Then, I can make an attempt to see whats up. Dion - Any further comments beyond what you've said on MAVEN-410 [1] ? -Rahul -Lukas [1] http://jira.codehaus.org/browse/MAVEN-410 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (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 resolved SCXML-15. Resolution: Won't Fix Yes, that would be another option, should have been option (e) in my last comment. Thanks for the clarification, I'm accordingly resolving without making any changes. > 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-16) The 'target' of a cannot be a data element name
[ http://issues.apache.org/jira/browse/SCXML-16?page=all ] Rahul Akolkar updated SCXML-16: --- Fix Version/s: 0.6 Assignee: Rahul Akolkar Correct. Also, targettype and sendid should be evaluated as well, in line with the latest Working Draft. If you want, you can update your patch to include those as well. I'll get to this in a couple of days. > The 'target' of a cannot be a data element name > -- > > Key: SCXML-16 > URL: http://issues.apache.org/jira/browse/SCXML-16 > 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: patch-send.txt > > > Based on the SCXML specification, the 'target' attribute of a element > can be "expression returning a unique identifier of the event target". > The specification also shows an example that reads the target from a data > element within . > The current SCXML runtime treats target as a literal string and does not > "evaluate" it. > The attached patch file shows a way to "evalulate" the target before calling > the EventDispatcher#send method, and support specifying the target by a data > element. Enclosing target within single-quote will prevent evaluation. -- 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]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-08082006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-08082006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-08082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-08082006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08082006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-08082006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-08082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-08082006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-08082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-08082006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08082006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.
Re: [nightly build] discovery net proxy finder failed.
On 8 Aug 2006 13:06:12 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20060808/discovery.log http://people.apache.org/~psteitz/commons-nightlies/20060808/net.log http://people.apache.org/~psteitz/commons-nightlies/20060808/proxy.log http://people.apache.org/~psteitz/commons-nightlies/20060808/finder.log Discovery fixed by moving to 1.2 target/source. Net fixed by adding a 1.2 source. Proxy fixed by adding a 1.2 source and changing the test port from 1099 to the less likely to clash 13099. Finder fixed by depending on the nightly snapshot of IO. Hope no one minds. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429752 - in /jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy: provider/TestRmiProvider.java util/rmi/RmiEchoImpl.java
Author: bayard
Date: Tue Aug 8 10:47:28 2006
New Revision: 429752
URL: http://svn.apache.org/viewvc?rev=429752&view=rev
Log:
Modified the RMI test to use 13099 as a port and not 1099. 1099 is the default,
so there's always a chance that it might be in use on the machine its running
on.
Modified:
jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/provider/TestRmiProvider.java
jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/util/rmi/RmiEchoImpl.java
Modified:
jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/provider/TestRmiProvider.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/provider/TestRmiProvider.java?rev=429752&r1=429751&r2=429752&view=diff
==
---
jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/provider/TestRmiProvider.java
(original)
+++
jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/provider/TestRmiProvider.java
Tue Aug 8 10:47:28 2006
@@ -35,6 +35,8 @@
private RmiEchoImpl implObject;
private Registry registry;
+// A port that is unlikely to clash with another on the build machine
+private int UNLIKELY_PORT = 13099;
//--
// Other Methods
@@ -42,8 +44,8 @@
public void setUpRegistry() throws Exception
{
-implObject = new RmiEchoImpl();
-registry = LocateRegistry.createRegistry( Registry.REGISTRY_PORT );
+implObject = new RmiEchoImpl( UNLIKELY_PORT );
+registry = LocateRegistry.createRegistry( UNLIKELY_PORT );
registry.bind( "echo", implObject );
}
@@ -59,6 +61,7 @@
{
final RmiProvider provider = new RmiProvider();
provider.setName( "echo" );
+provider.setPort( UNLIKELY_PORT );
try
{
provider.getObject();
@@ -82,6 +85,7 @@
{
setUpRegistry();
final RmiProvider provider = new RmiProvider( "echo" );
+provider.setPort( UNLIKELY_PORT );
final RmiEcho echo = ( RmiEcho ) provider.getObject();
assertEquals( "Hello, World!", echo.echoBack( "Hello, World!" ) );
}
@@ -90,6 +94,7 @@
{
setUpRegistry();
final RmiProvider provider = new RmiProvider( "localhost", "echo" );
+provider.setPort( UNLIKELY_PORT );
final RmiEcho echo = ( RmiEcho ) provider.getObject();
assertEquals( "Hello, World!", echo.echoBack( "Hello, World!" ) );
}
@@ -98,6 +103,7 @@
{
setUpRegistry();
final RmiProvider provider = new RmiProvider( "bogus" );
+provider.setPort( UNLIKELY_PORT );
try
{
provider.getObject();
@@ -112,6 +118,7 @@
{
setUpRegistry();
final RmiProvider provider = new RmiProvider( "localhost",
Registry.REGISTRY_PORT, "echo" );
+provider.setPort( UNLIKELY_PORT );
final RmiEcho echo = ( RmiEcho ) provider.getObject();
assertEquals( "Hello, World!", echo.echoBack( "Hello, World!" ) );
}
@@ -119,11 +126,11 @@
public void testGetObjectWithPortAndHostAndFactory() throws Exception
{
setUpRegistry();
-final RmiProvider provider = new RmiProvider( "localhost",
Registry.REGISTRY_PORT,
+final RmiProvider provider = new RmiProvider( "localhost",
UNLIKELY_PORT,
RMISocketFactory.getDefaultSocketFactory(), "echo" );
final RmiEcho echo = ( RmiEcho ) provider.getObject();
assertEquals( "Hello, World!", echo.echoBack( "Hello, World!" ) );
}
-}
\ No newline at end of file
+}
Modified:
jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/util/rmi/RmiEchoImpl.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/util/rmi/RmiEchoImpl.java?rev=429752&r1=429751&r2=429752&view=diff
==
---
jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/util/rmi/RmiEchoImpl.java
(original)
+++
jakarta/commons/sandbox/proxy/trunk/src/test/org/apache/commons/proxy/util/rmi/RmiEchoImpl.java
Tue Aug 8 10:47:28 2006
@@ -24,8 +24,9 @@
*/
public class RmiEchoImpl extends UnicastRemoteObject implements RmiEcho
{
-public RmiEchoImpl() throws RemoteException
+public RmiEchoImpl(int port) throws RemoteException
{
+super(port);
}
public String echoBack( String message ) throws RemoteException
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429751 - /jakarta/commons/sandbox/proxy/trunk/project.properties
Author: bayard Date: Tue Aug 8 10:46:54 2006 New Revision: 429751 URL: http://svn.apache.org/viewvc?rev=429751&view=rev Log: Moved to a source param of 1.2 to help compiling on JDK 1.5 Modified: jakarta/commons/sandbox/proxy/trunk/project.properties Modified: jakarta/commons/sandbox/proxy/trunk/project.properties URL: http://svn.apache.org/viewvc/jakarta/commons/sandbox/proxy/trunk/project.properties?rev=429751&r1=429750&r2=429751&view=diff == --- jakarta/commons/sandbox/proxy/trunk/project.properties (original) +++ jakarta/commons/sandbox/proxy/trunk/project.properties Tue Aug 8 10:46:54 2006 @@ -107,4 +107,5 @@ ## maven.javadoc.links=http://java.sun.com/j2se/1.4.2/docs/api/,http://aopalliance.sourceforge.net/doc,http://gee.cs.oswego.edu/dl/classes/ -maven.compile.target=1.3 \ No newline at end of file +maven.compile.target=1.3 +maven.compile.source=1.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-196) Unexpected error with DBCP and OJB where OJB was unable to get a connection. The root cause appears to be a org.apache.commons.dbcp.SQLNestedException: Cannot get a connect
Unexpected error with DBCP and OJB where OJB was unable to get a connection. The root cause appears to be a org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted, cause: null - Key: DBCP-196 URL: http://issues.apache.org/jira/browse/DBCP-196 Project: Commons Dbcp Issue Type: Bug Environment: Jboss 4.0 commons-dbcp-1.1.jar commons-pool-1.1.jar db-ojb-1.0.rc6.jar Reporter: Eric Ferrer Priority: Critical Attachments: dbcp_exhausted_connection_error.txt Our application has been running fine for 9 months and this is the first time I have encounted this error. It happend randomly throughout the day in an inconsistent pattern (user was entering data on web, user was searching for data, ect.) It did not occur on any particular screen. Attached is the stack trace from OJB Broker loadByExample request to DBCP error. THe rest of the stack trace was ommitted since it involves the uncaught exception entire stack back to the web tier -- 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]
[discovery] Re: commit: r429748 - /jakarta/commons/proper/discovery/trunk/project.properties
I wanted to flag that I changed Discovery to output 1.2 and not 1.1 bytecode. The JDK 1.5 compiler doesn't support this anymore and I couldn't see dropping 1.1 support as being a big deal (none of the rest of Commons supports 1.1 afaik). This was flagged by the nightly build. Hen On 8/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: bayard Date: Tue Aug 8 10:27:10 2006 New Revision: 429748 URL: http://svn.apache.org/viewvc?rev=429748&view=rev Log: Moving discovery from 1.1 files to 1.2 files. The JDK 1.5 compiler no longer supports the 1.1 target/source; and I doubt any other part of Commons supports 1.1. Will flag this with another email on commons-dev Modified: jakarta/commons/proper/discovery/trunk/project.properties Modified: jakarta/commons/proper/discovery/trunk/project.properties URL: http://svn.apache.org/viewvc/jakarta/commons/proper/discovery/trunk/project.properties?rev=429748&r1=429747&r2=429748&view=diff == --- jakarta/commons/proper/discovery/trunk/project.properties (original) +++ jakarta/commons/proper/discovery/trunk/project.properties Tue Aug 8 10:27:10 2006 @@ -31,6 +31,6 @@ maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html maven.xdoc.poweredby.image=maven-feather.png -# generate .class files that can be loaded into a version 1.1 JVM. -maven.compile.target=1.1 -maven.compile.source=1.1 \ No newline at end of file +# generate .class files that can be loaded into a version 1.2 JVM. +maven.compile.target=1.2 +maven.compile.source=1.2 - 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: r429748 - /jakarta/commons/proper/discovery/trunk/project.properties
Author: bayard Date: Tue Aug 8 10:27:10 2006 New Revision: 429748 URL: http://svn.apache.org/viewvc?rev=429748&view=rev Log: Moving discovery from 1.1 files to 1.2 files. The JDK 1.5 compiler no longer supports the 1.1 target/source; and I doubt any other part of Commons supports 1.1. Will flag this with another email on commons-dev Modified: jakarta/commons/proper/discovery/trunk/project.properties Modified: jakarta/commons/proper/discovery/trunk/project.properties URL: http://svn.apache.org/viewvc/jakarta/commons/proper/discovery/trunk/project.properties?rev=429748&r1=429747&r2=429748&view=diff == --- jakarta/commons/proper/discovery/trunk/project.properties (original) +++ jakarta/commons/proper/discovery/trunk/project.properties Tue Aug 8 10:27:10 2006 @@ -31,6 +31,6 @@ maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html maven.xdoc.poweredby.image=maven-feather.png -# generate .class files that can be loaded into a version 1.1 JVM. -maven.compile.target=1.1 -maven.compile.source=1.1 \ No newline at end of file +# generate .class files that can be loaded into a version 1.2 JVM. +maven.compile.target=1.2 +maven.compile.source=1.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r429746 - /jakarta/commons/proper/net/trunk/project.properties
Author: bayard Date: Tue Aug 8 10:25:16 2006 New Revision: 429746 URL: http://svn.apache.org/viewvc?rev=429746&view=rev Log: Setting the source parameter to be 1.2 as well as the target. This lets Net build under 1.5 Modified: jakarta/commons/proper/net/trunk/project.properties Modified: jakarta/commons/proper/net/trunk/project.properties URL: http://svn.apache.org/viewvc/jakarta/commons/proper/net/trunk/project.properties?rev=429746&r1=429745&r2=429746&view=diff == --- jakarta/commons/proper/net/trunk/project.properties (original) +++ jakarta/commons/proper/net/trunk/project.properties Tue Aug 8 10:25:16 2006 @@ -19,6 +19,7 @@ maven.jar.excludes=**/examples/** maven.compile.target=1.2 +maven.compile.source=1.2 # Jar Manifest Additional Attributes maven.jar.manifest.attributes.list=Implementation-Vendor-Id,X-Compile-Source-JDK,X-Compile-Target-JDK - 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_12426637 ] Kohsuke Kawaguchi commented on JELLY-236: - The change I made was to change the way the trimming happens. Specifically, I changed TagUtils.trimScript() and methods that are called from there, to perform the whitespace stripping like XSLT. So the compatibility implications are for the generated XML result, not for the code. > 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: > // text between two start tags > // 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: >x >y > Jelly agressively trims off whitespaces, even if they are not ignorable. So > in the above cases, it becomes: > x > y > 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: >some text here > ... becomes: > some texthere > 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: [JEXL] 1.1 now? (was: Re: [jira] Resolved: (JEXL-17) )
I am not familiar with jexl but has the bug that's causing us [1] ever been fixed? -Lukas [1] http://jira.codehaus.org/browse/MAVEN-410 Dion Gillard wrote: 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. > 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. > > --- > > - 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: r429679 - in /jakarta/commons/sandbox/finder/trunk: project.properties project.xml
Author: bayard Date: Tue Aug 8 08:06:49 2006 New Revision: 429679 URL: http://svn.apache.org/viewvc?rev=429679&view=rev Log: Now that [io] builds again, switch to depending on the nightly build (which should let finder build on the nightly too). Just need to make sure that build failure doesn't get rid of a snapshot jar in the m1 snapshot repo Modified: jakarta/commons/sandbox/finder/trunk/project.properties jakarta/commons/sandbox/finder/trunk/project.xml Modified: jakarta/commons/sandbox/finder/trunk/project.properties URL: http://svn.apache.org/viewvc/jakarta/commons/sandbox/finder/trunk/project.properties?rev=429679&r1=429678&r2=429679&view=diff == --- jakarta/commons/sandbox/finder/trunk/project.properties (original) +++ jakarta/commons/sandbox/finder/trunk/project.properties Tue Aug 8 08:06:49 2006 @@ -12,6 +12,8 @@ # See the License for the specific language governing permissions and # limitations under the License. +maven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://www.ibiblio.org/maven/ + maven.compile.source=1.2 maven.compile.target=1.2 Modified: jakarta/commons/sandbox/finder/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/sandbox/finder/trunk/project.xml?rev=429679&r1=429678&r2=429679&view=diff == --- jakarta/commons/sandbox/finder/trunk/project.xml (original) +++ jakarta/commons/sandbox/finder/trunk/project.xml Tue Aug 8 08:06:49 2006 @@ -72,7 +72,7 @@ commons-io commons-io - 1.3-SNAPSHOT + SNAPSHOT http://jakarta.apache.org/commons/io/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[nightly build] discovery net proxy finder failed.
Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20060808/discovery.log http://people.apache.org/~psteitz/commons-nightlies/20060808/net.log http://people.apache.org/~psteitz/commons-nightlies/20060808/proxy.log http://people.apache.org/~psteitz/commons-nightlies/20060808/finder.log - 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_12426488 ] Sitthichai Rernglertpricha commented on SCXML-15: - Thanks. I am trying to host the SCXMLExecutor on a web container. While I am processing the HTTPRequest, I wanted only to populate the current Context with the HTTP request attributes, so that the EL expression or JEXL expression can process them as if they are local variables within the state. Hence, I raised a request for the SCXMLExecutor to expose the current Context object for updating purpose. However, I just realized that I can create a Map object containing the HTTP request attributes and passed the Map as the payload object of the event that is triggered to the SCXMLExecutor. In this manner, the EL or JEXL expression can access these request attributes via "_eventdata.". This approach resolved my problem, without "polluting" the current Context with unnecessary attributes. > 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]
