[jira] Commented: (EXEC-50) Pumping lines from the command output
[ https://issues.apache.org/jira/browse/EXEC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934762#action_12934762 ] Siegfried Goeschl commented on EXEC-50: --- Merged your changes into the trunk and the tests succeed - I will attach a complete patch and review the changes > Pumping lines from the command output > - > > Key: EXEC-50 > URL: https://issues.apache.org/jira/browse/EXEC-50 > Project: Commons Exec > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Henryk Konsek >Assignee: Siegfried Goeschl >Priority: Trivial > Fix For: 1.2 > > Attachments: commons-exec.zip, lines_listener.patch > > > My application makes heavy use of analyzing output lines of the long running > executable. Executed command may run even up to to few hours. Actually I'm > not so interested in the result of execution, but rather in the output > produced by the program. Each line of the output contains some important > data. I need to listen to these lines of the output, filter them and send JMS > message containing selected of them. > Current implementation of the StreamPumper makes it hard to listen to the > output lines produced by the executable since it copies entire InputStream. > What I did is pumping command output to the FilterInputStream and looking for > the new line markers. It works for me, however it would be nice to have an > ability to read entire lines from the PumpStream instead of raw bytes only. > This is quite common case since executable usually format their output using > the lines instead of the raw stream of bytes. > I created patch refactoring StreamPumper to extend AbstractStreamPumper. I > created also BufferedReaderPumper (also extending AbstractStreamPumper) to > pump lines from the executable output and send them to the > OutputLinesListener. I also extracted creation of the StreamPumper in the > PumpStreamHandler to the factory method. This method can be overridden in > order to use BufferedReaderPumper instead of default StreamPumper. > What do you think about such approach? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EMAIL-101) Specified Content-ID is not used when embedding a File object in an HtmlEmail
[ https://issues.apache.org/jira/browse/EMAIL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934761#action_12934761 ] Siegfried Goeschl commented on EMAIL-101: - Hi Andrew, thanks for the patch ... > Specified Content-ID is not used when embedding a File object in an HtmlEmail > - > > Key: EMAIL-101 > URL: https://issues.apache.org/jira/browse/EMAIL-101 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2 >Reporter: Andrew Starodub >Assignee: Siegfried Goeschl > Fix For: 1.3 > > Attachments: HtmlEmail.patch, HtmlEmailTest.patch > > > When calling the .embed(File file, String cid) method on HtmlEmail, the cid > argument is never used within the method. > Consequently, even when the user specifies a Content-ID for the embedded > File, a new randomly generated Content-ID is generated every time. > I believe this is as simple as changing the last line of .embed(File file, > String cid) from: > return embed(new FileDataSource(file), file.getName()); > To: > return embed(new FileDataSource(file), file.getName(), cid); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BETWIXT-71) [patch] remove minor code stutter
[
https://issues.apache.org/jira/browse/BETWIXT-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated BETWIXT-71:
Attachment: stutter.patch
> [patch] remove minor code stutter
> -
>
> Key: BETWIXT-71
> URL: https://issues.apache.org/jira/browse/BETWIXT-71
> Project: Commons Betwixt
> Issue Type: Improvement
>Affects Versions: Nightly Builds
> Environment: ubuntu 10.10
>Reporter: Dave Brosius
>Priority: Trivial
> Fix For: Nightly Builds
>
> Attachments: stutter.patch
>
>
> code tests
> if ( size > 0 ) {
> back to back, remove one of them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (BETWIXT-71) [patch] remove minor code stutter
[patch] remove minor code stutter
-
Key: BETWIXT-71
URL: https://issues.apache.org/jira/browse/BETWIXT-71
Project: Commons Betwixt
Issue Type: Improvement
Affects Versions: Nightly Builds
Environment: ubuntu 10.10
Reporter: Dave Brosius
Priority: Trivial
Fix For: Nightly Builds
Attachments: stutter.patch
code tests
if ( size > 0 ) {
back to back, remove one of them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (BETWIXT-70) [patch] Fix LocalComplexType.equals typo due to copy/paste
[ https://issues.apache.org/jira/browse/BETWIXT-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated BETWIXT-70: Attachment: bad_equals.patch > [patch] Fix LocalComplexType.equals typo due to copy/paste > -- > > Key: BETWIXT-70 > URL: https://issues.apache.org/jira/browse/BETWIXT-70 > Project: Commons Betwixt > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: ubuntu 10.10 >Reporter: Dave Brosius >Priority: Minor > Fix For: Nightly Builds > > Attachments: bad_equals.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > LocalComplexType.equals logic was copied from GlobalComplexType.equals, and > was therefore incorrect. fixed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (BETWIXT-70) [patch] Fix LocalComplexType.equals typo due to copy/paste
[patch] Fix LocalComplexType.equals typo due to copy/paste -- Key: BETWIXT-70 URL: https://issues.apache.org/jira/browse/BETWIXT-70 Project: Commons Betwixt Issue Type: Bug Affects Versions: Nightly Builds Environment: ubuntu 10.10 Reporter: Dave Brosius Priority: Minor Fix For: Nightly Builds Attachments: bad_equals.patch LocalComplexType.equals logic was copied from GlobalComplexType.equals, and was therefore incorrect. fixed -- 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: (DBCP-292) Adds an mbean for exposing metrics around a BasicDataSource via JMX
[
https://issues.apache.org/jira/browse/DBCP-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934701#action_12934701
]
Cyrille Le Clerc edited comment on DBCP-292 at 11/22/10 9:01 PM:
-
For those who are using Spring, we packaged a JMX enabled extension of DBCP
BasicDataSource at [Google Code - XebiaManagementExtras -
ManagedBasicDataSource|http://code.google.com/p/xebia-france/wiki/ManagedBasicDataSource].
A Spring XML namespace configuration allows a compact datasource declaration
looking like:
{code:xml}
{code}
was (Author: cleclerc):
For those who are using Spring, we packaged a JMX enabled extension of DBCP
BasicDataSource at [Google Code - XebiaManagementExtras -
ManagedBasicDataSource|http://code.google.com/p/xebia-france/wiki/ManagedBasicDataSource].
A Spring XML namespace configuration allows a compact datasource declaration
looking like:
{code:xml}
{code}
> Adds an mbean for exposing metrics around a BasicDataSource via JMX
> ---
>
> Key: DBCP-292
> URL: https://issues.apache.org/jira/browse/DBCP-292
> Project: Commons Dbcp
> Issue Type: New Feature
>Affects Versions: 1.2.2
>Reporter: David Horne
>Priority: Minor
> Fix For: 2.0
>
> Attachments: BasicDataSourceMBean.patch
>
>
> The attached patch adds an mbean that exposes the following metrics of a
> BasicDataSource via jmx: numActive, numIdle, maxActive, maxIdle, minIdle &
> maxWait.
> I have put it in a new package: org.apache.commons.dbcp.management but feel
> free to put it in any package you see fit.
> If using Spring the bean can be configured a little something like this:
>
> ...
>
> class="org.apache.commons.dbcp.management.BasicDataSourceMBean">
>
>
>
>
>
>value-ref="dataSourceMBean"/>
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-292) Adds an mbean for exposing metrics around a BasicDataSource via JMX
[
https://issues.apache.org/jira/browse/DBCP-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934701#action_12934701
]
Cyrille Le Clerc commented on DBCP-292:
---
For those who are using Spring, we packaged a JMX enabled extension of DBCP
BasicDataSource at [Google Code - XebiaManagementExtras -
ManagedBasicDataSource|http://code.google.com/p/xebia-france/wiki/ManagedBasicDataSource].
A Spring XML namespace configuration allows a compact datasource declaration
looking like:
{code:xml}
{code}
> Adds an mbean for exposing metrics around a BasicDataSource via JMX
> ---
>
> Key: DBCP-292
> URL: https://issues.apache.org/jira/browse/DBCP-292
> Project: Commons Dbcp
> Issue Type: New Feature
>Affects Versions: 1.2.2
>Reporter: David Horne
>Priority: Minor
> Fix For: 2.0
>
> Attachments: BasicDataSourceMBean.patch
>
>
> The attached patch adds an mbean that exposes the following metrics of a
> BasicDataSource via jmx: numActive, numIdle, maxActive, maxIdle, minIdle &
> maxWait.
> I have put it in a new package: org.apache.commons.dbcp.management but feel
> free to put it in any package you see fit.
> If using Spring the bean can be configured a little something like this:
>
> ...
>
> class="org.apache.commons.dbcp.management.BasicDataSourceMBean">
>
>
>
>
>
>value-ref="dataSourceMBean"/>
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-293) FtpFileSystem causes deadlock
[
https://issues.apache.org/jira/browse/VFS-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved VFS-293.
-
Resolution: Fixed
Fix Version/s: 2.0
getClient and putClient no longer synchronize. Instead idleClient has been
changed to an AtomicReference.
> FtpFileSystem causes deadlock
> -
>
> Key: VFS-293
> URL: https://issues.apache.org/jira/browse/VFS-293
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Johannes Scharf
> Fix For: 2.0
>
>
> I use Commons VFS to access FTP from multiple threads. In each thread I
> create directories and copy files on the FTP server.
> Nearly everytime when i run the program a deadlock occurs which causes all
> threads to hang. I've created a stacktrace with "jstack" which clearly shows
> where the deadlock is happening.
> Stacktrace:
> {noformat}
> Found one Java-level deadlock:
> =
> "pool-1-thread-5":
> waiting to lock monitor 0x030813b4 (object 0x22f972e8, a
> org.apache.commons.vfs.provider.ftp.FtpFileSystem),
> which is held by "pool-1-thread-2"
> "pool-1-thread-2":
> waiting to lock monitor 0x03082c7c (object 0x22f999e0, a java.lang.Object),
> which is held by "pool-1-thread-4"
> "pool-1-thread-4":
> waiting to lock monitor 0x030813b4 (object 0x22f972e8, a
> org.apache.commons.vfs.provider.ftp.FtpFileSystem),
> which is held by "pool-1-thread-2"
> Java stack information for the threads listed above:
> ===
> "pool-1-thread-5":
> at
> org.apache.commons.vfs.provider.AbstractFileSystem.streamOpened(AbstractFileSystem.java:569)
> - waiting to lock <0x22f972e8> (a
> org.apache.commons.vfs.provider.ftp.FtpFileSystem)
> at
> org.apache.commons.vfs.provider.DefaultFileContent.streamOpened(DefaultFileContent.java:92)
> at
> org.apache.commons.vfs.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:377)
> at
> at.js.jtransporter.transporter.VFSTransporter.createFile(VFSTransporter.java:119)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.createFile(ResourceWorker.java:80)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.processJob(ResourceWorker.java:51)
> at
> at.js.jtransporter.worker.AbstractRunnableWorker.run(AbstractRunnableWorker.java:82)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> "pool-1-thread-2":
> at
> org.apache.commons.vfs.provider.ftp.FtpFileSystem.putClient(FtpFileSystem.java:137)
> - waiting to lock <0x22f999e0> (a java.lang.Object)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.doGetChildren(FtpFileObject.java:158)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getChildFile(FtpFileObject.java:103)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:181)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.refresh(FtpFileObject.java:208)
> at
> org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:319)
> - locked <0x22f972e8> (a
> org.apache.commons.vfs.provider.ftp.FtpFileSystem)
> at
> org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:267)
> - locked <0x22f972e8> (a
> org.apache.commons.vfs.provider.ftp.FtpFileSystem)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.getParent(AbstractFileObject.java:512)
> - locked <0x22f972e8> (a
> org.apache.commons.vfs.provider.ftp.FtpFileSystem)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:177)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.refresh(FtpFileObject.java:208)
> at
> org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:319)
> - locked <0x22f972e8> (a
> org.apache.commons.vfs.provider.ftp.FtpFileSystem)
> at
> org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:267)
> - locked <0x22f972e8> (a
> org.apache.commons.vfs.provider.ftp.FtpFileSystem)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.resolveFile(AbstractFileObject.java:670)
> at
> at.js.jtransporter.transporter.VFSTransporter.createFile(VFSTransporter.java:118)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.createFile(ResourceWorker.java:80)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.processJob(ResourceWorker.java:51)
> at
> at.js.jtransporter.worker.AbstractRunnableWorker.run(AbstractRunnableWorker.java:82)
> at
[jira] Commented: (VFS-343) Deadlock occurs in HTTP or WebDAV when all the connections are in use.
[ https://issues.apache.org/jira/browse/VFS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934661#action_12934661 ] Ralph Goers commented on VFS-343: - AbstractFileSystem has been changed to use an Atomicinteger instead of synchronizing on the FileSystem. > Deadlock occurs in HTTP or WebDAV when all the connections are in use. > -- > > Key: VFS-343 > URL: https://issues.apache.org/jira/browse/VFS-343 > Project: Commons VFS > Issue Type: Bug >Reporter: Ralph Goers > > The stacktrace below shows several threads all waiting on a FileSystem lock. > The thread holding that lock is waiting for an HTTP connection from the > connection pool. However, each of the threads waiting on the FileSystem lock > has already acquired a connection from the pool. This issue can be resolved > by reducing the amount of locking that occurs on the FileSystem objects. In > this case the threads are attempting to get the lock to increment a counter. > Changing the counters to AtomicIntegers will resolve the problem. > Full thread dump Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode): > "Attach Listener" daemon prio=10 tid=0x53834400 nid=0x23b1 waiting on > condition [0x..0x] > java.lang.Thread.State: RUNNABLE > "MultiThreadedHttpConnectionManager cleanup" daemon prio=10 > tid=0x538ff400 nid=0x21f0 in Object.wait() > [0x4077e000..0x4077ec10] > java.lang.Thread.State: TIMED_WAITING (on object monitor) >at java.lang.Object.wait(Native Method) >- waiting on <0x2aab82694428> (a java.lang.ref.ReferenceQueue$Lock) >at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) >- locked <0x2aab82694428> (a java.lang.ref.ReferenceQueue$Lock) >at > org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ReferenceQueueThread.run(MultiThreadedHttpConnectionManager.java:1082) > "Thread 2" prio=10 tid=0x2aabc00a0800 nid=0x21ef waiting for monitor > entry [0x40d17000..0x40d17c90] > java.lang.Thread.State: BLOCKED (on object monitor) >at > org.apache.commons.vfs.provider.AbstractFileSystem.streamOpened(AbstractFileSystem.java:602) >- waiting to lock <0x2aab827f92c8> (a > org.apache.commons.vfs.provider.webdav.WebdavFileSystem) >at > org.apache.commons.vfs.provider.DefaultFileContent.streamOpened(DefaultFileContent.java:93) >at > org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:373) >at > org.apache.commons.configuration.VFSFileSystem.getInputStream(VFSFileSystem.java:111) >at > org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:311) >at > org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:251) >at > org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:229) >at > org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.load(AbstractHierarchicalFileConfiguration.java:180) >at > com.diginsite.services.configsync.ConfigurationSynchronizer.synchronizeClientProduct(ConfigurationSynchronizer.java:862) >at > com.diginsite.services.configsync.ConfigurationSynchronizer.synchronizeClient(ConfigurationSynchronizer.java:829) >at > com.diginsite.services.configsync.ConfigurationSynchronizer.run(ConfigurationSynchronizer.java:416) >at java.lang.Thread.run(Thread.java:619) > "Thread 3" prio=10 tid=0x2aabc009f800 nid=0x21ec in Object.wait() > [0x42593000..0x42593d10] > java.lang.Thread.State: WAITING (on object monitor) >at java.lang.Object.wait(Native Method) >- waiting on <0x2aab826c67a8> (a > org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool) >at > org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:509) >- locked <0x2aab826c67a8> (a > org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool) >at > org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:394) >at > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:152) >at > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) >at > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324) >at > org.apache.commons.vfs.provider.webdav.WebdavFileObject.execute(WebdavFileObject.java:349) >at > org.apache.commons.vfs.provider.webdav.WebdavFileObjec
[jira] Commented: (MATH-430) Function objects
[
https://issues.apache.org/jira/browse/MATH-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934609#action_12934609
]
Gilles commented on MATH-430:
-
Functions and utilities added in revision 1037896. Replaced classes are
deprecated.
In a second, step I'll remove the redundant {{mapXxx}} and {{mapXxxToSelf}}
methods from the {{RealVector}} interface.
> Function objects
>
>
> Key: MATH-430
> URL: https://issues.apache.org/jira/browse/MATH-430
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 3.0
>
> Attachments: func.tar.gz
>
>
> Create a package {{function}} to contain classes implementing the
> {{UnivariateRealFunction}} interface for all the usual functions.
> As a consequence, all {{mapXxx}} methods and {{mapXxxToSelf}} methods in
> {{RealVector}} can be respectively replaced with
> {code}
> public void map(UnivariateRealFunction f);
> {code}
> and
> {code}
> public void mapToSelf(UnivariateRealFunction f);
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934575#action_12934575
]
Archie Cobbs commented on NET-343:
--
FYI, the latest version of my combined patch to fix NET-343, NET-344, and
NET-345 can be found
[here|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].
Please use this version as I'll be keeping it up to date.
> Telnet client: Support Client-initiated Subnegotiation Messages
> ---
>
> Key: NET-343
> URL: https://issues.apache.org/jira/browse/NET-343
> Project: Commons Net
> Issue Type: New Feature
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: patch1.txt
>
>
> I am in the process of trying to implement a Java client for [RFC
> 2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
> serial ports over TCP. Unfortunately, the commons-net telnet client is
> insufficient for this relatively simple task.
> There are two missing features in the commons-net telnet client code, one of
> which is a show stopper and the other of which would be a "real nice to
> have". This issue documents the first problem:
> RFC 2217 specifies that serial port events (such as server notifiying about a
> change in carrier detect, or the client instructing the server to change the
> baud rate) are delivered to the peer by subnegotiations. For example, to
> notify the client about carrier detect, the server sends {{IAC SB
> COM-PORT-OPTION NOTIFY-MODEMSTATE IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> IAC SE}} to the server. These messages can happen at any time and
> are not associated with any WILL/WONT/DO/DONT negotiation (according to my
> understanding).
> The problem is that while one can _receive_ such messages via
> {{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
> doesn't provide any way to _send_ (i.e., intiate) these messages.
> What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
> (properly renamed, etc.) as a public method.
> I'm going to attempt to come up with a patch and will attach it here if
> successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934573#action_12934573
]
Archie Cobbs commented on NET-345:
--
FYI, the latest version of my combined patch to fix NET-343, NET-344, and
NET-345 can be found
[here|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].
Please use this version as I'll be keeping it up to date.
> Telnet client: not properly handling IAC bytes within subnegotiation messages
> -
>
> Key: NET-345
> URL: https://issues.apache.org/jira/browse/NET-345
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: patch3.txt, patch4.txt
>
>
> Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
> IAC SE}}.
> Although it's not clearly spelled out in [RFC
> 854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
> these messages must be escaped by doubling. Other clients do this and this is
> the only behavior that makes sense.
> The commons-net telnet client is failing both to escape and to unescape
> {{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
> valid {{IAC IAC}} sequence within a subnegotiation message, it will
> incorrectly jump back to "data" input mode, discarding the message and
> introducing its remainder as garbage in the data stream.
> In addition, the code fails to check for an overflow of the subnegotiation
> buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
> malicious peer triggered this condition.
> Finally, a {{IAC SE}} sequence appearing by itself should probably be
> discarded, rather than passing as a command to the handler.
> I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-344) Telnet client: Support Listener Notification of Incoming Data
[
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934574#action_12934574
]
Archie Cobbs commented on NET-344:
--
FYI, the latest version of my combined patch to fix NET-343, NET-344, and
NET-345 can be found
[here|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].
Please use this version as I'll be keeping it up to date.
> Telnet client: Support Listener Notification of Incoming Data
> -
>
> Key: NET-344
> URL: https://issues.apache.org/jira/browse/NET-344
> Project: Commons Net
> Issue Type: New Feature
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: patch2.txt
>
>
> I am in the process of trying to implement a Java client for [RFC
> 2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
> serial ports over TCP. Unfortunately, the commons-net telnet client is
> insufficient for this relatively simple task.
> There are two missing features in the commons-net telnet client code, one of
> which is a show stopper (NET-343) and the other of which would be a "real
> nice to have". This issue documents the second problem:
> The API I am trying to support requires the ability to notify a listener that
> new incoming data is available. This would be trivial for me to do if only my
> library could somehow itself get a listener notification from the
> {{TelnetInputStream}} reader thread every time it reads new data.
> Unfortunately, there's no API provided for doing this, even though it would
> be trivial. So I have to implement a hack that requires a wrapper
> {{InputStream}} with yet another internal reader thread, etc. Bleh.
> I'm going to attempt to come up with a patch and will attach it here if
> successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DAEMON-165) Uncaught exceptions in main methods are being obscured
[ https://issues.apache.org/jira/browse/DAEMON-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934488#action_12934488 ] John Leed commented on DAEMON-165: -- I don't think this issue is resolved. I was having trouble figuring out why my app wasn't working with prunsrv until I wrapped my main method with a try catch. I'm using 1.0.4 x86 on Windows XP with JRE 1.6.20. > Uncaught exceptions in main methods are being obscured > -- > > Key: DAEMON-165 > URL: https://issues.apache.org/jira/browse/DAEMON-165 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.2, 1.0.3 > Environment: Procrun running on windows with any java release >Reporter: Antony Scerri > Fix For: 1.0.4 > > > Inside the__apxJavaWorkerThread method in javajni.c the following line just > after the call to execute the main method: > JVM_EXCEPTION_CLEAR(lpJava); > is making any uncaught exception in the main method simply disappear. This > can make diagnoising startup and/or shutdown issues in applications over > which you have no direct control (ie third party apps for which you dont have > sourcecode). I had this where a classpath error was causing some issues and > later some other exceptions, all were completely hidden until I removed this > line. > Two solutions I believe are possible. > 1) Simply remove this line, the VM will then handle the exception by > outputting it to standard error in which case it will appear in the service > stderr log file. > 2) Check for and then obtain any exception and log appropriately > The second would give greater control to procrun and be more prominant in the > main log rather than the stderr logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONFIGURATION-394) Providing BeanDiff(or ConfigurationDiff), BeanBatchUpdateListener, and some merge facility for Configuration(Specially for HierarchialConfiguration) to implement tw
[ https://issues.apache.org/jira/browse/CONFIGURATION-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Java Developer updated CONFIGURATION-394: - Attachment: BaseConfigBean.fixed.zip FinalConfigClasses.enh2.zip I know issue is closed, but current implementation has some benefits(e.g. using oracle Berkeley DB XML). thanks! > Providing BeanDiff(or ConfigurationDiff), BeanBatchUpdateListener, and some > merge facility for Configuration(Specially for HierarchialConfiguration) to > implement two-phase-commit-like protocol to alter entire configuration > hierarchy in atomic manner. > -- > > Key: CONFIGURATION-394 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-394 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Java Developer > Attachments: BaseConfigBean.fixed.zip, BeanDiff.zip, > cfggenengine.jar, ConfigFramework.zip, FinalConfigClasses.enh2.zip, > FinalConfigClasses.zip > > Original Estimate: 2016h > Remaining Estimate: 2016h > > Sorry for English and for such a generic summary: > If you have ever worked with Weblogic AdminConsole(Weblogic 10.3 in my case) > you would find out that it save your changes temporary and finally by > clicking "Apply changes" it would save all changes in configurations. If one > of the changes is failed then Weblogic would rollback all changes of > configurations. Something like database transaction. > The general idea could be that you create a clone of your entire or some > parts of your configuration hierarchy, then change the cloned version, and > finally apply back the cloned version on original version of hierarchy. Here > when you ask the original configuration hierarchy to accept new changes then > the original hierarchy would compute the Diff between itself and cloned > version and deliver the changes to all listeners that have registered for > configuration changes. If any of listeners are not agree with new changes > then all process of applying configuration would be rolled back! > Here in this scenario you need some facility to be added to Apache Commons > Config and also to Apache Commons BeanUtils: > 1- A BeanDiff class(http://issues.apache.org/jira/browse/BEANUTILS-304) that > can compute the difference between two JavaBeans. These JavaBeans are custom > classes that programmers write for application configuration (e.g. > CacheConfiguration class). These custom configuration classes would use the > apache common config classes to to store and retrieve the configuration from > any source. It can be extended to have ConfigurationDiff that would represent > the changes between two Configuration(shows which properties are altered) > 2- Cloning entire hierarchy of configuration, I actually do not know whether > currently Apache Commons Config support this feature. > 3- The most important part is adding some method to Configuration interface > which enables Configuration interface to accept a whole configuration > hierarchy and then apply that hierarchy to itself. The apply process consist > of traversing the hierarchy and visiting each node, then computing > ConfigurationDiff for each node and then notifying the registered listeners > of that node for all updates that node has. If one of listeners reject the > update then the process would call rollback method of listeners. > 4- Some class like ConfigurationUpdateListener(or BeanUpdateListener) that > has some method like : > public abstract void prepareUpdate(ConfigurationUpdateEvent updateevent) > throws ConfigurationUpdateRejectedException; > public abstract void activateUpdate(ConfigurationUpdateEvent updateevent) > throws ConfigurationUpdateFailedException; > public abstract void rollbackUpdate(ConfigurationUpdateEvent updateevent); > All classes that are interested in configuration changes(batch changes not > just one property changes) can implement this class and register themselves > in Configuration node in hierarchy. > -- > After some research! in Weblogic classes and jar files you can find the > "com.bea.core.descriptor_1.4.0.0.jar" in "BEA_HOME\modules" folder. > After another research you can find some interesting classes like > BeanUpdateListener, BeanUpdateEvent, DescriptorBean, Descriptor inside > "weblogic.descriptor" package. And also another interesting class > "weblogic.descriptor.internal.BeanDiff" class. Looking at them is useful!! > I could not completely understand the model that Weblogic works but that > point are what I understood about it. > I some useful f
[jira] Resolved: (SANDBOX-243) CSVWriter.writeValue() not using value delimiter
[
https://issues.apache.org/jira/browse/SANDBOX-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible resolved SANDBOX-243.
Resolution: Fixed
Assignee: Joerg Schaible
Applied with unit tests, thanks.
> CSVWriter.writeValue() not using value delimiter
>
>
> Key: SANDBOX-243
> URL: https://issues.apache.org/jira/browse/SANDBOX-243
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Affects Versions: Nightly Builds
>Reporter: Mike Cordes
>Assignee: Joerg Schaible
>Priority: Minor
> Fix For: CSV 1.0
>
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> CSVWriter.writeValue() only uses value delimiter if field values are fixed
> width.
> Here is the existing method:
> {code:title=CSVWriter.writeValue() error|borderStyle=solid}
> protected String writeValue(CSVField field, String value) throws Exception {
> if (config.isFixedWidth()) {
> if (value.length() < field.getSize()) {
> int fillPattern = config.getFill();
> if (field.overrideFill()) {
> fillPattern = field.getFill();
> }
> StringBuffer sb = new StringBuffer();
> int fillSize = (field.getSize() - value.length());
> char[] fill = new char[fillSize];
> Arrays.fill(fill, config.getFillChar());
> if (fillPattern == CSVConfig.FILLLEFT) {
> sb.append(fill);
> sb.append(value);
> value = sb.toString();
> } else {
> // defaults to fillpattern FILLRIGHT when fixedwidth is
> used
> sb.append(value);
> sb.append(fill);
> value = sb.toString();
> }
> } else if (value.length() > field.getSize()) {
> // value to big..
> value = value.substring(0, field.getSize());
> }
> if (!config.isValueDelimiterIgnored()) {
> // add the value delimiter..
> value =
> config.getValueDelimiter()+value+config.getValueDelimiter();
> }
> }
> return value;
>}
> {code}
> The {color:blue}{{if (!config.isValueDelimiterIgnored())}}{color} block
> should be removed from the {color:blue}{{if (config.isFixedWidth())}}{color}
> block, like so:
> {code:title=CSVWriter.writeValue() corrected|borderStyle=solid}
> protected String writeValue(CSVField field, String value) throws Exception {
> if (config.isFixedWidth()) {
> if (value.length() < field.getSize()) {
> int fillPattern = config.getFill();
> if (field.overrideFill()) {
> fillPattern = field.getFill();
> }
> StringBuffer sb = new StringBuffer();
> int fillSize = (field.getSize() - value.length());
> char[] fill = new char[fillSize];
> Arrays.fill(fill, config.getFillChar());
> if (fillPattern == CSVConfig.FILLLEFT) {
> sb.append(fill);
> sb.append(value);
> value = sb.toString();
> } else {
> // defaults to fillpattern FILLRIGHT when fixedwidth is
> used
> sb.append(value);
> sb.append(fill);
> value = sb.toString();
> }
> } else if (value.length() > field.getSize()) {
> // value to big..
> value = value.substring(0, field.getSize());
> }
> }
> if (!config.isValueDelimiterIgnored()) {
> // add the value delimiter..
> value =
> config.getValueDelimiter()+value+config.getValueDelimiter();
> }
> return value;
>}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (VFS-343) Deadlock occurs in HTTP or WebDAV when all the connections are in use.
Deadlock occurs in HTTP or WebDAV when all the connections are in use. -- Key: VFS-343 URL: https://issues.apache.org/jira/browse/VFS-343 Project: Commons VFS Issue Type: Bug Reporter: Ralph Goers The stacktrace below shows several threads all waiting on a FileSystem lock. The thread holding that lock is waiting for an HTTP connection from the connection pool. However, each of the threads waiting on the FileSystem lock has already acquired a connection from the pool. This issue can be resolved by reducing the amount of locking that occurs on the FileSystem objects. In this case the threads are attempting to get the lock to increment a counter. Changing the counters to AtomicIntegers will resolve the problem. Full thread dump Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode): "Attach Listener" daemon prio=10 tid=0x53834400 nid=0x23b1 waiting on condition [0x..0x] java.lang.Thread.State: RUNNABLE "MultiThreadedHttpConnectionManager cleanup" daemon prio=10 tid=0x538ff400 nid=0x21f0 in Object.wait() [0x4077e000..0x4077ec10] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x2aab82694428> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x2aab82694428> (a java.lang.ref.ReferenceQueue$Lock) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ReferenceQueueThread.run(MultiThreadedHttpConnectionManager.java:1082) "Thread 2" prio=10 tid=0x2aabc00a0800 nid=0x21ef waiting for monitor entry [0x40d17000..0x40d17c90] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.commons.vfs.provider.AbstractFileSystem.streamOpened(AbstractFileSystem.java:602) - waiting to lock <0x2aab827f92c8> (a org.apache.commons.vfs.provider.webdav.WebdavFileSystem) at org.apache.commons.vfs.provider.DefaultFileContent.streamOpened(DefaultFileContent.java:93) at org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:373) at org.apache.commons.configuration.VFSFileSystem.getInputStream(VFSFileSystem.java:111) at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:311) at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:251) at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:229) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.load(AbstractHierarchicalFileConfiguration.java:180) at com.diginsite.services.configsync.ConfigurationSynchronizer.synchronizeClientProduct(ConfigurationSynchronizer.java:862) at com.diginsite.services.configsync.ConfigurationSynchronizer.synchronizeClient(ConfigurationSynchronizer.java:829) at com.diginsite.services.configsync.ConfigurationSynchronizer.run(ConfigurationSynchronizer.java:416) at java.lang.Thread.run(Thread.java:619) "Thread 3" prio=10 tid=0x2aabc009f800 nid=0x21ec in Object.wait() [0x42593000..0x42593d10] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x2aab826c67a8> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:509) - locked <0x2aab826c67a8> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:394) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:152) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324) at org.apache.commons.vfs.provider.webdav.WebdavFileObject.execute(WebdavFileObject.java:349) at org.apache.commons.vfs.provider.webdav.WebdavFileObject.getProperties(WebdavFileObject.java:442) at org.apache.commons.vfs.provider.webdav.WebdavFileObject.getProperties(WebdavFileObject.java:417) at org.apache.commons.vfs.provider.webdav.WebdavFileObject.getProperty(WebdavFileObject.java:410) at org.apache.commons.vfs.provider.webdav.WebdavFileObject.getProperty(WebdavFileObject.java:402) at org.apache.commons.vfs.provider.webdav.WebdavFileObject.isDirectory(WebdavFileObject.java:382) at org.apache.co
[jira] Resolved: (VFS-333) ThreadLocalHttpConnectionManager.getConnectionWithTimeout ignores timeout parameter
[ https://issues.apache.org/jira/browse/VFS-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved VFS-333. - Resolution: Fixed Fix Version/s: 2.0 ThreadLocalHttpConnectionManager is not used any longer and has been removed. > ThreadLocalHttpConnectionManager.getConnectionWithTimeout ignores timeout > parameter > --- > > Key: VFS-333 > URL: https://issues.apache.org/jira/browse/VFS-333 > Project: Commons VFS > Issue Type: Bug >Reporter: Sebb > Fix For: 2.0 > > > ThreadLocalHttpConnectionManager.getConnectionWithTimeout ignores its timeout > parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
