The BaseConfiguration has an initial set of Lookups that are hardwired so that
some variable substitution is possible on the attributes on the Configuration
element. Until the packages attribute is handled custom lookups won't be found.
Your custom Lookups should work for other elements in the c
On Fri, Aug 16, 2013 at 7:54 PM, Gary Gregory wrote:
> On Fri, Aug 16, 2013 at 6:21 PM, David Nault > wrote:
>
>> Hi All,
>>
>> We're using Log4j in a webapp and are looking at migrating to Log4j 2.
>>
>> We'd like to continue writing our log files to a location under the
>> webapp's context root
On Fri, Aug 16, 2013 at 6:21 PM, David Nault
wrote:
> Hi All,
>
> We're using Log4j in a webapp and are looking at migrating to Log4j 2.
>
> We'd like to continue writing our log files to a location under the
> webapp's context root -- that is, under the directory returned by
> ServletContext.getR
Hi All,
We're using Log4j in a webapp and are looking at migrating to Log4j 2.
We'd like to continue writing our log files to a location under the webapp's
context root -- that is, under the directory returned by
ServletContext.getRealPath("/"). This works very well in our QA environment
where
Actually, I'd very much appreciate you NOT going back to log4j 1 and working
through this.
LogManager calls ProviderUtils.getProviders(). ProviderUtil has a static
initializer that calls the ClassLoader's getResources method looking for all
instances of the file "META-INF/log4j-provider.proper
some trace
LogManager line 58: factoryClass is null
line 76: hasProviders() returns false
lb
START LEVEL 4
ID|State |Level|Name
0|Active |0|System Bundle (4.2.1)
4|Active |2|Apache Felix Bundle Repository (1.6.6)
5|Active |2|Apache Fe
I've thought about it and it should would work as is, since core api and
config have the same class loader. Maybe I have a bug in my patch...let me
see.
--
View this message in context:
http://apache-logging.6191.n7.nabble.com/Discussion-about-correct-initialization-of-log4j2-in-OSGi-context-tp
That is a important information! The implementation-bundle should be a host,
but it is a fragment of the api-bundle. Because fragmented bundles can not
have fragments it is not possible with this architecture to load
configurations of fragmented bundles. The usual approach with OSGi is not
possible
The implementation loads the configuration. If it can't find the implementation
it will never load a configuration. Others have reported the have gotten at
least that much to work so I have no idea what the issue is.
Sent from my iPad
On Aug 16, 2013, at 12:15 AM, Roland wrote:
> addendum:
>
addendum:
Am I wrong? Are these two different errors having nothing in common?
Thanks
Roalnd
--
View this message in context:
http://apache-logging.6191.n7.nabble.com/Discussion-about-correct-initialization-of-log4j2-in-OSGi-context-tp39733p39753.html
Sent from the Log4j - Users mailing list
Hello Ralph,
That's right. Log4j2 api can not find the implementation. Due to similar
error messages of other users I think that the configuration can not be
found and thus no implementation. I started to debug log4j2 and I do not
understand how log4j2 loads a configuration in an OSGi-environment.
Hello Remko,
Sorry I did not to clarified my intention.
I have a problem with log4j2 in an OSGi-environment (Unable to locate a
logging implementation...). So, I started to debug log4j2 but I was
unsuccessful. My intention was to present an easy way how log4j2 could load
a configuration within an O
12 matches
Mail list logo
