[jira] Updated: (IO-71) [io] PipedUtils
[
https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated IO-71:
Attachment: ReverseFilterOutputStream.patch
See the attached patch (ReverseFilterInputStream.patch) for a simple draft (not
thoroughly tested or documented) of a class that turns an OutputStream filter
into an InputStream filter without the need for an extra thread or a pipe.
With the ReverseFilterInputStream class your example test case would become:
{code}
//starting data
InputStream original = new ByteArrayInputStream("hello
world".getBytes("us-ascii"));
// Compress
InputStream reversed = new ReverseFilterInputStream(original,
GZIPOutputStream.class);
// Uncompress
InputStream results = new GZIPInputStream(reversed);
//show results
StringWriter swresult = new StringWriter();
CopyUtils.copy(results,swresult);
assertEquals("hello world", swresult.toString());
{code}
> [io] PipedUtils
> ---
>
> Key: IO-71
> URL: https://issues.apache.org/jira/browse/IO-71
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Environment: Operating System: All
> Platform: All
>Reporter: David Smiley
>Priority: Minor
> Fix For: 2.x
>
> Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch
>
>
> I developed some nifty code that takes an OutputStream and sort of reverses
> it as if it were an
> InputStream. Error passing and handling close is dealt with. It needs
> another thread to do the work
> which runs in parallel. It uses Piped streams. I created this because I
> had to conform
> GZIPOutputStream to my framework which demanded an InputStream.
> See URL to source.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-71) [io] PipedUtils
[ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568382#action_12568382 ] David Smiley commented on IO-71: Jukka... I'm not going to tell you your code doesn't work, but it predictably suffers from the problems I told you about (reference my paragraph starting with "The 2nd thread is a ..."). Did you understand what I had to say? If you need an example, I'll elaborate giving you a hypothetical situation. Perhaps in spite of these problems, it may be something that people find useful provided that it's documentation heavily warn users of its limitations. Personally, I wouldn't use it. Is requiring a thread to avoid these problem all that bad any way? > [io] PipedUtils > --- > > Key: IO-71 > URL: https://issues.apache.org/jira/browse/IO-71 > Project: Commons IO > Issue Type: Improvement > Components: Utilities > Environment: Operating System: All > Platform: All >Reporter: David Smiley >Priority: Minor > Fix For: 2.x > > Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch > > > I developed some nifty code that takes an OutputStream and sort of reverses > it as if it were an > InputStream. Error passing and handling close is dealt with. It needs > another thread to do the work > which runs in parallel. It uses Piped streams. I created this because I > had to conform > GZIPOutputStream to my framework which demanded an InputStream. > See URL to source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-412) StrBuilder appendFixedWidth does not handle nulls
StrBuilder appendFixedWidth does not handle nulls - Key: LANG-412 URL: https://issues.apache.org/jira/browse/LANG-412 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Environment: Java 1.5 Reporter: Peter Oxenham Appending a null value with fixed width causes a null pointer exception if getNullText() has not been set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EMAIL-69) HtmlEmail generated email don't display in Macos X Mail.app
[
https://issues.apache.org/jira/browse/EMAIL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568431#action_12568431
]
Chris Beaumont commented on EMAIL-69:
-
Sadly, patch is incomplete: now it is broken when you have an embed'ded image
...
email.setHostName("smtp-server");
email.addTo("[EMAIL PROTECTED]", "John Doe");
email.setFrom("[EMAIL PROTECTED]", "Me");
email.setSubject("Test email with inline image");
URLurl = new
URL("http://www.apache.org/images/asf_logo_wide.gif";);
String cid = email.embed(url, "Apache logo");
email.setHtmlMsg("TESTINGTESTINGThe apache logo -
");
email.setTextMsg("Your email client does not support HTML
messages");
email.send();
This will display the Apache logo all by itself (since we have a
multipart/alternative FIRST).
Assignment of boolean in the patch should read:
boolean useAlternative = (EmailUtils.isNotEmpty(this.html)
&& EmailUtils.isNotEmpty(this.text)
&& (this.inlineEmbeds.size() == 0)
// This was lost from Tobias's post
);
[i.e., use alternative when we have text AND html but NO embed (if embed, then
it is covered by the sub-container) ]
> HtmlEmail generated email don't display in Macos X Mail.app
> ---
>
> Key: EMAIL-69
> URL: https://issues.apache.org/jira/browse/EMAIL-69
> Project: Commons Email
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Macos X 10.4 with Mail.app
>Reporter: Numa Schmeder
> Attachments: EMAIL-69-fix.patch, EMAIL-69-test.patch
>
>
> Hi,
> The mail generated by HtmlEmail seems boggus in its mime layout. Mail.app
> doesn't recognize and display the html part when you send a mail with a Html
> and Text part as alternative.
> For example this email will only display the text part and not the html part
> on Mail.app:
> HtmlEmail htmlEmail = new HtmlEmail();
> htmlEmail.setHtmlMsg(htmlMessage);
> htmlEmail.setTextMsg(textMessage);
> email.setFrom(from,fromName);
> email.addTo(to, toName);
> email.setSubject(subject);
> email.send();
>
> But this email will disply correctly the html in Mail.app:
> HtmlEmail htmlEmail = new HtmlEmail();
> htmlEmail.setHtmlMsg(htmlMessage);
> email.setFrom(from,fromName);
> email.addTo(to, toName);
> email.setSubject(subject);
> email.send();
> The bug might be I think in the mime layout, I looked at the raw email
> source and the mime layout is as follow:
> MIME-Version: 1.0
> Content-Type: multipart/related;
> boundary="=_Part_0_11727281.1194085710604"
> --=_Part_0_11727281.1194085710604
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> Ch=C3=A8re Mme Dupont ,=20
> Text Blah blah
> --=_Part_0_11727281.1194085710604
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> http://www.=
> w3.org/TR/html4/loose.dtd">
>
>
>
> =
> =20
> =09 My Email
>
> >
> Ch=C3=A8re Mme Dupont ,=20
>
> Blah Blah html content
>
>
> --=_Part_0_11727281.1194085710604--
> This is wrong, I am not an expert but shouldn't it be multipart/alternative ?
> In all other html email I have checked the mime layout uses
> multipart/alternative.
> I hop there is a quick fix for this.
> Thank you for your help.
> Numa
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-412) StrBuilder appendFixedWidth does not handle nulls
[ https://issues.apache.org/jira/browse/LANG-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568433#action_12568433 ] Henri Yandell commented on LANG-412: Confirmed (visually). As appendNull's effect is to do nothing if it is set to null, my assumption is that having nullText be null is merely an optmization for the empty String. So I think the solution will be to make the fixed width methods use an empty string if they get back a null nullText. > StrBuilder appendFixedWidth does not handle nulls > - > > Key: LANG-412 > URL: https://issues.apache.org/jira/browse/LANG-412 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.3 > Environment: Java 1.5 >Reporter: Peter Oxenham > Fix For: 2.4 > > > Appending a null value with fixed width causes a null pointer exception if > getNullText() has not been set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-412) StrBuilder appendFixedWidth does not handle nulls
[ https://issues.apache.org/jira/browse/LANG-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-412: --- Fix Version/s: 2.4 > StrBuilder appendFixedWidth does not handle nulls > - > > Key: LANG-412 > URL: https://issues.apache.org/jira/browse/LANG-412 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.3 > Environment: Java 1.5 >Reporter: Peter Oxenham > Fix For: 2.4 > > > Appending a null value with fixed width causes a null pointer exception if > getNullText() has not been set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-412) StrBuilder appendFixedWidth does not handle nulls
[ https://issues.apache.org/jira/browse/LANG-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-412: --- Attachment: LANG-412.patch Attaching tests and a fix (null -> ""). > StrBuilder appendFixedWidth does not handle nulls > - > > Key: LANG-412 > URL: https://issues.apache.org/jira/browse/LANG-412 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.3 > Environment: Java 1.5 >Reporter: Peter Oxenham > Fix For: 2.4 > > Attachments: LANG-412.patch > > > Appending a null value with fixed width causes a null pointer exception if > getNullText() has not been set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-412) StrBuilder appendFixedWidth does not handle nulls
[ https://issues.apache.org/jira/browse/LANG-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-412. -- Resolution: Fixed svn ci -m "Applying my patch from LANG-412; fixing Peter Oxenham's report that the appendFixedWidthPadRight and appendFixedWidthPadLeft are not null safe if the nullText has not been set" src Sendingsrc/java/org/apache/commons/lang/text/StrBuilder.java Sendingsrc/test/org/apache/commons/lang/text/StrBuilderTest.java Transmitting file data .. Committed revision 627248. > StrBuilder appendFixedWidth does not handle nulls > - > > Key: LANG-412 > URL: https://issues.apache.org/jira/browse/LANG-412 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.3 > Environment: Java 1.5 >Reporter: Peter Oxenham > Fix For: 2.4 > > Attachments: LANG-412.patch > > > Appending a null value with fixed width causes a null pointer exception if > getNullText() has not been set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
[ https://issues.apache.org/jira/browse/LANG-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568247#action_12568247 ] Niall Pemberton commented on LANG-409: -- Validator has GenericValidator.minLength(String, int) - but it doesn't do the "ignoring whitespace" bit: http://tinyurl.com/2ne6qk > StringUtils.isText to check in a null safe way if a String has (real) text > -- > > Key: LANG-409 > URL: https://issues.apache.org/jira/browse/LANG-409 > Project: Commons Lang > Issue Type: Improvement >Reporter: Jörg Gottschling >Priority: Minor > > I used something similar from the Spring Framework and it was useful. I > suggest two methods where the second is a little more advanced then theirs. > First a method StringUtils.isText(String text) : boolean which checks if the > String is not null and contains a least one not whitespace character. (In > Spring it's "hasText", but "isText" seams to be more consistent within > commons lang.) > The second method could be StringUtils.isText(String text, int n) : boolean > which checks if the String is not null and contains a least n not whitespace > characters. > Question: What happens if a (stupid ;-) developer checks for -5 characters? I > think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
[ https://issues.apache.org/jira/browse/LANG-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568236#action_12568236 ] [EMAIL PROTECTED] edited comment on LANG-409 at 2/12/08 9:38 AM: Then maybe this request belongs to to the [validator] ([http://commons.apache.org/validator/]) project. was (Author: [EMAIL PROTECTED]): Then maybe this request belongs to to the [validation] project. > StringUtils.isText to check in a null safe way if a String has (real) text > -- > > Key: LANG-409 > URL: https://issues.apache.org/jira/browse/LANG-409 > Project: Commons Lang > Issue Type: Improvement >Reporter: Jörg Gottschling >Priority: Minor > > I used something similar from the Spring Framework and it was useful. I > suggest two methods where the second is a little more advanced then theirs. > First a method StringUtils.isText(String text) : boolean which checks if the > String is not null and contains a least one not whitespace character. (In > Spring it's "hasText", but "isText" seams to be more consistent within > commons lang.) > The second method could be StringUtils.isText(String text, int n) : boolean > which checks if the String is not null and contains a least n not whitespace > characters. > Question: What happens if a (stupid ;-) developer checks for -5 characters? I > think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-408) StringUtils.isLength(String string, int length) : boolean
[ https://issues.apache.org/jira/browse/LANG-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568235#action_12568235 ] Jörg Gottschling commented on LANG-408: --- Sorry I do not understand you first comment. What do you think is better? And which method was added? I think your one is more flexible. > StringUtils.isLength(String string, int length) : boolean > - > > Key: LANG-408 > URL: https://issues.apache.org/jira/browse/LANG-408 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Jörg Gottschling >Priority: Minor > > Just a null safe way to check the length of an String. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
[ https://issues.apache.org/jira/browse/LANG-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568233#action_12568233 ] Jörg Gottschling commented on LANG-409: --- Yes, but mainly with validation of user inputs, I think. I remember just one other case, where a String had to be at least three 'real' characters long. All other cases where more complex, like 40 hex chars or something like that. > StringUtils.isText to check in a null safe way if a String has (real) text > -- > > Key: LANG-409 > URL: https://issues.apache.org/jira/browse/LANG-409 > Project: Commons Lang > Issue Type: Improvement >Reporter: Jörg Gottschling >Priority: Minor > > I used something similar from the Spring Framework and it was useful. I > suggest two methods where the second is a little more advanced then theirs. > First a method StringUtils.isText(String text) : boolean which checks if the > String is not null and contains a least one not whitespace character. (In > Spring it's "hasText", but "isText" seams to be more consistent within > commons lang.) > The second method could be StringUtils.isText(String text, int n) : boolean > which checks if the String is not null and contains a least n not whitespace > characters. > Question: What happens if a (stupid ;-) developer checks for -5 characters? I > think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SANDBOX-210) Commons CSV EXCELL_STRATEGY is reading CSV files with double quote and comma properly but not writing them back the same way
Commons CSV EXCELL_STRATEGY is reading CSV files with double quote and comma properly but not writing them back the same way Key: SANDBOX-210 URL: https://issues.apache.org/jira/browse/SANDBOX-210 Project: Commons Sandbox Issue Type: Bug Components: CSV Reporter: Ilya Egoshin original line: My line is containing ", symbols line in CSV file after "Save as CSV" in Excell: "My line containing "", symbols" line is CSV file as output from CSVPrinter with EXCELL_STRATEGY: "My line containing \", symbols" as a result when you will try to open that file in the excell you see text inside two cells: 1 cell: My line containing \ 2 cell: symbols is it again Microsoft "features", that are "improving" RFC? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-305) PropertyUtilsBean.isWritable() returns false when the property is mapped and there is a mapped write method available
[
https://issues.apache.org/jira/browse/BEANUTILS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-305.
---
Resolution: Duplicate
Fix Version/s: 1.8.0-BETA
> PropertyUtilsBean.isWritable() returns false when the property is mapped and
> there is a mapped write method available
> --
>
> Key: BEANUTILS-305
> URL: https://issues.apache.org/jira/browse/BEANUTILS-305
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.7.0
> Environment: jdk 1.4.2
>Reporter: Stuart Brown
> Fix For: 1.8.0-BETA
>
>
> PropertyUtilsBean.isWritable returns false when there is a mapped property
> write method. It does not do this on indexed properties, I am not sure why
> mapped properties would be handled differently, but I do not believe they
> should be. Also this means there is no method in the class to test for
> writable mapped properties.
> Also PropertyUtilsBean.isReadable has the same issue and the fix is similar.
> Following code should work :
> 1185Method writeMethod = desc.getWriteMethod();
> 1186if ((writeMethod == null) &&
> 1187(desc instanceof IndexedPropertyDescriptor)) {
> 1188writeMethod = ((IndexedPropertyDescriptor)
> desc).getIndexedWriteMethod();
> 1189}
> + if (( writeMethod==null) &&
> + (desc instanceof MappedPropertyDescriptor)) {
> + writeMethod =
> ((MappedPropertyDescriptor)desc).getMappedWriteMethod();
> +}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
[ https://issues.apache.org/jira/browse/LANG-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568236#action_12568236 ] Gary Gregory commented on LANG-409: --- Then maybe this request belongs to to the [validation] project. > StringUtils.isText to check in a null safe way if a String has (real) text > -- > > Key: LANG-409 > URL: https://issues.apache.org/jira/browse/LANG-409 > Project: Commons Lang > Issue Type: Improvement >Reporter: Jörg Gottschling >Priority: Minor > > I used something similar from the Spring Framework and it was useful. I > suggest two methods where the second is a little more advanced then theirs. > First a method StringUtils.isText(String text) : boolean which checks if the > String is not null and contains a least one not whitespace character. (In > Spring it's "hasText", but "isText" seams to be more consistent within > commons lang.) > The second method could be StringUtils.isText(String text, int n) : boolean > which checks if the String is not null and contains a least n not whitespace > characters. > Question: What happens if a (stupid ;-) developer checks for -5 characters? I > think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (POOL-124) Access to enclosing constructor Foo.Bar() is emulated by a synthetic accessor method. Increasing its visibility will improve your performance.
Access to enclosing constructor Foo.Bar() is emulated by a synthetic accessor
method. Increasing its visibility will improve your performance.
--
Key: POOL-124
URL: https://issues.apache.org/jira/browse/POOL-124
Project: Commons Pool
Issue Type: Improvement
Affects Versions: 1.4
Environment: Eclipse Compiler 3.3M5.
Reporter: Gary Gregory
Fix For: 2.0
Fix compiler warnings like:
{quote}
Access to enclosing constructor GenericKeyedObjectPool.ObjectQueue() is
emulated by a synthetic accessor method. Increasing its visibility will improve
your performance."
{quote}
By definition, when a class element is private, it cannot be seen from outside
the scope of the type that defines it. The compiler treats inner classes with
some special processing though.
Here is Olivier Thomann's explanation [1]:
"You get this warning as soon as you access a private member (fields or
methods) of the enclosing class inside an inner class (anonymous, local or
member classes).
The compiler uses a static access method to access the private member in order
to workaround the VM access violation. You cannot access directly a private
member from another class. From the VM point of view, an inner class is a
different class and has no relation with its enclosing class.
So doing this access to a private member you pay the price of a method
invocation each time you access the member at runtime. This is not the case if
the member is package visible."
Gary
[1] http://dev.eclipse.org/mhonarc/lists/jdt-dev/msg00145.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (BEANUTILS-305) PropertyUtilsBean.isWritable() returns false when the property is mapped and there is a mapped write method available
PropertyUtilsBean.isWritable() returns false when the property is mapped and
there is a mapped write method available
--
Key: BEANUTILS-305
URL: https://issues.apache.org/jira/browse/BEANUTILS-305
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: jdk 1.4.2
Reporter: Stuart Brown
PropertyUtilsBean.isWritable returns false when there is a mapped property
write method. It does not do this on indexed properties, I am not sure why
mapped properties would be handled differently, but I do not believe they
should be. Also this means there is no method in the class to test for writable
mapped properties.
Also PropertyUtilsBean.isReadable has the same issue and the fix is similar.
Following code should work :
1185Method writeMethod = desc.getWriteMethod();
1186if ((writeMethod == null) &&
1187(desc instanceof IndexedPropertyDescriptor)) {
1188writeMethod = ((IndexedPropertyDescriptor)
desc).getIndexedWriteMethod();
1189}
+ if (( writeMethod==null) &&
+ (desc instanceof MappedPropertyDescriptor)) {
+ writeMethod =
((MappedPropertyDescriptor)desc).getMappedWriteMethod();
+}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SCXML-68) Javascript expression evaluator
[ https://issues.apache.org/jira/browse/SCXML-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-68: --- Fix Version/s: 1.0 > Javascript expression evaluator > --- > > Key: SCXML-68 > URL: https://issues.apache.org/jira/browse/SCXML-68 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Tony Seebregts >Priority: Minor > Fix For: 1.0 > > Attachments: org.apache.commons.scxml.env.javascript.zip > > > A Javascript expression evaluator for SCXML expression offers some > functionality (e.g. functions) not supported by the sample JEXL expression > evaluator included in the SCXML project - and is easily implemented as a > wrapper around the Javascript engine included in the Java 6 JDK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SCXML-68) Javascript expression evaluator
[ https://issues.apache.org/jira/browse/SCXML-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568151#action_12568151 ] Rahul Akolkar commented on SCXML-68: Thanks, looks good. Please note, there are no @author tags in the Commons SCXML codebase. If you can please attach a newer version that does not have these tags, we can add this to the J5 branch (in svn). Attribution is in terms of the listing on the project team page: http://commons.apache.org/scxml/team-list.html As you mentioned on the user list, we will need tests. Of lesser importance, it'd be great if you could use the existing conventions for placement of curly braces in Java source. I can do this later, if you prefer. > Javascript expression evaluator > --- > > Key: SCXML-68 > URL: https://issues.apache.org/jira/browse/SCXML-68 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Tony Seebregts >Priority: Minor > Attachments: org.apache.commons.scxml.env.javascript.zip > > > A Javascript expression evaluator for SCXML expression offers some > functionality (e.g. functions) not supported by the sample JEXL expression > evaluator included in the SCXML project - and is easily implemented as a > wrapper around the Javascript engine included in the Java 6 JDK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-410) Ambiguous / confusing names in StringUtils replace* methods
[ https://issues.apache.org/jira/browse/LANG-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568448#action_12568448 ] Henri Yandell commented on LANG-410: Looks good - but the patch doesn't work. I think Gary and Matt made changes just after you did this and it's thrown things off. Could you update and repatch? > Ambiguous / confusing names in StringUtils replace* methods > --- > > Key: LANG-410 > URL: https://issues.apache.org/jira/browse/LANG-410 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb >Priority: Minor > Attachments: StringUtils.patch > > > The recently added replaceEach* methods use "repl" for the original string > list, and "with" for the new (replacement) string list. > These names are rather confusing. > RE engines tend to use words such as: > Perl: > searchlist > replacementlist > ORO: > pattern > replacement > Java has String.replace(regex, replacement) > In all cases, "replacement" is used for the NEW string, not the original > string which is to be replaced. > Seems to me that searchString/List and replacement[List] would be unambiguous > as well as descriptive. > Also useful in IDEs which show possible method completions. > Changing the names of the parameters would not affect the API. > Patch to follow -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-410) Ambiguous / confusing names in StringUtils replace* methods
[ https://issues.apache.org/jira/browse/LANG-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-410: --- Fix Version/s: 2.4 > Ambiguous / confusing names in StringUtils replace* methods > --- > > Key: LANG-410 > URL: https://issues.apache.org/jira/browse/LANG-410 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb >Priority: Minor > Fix For: 2.4 > > Attachments: StringUtils.patch > > > The recently added replaceEach* methods use "repl" for the original string > list, and "with" for the new (replacement) string list. > These names are rather confusing. > RE engines tend to use words such as: > Perl: > searchlist > replacementlist > ORO: > pattern > replacement > Java has String.replace(regex, replacement) > In all cases, "replacement" is used for the NEW string, not the original > string which is to be replaced. > Seems to me that searchString/List and replacement[List] would be unambiguous > as well as descriptive. > Also useful in IDEs which show possible method completions. > Changing the names of the parameters would not affect the API. > Patch to follow -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-410) Ambiguous / confusing names in StringUtils replace* methods
[ https://issues.apache.org/jira/browse/LANG-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568448#action_12568448 ] bayard edited comment on LANG-410 at 2/12/08 10:58 PM: -- Looks good - but the patch doesn't work. I think Gary and Matt made changes just after you did this and it's thrown things off. Could you update and repatch or commit? was (Author: bayard): Looks good - but the patch doesn't work. I think Gary and Matt made changes just after you did this and it's thrown things off. Could you update and repatch? > Ambiguous / confusing names in StringUtils replace* methods > --- > > Key: LANG-410 > URL: https://issues.apache.org/jira/browse/LANG-410 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb >Priority: Minor > Fix For: 2.4 > > Attachments: StringUtils.patch > > > The recently added replaceEach* methods use "repl" for the original string > list, and "with" for the new (replacement) string list. > These names are rather confusing. > RE engines tend to use words such as: > Perl: > searchlist > replacementlist > ORO: > pattern > replacement > Java has String.replace(regex, replacement) > In all cases, "replacement" is used for the NEW string, not the original > string which is to be replaced. > Seems to me that searchString/List and replacement[List] would be unambiguous > as well as descriptive. > Also useful in IDEs which show possible method completions. > Changing the names of the parameters would not affect the API. > Patch to follow -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-408) StringUtils.isLength(String string, int length) : boolean
[ https://issues.apache.org/jira/browse/LANG-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-408. -- Resolution: Won't Fix StringUtils.length(String) was just added; so I'm going to close this as a WONTFIX as it sounds like you prefer that too :) > StringUtils.isLength(String string, int length) : boolean > - > > Key: LANG-408 > URL: https://issues.apache.org/jira/browse/LANG-408 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Jörg Gottschling >Priority: Minor > > Just a null safe way to check the length of an String. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-71) [io] PipedUtils
[ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568119#action_12568119 ] David Smiley commented on IO-71: I change my mind... a pair of parallel classes don't have access to the originating InputStream to close... nor do they know what particular IOException needs to get propagated forward. Perhaps you could have setters for these... but I think in the end, using these hypothetical pair of improved piped streams would result in code less natural to use than my PipedUtils. > [io] PipedUtils > --- > > Key: IO-71 > URL: https://issues.apache.org/jira/browse/IO-71 > Project: Commons IO > Issue Type: Improvement > Components: Utilities > Environment: Operating System: All > Platform: All >Reporter: David Smiley >Priority: Minor > Fix For: 2.x > > Attachments: PipedUtils.zip > > > I developed some nifty code that takes an OutputStream and sort of reverses > it as if it were an > InputStream. Error passing and handling close is dealt with. It needs > another thread to do the work > which runs in parallel. It uses Piped streams. I created this because I > had to conform > GZIPOutputStream to my framework which demanded an InputStream. > See URL to source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-405) StringUtils.truncate() to cut out middle part of a String
[ https://issues.apache.org/jira/browse/LANG-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-405: --- Fix Version/s: 3.0 So public String truncateMiddle(String str, String middle, int length); I think it would be worth looking at further - so patches welcome :) Putting in 3.0 until someone codes something. > StringUtils.truncate() to cut out middle part of a String > - > > Key: LANG-405 > URL: https://issues.apache.org/jira/browse/LANG-405 > Project: Commons Lang > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Gregor B. Rosenauer >Priority: Minor > Fix For: 3.0 > > > It would be handy to have a String method that cuts out the middle part of a > String such that as much as possible is kept from the start and end of the > String, but the middle part is replaced by an ellipsis "..." > BeOS had a function like this, but it's poorly documented, missing examples: > http://www.beunited.org/bebook/The%20Support%20Kit/String.html#Truncate() > e.g.: > A very long text with unimportant stuff in the middle but interesting start > and end to see if the text is complete. > becomes: > A very long text...to see if the text is complete. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SCXML-68) Javascript expression evaluator
[ https://issues.apache.org/jira/browse/SCXML-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Seebregts updated SCXML-68: Description: A Javascript expression evaluator for SCXML expression offers some functionality (e.g. functions) not supported by the sample JEXL expression evaluator included in the SCXML project - and is easily implemented as a wrapper around the Javascript engine included in the Java 6 JDK. (was: A Javascript expression evaluator for SCXML expression offers some functionality not supported by the sample JEXL expression evaluator included in the SCXML project - and is easily implemented as a wrapper around the Javascript engine included in the Java 6 JDK.) > Javascript expression evaluator > --- > > Key: SCXML-68 > URL: https://issues.apache.org/jira/browse/SCXML-68 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Tony Seebregts >Priority: Minor > Attachments: org.apache.commons.scxml.env.javascript.zip > > > A Javascript expression evaluator for SCXML expression offers some > functionality (e.g. functions) not supported by the sample JEXL expression > evaluator included in the SCXML project - and is easily implemented as a > wrapper around the Javascript engine included in the Java 6 JDK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SCXML-68) Javascript expression evaluator
[ https://issues.apache.org/jira/browse/SCXML-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568054#action_12568054 ] tonys edited comment on SCXML-68 at 2/12/08 3:31 AM: -- Preliminary implementation of a Javascript expression evaluator. Does not yet include test cases or support for E4X but does support the Data() function as per the JEXL expression evaluator. was (Author: tonys): Preliminary implementation of a Javascript expression evaluator, implemented as a wrapper around the Javascript engine in Java 6. Does not yet include test cases or support for E4X but does support the Data() function as per the JEXL expression evaluator. > Javascript expression evaluator > --- > > Key: SCXML-68 > URL: https://issues.apache.org/jira/browse/SCXML-68 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Tony Seebregts >Priority: Minor > Attachments: org.apache.commons.scxml.env.javascript.zip > > > A Javascript expression evaluator for SCXML expression offers some > functionality not supported by the sample JEXL expression evaluator included > in the SCXML project - and is easily implemented as a wrapper around the > Javascript engine included in the Java 6 JDK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SCXML-68) Javascript expression evaluator
[ https://issues.apache.org/jira/browse/SCXML-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Seebregts updated SCXML-68: Attachment: org.apache.commons.scxml.env.javascript.zip Preliminary implementation of a Javascript expression evaluator, implemented as a wrapper around the Javascript engine in Java 6. Does not yet include test cases or support for E4X but does support the Data() function as per the JEXL expression evaluator. > Javascript expression evaluator > --- > > Key: SCXML-68 > URL: https://issues.apache.org/jira/browse/SCXML-68 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Tony Seebregts >Priority: Minor > Attachments: org.apache.commons.scxml.env.javascript.zip > > > A Javascript expression evaluator for SCXML expression offers some > functionality not supported by the sample JEXL expression evaluator included > in the SCXML project - and is easily implemented as a wrapper around the > Javascript engine included in the Java 6 JDK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SCXML-68) Javascript expression evaluator
Javascript expression evaluator --- Key: SCXML-68 URL: https://issues.apache.org/jira/browse/SCXML-68 Project: Commons SCXML Issue Type: Improvement Affects Versions: 0.7 Reporter: Tony Seebregts Priority: Minor A Javascript expression evaluator for SCXML expression offers some functionality not supported by the sample JEXL expression evaluator included in the SCXML project - and is easily implemented as a wrapper around the Javascript engine included in the Java 6 JDK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
