Re: Problems with private directory
The issues list is mostly for automated posts (such as JIRA). Please
post to the user list instead and clarify what Commons component you
are talking about by using an email subject containing the component
name prefix in square brackets.
-Rahul
On Thu, Sep 11, 2008 at 4:06 PM, magaupe <[EMAIL PROTECTED]> wrote:
>
> I'm trying to access a directory that is only visible when connected with
> determined user. How can I do this?
> This is what's going on:
>
> [code]
> connect("ftp.e***a.intranet");
> login("f***1","");
> [/code]
>
> These to methods return me true but when I try to change directory using
> changeWorkingDirectory() passing the private directory it returns me false
> as if it could not find it. I verify the current directory using
> printWorkingDirectory() and this is the one that is coming:
> "/VM/maqvm/fcpc". It seems it's just not recognizing private directory cause
> when I change to a public one it works fine.
> Any help would be appreciated.
> --
> View this message in context:
> http://www.nabble.com/Problems-with-private-directory-tp19443416p19443416.html
> Sent from the Commons - Issues mailing list archive at Nabble.com.
>
>
Problems with private directory
I'm trying to access a directory that is only visible when connected with
determined user. How can I do this?
This is what's going on:
[code]
connect("ftp.e***a.intranet");
login("f***1","");
[/code]
These to methods return me true but when I try to change directory using
changeWorkingDirectory() passing the private directory it returns me false
as if it could not find it. I verify the current directory using
printWorkingDirectory() and this is the one that is coming:
"/VM/maqvm/fcpc". It seems it's just not recognizing private directory cause
when I change to a public one it works fine.
Any help would be appreciated.
--
View this message in context:
http://www.nabble.com/Problems-with-private-directory-tp19443416p19443416.html
Sent from the Commons - Issues mailing list archive at Nabble.com.
[jira] Updated: (JXPATH-12) Descendant or self axis does not work correctly at root node
[
https://issues.apache.org/jira/browse/JXPATH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murty Gurajada updated JXPATH-12:
-
Attachment: xpathEvalBug.zip
Attached zip file contains a package with the JUnit test
org.apache.commons.jxpath.test.TestDescOrSelfEval.java that I ran in Java 1.5
to demo a bug when an Element node context is passed to evaluate an xpath
expression starting with '//'
> Descendant or self axis does not work correctly at root node
>
>
> Key: JXPATH-12
> URL: https://issues.apache.org/jira/browse/JXPATH-12
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.2 Final
> Environment: Operating System: other
> Platform: Other
>Reporter: Simon Raess
> Fix For: 1.3
>
> Attachments: DescendantOrSelfTest.java, patch.jxpath-12.txt,
> xpathEvalBug.zip
>
>
> Given the following XML document:
> and the XPath: //root/@id/text().
> JXPath returns null instead of "1234".
> JXPathContext context = JXPathContext.newContext(doc);
> assertEquals(value, context.selectSingleNode("//root/@id/text()"));
> The attached JUnit test highlights the problem. It seems that JXPath does not
> find the root node if it is accessed with the axis descendant-or-self.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JXPATH-12) Descendant or self axis does not work correctly at root node
[
https://issues.apache.org/jira/browse/JXPATH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630238#action_12630238
]
Murty Gurajada commented on JXPATH-12:
--
The fix that is in JXPath 1.3 appears to solve only part of the problem. When
the context node supplied to JXPath is a Document, the evaluation of the XPath
correctly returns the expected data. However, if the context node is an
Element, the xpath expression does not evaluate correctly. Specifically, the
behavior in JXPath 1.3 does not appear to be consistent with javax.xml.xpath in
Java 1.5 as well as the text in XPath 1.0 specification.
>From the Xpath specification at:
http://www.w3.org/TR/xpath
descendant-or-self::para selects the para element descendants of the context
node and, if the context node is a para element, the context node as well
Section '2.5 Abbreviated Syntax' clarifies with an example:
//para selects all the para descendants of the document root and thus selects
all para elements in the same document as the context node
Please see the attached zip file (xpathEvalBug.zip) containing a package with
the JUnit test org.apache.commons.jxpath.test.TestDescOrSelfEval.java that I
ran in Java 1.5.
I have used the same xml fragment used in the bug report:
The class contains 4 tests:
1. testJXPathDescOrSelfWithDoc() throws Exception tests JXPath evaluation of a
descendant-or-self ('//') expression on a Document context
This test returns the expected data in JXPath 1.3 whereas it used to fail in
JXPath 1.2.
2. testJXPathDescOrSelfWithEl() throws Exception tests JXPath evaluation of a
descendant-or-self ('//') expression on an Element context (for 'root')
This test does not return the expected data in JXPath 1.3. It also used to fail
in JXPath 1.2.
3. testXPathDescOrSelfWithDoc() tests javax.xml.xpath evaluation of a
descendant-or-self ('//') expression on a Document context
This test returns the expected data.
4. testXPathDescOrSelfWithEl() tests javax.xml.xpath evaluation of a
descendant-or-self ('//') expression on an Element context (for 'root')
This test returns the expected data.
If you run the attached JUnit test in java 1.5, the javax.xml.xpath
implementation returns data consistent with the text of the specification. I
really want to use JXPath in my project because some tests I ran show it is
much faster than javax.xml.xpath. However, this issue is preventing me from
migrating to JXPath. Is it possible to fix this issue? If yes, how soon would
it be available for download?
> Descendant or self axis does not work correctly at root node
>
>
> Key: JXPATH-12
> URL: https://issues.apache.org/jira/browse/JXPATH-12
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.2 Final
> Environment: Operating System: other
> Platform: Other
>Reporter: Simon Raess
> Fix For: 1.3
>
> Attachments: DescendantOrSelfTest.java, patch.jxpath-12.txt
>
>
> Given the following XML document:
> and the XPath: //root/@id/text().
> JXPath returns null instead of "1234".
> JXPathContext context = JXPathContext.newContext(doc);
> assertEquals(value, context.selectSingleNode("//root/@id/text()"));
> The attached JUnit test highlights the problem. It seems that JXPath does not
> find the root node if it is accessed with the axis descendant-or-self.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LOGGING-126) Within Tomcat 5.x implementation, under Windows ONLY Commons-logging forbids hot deployment due to JAR locking
[ https://issues.apache.org/jira/browse/LOGGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated LOGGING-126: - Attachment: Patch.txt This patch solves the issue by disabling the URLConnection cache. > Within Tomcat 5.x implementation, under Windows ONLY Commons-logging forbids > hot deployment due to JAR locking > --- > > Key: LOGGING-126 > URL: https://issues.apache.org/jira/browse/LOGGING-126 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 1.0, 1.0.1, 1.0.3, 1.0.4, 1.1.0, 1.1.1 > Environment: Windows only >Reporter: Philippe Mouawad > Attachments: Patch.txt > > > To reproduce the problem: > Create a WAR that contains a JAR that contains commons-logging.properties. > Deploy this WAR to TOMCAT 5.x > Try to redeploy it, it will fail > This is due to the fact that LogFactory uses url.openStream to open this file > , thus URLConnection will use an internal cache and this will provoke a lock > on the file from Window. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LOGGING-126) Within Tomcat 5.x implementation, under Windows ONLY Commons-logging forbids hot deployment due to JAR locking
Within Tomcat 5.x implementation, under Windows ONLY Commons-logging forbids hot deployment due to JAR locking --- Key: LOGGING-126 URL: https://issues.apache.org/jira/browse/LOGGING-126 Project: Commons Logging Issue Type: Improvement Affects Versions: 1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.1, 1.0 Environment: Windows only Reporter: Philippe Mouawad Attachments: Patch.txt To reproduce the problem: Create a WAR that contains a JAR that contains commons-logging.properties. Deploy this WAR to TOMCAT 5.x Try to redeploy it, it will fail This is due to the fact that LogFactory uses url.openStream to open this file , thus URLConnection will use an internal cache and this will provoke a lock on the file from Window. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOGGING-125) where the log file is stored
[ https://issues.apache.org/jira/browse/LOGGING-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching resolved LOGGING-125. Resolution: Invalid I have no idea what you mean here. 1) This is a bug tracking system, not a help forum. 2) apache commons-logging is a java.-only library, and has nothing to do with c# 3) commons-logging does not configure logging systems Therefore, closing this as INVALID. Please do NOT post any further comments against this particular issue entry. > where the log file is stored > - > > Key: LOGGING-125 > URL: https://issues.apache.org/jira/browse/LOGGING-125 > Project: Commons Logging > Issue Type: Bug > Environment: C#.Net >Reporter: shreenath > Fix For: 2.0 > > Original Estimate: 0.67h > Remaining Estimate: 0.67h > > How to configure log file, on default where the log file is stored -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LOGGING-125) where the log file is stored
where the log file is stored - Key: LOGGING-125 URL: https://issues.apache.org/jira/browse/LOGGING-125 Project: Commons Logging Issue Type: Bug Environment: C#.Net Reporter: shreenath Fix For: 2.0 How to configure log file, on default where the log file is stored -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-304) SetUniqueList set method use corrupts uniqness
[
https://issues.apache.org/jira/browse/COLLECTIONS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated COLLECTIONS-304:
--
Fix Version/s: 3.3
> SetUniqueList set method use corrupts uniqness
> --
>
> Key: COLLECTIONS-304
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-304
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: JDK 1.6/Windows/Eclipse Ganymede
>Reporter: Rafał Figas
> Fix For: 3.3
>
>
> When set method is used to put element (Strawberry) on list, then it is
> possible to add the same element (Strawberry) with add method. Also you
> cannot add element (Lemon) that has been once removed with set method.
> Reproduction code below:
> List list = new LinkedList();
> SetUniqueList decoratedList = SetUniqueList.decorate(list);
> decoratedList.add("Apple");
> decoratedList.add("Lemon");
> decoratedList.add("Orange");
> System.out.println(decoratedList.toString());
> decoratedList.set(1, "Strawberry");
> System.out.println(decoratedList.toString());
> decoratedList.add(1, "Strawberry");
> System.out.println(decoratedList.toString());
> decoratedList.add(1, "Lemon");
> System.out.println(decoratedList.toString());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-181) LineIterator should implement Iterable
[ https://issues.apache.org/jira/browse/IO-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630149#action_12630149 ] Henri Yandell commented on IO-181: -- I thought things that produced Iterators implemented Iterables; not Iterators? > LineIterator should implement Iterable > --- > > Key: IO-181 > URL: https://issues.apache.org/jira/browse/IO-181 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Michael Ernst > Original Estimate: 1h > Remaining Estimate: 1h > > org.apache.commons.io.LineIterator does not implement Iterable. This makes > it impossible to use in certain stylized ways, such as in a new-style for > statement. Such use is not always desirable (it might temporarily leak a > file descriptor, until the finalizer is called), but should be possible in > situations where it is known to be acceptable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (IO-180) LineIterator documentation
[
https://issues.apache.org/jira/browse/IO-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed IO-180.
Resolution: Fixed
Fix Version/s: 1.5
Thanks Michael, fix committed.
> LineIterator documentation
> ---
>
> Key: IO-180
> URL: https://issues.apache.org/jira/browse/IO-180
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Michael Ernst
>Priority: Minor
> Fix For: 1.5
>
> Original Estimate: 0.05h
> Remaining Estimate: 0.05h
>
> In the Javadoc for rg.apache.commons.io.LineIterator (in Commons IO 1.4),
> this code snippet is incorrect: the last instance of "iterator" should be
> "it".
> LineIterator it = FileUtils.lineIterator(file, "UTF-8");
>try {
> while (it.hasNext()) {
>String line = it.nextLine();
>/// do something with line
> }
>} finally {
> LineIterator.closeQuietly(iterator);
>}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-457) NumberUtils createNumber thows a StringIndexOutOfBoundsException when only an "l" is passed in.
[ https://issues.apache.org/jira/browse/LANG-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-457: --- Fix Version/s: 3.0 > NumberUtils createNumber thows a StringIndexOutOfBoundsException when only an > "l" is passed in. > --- > > Key: LANG-457 > URL: https://issues.apache.org/jira/browse/LANG-457 > Project: Commons Lang > Issue Type: Bug >Reporter: Waldo Rochow > Fix For: 3.0 > > > Seems to be similar to LANG-300, except that if you don't place a digit in > front of the "l" or "L" it throws a StringIndexOutOfBoundsException instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
