[jira] [Created] (LOG4J2-400) Provide Appender-Bundles

Discussion:

Roland Weiglhofer (JIRA)

2013-09-12 07:51:53 UTC

Roland Weiglhofer created LOG4J2-400:
----------------------------------------

Summary: Provide Appender-Bundles
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical

Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!

This reduces the number of dependencies and reduces the startup time of the whole system.

referes to LOG4J2-389 https://issues.apache.org/jira/browse/LOG4J2-389

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Roland Weiglhofer (JIRA)

2013-09-12 08:01:56 UTC

Permalink

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Roland Weiglhofer (JIRA)

2013-09-17 07:15:58 UTC

Permalink

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

Matt Sicker (JIRA)

2014-01-26 23:50:38 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882482#comment-13882482 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

Linking this to an epic for OSGi support.

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

Matt Sicker (JIRA)

2014-02-02 22:24:09 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889086#comment-13889086 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

I believe there are many, many ways to implement this idea. One of the most direct ways would be creating a custom Felix SCR annotation processor that parses the {{@Plugin}} annotations to build up the component list.

Another option would be adding the proper SCR annotations to the existing code so that we can just use the normal annotation processor in Felix's maven plugin.

Another option that conforms more so to the OSGi way of doing things would be using capabilities on each plugin and such so that the OSGi version can simply query for services/components/something that provide the proper capabilities. This idea, while cooler, would take some refactoring effort in order to prevent a lot of code duplication.

There are other ways to do it, of course, but these seem to be the simplest. The idea suggested by Roland, while workable, is very fragile to orders of dependencies and such. Lifecycle hooks like that shouldn't be abused for this; listeners and the OSGi whiteboard thing are more robust.

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

Matt Sicker (JIRA)

2014-03-06 04:33:44 UTC

Permalink

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

Matt Sicker updated LOG4J2-400:
-------------------------------

Affects Version/s: 2.0-rc1
Fix Version/s: 2.0

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Matt Sicker (JIRA)

2014-03-08 21:51:43 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925024#comment-13925024 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

