RE: [Configuration] Bug with XMLConfiguration and getString() ...?!
Hi Oliver,
nice feature, but there are problems ...
a) if you have both, list-entries and simple entries with decollator-signs I
think you have to disable/enable this feature each time ... ok, better than
nothing. If there are compatibility reasons, I agree but...
b) for me it doesn't work as described
f.e. I've got this code ...
private static XMLConfiguration xml_config;
/**
* inits the configuration
*/
private static void initConfiguration() {
try {
xml_config = new
XMLConfiguration(ApplicationContext.class.getResource(APPLICATION_CONFIG));
} catch (ConfigurationException ex) {
ex.printStackTrace();
}
}
/**
* static inner class for SFTP-params
*/
static class SFTPParamObj {
public String host = xml_config.getString(sftp.host);
public String port = xml_config.getString(sftp.port);
public String user = xml_config.getString(sftp.user);
public String pass = getPasswd();
/**
* @return
*/
private String getPasswd() {
xml_config.setDelimiterParsingDisabled(true);
String pass = xml_config.getString(sftp.pass);
xml_config.setDelimiterParsingDisabled(false);
return pass;
}
}
and the result of pass: 08 !!!
What's wrong ???
Thanks,
Markus
-Ursprüngliche Nachricht-
Von: Oliver Heger [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 29. Oktober 2008 21:55
An: Commons Users List
Betreff: Re: [Configuration] Bug with XMLConfiguration and getString() ...?!
Jörg Schaible schrieb:
Grimm, Markus wrote:
Hi guys,
I've got the following problem:
I've got a xml-config-file with that content:
?xml version=1.0 encoding=UTF-8?
config
...
sftp
hostmyhost/host
port22/port
usertestuser/user
pass08,15/pass
/sftp
...
/config
In my application I get the info about pass f.e. like this
String pass = xml_config.getString(sftp.pass);
value of pass: '08' and not '08,15'
I know, that ',' is the default-decollator für list-entries,
but I think it shouldn't affect the getString()-Method ?!
So it might be a bug?!
Actually, it works as designed. getString() delivers the first list entry.
And I am sure, that quite everyone will consider this as a bug ... it makes
no sense to me either :-/
- Jörg
You can disable this behavior by calling
xml_config.setDelimiterParsingDisabled(true);
That said, I fully agree that the default behavior is confusing - I fell
into this trap more than once myself. For reasons of backwards
compatibility we cannot change this in the 1.x series. But in a 2.0
version I am happy to disable delimiter parsing per default.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Bug with XMLConfiguration and getString() ...?!
Grimm, Markus schrieb:
Hi Oliver,
nice feature, but there are problems ...
a) if you have both, list-entries and simple entries with decollator-signs I
think you have to disable/enable this feature each time ... ok, better than
nothing. If there are compatibility reasons, I agree but...
There are two workarounds:
- You can change the character used as list delimiter using the
setListDelimiter() method (or even globally using
AbstractConfiguration.setDefaultListDelimiter()).
- List delimiters in strings can be escaped with a backslash. Your
property value could be changed to 08\,15.
b) for me it doesn't work as described
f.e. I've got this code ...
private static XMLConfiguration xml_config;
/**
* inits the configuration
*/
private static void initConfiguration() {
try {
xml_config = new
XMLConfiguration(ApplicationContext.class.getResource(APPLICATION_CONFIG));
} catch (ConfigurationException ex) {
ex.printStackTrace();
}
}
You have to call setDelimiterParsingDisabled(true) before you load the
configuration. The processing of list elements is done during parsing of
the configuration file. This is also mentioned in the Javadocs of the
setDelimiterParsingDisabled() method.
Oliver
/**
* static inner class for SFTP-params
*/
static class SFTPParamObj {
public String host = xml_config.getString(sftp.host);
public String port = xml_config.getString(sftp.port);
public String user = xml_config.getString(sftp.user);
public String pass = getPasswd();
/**
* @return
*/
private String getPasswd() {
xml_config.setDelimiterParsingDisabled(true);
String pass = xml_config.getString(sftp.pass);
xml_config.setDelimiterParsingDisabled(false);
return pass;
}
}
and the result of pass: 08 !!!
What's wrong ???
Thanks,
Markus
-Ursprüngliche Nachricht-
Von: Oliver Heger [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 29. Oktober 2008 21:55
An: Commons Users List
Betreff: Re: [Configuration] Bug with XMLConfiguration and getString() ...?!
Jörg Schaible schrieb:
Grimm, Markus wrote:
Hi guys,
I've got the following problem:
I've got a xml-config-file with that content:
?xml version=1.0 encoding=UTF-8?
config
...
sftp
hostmyhost/host
port22/port
usertestuser/user
pass08,15/pass
/sftp
...
/config
In my application I get the info about pass f.e. like this
String pass = xml_config.getString(sftp.pass);
value of pass: '08' and not '08,15'
I know, that ',' is the default-decollator für list-entries,
but I think it shouldn't affect the getString()-Method ?!
So it might be a bug?!
Actually, it works as designed. getString() delivers the first list entry. And
I am sure, that quite everyone will consider this as a bug ... it makes no
sense to me either :-/
- Jörg
You can disable this behavior by calling
xml_config.setDelimiterParsingDisabled(true);
That said, I fully agree that the default behavior is confusing - I fell
into this trap more than once myself. For reasons of backwards
compatibility we cannot change this in the 1.x series. But in a 2.0
version I am happy to disable delimiter parsing per default.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Bug with XMLConfiguration and getString() ...?!
Oliver Heger wrote: Jörg Schaible schrieb: [snip] Actually, it works as designed. getString() delivers the first list entry. And I am sure, that quite everyone will consider this as a bug ... it makes no sense to me either :-/ - Jörg You can disable this behavior by calling xml_config.setDelimiterParsingDisabled(true); That said, I fully agree that the default behavior is confusing - I fell into this trap more than once myself. For reasons of backwards compatibility we cannot change this in the 1.x series. But in a 2.0 version I am happy to disable delimiter parsing per default. +1000, really looking forward to 2.0 - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Bug with XMLConfiguration and getString() ...?!
Hi,
You have to call setDelimiterParsingDisabled(true) before you load the
configuration. The processing of list elements is done during parsing of
the configuration file. This is also mentioned in the Javadocs of the
setDelimiterParsingDisabled() method.
ok. you're right ... rtfm ...
but there are some other solutions, too ... (if I would look at the api-docs
...)
a) you can set the listDelimiter to another sign
b) you can escape the delimiter sign f.e. pass08\,15pass
so anyway... it works and thanks for your help.
Markus
Oliver
/**
* static inner class for SFTP-params
*/
static class SFTPParamObj {
public String host = xml_config.getString(sftp.host);
public String port = xml_config.getString(sftp.port);
public String user = xml_config.getString(sftp.user);
public String pass = getPasswd();
/**
* @return
*/
private String getPasswd() {
xml_config.setDelimiterParsingDisabled(true);
String pass = xml_config.getString(sftp.pass);
xml_config.setDelimiterParsingDisabled(false);
return pass;
}
}
and the result of pass: 08 !!!
What's wrong ???
Thanks,
Markus
-Ursprüngliche Nachricht-
Von: Oliver Heger [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 29. Oktober 2008 21:55
An: Commons Users List
Betreff: Re: [Configuration] Bug with XMLConfiguration and getString() ...?!
Jörg Schaible schrieb:
Grimm, Markus wrote:
Hi guys,
I've got the following problem:
I've got a xml-config-file with that content:
?xml version=1.0 encoding=UTF-8?
config
...
sftp
hostmyhost/host
port22/port
usertestuser/user
pass08,15/pass
/sftp
...
/config
In my application I get the info about pass f.e. like this
String pass = xml_config.getString(sftp.pass);
value of pass: '08' and not '08,15'
I know, that ',' is the default-decollator für list-entries,
but I think it shouldn't affect the getString()-Method ?!
So it might be a bug?!
Actually, it works as designed. getString() delivers the first list entry.
And I am sure, that quite everyone will consider this as a bug ... it makes
no sense to me either :-/
- Jörg
You can disable this behavior by calling
xml_config.setDelimiterParsingDisabled(true);
That said, I fully agree that the default behavior is confusing - I fell
into this trap more than once myself. For reasons of backwards
compatibility we cannot change this in the 1.x series. But in a 2.0
version I am happy to disable delimiter parsing per default.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[CONFIGURATION] Deadlock during refresh properties
Hi
Commons configurations get itself stuck in deadlock when refreshing
properties using Managed reloading strategy. It seems to me it get stuck
because of fireEvent in reload method. Another access grabs lock on
synchronized (getNodeCombiner()) when trying to rebuild but Combined
configuration is one of the listeners for event es well and it gets
stuck when processing invalidate. Can anyone suggest quick fix please?
Relevant information follows. I will create bugreport as well
Thanks
Pavel
Configuration:
configuration
override
system/
properties fileName=gsxweb.properties
throwExceptionOnMissing=false
config-name=gsxweb config-optional=false listDelimiter=|
reloadingStrategy
config-class=org.apache.commons.configuration.reloading.ManagedReloadingStrategy/
/properties
/override
/configuration
Our Reload code:
int ln = combinedConfiguration.getNumberOfConfigurations();
int reloaded = 0;
for (int i = 0; i ln; i++) {
Configuration conf =
combinedConfiguration.getConfiguration(i);
if (conf instanceof PropertiesConfiguration) {
ManagedReloadingStrategy strat = null;
ReloadingStrategy strategy = ((PropertiesConfiguration)
conf).getReloadingStrategy();
//refresh if managed strategy
if (strategy instanceof ManagedReloadingStrategy) {
((ManagedReloadingStrategy) strategy).refresh();
//reload if file changed strategy
} else if (strategy instanceof
FileChangedReloadingStrategy) {
((PropertiesConfiguration) conf).reload();
}
reloaded++;
}
}
Stack trace of deadlock threads
Name: http-10980-1
State: BLOCKED on
[EMAIL PROTECTED] owned by:
http-10980-6
Total blocked: 154 Total waited: 2
Stack trace:
org.apache.commons.configuration.CombinedConfiguration.invalidate(CombinedConfiguration.java:474)
org.apache.commons.configuration.CombinedConfiguration.configurationChanged(CombinedConfiguration.java:488)
org.apache.commons.configuration.event.EventSource.fireEvent(EventSource.java:249)
org.apache.commons.configuration.AbstractFileConfiguration.fireEvent(AbstractFileConfiguration.java:911)
org.apache.commons.configuration.AbstractFileConfiguration.reload(AbstractFileConfiguration.java:828)
- locked [EMAIL PROTECTED]
org.apache.commons.configuration.AbstractFileConfiguration.isEmpty(AbstractFileConfiguration.java:927)
org.apache.commons.configuration.reloading.ManagedReloadingStrategy.refresh(ManagedReloadingStrategy.java:91)
com.gsx.properties.PropertyProviderImpl.reset(PropertyProviderImpl.java:203)
- locked [EMAIL PROTECTED]
org.apache.jsp.test.testPropertyProvider_jsp._jspService(testPropertyProvider_jsp.java:60)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
Name: http-10980-6
State: BLOCKED on [EMAIL PROTECTED] owned by: http-10980-1
Total blocked: 115 Total waited: 2
Stack trace:
org.apache.commons.configuration.AbstractFileConfiguration.reload(AbstractFileConfiguration.java:814)
org.apache.commons.configuration.AbstractFileConfiguration.getKeys(AbstractFileConfiguration.java:939)
org.apache.commons.configuration.ConfigurationUtils.copy(ConfigurationUtils.java:139)
org.apache.commons.configuration.ConfigurationUtils.convertToHierarchical(ConfigurationUtils.java:199)
org.apache.commons.configuration.CombinedConfiguration
$ConfigData.getTransformedRoot(CombinedConfiguration.java:794)
org.apache.commons.configuration.CombinedConfiguration.constructCombinedNode(CombinedConfiguration.java:653)
org.apache.commons.configuration.CombinedConfiguration.getRootNode(CombinedConfiguration.java:504)
- locked
[EMAIL PROTECTED]
org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925)
org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:327)
org.apache.commons.configuration.CombinedConfiguration.getProperty(CombinedConfiguration.java:578)
org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1155)
org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1034)
org.apache.jsp.test.testPropertyProvider_jsp._jspService(testPropertyProvider_jsp.java:69)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
Re: [CONFIGURATION] Deadlock during refresh properties
Hi,
Here is my quick dirty fix,
Because getNodeCombiner() is public method i can grab lock in my code
first before try to do reloading.
synchronized (combinedConfiguration.getNodeCombiner()){
//do the reloading
}
It means locks are grabbed always in the same order so deadlock can't
happen.
Best
Pavel
On Thu, 2008-10-30 at 11:32 +, Pavel Savara wrote:
Hi
Commons configurations get itself stuck in deadlock when refreshing
properties using Managed reloading strategy. It seems to me it get stuck
because of fireEvent in reload method. Another access grabs lock on
synchronized (getNodeCombiner()) when trying to rebuild but Combined
configuration is one of the listeners for event es well and it gets
stuck when processing invalidate. Can anyone suggest quick fix please?
Relevant information follows. I will create bugreport as well
Thanks
Pavel
Configuration:
configuration
override
system/
properties fileName=gsxweb.properties
throwExceptionOnMissing=false
config-name=gsxweb config-optional=false listDelimiter=|
reloadingStrategy
config-class=org.apache.commons.configuration.reloading.ManagedReloadingStrategy/
/properties
/override
/configuration
Our Reload code:
int ln = combinedConfiguration.getNumberOfConfigurations();
int reloaded = 0;
for (int i = 0; i ln; i++) {
Configuration conf =
combinedConfiguration.getConfiguration(i);
if (conf instanceof PropertiesConfiguration) {
ManagedReloadingStrategy strat = null;
ReloadingStrategy strategy = ((PropertiesConfiguration)
conf).getReloadingStrategy();
//refresh if managed strategy
if (strategy instanceof ManagedReloadingStrategy) {
((ManagedReloadingStrategy) strategy).refresh();
//reload if file changed strategy
} else if (strategy instanceof
FileChangedReloadingStrategy) {
((PropertiesConfiguration) conf).reload();
}
reloaded++;
}
}
Stack trace of deadlock threads
Name: http-10980-1
State: BLOCKED on
[EMAIL PROTECTED] owned by:
http-10980-6
Total blocked: 154 Total waited: 2
Stack trace:
org.apache.commons.configuration.CombinedConfiguration.invalidate(CombinedConfiguration.java:474)
org.apache.commons.configuration.CombinedConfiguration.configurationChanged(CombinedConfiguration.java:488)
org.apache.commons.configuration.event.EventSource.fireEvent(EventSource.java:249)
org.apache.commons.configuration.AbstractFileConfiguration.fireEvent(AbstractFileConfiguration.java:911)
org.apache.commons.configuration.AbstractFileConfiguration.reload(AbstractFileConfiguration.java:828)
- locked [EMAIL PROTECTED]
org.apache.commons.configuration.AbstractFileConfiguration.isEmpty(AbstractFileConfiguration.java:927)
org.apache.commons.configuration.reloading.ManagedReloadingStrategy.refresh(ManagedReloadingStrategy.java:91)
com.gsx.properties.PropertyProviderImpl.reset(PropertyProviderImpl.java:203)
- locked [EMAIL PROTECTED]
org.apache.jsp.test.testPropertyProvider_jsp._jspService(testPropertyProvider_jsp.java:60)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
Name: http-10980-6
State: BLOCKED on [EMAIL PROTECTED] owned by: http-10980-1
Total blocked: 115 Total waited: 2
Stack trace:
org.apache.commons.configuration.AbstractFileConfiguration.reload(AbstractFileConfiguration.java:814)
org.apache.commons.configuration.AbstractFileConfiguration.getKeys(AbstractFileConfiguration.java:939)
org.apache.commons.configuration.ConfigurationUtils.copy(ConfigurationUtils.java:139)
org.apache.commons.configuration.ConfigurationUtils.convertToHierarchical(ConfigurationUtils.java:199)
org.apache.commons.configuration.CombinedConfiguration
$ConfigData.getTransformedRoot(CombinedConfiguration.java:794)
org.apache.commons.configuration.CombinedConfiguration.constructCombinedNode(CombinedConfiguration.java:653)
org.apache.commons.configuration.CombinedConfiguration.getRootNode(CombinedConfiguration.java:504)
- locked
[EMAIL PROTECTED]
org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925)
org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:327)
jxpath - how to access Boolean is.......() ?
Hi,
I have some JAXB generated classes like this:
public class OPBDataType
implements Serializable
{
...
@XmlElement(name = OPB_NamePos)
protected Boolean opbNamePos;
...
public Boolean isOPBNamePos() {
return opbNamePos;
}
public void setOPBNamePos(Boolean value) {
this.opbNamePos = value;
}
...
}
now, I want to access the property OPBNamePos, but I always get
org.apache.commons.jxpath.JXPathException: Cannot access property:
.OPBDataType.OPBNamePos; No read method
at org.apache.commons.jxpath.util.ValueUtils.getValue(ValueUtils.java:370)
at
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getBaseValue(BeanPropertyPointer.java:120)
at
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getImmediateNode(BeanPropertyPointer.java:149)
at
org.apache.commons.jxpath.ri.model.beans.PropertyPointer.getImmediateValuePointer(PropertyPointer.java:161)
at
org.apache.commons.jxpath.ri.model.NodePointer.getValuePointer(NodePointer.java:297)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:370)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:313)
I guess the reason is the BeanInfo API, where only boolean is..() is
supported by default.
= Is there an easy way to resolve this?
I dont want to write special BeanInfo classes, because I have a lot of
JAXB generated stuff
Thanx, Torsten
export control: Commons (-collections 2.1.1, -io 1.2, -lang 2.1, -logging 1.0.3, -beanutils 1.7.0, -codec 1.3, -digester 1.6, -el 1.0, -fileupload 1.1.1) and cglib 2.1.3
Hi, I am engaged in export control compliance and need to know the ECCN of *Commons (-collections 2.1.1, -io 1.2, -lang 2.1, -logging 1.0.3, -beanutils 1.7.0, -codec 1.3, -digester 1.6, -el 1.0, -fileupload 1.1.1) and cglib 2.1.3* and whether any license exceptions are available. I know that there is some information on export control at http://www.apache.org/licenses/export/ but especially for the named software there is none. On this webpage is stated that each and every ASF-product that is not on the list provided there, does not have one of the two possible ECCNs 5D002 or 5D992. Is that true for the above mentioned software? Who can help? Regards, Michelle. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: export control: Commons (-collections 2.1.1, -io 1.2, -lang 2.1, -logging 1.0.3, -beanutils 1.7.0, -codec 1.3, -digester 1.6, -el 1.0, -fileupload 1.1.1) and cglib 2.1.3
Export Control skrev: Hi, I am engaged in export control compliance and need to know the ECCN of *Commons (-collections 2.1.1, -io 1.2, -lang 2.1, -logging 1.0.3, -beanutils 1.7.0, -codec 1.3, -digester 1.6, -el 1.0, -fileupload 1.1.1) and cglib 2.1.3* and whether any license exceptions are available. I know that there is some information on export control at http://www.apache.org/licenses/export/ but especially for the named software there is none. On this webpage is stated that each and every ASF-product that is not on the list provided there, does not have one of the two possible ECCNs 5D002 or 5D992. Is that true for the above mentioned software? Who can help? Only a missing s - but the link is: http://www.apache.org/licenses/exports/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
