Re: [configuration] attributes in xml config don't apply to all entries of a list
Hi Oliver,
thanks for your clarification.
From my point of view it would be more straightforward assigning
attributes to all nodes of a list. Otherwise the list feature seems
incomlete to me.
Our lists are a bit longish so I was very happy that I can avoid
repeating tags in our config.xml.
Does it make sense to create an improvement issue?
Otherwise I think I would prefer to read the list as string and parse
it as a list by myself ...
Thank you for your help,
Alex
2012/5/30 Oliver Heger oliver.he...@oliver-heger.de:
Am 30.05.2012 16:53, schrieb Alexander Selg:
Hi,
I'm using a different implementation of the DefaultExpressionEngine. I
use attributes in our applications conf.xml to filter the result of
DefaultExpressionEngine.query().
So I have a config file like
configuration
someStrings environment=teststr1,str2,str3/someStrings
someStrings environment=prodstr4,str5,str6/someStrings
/configuration
In the query() methode of MyExpressionEngine I want to access these
attributes
ListConfigurationNode queryResults = super.query(root, key);
for (ConfigurationNode queryResult : queryResults) {
attributes = queryResult.getAttributes();
...
}
The problem is that I only get the attributes for the first node - the
subsequent nodes don't have any attributes set.
So for str1 I'll get the attribute environment=test, for str2
and str3 I'll get no attributes.
Is that a bug?
Am I doing something wrong?
I'm using commons-configuration 1.8 with jdk1.6
Any help would be appreciated,
Alex
Not sure whether this behavior is somewhere documented, but it is indeed
intended. There are unit tests for XMLConfiguration which test that
attributes are only assigned to the first node of a list.
I guess, there are different use cases. When the code was developed a
decision had to be taken. At that time assigning attributes only to the
first node seemed to be straightforward.
If you have any control over your XML, I would recommend to avoid
comma-separated properties with multiple values. In XML lists can be defined
in a natural way by just repeating tags. Then the association between
attributes and values nodes is obvious.
HTH
Oliver
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Commons daemon - stop the service
I need some insights on how procrun shuts down an application. Procrun has a parameter called StopTimeout which Defines the timeout in seconds that procrun waits for service to exit gracefully. What happens after the timeout period? Doe procrun shut down the JVM? A more general question is: how do the involved parties interact with one another - JVM, procrun, and Windows service manager? I have been perplexed by two errors: one says the process ended unexpectedly. The other says service manager could not get a response from procrun (after a long wait). In both cases, the event viewer showed errors related to prunsrv.exe. These errors are more associated with the 32 bit version. AMD64 seems to work a better. Any suggestions? Thanks. James Wang | Software Engineer, Development | [Description: Description: infor-logo-esig] | direct: 734.623.4056 | fax: 734.623.4190 | james.w...@infor.commailto:james.w...@infor.com
Re: [scxml] ANN: SCION-Java project
Will do. Thanks, Jake On Thu, May 31, 2012 at 9:31 AM, Rahul Akolkar rahul.akol...@gmail.com wrote: If you want to provide a patch to the Commons SCXML home page source via JIRA, we could add this to the Related Projects section [1]. -Rahul [1] http://commons.apache.org/scxml/#Related_Projects On Wed, May 30, 2012 at 5:36 PM, Jacob Beard jbea...@cs.mcgill.ca wrote: Hi, While not specifically related to SCXML Commons, I wanted to draw your attention to a new SCXML-related project I have just released called SCION-Java [0]. SCION is an implementation of SCXML in JavaScript [1], and SCION-Java provides lightweight bindings to the SCION library for Java. Some advantages of SCION-Java are: * liberally licensed (Apache 2) * extremely simple Java API (just one class) * well-tested, using the SCXML Test Framework [2] * supports scripting with ECMAScript out of the box The Java API is not quite complete yet, as I still need to allow registering state change listeners from Java. If you have any questions or comments, please do not hesitate to contact me. Thanks, Jake [0] https://github.com/jbeard4/SCION-Java [1] https://github.com/jbeard4/SCION [2] https://github.com/jbeard4/scxml-test-framework - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[math] PolynomialFitter.fit() stalls
Hi, in certain cases I ran into the problem that the PolynomialFitter.fit() method stalls, meaning that it does not return, nor throw an Exception. Is there a way to tell the PolynomialFitter to iterate only N-times to ensure that my program does not stall? Maybe I should note that when I used a LevenbergMarquardOptimizer instead of a GaussNewtonOptimizer the fit worked fine for the limited number of test cases considered, but this is not a guarantee that the LevenbergMarquardOptimizer will work for all cases. Here is a test case that stalls the PolynomialFitter.fit() on my machine: PolynomialFitter RshuntFitter = new PolynomialFitter(1, new GaussNewtonOptimizer()); RshuntFitter.addObservedPoint(-0.2, -7.12442E-13); RshuntFitter.addObservedPoint(-0.199, -4.33397E-13); RshuntFitter.addObservedPoint(-0.198, -2.823E-13); RshuntFitter.addObservedPoint(-0.197, -1.40405E-13); RshuntFitter.addObservedPoint(-0.196, -7.80821E-15); RshuntFitter.addObservedPoint(-0.195, 6.20484E-14); RshuntFitter.addObservedPoint(-0.194, 7.24673E-14); RshuntFitter.addObservedPoint(-0.193, 1.47152E-13); RshuntFitter.addObservedPoint(-0.192, 1.9629E-13); RshuntFitter.addObservedPoint(-0.191, 2.12038E-13); RshuntFitter.addObservedPoint(-0.19, 2.46906E-13); RshuntFitter.addObservedPoint(-0.189, 2.77495E-13); RshuntFitter.addObservedPoint(-0.188, 2.51281E-13); RshuntFitter.addObservedPoint(-0.187, 2.64001E-13); RshuntFitter.addObservedPoint(-0.186, 2.8882E-13); RshuntFitter.addObservedPoint(-0.185, 3.13604E-13); RshuntFitter.addObservedPoint(-0.184, 3.14248E-13); RshuntFitter.addObservedPoint(-0.183, 3.1172E-13); RshuntFitter.addObservedPoint(-0.182, 3.12912E-13); RshuntFitter.addObservedPoint(-0.181, 3.06761E-13); RshuntFitter.addObservedPoint(-0.18, 2.8559E-13); RshuntFitter.addObservedPoint(-0.179, 2.86806E-13); RshuntFitter.addObservedPoint(-0.178, 2.985E-13); RshuntFitter.addObservedPoint(-0.177, 2.67148E-13); RshuntFitter.addObservedPoint(-0.176, 2.94173E-13); RshuntFitter.addObservedPoint(-0.175, 3.27528E-13); RshuntFitter.addObservedPoint(-0.174, 3.33858E-13); RshuntFitter.addObservedPoint(-0.173, 2.97511E-13); RshuntFitter.addObservedPoint(-0.172, 2.8615E-13); RshuntFitter.addObservedPoint(-0.171, 2.84624E-13); PolynomialFunction RshuntFit = new PolynomialFunction(RshuntFitter.fit()); Thanks for your help, Kurt
Re: [configuration] attributes in xml config don't apply to all entries of a list
Am 31.05.2012 08:30, schrieb Alexander Selg:
Hi Oliver,
thanks for your clarification.
From my point of view it would be more straightforward assigning
attributes to all nodes of a list. Otherwise the list feature seems
incomlete to me.
Our lists are a bit longish so I was very happy that I can avoid
repeating tags in our config.xml.
Does it make sense to create an improvement issue?
Why not? However, I think this issue will not be dealt with in an 1.x
version because it might break existing code.
For Configuration 2.x list handling and list delimiter parsing are
certainly topics which can be improved.
Oliver
Otherwise I think I would prefer to read the list as string and parse
it as a list by myself ...
Thank you for your help,
Alex
2012/5/30 Oliver Hegeroliver.he...@oliver-heger.de:
Am 30.05.2012 16:53, schrieb Alexander Selg:
Hi,
I'm using a different implementation of the DefaultExpressionEngine. I
use attributes in our applications conf.xml to filter the result of
DefaultExpressionEngine.query().
So I have a config file like
configuration
someStrings environment=teststr1,str2,str3/someStrings
someStrings environment=prodstr4,str5,str6/someStrings
/configuration
In the query() methode of MyExpressionEngine I want to access these
attributes
ListConfigurationNodequeryResults = super.query(root, key);
for (ConfigurationNode queryResult : queryResults) {
attributes = queryResult.getAttributes();
...
}
The problem is that I only get the attributes for the first node - the
subsequent nodes don't have any attributes set.
So for str1 I'll get the attribute environment=test, for str2
and str3 I'll get no attributes.
Is that a bug?
Am I doing something wrong?
I'm using commons-configuration 1.8 with jdk1.6
Any help would be appreciated,
Alex
Not sure whether this behavior is somewhere documented, but it is indeed
intended. There are unit tests for XMLConfiguration which test that
attributes are only assigned to the first node of a list.
I guess, there are different use cases. When the code was developed a
decision had to be taken. At that time assigning attributes only to the
first node seemed to be straightforward.
If you have any control over your XML, I would recommend to avoid
comma-separated properties with multiple values. In XML lists can be defined
in a natural way by just repeating tags. Then the association between
attributes and values nodes is obvious.
HTH
Oliver
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [math] PolynomialFitter.fit() stalls
Hi. Hi, in certain cases I ran into the problem that the PolynomialFitter.fit() method stalls, meaning that it does not return, nor throw an Exception. Is there a way to tell the PolynomialFitter to iterate only N-times to ensure that my program does not stall? My guess is that it will throw an exception if you wait long enough. ;-) Maybe I should note that when I used a LevenbergMarquardOptimizer instead of a GaussNewtonOptimizer the fit worked fine for the limited number of test cases considered, but this is not a guarantee that the LevenbergMarquardOptimizer will work for all cases. Here is a test case that stalls the PolynomialFitter.fit() on my machine: PolynomialFitter RshuntFitter = new PolynomialFitter(1, new GaussNewtonOptimizer()); RshuntFitter.addObservedPoint(-0.2, -7.12442E-13); RshuntFitter.addObservedPoint(-0.199, -4.33397E-13); RshuntFitter.addObservedPoint(-0.198, -2.823E-13); RshuntFitter.addObservedPoint(-0.197, -1.40405E-13); RshuntFitter.addObservedPoint(-0.196, -7.80821E-15); RshuntFitter.addObservedPoint(-0.195, 6.20484E-14); RshuntFitter.addObservedPoint(-0.194, 7.24673E-14); RshuntFitter.addObservedPoint(-0.193, 1.47152E-13); RshuntFitter.addObservedPoint(-0.192, 1.9629E-13); RshuntFitter.addObservedPoint(-0.191, 2.12038E-13); RshuntFitter.addObservedPoint(-0.19, 2.46906E-13); RshuntFitter.addObservedPoint(-0.189, 2.77495E-13); RshuntFitter.addObservedPoint(-0.188, 2.51281E-13); RshuntFitter.addObservedPoint(-0.187, 2.64001E-13); RshuntFitter.addObservedPoint(-0.186, 2.8882E-13); RshuntFitter.addObservedPoint(-0.185, 3.13604E-13); RshuntFitter.addObservedPoint(-0.184, 3.14248E-13); RshuntFitter.addObservedPoint(-0.183, 3.1172E-13); RshuntFitter.addObservedPoint(-0.182, 3.12912E-13); RshuntFitter.addObservedPoint(-0.181, 3.06761E-13); RshuntFitter.addObservedPoint(-0.18, 2.8559E-13); RshuntFitter.addObservedPoint(-0.179, 2.86806E-13); RshuntFitter.addObservedPoint(-0.178, 2.985E-13); RshuntFitter.addObservedPoint(-0.177, 2.67148E-13); RshuntFitter.addObservedPoint(-0.176, 2.94173E-13); RshuntFitter.addObservedPoint(-0.175, 3.27528E-13); RshuntFitter.addObservedPoint(-0.174, 3.33858E-13); RshuntFitter.addObservedPoint(-0.173, 2.97511E-13); RshuntFitter.addObservedPoint(-0.172, 2.8615E-13); RshuntFitter.addObservedPoint(-0.171, 2.84624E-13); PolynomialFunction RshuntFit = new PolynomialFunction(RshuntFitter.fit()); This looks like a bug. Could you please open a ticket on the bug tracking system[1]? Once the issue is created, you should also upload a fully contained unit test demonstrating the problem. Thanks, Gilles [1] https://issues.apache.org/jira/browse/MATH - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: Commons daemon - stop the service
On 05/31/2012 02:37 PM, James Wang wrote: I need some insights on how procrun shuts down an application. Procrun has a parameter called “StopTimeout” which Defines the timeout in seconds that procrun waits for service to exit gracefully. What happens after the timeout period? Doe procrun shut down the JVM? A more general question is: how do the involved parties interact with one another – JVM, procrun, and Windows service manager? I have been perplexed by two errors: one says the process ended unexpectedly. The other says service manager could not get a response from procrun (after a long wait). In both cases, the event viewer showed errors related to prunsrv.exe. These errors are more associated with the 32 bit version. AMD64 seems to work a better. Depends on the mode you select. In general service stop is treated as separate process which should by some IPC mechanism inform the 'service' to stop. The simplest one is System.exit, which just calls System.exit() for the service. More complex involves either special process or method call which must cause main service to exit cleanly. Shutdown timeout can occur if any of those goes over defined timeout. Service code should never call System.exit by itself cause that can lead to 'process ended unexpectedly'. Reason is because 'stop' waits for 'start' to finish and then 'stopped' is reported to service manager. So if your service code uses system.exit then you must use java mode which spawns a separate process and stop is then program which must by some IPC (usually socket) inform the 'master' to shut down. With jvm mode all that happens in the same process (and the same JVM) thus your stop code must set some variable in main program which will cause clean exit from main method. This can be tricky if you depend on daemon threads. Hope that shares some light. Regards -- ^TM - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [math] PolynomialFitter.fit() stalls
On 05/31/2012 06:12 PM, Gilles Sadowski wrote: Hi. [snip test case] This looks like a bug. Could you please open a ticket on the bug tracking system[1]? Once the issue is created, you should also upload a fully contained unit test demonstrating the problem. This is most likely related to the GaussNewtonOptimizer (hasn't there been a change recently?). The test case runs through successfully with the LevenbergMarquardtOptimizer. Thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [math] PolynomialFitter.fit() stalls
On 05/31/2012 06:12 PM, Gilles Sadowski wrote: Hi. Hi, in certain cases I ran into the problem that the PolynomialFitter.fit() method stalls, meaning that it does not return, nor throw an Exception. Is there a way to tell the PolynomialFitter to iterate only N-times to ensure that my program does not stall? My guess is that it will throw an exception if you wait long enough. ;-) In fact it will run forever ;-) With the default settings there is no criteria to stop the optimization process (but you can provide your own ConvergenceChecker which takes also iterations into account). After further digging into this, I have seen that the two optimizers (GaussNewton, LevenbergMarquardt) use different convergence criteria, with the Gauss one being stricter. So when providing your test case with the same default settings as for the LM than it works also for the GN case: PolynomialFitter RshuntFitter = new PolynomialFitter(1, new GaussNewtonOptimizer( new SimplePointChecker(10e-10, Precision.SAFE_MIN))); In fact the LM optimizer uses two different convergence criteria (the provided ConvergenceChecker and additional ones that are provided at construction time) and uses both in the optimization process. Thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [math] PolynomialFitter.fit() stalls
Hi. [snip test case] This looks like a bug. Could you please open a ticket on the bug tracking system[1]? Once the issue is created, you should also upload a fully contained unit test demonstrating the problem. This is most likely related to the GaussNewtonOptimizer Yes, hence my request to provide a fully-working self-contained unit tests that displays the problem. (hasn't there been a change recently?). No. The test case runs through successfully with the LevenbergMarquardtOptimizer. So? Regards, Gilles - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [math] PolynomialFitter.fit() stalls
On Thu, May 31, 2012 at 07:00:58PM +0200, Thomas Neidhart wrote: On 05/31/2012 06:12 PM, Gilles Sadowski wrote: Hi. Hi, in certain cases I ran into the problem that the PolynomialFitter.fit() method stalls, meaning that it does not return, nor throw an Exception. Is there a way to tell the PolynomialFitter to iterate only N-times to ensure that my program does not stall? My guess is that it will throw an exception if you wait long enough. ;-) In fact it will run forever ;-) No it shouldn't. If the convergence criterion is never met it will throw an exception after exhausting all the evaluations (which in the PolynomialFitter is set to Integer.MAX_VALUE). Will be long but not forever. :-) With the default settings there is no criteria to stop the optimization process (but you can provide your own ConvergenceChecker which takes also iterations into account). There is a default criterion: it is defined by a default instance of SimpleVectorValueChecker. After further digging into this, I have seen that the two optimizers (GaussNewton, LevenbergMarquardt) use different convergence criteria, with the Gauss one being stricter. So when providing your test case with the same default settings as for the LM than it works also for the GN case: PolynomialFitter RshuntFitter = new PolynomialFitter(1, new GaussNewtonOptimizer( new SimplePointChecker(10e-10, Precision.SAFE_MIN))); Here the checker use the point while the default one uses the value. It doesn't give an explanation as to why one works and the other not. One can just deduce that, if there is no bug in optimizer, the convergence criterion is too stringent for the problem at hand. [...] Best, Gilles - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
RE: Commons daemon - stop the service
Thanks for the comments. I set both start mode and stop mode to JVM. My test showed that worked best for me. The procrun documentation says that to use this mode, the start method should not stop until stop is called. My start method exits immediately but it did not seem to be the cause of my grievances. My stop code also calls System.exit() in a separate thread, after couple of seconds of sleep. I cannot get rid of it because some of our customers still want to start and stop the application using batch scripts. But the stop did not fail consistently with unexpected stoppage. That makes me think that there is an issue of timing. What I have recently tried is to terminate most, if not all, threads spawned by the applications gracefully. That seemed to have improved the performance (fewer error messages from service manager). But my testing is done when the app is not loaded with much work. What will happen when a thread needs 20 more minutes to complete its job? Would procrun be patient enough to wait (if I set the timeout to 20 minutes)? It is hard to test this scenario because I have not been able to put a heavy load on the application. So I would like know what actually happens after procrun calls the stop class? Does it monitor the JVM in some way? Does procrun eventually call System.exit() to shut down JVM? Thanks. James Wang -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Thursday, May 31, 2012 12:15 PM To: user@commons.apache.org Subject: Re: Commons daemon - stop the service On 05/31/2012 02:37 PM, James Wang wrote: I need some insights on how procrun shuts down an application. Procrun has a parameter called StopTimeout which Defines the timeout in seconds that procrun waits for service to exit gracefully. What happens after the timeout period? Doe procrun shut down the JVM? A more general question is: how do the involved parties interact with one another - JVM, procrun, and Windows service manager? I have been perplexed by two errors: one says the process ended unexpectedly. The other says service manager could not get a response from procrun (after a long wait). In both cases, the event viewer showed errors related to prunsrv.exe. These errors are more associated with the 32 bit version. AMD64 seems to work a better. Depends on the mode you select. In general service stop is treated as separate process which should by some IPC mechanism inform the 'service' to stop. The simplest one is System.exit, which just calls System.exit() for the service. More complex involves either special process or method call which must cause main service to exit cleanly. Shutdown timeout can occur if any of those goes over defined timeout. Service code should never call System.exit by itself cause that can lead to 'process ended unexpectedly'. Reason is because 'stop' waits for 'start' to finish and then 'stopped' is reported to service manager. So if your service code uses system.exit then you must use java mode which spawns a separate process and stop is then program which must by some IPC (usually socket) inform the 'master' to shut down. With jvm mode all that happens in the same process (and the same JVM) thus your stop code must set some variable in main program which will cause clean exit from main method. This can be tricky if you depend on daemon threads. Hope that shares some light. Regards -- ^TM - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: Commons daemon - stop the service
On 05/31/2012 07:53 PM, James Wang wrote: Thanks for the comments. I set both start mode and stop mode to JVM. OK. What will happen when a thread needs 20 more minutes to complete its job? Well for something like that procrun is not the toolkit to use. First of all, if you need to frequently start/stop service why using the service at the first place? The sole purpose of service concept is to start the application at boot mode or on demand and to start them in correct order. Then there is absolute limit which OS imposes on the service shutdown timeout, and this is for all services on the system, see http://support.microsoft.com/kb/Q146092 So the only clean solution is that your shutdown code does the actual cleanup causing the clean exit. By spec, JVM won't exit if you have non-daemon threads running, so if you cant make them exit, then the only solution is System.exit, which calls OS process _exit() which causes the SCM to think service failed. Also you should design your application differently for service and command line mode. Procrun does not need to call the main() method. Take a look at Tomcat. We call Bootstrap start/stop methods and main() calls Bootstrap.start (after setting correct mode) Regards -- ^TM - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [math] PolynomialFitter.fit() stalls
Hi, thanks for your quick response !! My guess is that it will throw an exception if you wait long enough. ;-) Well, not within 90 min ... This looks like a bug. Could you please open a ticket on the bug tracking system[1]? Once the issue is created, you should also upload a fully contained unit test demonstrating the problem. Done: https://issues.apache.org/jira/browse/MATH-798 Thanks a lot, Kurt
[vfs] does vfs webdav support https
Can somehone shows me an example on how to configure webdav:// url to use https? Thanks -D - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [vfs] does vfs webdav support https
Well darn. I keep thinking this should be as simple as using webdavs as the protocol but we never implemented a WebdavsFileProvider. Ralph On May 31, 2012, at 8:53 PM, Dan Tran wrote: Can somehone shows me an example on how to configure webdav:// url to use https? Thanks -D - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
