logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-466) Wrong path decoding if path consists of '+'
Date Sat, 04 Jan 2014 12:10:50 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Remko Popma updated LOG4J2-466:
-------------------------------

    Description: 
Hello,

I was trying to programmatically load a XML config file from the temporary data directory
of a MacOS X system. The temp path consists of serveral '\+' characters like MacOS automatically
generates this path so we have to take it this way. Even I would agree that it is not nice
to have '\+' chars in a path name.

When I tried to load the XML config the framework permanently loaded the DefaultConfig and
not the desired XML configuration.
By stepping through the debugger I figured out that this was caused by the method fileFromURI()
in org.apache.logging.log4j.core.helpers.FileUtils.java .
The misbehaviour was basically caused by the call of URL.decode() which converts '+' to '
' (space) of a given String. 
Now I self-compiled the whole framework without the call of URL.decode() and the XML configuration
loaded properly. 
I can not see why this call is necessary in this method so in my opinion this should be removed.


Kind regards

  was:
Hello,

I was trying to programmatically load a XML config file from the temporary data directory
of a MacOS X system. The temp path consists of serveral '+' characters like MacOS automatically
generates this path so we have to take it this way. Even I would agree that it is not nice
to have '+' chars in a path name.

When I tried to load the XML config the framework permanently loaded the DefaultConfig and
not the desired XML configuration.
By stepping through the debugger I figured out that this was caused by the method fileFromURI()
in org.apache.logging.log4j.core.helpers.FileUtils.java .
The misbehaviour was basically caused by the call of URL.decode() which converts '+' to '
' (space) of a given String. 
Now I self-compiled the whole framework without the call of URL.decode() and the XML configuration
loaded properly. 
I can not see why this call is necessary in this method so in my opinion this should be removed.


Kind regards


> Wrong path decoding if path consists of '+'
> -------------------------------------------
>
>                 Key: LOG4J2-466
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-466
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0-beta9
>         Environment: Mac Pro 
>            Reporter: Jan Tepke
>            Priority: Trivial
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Hello,
> I was trying to programmatically load a XML config file from the temporary data directory
of a MacOS X system. The temp path consists of serveral '\+' characters like MacOS automatically
generates this path so we have to take it this way. Even I would agree that it is not nice
to have '\+' chars in a path name.
> When I tried to load the XML config the framework permanently loaded the DefaultConfig
and not the desired XML configuration.
> By stepping through the debugger I figured out that this was caused by the method fileFromURI()
in org.apache.logging.log4j.core.helpers.FileUtils.java .
> The misbehaviour was basically caused by the call of URL.decode() which converts '+'
to ' ' (space) of a given String. 
> Now I self-compiled the whole framework without the call of URL.decode() and the XML
configuration loaded properly. 
> I can not see why this call is necessary in this method so in my opinion this should
be removed.
> Kind regards



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message