[jira] [Commented] (MATH-677) About package "transform"
[
https://issues.apache.org/jira/browse/MATH-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196749#comment-13196749
]
Sébastien Brisard commented on MATH-677:
h4. Refactoring of {{RootsOfUnity}}
In {{r1238179}}, the following changes have been adopted
* {{computeOmega(int n)}} now computes the roots of unity {{exp(i * k / n)}}.
{{FastFourierTransformer}} has been updated accordingly.
* {{isForward()}} has been renamed {{isCounterClockwise()}}, which refers to
the way the roots are ordered depending on the sign of {{n}}.
What do you think of these changes?
> About package "transform"
> -
>
> Key: MATH-677
> URL: https://issues.apache.org/jira/browse/MATH-677
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Sébastien Brisard
>Priority: Minor
> Labels: api-change
> Fix For: 3.0
>
>
> Classes in package "o.a.c.m.transform" might require some changes in order to
> conform to goals set for the next major release.
> Some observations:
> # Exceptions {color:red}done (see below){color}
> ## Should remove use of deprecated "MathRuntimeException"
> ## Should throw more specific "Math...Exception" instances instead of
> standard IAE
> # Interface "RealTransformer" (and implementations) contain non-conformant
> method names (e.g. "inversetransform" instead of "inverseTransform").
> {color:red}Fixed in {{r1208293}}.{color}
> # "FastFourierTransformer":
> ## Methods "mdfft" and "verifyDataSet" take an argument of type "Object" (to
> allow an argument with an unspecified number of dimensions)
> ## The "RootsOfUnity" helper class could be moved to the "complex" package.
> {color:red}Done in {{r1237544}}.{color} New class needs a little bit of
> cleaning up (as well as unit tests), see below.
> ## For clarity, multidimensional transform should be moved to a class of its
> own (and I also wonder whether the "MultiDimensionalComplexMatrix" name is
> not misleading)
> # "FastFourierTransformer", "FastSineTranformer" and "FastCosineTranformer"
> define public methods "tranform2" and "inversetransform2" but they are not
> part of an interface. {color:red}As of {{r1213157}}, these methods have been
> removed, and replaced by factory methods {{create()}} and {{createUnitary()}}
> (FFT) or {{createOrthogonal()}} (FCT, FST).{color}
> # Code uses variables that start with an uppercase. {color:red}Fixed,
> together with various formatting issues.{color}
> # "FastHadamardTransformer" contains illegible developer documentation (see
> Javadoc for protected method "fht"). {color:red}Tried to improve things in
> {{r1208986}}, but things are still a bit obscure. Besides, the link provided
> is broken. Will look into that.{color}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-374) Kruskal's algorithm doesn't accept sparse graph
[
https://issues.apache.org/jira/browse/SANDBOX-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Speranza updated SANDBOX-374:
---
Attachment: SANDBOX-374-Kruskal-NotConnectGraph_problem.patch
Hi here is a patch that resolve the problem and the relative test case.
ciao
> Kruskal's algorithm doesn't accept sparse graph
> ---
>
> Key: SANDBOX-374
> URL: https://issues.apache.org/jira/browse/SANDBOX-374
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
>Reporter: Marco Speranza
> Attachments: SANDBOX-374-Kruskal-NotConnectGraph_problem.patch
>
>
> Hi guys,
> I found a little problem into Kruskal's algorithm when the input graph is not
> connected and/or it's a graph without the edges.
> I created a test case that produces the follow error:
> {code}
> Running org.apache.commons.graph.spanning.KruskalTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.096 sec <<<
> FAILURE!
> verifyNotConnectedMinimumSpanningTree(org.apache.commons.graph.spanning.KruskalTestCase)
> Time elapsed: 0.007 sec <<< ERROR!
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:90)
> at
> org.apache.commons.graph.spanning.DefaultSpanningTreeAlgorithmSelector.applyingKruskalAlgorithm(DefaultSpanningTreeAlgorithmSelector.java:87)
> {code}
> ciao
> Marco
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-374) Kruskal's algorithm doesn't accept sparse graph
Kruskal's algorithm doesn't accept sparse graph
---
Key: SANDBOX-374
URL: https://issues.apache.org/jira/browse/SANDBOX-374
Project: Commons Sandbox
Issue Type: Bug
Components: Graph
Reporter: Marco Speranza
Hi guys,
I found a little problem into Kruskal's algorithm when the input graph is not
connected and/or it's a graph without the edges.
I created a test case that produces the follow error:
{code}
Running org.apache.commons.graph.spanning.KruskalTestCase
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.096 sec <<<
FAILURE!
verifyNotConnectedMinimumSpanningTree(org.apache.commons.graph.spanning.KruskalTestCase)
Time elapsed: 0.007 sec <<< ERROR!
java.util.NoSuchElementException
at java.util.AbstractQueue.remove(AbstractQueue.java:90)
at
org.apache.commons.graph.spanning.DefaultSpanningTreeAlgorithmSelector.applyingKruskalAlgorithm(DefaultSpanningTreeAlgorithmSelector.java:87)
{code}
ciao
Marco
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Speranza updated SANDBOX-348:
---
Attachment: SANDBOX-348-ConnectivityAlgo.patch
Hi all, I provided a simple implementation of connectivity problem. This algo
finds the number of the connected component for an input graph.
The algo returns a collection of list of vertices, and it's possible find the
connected component for a specific set of vertices.
I am available for comments and tips :-)
ciao
Marco
> Implement the Boruvka's algorithm
> -
>
> Key: SANDBOX-348
> URL: https://issues.apache.org/jira/browse/SANDBOX-348
> Project: Commons Sandbox
> Issue Type: Sub-task
> Components: Graph
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Attachments: SANDBOX-348-ConnectivityAlgo.patch
>
>
> The class {{org.apache.commons.graph.spanning.Boruvka}} contains an empty
> implementation of
> [Boruvka|http://en.wikipedia.org/wiki/Bor%C5%AFvka's_algorithm]'s algorithm,
> that needs to be filled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-392) AbstractHashedMap should not throw exception when initialized to zero size
[ https://issues.apache.org/jira/browse/COLLECTIONS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196371#comment-13196371 ] Gary D. Gregory commented on COLLECTIONS-392: - This looks like a duplicate of [COLLECTIONS-323]. If not, can you test a trunk build please for your specific test case? Better yet, can you provide a unit test patch to show the failure in trunk? Thank you. > AbstractHashedMap should not throw exception when initialized to zero size > -- > > Key: COLLECTIONS-392 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-392 > Project: Commons Collections > Issue Type: Improvement > Components: Map >Reporter: Bernhard Seebass >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > AbstractHashedMap(int initialCapacity, float loadFactor) throws > IllegalArgumentException when initialized to zero initialCapacity. Although > this is the documented behaviour it is quite unexpected as it differs from > the java.util.HashMap implementation and provokes absurd exceptions, e.g. in > code like this: > List results = criteria.list(); > Map resultMap = new HashedMap(results.size()); > It would be much safer to silently replace a zero initial capacity by initial > capacity 1. Exactly this behaviour is already implemented in > calculateNewCapacity(). Only the validation and the javadoc would have to be > adapted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-211) Proxy support for pooled objects
[ https://issues.apache.org/jira/browse/POOL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196359#comment-13196359 ] Mark Thomas commented on POOL-211: -- Pool 2 doesn't provide this functionality directly. The detection of leaked objects should be simpler with Pool2 since all objects are tracked and PooledObject contains all the necessary timing and state information. Note with Pool1 and DBCP1 this is all done in DBCP. I anticipate this moving to Pool2. Detection of using pooled objects after they have been returned to the pool is not currently supported in Pool2 and isn't on the road-map. > Proxy support for pooled objects > > > Key: POOL-211 > URL: https://issues.apache.org/jira/browse/POOL-211 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 1.6 >Reporter: Brad Koehn > Labels: features, patch > Fix For: Nightly Builds > > Attachments: src.jar, test.jar > > Original Estimate: 48h > Remaining Estimate: 48h > > Attached are files and tests that would allow users of commons-pool to > interact with a proxy to the pooled object rather than the pooled object > itself. This provides two benefits: detection of leaked pooled objects (when > returnObject() isn't called) with a stack trace and detection of using pooled > objects after they have been returned to the pool. The system provides a > delegate which can be placed in front of any ObjectPool, similar to calling > Collections.unmodifiableCollection(). Callers do not know that they're > working with a proxy rather than the pooled object itself. Implementations > are provided to use Java proxies or CGLib (useful when the pooled object > doesn't implement an interface). Unit tests are also provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196346#comment-13196346
]
Gary D. Gregory commented on VFS-398:
-
Try to percent-encode the reserved URI character ":" according to RFC3986
(https://tools.ietf.org/html/rfc3986)?
For example: "ftp://user:pass@host/some/path/some%3Afile"; instead of
"ftp://user:pass@host/some/path/some:file";
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Priority: Blocker
> Fix For: 2.0
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision&revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file";);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-238) Behaviour of environment variables is not documented, and is unexpected
[ https://issues.apache.org/jira/browse/DAEMON-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-238: Component/s: Procrun > Behaviour of environment variables is not documented, and is unexpected > --- > > Key: DAEMON-238 > URL: https://issues.apache.org/jira/browse/DAEMON-238 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Reporter: Sebb > > The documentation does not currently state whether environment variables are > processed before or after command-line options. > It appears that they are processed *after* any command-line options, at least > in 1.0.7 amd 1.0.8. > They completely override the corresponding command-line option in both > versions. > for example: > set PR_JVMOPTION=-Da=1 > prunsrv //US//Service --JvmOption -Da=2 ++JvmOption -Db=1 > results in -Da=1 only, as does > set PR_JVMOPTION=-Da=1 > prunsrv //US//Service --JvmOption -Da2=1 ++JvmOption -Db=1 > If this really is the intended behaviour, it should be documented as such. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-211) Proxy support for pooled objects
[ https://issues.apache.org/jira/browse/POOL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196285#comment-13196285 ] Gary D. Gregory commented on POOL-211: -- It would be good to know how this relates to the Pool 2.0 effort. Anyone familiar with the current 2.0 state care to comment? > Proxy support for pooled objects > > > Key: POOL-211 > URL: https://issues.apache.org/jira/browse/POOL-211 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 1.6 >Reporter: Brad Koehn > Labels: features, patch > Fix For: Nightly Builds > > Attachments: src.jar, test.jar > > Original Estimate: 48h > Remaining Estimate: 48h > > Attached are files and tests that would allow users of commons-pool to > interact with a proxy to the pooled object rather than the pooled object > itself. This provides two benefits: detection of leaked pooled objects (when > returnObject() isn't called) with a stack trace and detection of using pooled > objects after they have been returned to the pool. The system provides a > delegate which can be placed in front of any ObjectPool, similar to calling > Collections.unmodifiableCollection(). Callers do not know that they're > working with a proxy rather than the pooled object itself. Implementations > are provided to use Java proxies or CGLib (useful when the pooled object > doesn't implement an interface). Unit tests are also provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-211) Proxy support for pooled objects
[ https://issues.apache.org/jira/browse/POOL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Koehn updated POOL-211: Attachment: test.jar src.jar Source code and tests. > Proxy support for pooled objects > > > Key: POOL-211 > URL: https://issues.apache.org/jira/browse/POOL-211 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 1.6 >Reporter: Brad Koehn > Labels: features, patch > Fix For: Nightly Builds > > Attachments: src.jar, test.jar > > Original Estimate: 48h > Remaining Estimate: 48h > > Attached are files and tests that would allow users of commons-pool to > interact with a proxy to the pooled object rather than the pooled object > itself. This provides two benefits: detection of leaked pooled objects (when > returnObject() isn't called) with a stack trace and detection of using pooled > objects after they have been returned to the pool. The system provides a > delegate which can be placed in front of any ObjectPool, similar to calling > Collections.unmodifiableCollection(). Callers do not know that they're > working with a proxy rather than the pooled object itself. Implementations > are provided to use Java proxies or CGLib (useful when the pooled object > doesn't implement an interface). Unit tests are also provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-211) Proxy support for pooled objects
Proxy support for pooled objects Key: POOL-211 URL: https://issues.apache.org/jira/browse/POOL-211 Project: Commons Pool Issue Type: Improvement Affects Versions: 1.6 Reporter: Brad Koehn Fix For: Nightly Builds Attached are files and tests that would allow users of commons-pool to interact with a proxy to the pooled object rather than the pooled object itself. This provides two benefits: detection of leaked pooled objects (when returnObject() isn't called) with a stack trace and detection of using pooled objects after they have been returned to the pool. The system provides a delegate which can be placed in front of any ObjectPool, similar to calling Collections.unmodifiableCollection(). Callers do not know that they're working with a proxy rather than the pooled object itself. Implementations are provided to use Java proxies or CGLib (useful when the pooled object doesn't implement an interface). Unit tests are also provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-233) Heap corruption in apxMultiSzToArrayW for windows procrun
[
https://issues.apache.org/jira/browse/DAEMON-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated DAEMON-233:
Description:
When I tried to use commons daemon 1.0.8 for a project, after successfully
installing the service, starting it on Windows 7 failed reliably, and it failed
sporadically on other platforms. I traced the problem to a heap corruption bug
due to an over-long pointer write in utils.c, line 321.
The original line (inside of apxMultiSzToArrayW) reads:
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR) + sizeof(WCHAR));
The fix is to remove the "+ sizeof(WCHAR)" from the line, leaving it as
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR));
Note that you've already taken care of the terminating null inside of "l".
After I'd made that change and rebuilt, things worked happily for me. Please
could you include this fix in a subsequent release.
To reproduce:
{noformat}
1. Ensure that you do NOT have a JRE or a JDK installed on the target machine.
2. Create a folder structure something like
\MyApp\Jetty
\MyApp\jre7 <<- copy a JRE into here, but do NOT run the JRE
installation
\MyApp\Jetty\bin <<-- place prunsrv.exe here
3. Ensure that you do not have the JRE on your system path
4. Install the service via the command line:
C:\MyApp\Jetty\bin\prunsrv.exe install MyService --DisplayName="My Service"
--Install=C:\MyApp\Jetty\bin\prunsrv.exe
--LogPath=C:\MyApp\Jetty\logs --LogLevel=Info --StdOutput=auto --StdError=auto
--StartMode=jvm --StopMode=jvm
--JavaHome="C:\MyApp\jre7" --Jvm="C:\MyApp\jre7\bin\client\jvm.dll"
--Startup=auto --StartPath=C:\MyApp\Jetty
--Classpath=C:\MyApp\Jetty\start.jar;C:\MyApp\Jetty\commons-daemon-1.0.8.jar
++StartParams=--daemon --StartClass=org.eclipse.jetty.start.Main
--StopClass=org.eclipse.jetty.start.Main ++StopParams=--stop
++JvmOptions=-Djetty.home=C:\MyApp\Jetty ++JvmOptions=-Djetty.port=80
++JvmOptions=-DSTOP.PORT=9131 ++JvmOptions=-DSTOP.KEY=stopMyApp
5. Start the service via "net start MyService". Observe that it fails to start.
Depending on the machine, sometimes it started and sometimes it failed to
start.
The joys of heap corruption ...
{noformat}
Anyway, I debugged this with Visual Studio 2010 and used the data change
breakpoint to observe the memory write (2 bytes beyond the end of the allocated
block).
was:
When I tried to use commons daemon 1.0.8 for a project, after successfully
installing the service, starting it on Windows 7 failed reliably, and it failed
sporadically on other platforms. I traced the problem to a heap corruption bug
due to an over-long pointer write in utils.c, line 321.
The original line (inside of apxMultiSzToArrayW) reads:
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR) + sizeof(WCHAR));
The fix is to remove the "+ sizeof(WCHAR)" from the line, leaving it as
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR));
Note that you've already taken care of the terminating null inside of "l".
After I'd made that change and rebuilt, things worked happily for me. Please
could you include this fix in a subsequent release.
To reproduce:
1. Ensure that you do NOT have a JRE or a JDK installed on the target machine.
2. Create a folder structure something like
\MyApp\Jetty
\MyApp\jre7 <<- copy a JRE into here, but do NOT run the JRE
installation
\MyApp\Jetty\bin <<-- place prunsrv.exe here
3. Ensure that you do not have the JRE on your system path
4. Install the service via the command line:
C:\MyApp\Jetty\bin\prunsrv.exe install MyService --DisplayName="My Service"
--Install=C:\MyApp\Jetty\bin\prunsrv.exe --LogPath=C:\MyApp\Jetty\logs
--LogLevel=Info --StdOutput=auto --StdError=auto --StartMode=jvm --StopMode=jvm
--JavaHome="C:\MyApp\jre7" --Jvm="C:\MyApp\jre7\bin\client\jvm.dll"
--Startup=auto --StartPath=C:\MyApp\Jetty
--Classpath=C:\MyApp\Jetty\start.jar;C:\MyApp\Jetty\commons-daemon-1.0.8.jar
++StartParams=--daemon --StartClass=org.eclipse.jetty.start.Main
--StopClass=org.eclipse.jetty.start.Main ++StopParams=--stop
++JvmOptions=-Djetty.home=C:\MyApp\Jetty ++JvmOptions=-Djetty.port=80
++JvmOptions=-DSTOP.PORT=9131 ++JvmOptions=-DSTOP.KEY=stopMyApp
5. Start the service via "net start MyService". Observe that it fails to start.
Depending on the machine, sometimes it started and sometimes it failed to
start. The joys of heap corruption ...
Anyway, I debugged this with Visual Studio 2010 and used the data change
breakpoint to observe the memory write (2 bytes beyond the end of the allocated
block).
Make command easier to read
> Heap corruption in apxMultiSzToArrayW for windows procrun
> -
>
> Key: DAEMON-233
> URL: https://issues.apache.org/jira/browse/DAEMON-233
> Project: Commons Daemon
> Issue Type: Bug
> Componen
[jira] [Resolved] (DAEMON-235) When running java application via procrun (in jvm mode) an RMI thread triggers an EXCEPTION_ACCESS_VIOLATION
[
https://issues.apache.org/jira/browse/DAEMON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved DAEMON-235.
-
Resolution: Not A Problem
This is clearly not a Commons Daemon bug; the crash is in user JNI code called
by the java method:
com.esko.webcenter.cadxserver.CadXServer.generateThumbnail
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
>
>
> Key: DAEMON-235
> URL: https://issues.apache.org/jira/browse/DAEMON-235
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.5, 1.0.6, 1.0.7, 1.0.8
> Environment: Windows XP SP3 and Win 7 SP1 x64
> JDK 1.6.0_30 Server VM (same for client) 32 bit
>Reporter: J-L
>
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
> It happens with both with a series of VM tweaking options and no options at
> all.
> Using the same options executing from a bat file (with java.exe) does not
> crash.
> The crashing application is hosting an RMI registry at the moment of the
> crash. An rmi call to the application is probably triggering the crash.
> Adding an example hs_err_pid file. (Note: the java_home pointing elsewhere
> doesn't effect the result).
> {code:none}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7824f786, pid=5876,
> tid=3656
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) Server VM (20.5-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C [MFC80.DLL+0x7f786]
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> --- T H R E A D ---
> Current thread (0x20206c00): JavaThread "RMI TCP
> Connection(2)-192.168.56.101" daemon [_thread_in_native, id=3656,
> stack(0x20ba,0x20c1)]
> siginfo: ExceptionCode=0xc005, reading address 0x21301e90
> Registers:
> EAX=0x21301e74, EBX=0x22f83170, ECX=0x22f83170, EDX=0x
> ESP=0x20c0f0c8, EBP=0x20c0f154, ESI=0x20c0f1c4, EDI=0x0004
> EIP=0x7824f786, EFLAGS=0x00010202
> Top of Stack: (sp=0x20c0f0c8)
> 0x20c0f0c8: 0002 d8a81ade 0004 20c0f1d4
> 0x20c0f0d8:
> 0x20c0f0e8: 20c0f110 206a
> 0x20c0f0f8: 00139f28
> 0x20c0f108: 0001 0027 20c0f06c 7712556e
> 0x20c0f118: 20c0f158 7c90e920 7c910060
> 0x20c0f128: 7c91005d 204cf1b7 206a
> 0x20c0f138: 22f83170 d92a86cf 0004 20c0f0cc
> Instructions: (pc=0x7824f786)
> 0x7824f766: 78 ff 75 10 e8 70 98 fa ff 85 c0 59 59 75 0a b8
> 0x7824f776: 01 00 02 80 e9 39 04 00 00 ff 75 0c 8b 03 8b cb
> 0x7824f786: ff 50 1c 85 c0 75 0a b8 ff ff 00 80 e9 21 04 00
> 0x7824f796: 00 8d 7d c8 a5 a5 a5 a5 33 ff 39 7d d4 74 18 83
> Register to memory mapping:
> EAX=0x21301e74 is an unknown value
> EBX=0x22f83170 is an unknown value
> ECX=0x22f83170 is an unknown value
> EDX=0x is an unknown value
> ESP=0x20c0f0c8 is pointing into the stack for thread: 0x20206c00
> EBP=0x20c0f154 is pointing into the stack for thread: 0x20206c00
> ESI=0x20c0f1c4 is pointing into the stack for thread: 0x20206c00
> EDI=0x0004 is an unknown value
> Stack: [0x20ba,0x20c1], sp=0x20c0f0c8, free space=444k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [MFC80.DLL+0x7f786] Ordinal3901+0x58
> C [cadxwrapper.dll+0x4e90]
> C [cadxwrapper.dll+0x519c]
> C [cadxwrapper.dll+0x133b]
> Java_com_esko_webcenter_cadxserver_CadXJNIImpl_OpenDesign+0x3b
> j
> com.esko.webcenter.cadxserver.CadXServer.generateThumbnail(Ljava/lang/String;Ljava/lang/String;)V+21
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dll+0x10e44d]
> V [jvm.dll+0x1185d3]
> V [jvm.dll+0x118f16]
> V [jvm.dll+0xc22ae]
> C [java.dll+0x7225] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x15
> j
> sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
> j
> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
> j
> sun.rmi.server.UnicastServerRef.dispatch(Ljava/rmi/Remote;Ljava/rmi/server/RemoteCall;)V+242
> j sun.rmi.transport.Transport$1.run()Ljava/lang/Object;+23
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll
[jira] [Resolved] (DAEMON-239) prunsrv //ES (start) option not documented
[ https://issues.apache.org/jira/browse/DAEMON-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved DAEMON-239. - Resolution: Fixed Fix Version/s: 1.0.9 > prunsrv //ES (start) option not documented > -- > > Key: DAEMON-239 > URL: https://issues.apache.org/jira/browse/DAEMON-239 > Project: Commons Daemon > Issue Type: Bug >Affects Versions: 1.0.8 >Reporter: Sebb > Fix For: 1.0.9 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-239) prunsrv //ES (start) option not documented
[ https://issues.apache.org/jira/browse/DAEMON-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-239: Affects Version/s: 1.0.8 > prunsrv //ES (start) option not documented > -- > > Key: DAEMON-239 > URL: https://issues.apache.org/jira/browse/DAEMON-239 > Project: Commons Daemon > Issue Type: Bug >Affects Versions: 1.0.8 >Reporter: Sebb > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-239) prunsrv //ES (start) option not documented
prunsrv //ES (start) option not documented -- Key: DAEMON-239 URL: https://issues.apache.org/jira/browse/DAEMON-239 Project: Commons Daemon Issue Type: Bug Reporter: Sebb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-237) ++JvmOptions processed as --JvmOptions
[ https://issues.apache.org/jira/browse/DAEMON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-237: Attachment: DAEMON-237.patch The code in prunsrv.c depends on the order of entries in the _commands and _altcmds tables. Looks like some of the checks against lpCmdline->dwCmdIndex were not updated when the option //ES (start) was added to _commands. Patch should fix the issue. > ++JvmOptions processed as --JvmOptions > -- > > Key: DAEMON-237 > URL: https://issues.apache.org/jira/browse/DAEMON-237 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.8 > Environment: XP 64-bit, XP 32-bit, Windows 7 64-bit >Reporter: Mark Thomas > Attachments: DAEMON-237.patch > > > See https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 and > http://tomcat.markmail.org/thread/md3ibbv2w3mxtnb2 for details -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-238) Behaviour of environment variables is not documented, and is unexpected
Behaviour of environment variables is not documented, and is unexpected --- Key: DAEMON-238 URL: https://issues.apache.org/jira/browse/DAEMON-238 Project: Commons Daemon Issue Type: Bug Reporter: Sebb The documentation does not currently state whether environment variables are processed before or after command-line options. It appears that they are processed *after* any command-line options, at least in 1.0.7 amd 1.0.8. They completely override the corresponding command-line option in both versions. for example: set PR_JVMOPTION=-Da=1 prunsrv //US//Service --JvmOption -Da=2 ++JvmOption -Db=1 results in -Da=1 only, as does set PR_JVMOPTION=-Da=1 prunsrv //US//Service --JvmOption -Da2=1 ++JvmOption -Db=1 If this really is the intended behaviour, it should be documented as such. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-359) Move License Agreement to file top
[
https://issues.apache.org/jira/browse/SANDBOX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-359.
Resolution: Fixed
Assignee: Simone Tripodi
fixed on r1237727; if you just run {{mvn checkstyle:checkstyle}}, pom's
settings are ignored; run {{svn up && mvn site && && open
target/site/checkstyle.html}} instead
> Move License Agreement to file top
> --
>
> Key: SANDBOX-359
> URL: https://issues.apache.org/jira/browse/SANDBOX-359
> Project: Commons Sandbox
> Issue Type: Task
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
>Assignee: Simone Tripodi
>Priority: Trivial
>
> Currently, license agreements are located between package declaration and
> import statements. To stick to conventions, the license agreements should be
> moved up to the very top of each file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-373) [BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor
[ https://issues.apache.org/jira/browse/SANDBOX-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-373. Resolution: Fixed Assignee: Simone Tripodi patch applied on r1237721 > [BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor > > > Key: SANDBOX-373 > URL: https://issues.apache.org/jira/browse/SANDBOX-373 > Project: Commons Sandbox > Issue Type: Task > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter >Assignee: Simone Tripodi > Attachments: SANDBOX-373.txt > > > Implement the above mentioned method: > * check if a property of the given name is available > * check if the property has a write method > * create a new DefaultBeanPropertySetter with bean and the setter method as > parameters > * Implement DefaultBeanPropertySetter > * In DefaultBeanPropertySetter.withValue(V value): > ** check if the given value can be assigned to the value > *** if property is primitive, throw IllegalArgumentException for null values > *** if property is not primitive and value is not null, call > TypeUtils.isAssignmentCompatible() > ** invoke setter method on bean with value > ** return a new DefaultBeanAccessor with bean as parameter > * implement a SetPropertyTestCase -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-371) [BeanUtils2] Make sure that a property is readable in DefaultBeanAccessor.getProperty( String name )
[
https://issues.apache.org/jira/browse/SANDBOX-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-371.
Resolution: Fixed
Assignee: Simone Tripodi
fixed on r1237703
> [BeanUtils2] Make sure that a property is readable in
> DefaultBeanAccessor.getProperty( String name )
>
>
> Key: SANDBOX-371
> URL: https://issues.apache.org/jira/browse/SANDBOX-371
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
>Assignee: Simone Tripodi
> Attachments: SANDBOX-371.txt
>
>
> Problem: The following statement in line 50 in DefaultBeanAccessor may cause
> a NullPointerException, because getReadMethod() will return null, if no
> getter for the property is present:
> {code:java}Object newBean = propertyDescriptor.getReadMethod().invoke( bean
> ); {code}
> Solution: throw a NoSuchMethodException, if the property is write only.
> {code:java}
> if ( propertyDescriptor.getReadMethod() == null )
> {
> throw new NoSuchMethodException( String.format( "Bean of type %s does not
> provide a getter for property '%s'!",
> bean.getClass().getName(),
> name ) );
> }{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-237) ++JvmOptions processed as --JvmOptions
[ https://issues.apache.org/jira/browse/DAEMON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196157#comment-13196157 ] Sebb commented on DAEMON-237: - The linked Bugzilla issue expects to use ++JvmOptions to update the options across invocations of the prunsrv application. This is not documented as being supported, as far as I can tell, but does (sort of) work in 1.0.7. For example: prunsrv107 //US//Service --JvmOptions -Da=1 => sets -Da=1 prunsrv107 //US//Service ++JvmOptions -Db=2 => adds -Db=2 However the command-line: prunsrv107 //US//Service --JvmOptions -Da=1 ++JvmOptions -Db=2 => adds -Da=1 -Db=2 i.e. the presence of a single ++ option converts the entire line into an addition. This is a bit unexpected. In the case of 1.0.8, each invocation command-line is treated as a separate update of the registry; the existing registry entries don't seem to be taken into account at all. The behaviour of previous versions was more flexible, however it was not self-consistent I suggest the behavior should be as follows for multi-valued registry entries: 1) populate values from registry 2) merge in command-line options: - if --option is detected, replace current values with cmd-line value(s), i.e. reset them. - if ++option is detected, append cmd-line value(s) to current value(s) Individual -- and ++ options can have multiple # or , separated values, these should be treated as a whole. 3) update registry with result. > ++JvmOptions processed as --JvmOptions > -- > > Key: DAEMON-237 > URL: https://issues.apache.org/jira/browse/DAEMON-237 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.8 > Environment: XP 64-bit, XP 32-bit, Windows 7 64-bit >Reporter: Mark Thomas > > See https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 and > http://tomcat.markmail.org/thread/md3ibbv2w3mxtnb2 for details -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-359) Move License Agreement to file top
[ https://issues.apache.org/jira/browse/SANDBOX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196150#comment-13196150 ] Benedikt Ritter commented on SANDBOX-359: - running mvn checkstyle:checkstyle will criticize on every file, that the first line does not match the expected header line: '^ \* Licensed to the Apache Software Foundation \(ASF\) under one\s*$'. ;) > Move License Agreement to file top > -- > > Key: SANDBOX-359 > URL: https://issues.apache.org/jira/browse/SANDBOX-359 > Project: Commons Sandbox > Issue Type: Task > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter >Priority: Trivial > > Currently, license agreements are located between package declaration and > import statements. To stick to conventions, the license agreements should be > moved up to the very top of each file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-373) [BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor
[ https://issues.apache.org/jira/browse/SANDBOX-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated SANDBOX-373: Attachment: SANDBOX-373.txt I've implemented a patch. It should be applied after SANDBOX-371. > [BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor > > > Key: SANDBOX-373 > URL: https://issues.apache.org/jira/browse/SANDBOX-373 > Project: Commons Sandbox > Issue Type: Task > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: SANDBOX-373.txt > > > Implement the above mentioned method: > * check if a property of the given name is available > * check if the property has a write method > * create a new DefaultBeanPropertySetter with bean and the setter method as > parameters > * Implement DefaultBeanPropertySetter > * In DefaultBeanPropertySetter.withValue(V value): > ** check if the given value can be assigned to the value > *** if property is primitive, throw IllegalArgumentException for null values > *** if property is not primitive and value is not null, call > TypeUtils.isAssignmentCompatible() > ** invoke setter method on bean with value > ** return a new DefaultBeanAccessor with bean as parameter > * implement a SetPropertyTestCase -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-373) [BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor
[BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor Key: SANDBOX-373 URL: https://issues.apache.org/jira/browse/SANDBOX-373 Project: Commons Sandbox Issue Type: Task Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Implement the above mentioned method: * check if a property of the given name is available * check if the property has a write method * create a new DefaultBeanPropertySetter with bean and the setter method as parameters * Implement DefaultBeanPropertySetter * In DefaultBeanPropertySetter.withValue(V value): ** check if the given value can be assigned to the value *** if property is primitive, throw IllegalArgumentException for null values *** if property is not primitive and value is not null, call TypeUtils.isAssignmentCompatible() ** invoke setter method on bean with value ** return a new DefaultBeanAccessor with bean as parameter * implement a SetPropertyTestCase -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-372) Make the org.apache.commons.graph.visit.GraphVisitHandler able to return objects
[
https://issues.apache.org/jira/browse/SANDBOX-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-372.
Resolution: Fixed
fixed on trunk, see
[r1237632|https://svn.apache.org/viewvc?view=revision&revision=1237632]
> Make the org.apache.commons.graph.visit.GraphVisitHandler able to return
> objects
>
>
> Key: SANDBOX-372
> URL: https://issues.apache.org/jira/browse/SANDBOX-372
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
>
> Graph visit could produce output objects, taking inspiration form DbUtil's
> [ResultSetHandler|http://commons.apache.org/dbutils/apidocs/org/apache/commons/dbutils/ResultSetHandler.html]
> and AsyncHttpClient's
> [AsyncHandler|http://sonatype.github.com/async-http-client/apidocs/com/ning/http/client/AsyncHandler.html]
> it would be possible invoke:
> {code}
> final List visited = visit( inputGraph ).from( startVertex
> ).applyingDepthFirstSearch( new MyHandler() );
> {code}
> just adding a callback method in {{GraphVisitHandler}}, something like:
> {code}
> public interface GraphVisitHandler extends Graph, O>
> {
> [...]
> O onCompleted();
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-236) --JvmOption in procrun.html page is not correct
[ https://issues.apache.org/jira/browse/DAEMON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved DAEMON-236. - Resolution: Duplicate > --JvmOption in procrun.html page is not correct > > > Key: DAEMON-236 > URL: https://issues.apache.org/jira/browse/DAEMON-236 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.8 >Reporter: emanuele granieri >Priority: Minor > Labels: JvmOptions, documentation, procrun > > In the examples for command line arguments I read : "--JvmOption=-Done=1 > ++JvmOption=-Dtwo=2" > but I think the parameter name should be "JvmOptions" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-372) Make the org.apache.commons.graph.visit.GraphVisitHandler able to return objects
Make the org.apache.commons.graph.visit.GraphVisitHandler able to return objects
Key: SANDBOX-372
URL: https://issues.apache.org/jira/browse/SANDBOX-372
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Graph visit could produce output objects, taking inspiration form DbUtil's
[ResultSetHandler|http://commons.apache.org/dbutils/apidocs/org/apache/commons/dbutils/ResultSetHandler.html]
and AsyncHttpClient's
[AsyncHandler|http://sonatype.github.com/async-http-client/apidocs/com/ning/http/client/AsyncHandler.html]
it would be possible invoke:
{code}
final List visited = visit( inputGraph ).from( startVertex
).applyingDepthFirstSearch( new MyHandler() );
{code}
just adding a callback method in {{GraphVisitHandler}}, something like:
{code}
public interface GraphVisitHandler, O>
{
[...]
O onCompleted();
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-371) [BeanUtils2] Make sure that a property is readable in DefaultBeanAccessor.getProperty( String name )
[
https://issues.apache.org/jira/browse/SANDBOX-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated SANDBOX-371:
Attachment: SANDBOX-371.txt
I've created a patch. Summary:
* Added the above mentioned code to DefaultBeanAccessor.getProperty(String name)
* Extended GetPropertyTestCase
* Fixed wrong Annotion on GetPropertyTestCase, that caused the test to fail
* Changed assert messages on GetPropertyTestCase.getSimpleProperty()
> [BeanUtils2] Make sure that a property is readable in
> DefaultBeanAccessor.getProperty( String name )
>
>
> Key: SANDBOX-371
> URL: https://issues.apache.org/jira/browse/SANDBOX-371
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
> Attachments: SANDBOX-371.txt
>
>
> Problem: The following statement in line 50 in DefaultBeanAccessor may cause
> a NullPointerException, because getReadMethod() will return null, if no
> getter for the property is present:
> {code:java}Object newBean = propertyDescriptor.getReadMethod().invoke( bean
> ); {code}
> Solution: throw a NoSuchMethodException, if the property is write only.
> {code:java}
> if ( propertyDescriptor.getReadMethod() == null )
> {
> throw new NoSuchMethodException( String.format( "Bean of type %s does not
> provide a getter for property '%s'!",
> bean.getClass().getName(),
> name ) );
> }{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-371) [BeanUtils2] Make sure that a property is readable in DefaultBeanAccessor.getProperty( String name )
[BeanUtils2] Make sure that a property is readable in
DefaultBeanAccessor.getProperty( String name )
Key: SANDBOX-371
URL: https://issues.apache.org/jira/browse/SANDBOX-371
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Problem: The following statement in line 50 in DefaultBeanAccessor may cause a
NullPointerException, because getReadMethod() will return null, if no getter
for the property is present:
{code:java}Object newBean = propertyDescriptor.getReadMethod().invoke( bean );
{code}
Solution: throw a NoSuchMethodException, if the property is write only.
{code:java}
if ( propertyDescriptor.getReadMethod() == null )
{
throw new NoSuchMethodException( String.format( "Bean of type %s does not
provide a getter for property '%s'!",
bean.getClass().getName(),
name ) );
}{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JEXL-128) ObjectContext<> should implement NamespaceResolver
ObjectContext<> should implement NamespaceResolver -- Key: JEXL-128 URL: https://issues.apache.org/jira/browse/JEXL-128 Project: Commons JEXL Issue Type: Improvement Reporter: Matteo Trotta Priority: Minor Fix For: 3.0 On Matteo's behalf from his comment in JEXL-125, ObjectContext should implement NamespaceResolver so methods on the wrapped object can be automatically solved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JEXL-127) Allow the creation of functions
Allow the creation of functions
---
Key: JEXL-127
URL: https://issues.apache.org/jira/browse/JEXL-127
Project: Commons JEXL
Issue Type: Improvement
Reporter: Henri Biestro
Fix For: 3.0
As script get richer, being able to create functions is a strong need.
This only requires adding a new keyword ('function') and the syntax would be:
var fn = function(x, y, z) {...}.
It would be nice to allow those to behave as closures (thru local variable
hoistering).
This will bring JEXL closer to ECMAScript in functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JEXL-126) Decimal numbers literals should be 'double' by default (instead of 'float')
Decimal numbers literals should be 'double' by default (instead of 'float') --- Key: JEXL-126 URL: https://issues.apache.org/jira/browse/JEXL-126 Project: Commons JEXL Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Fix For: 3.0 Since Jexl 1.x, decimal number literals are 'float'; it would be more natural (pun unintended) to create 'double' instead since they are used more often (reduce 'surprise' effects). Note that since 2.1, numbers literals notations allow typing; '123f' is a float literal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-370) GraphML format exporter
[
https://issues.apache.org/jira/browse/SANDBOX-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-370.
Resolution: Fixed
Patch applied, thanks for your efforts Matteo!!! see
[r1237585|https://svn.apache.org/viewvc?view=revision&revision=1237585] for
more details!
While keeping the core implementation, I applied some minor modifications to
your patch, one of the purposes of exporters is be used via fluent APIs as
well, so tests now look like:
{code}
@Test
public void shouldPrintGraphMLFormat()
throws Exception
{
export( actual ).to( System.out ).usingGraphMLFormat();
}
{code}
As a side note: the {Basic} implementations shall not be used to check
Vertex/Edge type - we expect users will provide façades on their own data, so I
moved checks over Labeled/Weighted interfaces
> GraphML format exporter
> ---
>
> Key: SANDBOX-370
> URL: https://issues.apache.org/jira/browse/SANDBOX-370
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Affects Versions: Nightly Builds
>Reporter: Matteo Moci
>Assignee: Simone Tripodi
>Priority: Minor
> Labels: export, graph, xml
> Attachments: SANDBOX-370.patch
>
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> Commons-graph should have some way to read and write graph representations
> encoded with GraphML - http://graphml.graphdrawing.org/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