One important thing that has to be done before 2.0 GA is reorganizing the appender classes into separate packages. This will make it possible for the bundles to be split (can't provide the same package in separate bundles like you can with a normal artifact). It might make sense to do so for the other parts, too. This won't affect log4j-core packaging, but it will allow a much more modular osgi version.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Ralph Goers (JIRA)

2014-03-08 22:18:43 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925030#comment-13925030 ]

Ralph Goers commented on LOG4J2-400:
------------------------------------

I don't know what it means to reorganize the appender classes into separate packages without affecting log4j-core. Are you just talking about moving stuff around into different directories?

Whatever you are thinking, I'd like to see the list of changes before they are actually done. FWIW, with all the separate jars and packaging needed for OSGi I am beginning to regret ever wanting to support it.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Gary Gregory (JIRA)

2014-03-09 00:31:43 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925065#comment-13925065 ]

Gary Gregory commented on LOG4J2-400:
-------------------------------------

I agree with Ralph. This is getting ridiculous. Supporting OSGi is one thing but thus micro slicing and dicing is too much. Personally the less jars the better for me.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Matt Sicker

2014-03-10 00:38:44 UTC

Permalink

Post by Ralph Goers (JIRA)
Are you just talking about moving stuff around into different directories?

Pretty much. It's rather simple structuring. It's not to increase the
number of JAR files, but it does increase the number of packages. Let me
give an example. Suppose we want to make the JMS support its own bundle
(which makes sense as a bundle, but in a normal class path only
environment, you would just use log4j-core where it's all in one and
requires other JARs in the class path to enable optional features). Then
here are the changes I'd make:

In o.a.l.l.c.appender.JMSQueueAppender and JMSTopicAppender, I'd put those
in o.a.l.l.c.appender.jms. Then, in o.a.l.l.c.net, I'd move the six JMS
classes there into o.a.l.l.c.net.jms.

Really, when it comes down to it, OSGi usage isn't always about making a
bazillion bundles. OSGi modularity is done at the package level. Thus,
while one approach to using bundles is to split them up as much as
possible, another common approach is to stick with your large JARs, but
properly split up modules by packages. This makes it easier to keep
internal classes private (in the OSGi sense; not a private class, but a
private package) as well.

Then there's the service approach which uses more of the OSGi layers. This
is somewhat similar to Spring beans (which are actually one of the
supported methods of configuring services and such in OSGi Blueprints).
This can be done for log4j without screwing around with structure thanks to
the existing @Plugin annotations which can be parsed into SCR metadata (or
something similar).

I think the best way to actually split up core into bundles is by major
dependency groups. For instance, if you want to use JMS, you'd include the
JMS bundle. If you want to use it with servlets, you would include the web
bundle. If you want async support, include the async module. Basically,
this helps isolate external dependencies in a more explicit way rather than
the current method of manually having to include extra dependencies on your
class path to support the optional features. Also, since we have all the
bundles that would require, we could even include auto-setup in OSGi based
on your config file! Wouldn't that be neat?

Personally, I'd prefer the OSGi bundles to be configured differently than
they are now, because the current method requires a shitload of extra pom
files. It would be cool to just specify the metadata (perhaps the manifest
file?) for each bundle to generate and let the build system create them
from there.

Post by Ralph Goers (JIRA)
[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925065#comment-13925065]
-------------------------------------
I agree with Ralph. This is getting ridiculous. Supporting OSGi is one
thing but thus micro slicing and dicing is too much. Personally the less
jars the better for me.

lightweight, optional

Post by Roland Weiglhofer (JIRA)
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be

much better if the customer can choose which appender he wants to provide.
It's easy to hive the appender off in a separate bundle fragment. The host
bundle is the API bundle. The Plugin Manager (core fragment) finds the
deployed appenders in the classpath of the host bundle. The PluginManager
should parse the class path in a separate thread (Startup-Hook) and only
once at the start of the host bundle, but not for each call (when a
consumer bundle aquires a logger). Make package-imports optional
(<Import-Package>*;resolution:=optional</Import-Package>)!!!!

Post by Roland Weiglhofer (JIRA)
This reduces the number of dependencies and reduces the startup time of

the whole system.

Post by Roland Weiglhofer (JIRA)
One possible solution for the Plugin Manager is to use the reflections

plugin during the maven build process. This plugin lists all classes of a
project within a xml file. This file can be marked as a bundle resource and
is stored within the appender bundle fragment. The idea is that each
appender fragment has its own class list. Because the bundle host (log4j2
core) sees all resources of its fragments it can load these class lists at
runtime. Thus, the Plugin Manager gets only those appenders that are
installed within deployed bundle fragements. The class list is created
during the build process, the plugin manager must not parse the classpath
at runtime. Log4j2 uses a xml parser by default. An additional new
dependency to a xml-parser library is not required.

Post by Roland Weiglhofer (JIRA)
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>

<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>

Post by Roland Weiglhofer (JIRA)
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------

--
Matt Sicker <***@gmail.com>

Matt Sicker (JIRA)

2014-03-10 00:56:43 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925372#comment-13925372 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

Whoops, added my comment to the mailing list. Quick summary: I'm only looking at shuffling files around into new directories (packages), not create more JARs. The JARs part for bundles should be automated in a different way than is currently being done. We shouldn't need to have so many bundles, anyway, considering how OSGi works via package exports/imports rather than entire bundle export/import.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Ralph Goers (JIRA)

2014-03-10 03:06:44 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925418#comment-13925418 ]

Ralph Goers commented on LOG4J2-400:
------------------------------------

I have absolutely no problem with moving files into packages that help promote OSGi modularity. I am 100% in favor of dumping all the OSGi jars if possible.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Matt Sicker (JIRA)

2014-03-10 04:13:44 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925437#comment-13925437 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

As I learn more about OSGi, I'm finding that there's always more than one way to do things there, so there is most likely an efficient way to modularise the core without making a bunch of JARs.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Matt Sicker (JIRA)

2014-04-07 23:36:15 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962390#comment-13962390 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

It might be useful to add annotations to packages to specify which sub-module (i.e., auto-generated OSGi bundle) a package belongs to and whether it's an export package or private package. This would be a fully custom OSGi solution to avoid splitting up appenders into their own Maven modules which would get rather tiresome rather fast (and would just cause a big mess).

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Roland Weiglhofer (JIRA)

2014-04-09 11:37:17 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964044#comment-13964044 ]

Roland Weiglhofer commented on LOG4J2-400:
------------------------------------------

Keep in mind that many target systems run with OSGi-R3 and OSGi-R4 and with an embedded JVM without annotation support (because of a enhanced security requirements), e.g. remote terminal units of a building management system or cars like BMWs using OSGi R3 for the built-in entertainment electronics. User friendly apps provide a wide support for different systems. Thus, Log4j2 should also support target devices with limited resources, limited processing power and enhanced security requirements. So, many of the nice features of OSGi-R5 and OSGi-4 are to heavy.

My solution is not the best but meets the demands.

________________________________________
Requirements for a modular log4j2

1. OGSi-R3 and R4 compliant (eg. no javax !)
2. Modular Appenders and Features as it descript in JIRA LOG4j2-400!
3. less (transitive) dependencies at all. (The more constraints, the longer the start time of the software) Import of non-required dependencies must be marked as opptional.
4. low memory footprint
5. low computational effort at all (for target systems like PowerPC or ARM)

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Roland Weiglhofer (JIRA)

2014-04-09 11:37:15 UTC

Permalink

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

Roland Weiglhofer updated LOG4J2-400:
-------------------------------------

Attachment: Unbenannt.jpg

Imagine the question: What happens when fifty components use log4j2?

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Roland Weiglhofer (JIRA)

2014-04-09 11:39:18 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964043#comment-13964043 ]

Roland Weiglhofer edited comment on LOG4J2-400 at 4/9/14 11:38 AM:
-------------------------------------------------------------------

Imagine the question: What happens when fifty bundles of a osgi-container use log4j2?

was (Author: rol):
Imagine the question: What happens when fifty components use log4j2?

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Roland Weiglhofer (JIRA)

2014-04-09 11:53:17 UTC

Permalink

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

Roland Weiglhofer updated LOG4J2-400:
-------------------------------------

Description:
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!

This reduces the number of dependencies and reduces the startup time of the whole system.

One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.

<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

was:
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!

This reduces the number of dependencies and reduces the startup time of the whole system.

One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.

<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Gary Gregory (JIRA)

2014-04-09 12:50:17 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964104#comment-13964104 ]

Gary Gregory commented on LOG4J2-400:
-------------------------------------

@Roland Weiglhofer
yes, what does happen?

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Gary Gregory (JIRA)

2014-04-09 12:56:17 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964115#comment-13964115 ]

Gary Gregory commented on LOG4J2-400:
-------------------------------------

It feels like we need a separate sister project with a separate release schedule for Log4j-OSGi. This project could slice and dice log4j to its heart's content without polluting the main project with module after module after module.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Matt Sicker (JIRA)

2014-04-09 23:06:15 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964781#comment-13964781 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

While I'm thinking about it, the [BundleTracker class|http://www.osgi.org/javadoc/r5/core/org/osgi/util/tracker/BundleTracker.html] looks rather useful for these sorts of things. A brief look at how Camel handles OSGi support indicates that's how they work with bundles.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Matt Sicker (JIRA)

2014-04-27 20:19:15 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982453#comment-13982453 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

So that BundleTracker class is in R5, not R4.2 or R4.3. So much for that. We can still do the old-style way of tracking bundles, though.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Gary Gregory (JIRA)

2014-04-27 20:36:16 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982457#comment-13982457 ]

Gary Gregory commented on LOG4J2-400:
-------------------------------------

Can we document in the manual which OSGi version we support, why and what is our update plan if any?

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Matt Sicker (JIRA)

2014-04-27 20:48:15 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982461#comment-13982461 ]

Matt Sicker commented on LOG4J2-400:
------------------------------------

We've got 4.3.0 in our dependencies, and considering how recent 5.0.0 was released, I think we should stick to 4.3 for now to support the most common environments. I'm not even sure which version of Felix and Equinox support 5.0, and then there's WildFly/JBoss, WebLogic, WebSphere, GlassFish, and any other OSGi environments I don't know of.

In general, we need some better documentation on using Log4j with OSGi. I'll start writing something for that once I can get it working in the first place!

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Łukasz Dywicki (JIRA)

2014-04-29 08:53:16 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984125#comment-13984125 ]

Łukasz Dywicki commented on LOG4J2-400:
---------------------------------------

4.3.0 is sufficient and widely used. 5.0.0 brings some new features but so far they are not important from log4j point of view.

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Remko Popma (JIRA)

2014-07-18 03:46:06 UTC

Permalink

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

Remko Popma updated LOG4J2-400:
-------------------------------

Fix Version/s: (was: 2.0)
2.1

Post by Roland Weiglhofer (JIRA)
Provide Appender-Bundles
------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.1
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Remko Popma (JIRA)

2014-09-20 06:06:34 UTC

Permalink

[OSGi] Provide Appender-Bundles
-------------------------------
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager, lightweight, optional
Fix For: 2.2
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much better if the customer can choose which appender he wants to provide. (I want a lightweight version without database and http stuff. I do not want to install libraries, which I do not need. All the (transitiv) log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host bundle is the API bundle. The Plugin Manager (core fragment) finds the deployed appenders in the classpath of the host bundle. The PluginManager should parse the class path in a separate thread (Startup-Hook) and only once at the start of the host bundle, but not for each call (when a consumer bundle aquires a logger). Make package-imports optional (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
This reduces the number of dependencies and reduces the startup time of the whole system.
One possible solution for the Plugin Manager is to use the reflections plugin during the maven build process. This plugin lists all classes of a project within a xml file. This file can be marked as a bundle resource and is stored within the appender bundle fragment. The idea is that each appender fragment has its own class list. Because the bundle host (log4j2 core) sees all resources of its fragments it can load these class lists at runtime. Thus, the Plugin Manager gets only those appenders that are installed within deployed bundle fragements. The class list is created during the build process, the plugin manager must not parse the classpath at runtime. Log4j2 uses a xml parser by default. An additional new dependency to a xml-parser library is not required.
<plugin>
<groupId>org.reflections</groupId>
<artifactId>reflections-maven</artifactId>
<version>0.9.8</version>
<executions>
<execution>
<goals>
<goal>reflections</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
<configuration>
<destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
</configuration>
</plugin>

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)