Logback source code organization and extensions
Hi Ceki (et. al), I'm trying to wrap my head around making it easy to add and support contributions/extensions to logback in a clean/modular way. For example, I'd like to see a JSON formatter and a Loggly appender added to Logback. However, these additions probably don't make sense to be added to logback core/classic as they would bloat the library for those not using these features. As such, it makes sense (to me at least) to have a more modular source code organization where different features/extensions are represented as a dedicated Maven module. This way, people can easily (and deterministically) use a respective dependency depending on the feature they wish to enable. Clean and easy. Now, with regards to a JSON formatter and a Loggly appender (which would likely use the JSON formatter), I'd envision something like this in the Logback source tree: logback/ logback-access/ logback-classic/ logback-core/ ... logback-extensions/ Where 'logback-extensions' is a new Maven module. It would just be a wrapper module containing children. Below it, you might see the following: logback-extensions/ json/ common/ groovy/ jackson/ loggly/ foo/ bar/ ... In the above example, the logback-json module: 1) provides a 'common' sub module where JSON-specific needs are defined, and 2) has other sub-modules depending on _how_ you want JSON to be formatted. You can depend on the logback-json-jackson dependency if you want to use Jackson, or you can depend on logback-json-groovy if you want to use the built-in JSON support in a Groovy 1.8+ environment. The 'loggly' extension could depend on logback-json-common. The idea is that you can depend on a dependency that is copacetic with your intended runtime environment. I think this makes a lot of sense - we use it in Apache Shiro (http://svn.apache.org/repos/asf/shiro/trunk/support/) and it works very well for us. Before I go off and create my own 'logback-extensions' project on GitHub, I'd rather contribute this back to Logback proper as a pull request if this is something you are willing to implement. Thoughts? Cheers, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 PMC Chair, Apache Shiro | http://shiro.apache.org twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
Hi Les, Thank you for considering making a contribution to the logback project. The modularization scheme for logback extensions you propose sounds quite reasonable. However, I should mention that logback is already split by logging event type (logback-access, logback-classic) with logback-core providing shared code, applying the core/classic/access separation to the modularization scheme for logback extensions, we could end up in 18 (=3x6) modules (core/access/classic x extensions/json/commmon/groovy/jackson/loggly/). If logback-classic is the only target for logback-extensions, this combinatorial problem obviously does not apply. To keep things simple, we could ignore logback-access and concentrate on extending only logback-classic. More importantly though, I personally cannot and do not wish to commit to the maintenance of logback-extensions. Thus, I would prefer to support logback-extensions as a separate project as far as the code is concerned. However, at the web-site level (http://logback.qos.ch), the two projects could be integrated by allowing you to manage on your own the branch under say http://logback.qos.ch/extensions/. Thoughts? -- Ceki http://twitter.com/#!/ceki On 08.03.2012 20:40, Les Hazlewood wrote:
Hi Ceki (et. al),
I'm trying to wrap my head around making it easy to add and support contributions/extensions to logback in a clean/modular way. For example, I'd like to see a JSON formatter and a Loggly appender added to Logback.
However, these additions probably don't make sense to be added to logback core/classic as they would bloat the library for those not using these features. As such, it makes sense (to me at least) to have a more modular source code organization where different features/extensions are represented as a dedicated Maven module. This way, people can easily (and deterministically) use a respective dependency depending on the feature they wish to enable. Clean and easy.
Now, with regards to a JSON formatter and a Loggly appender (which would likely use the JSON formatter), I'd envision something like this in the Logback source tree:
logback/ logback-access/ logback-classic/ logback-core/ ... logback-extensions/
Where 'logback-extensions' is a new Maven module. It would just be a wrapper module containing children. Below it, you might see the following:
logback-extensions/ json/ common/ groovy/ jackson/ loggly/ foo/ bar/ ...
In the above example, the logback-json module: 1) provides a 'common' sub module where JSON-specific needs are defined, and 2) has other sub-modules depending on _how_ you want JSON to be formatted.
You can depend on the logback-json-jackson dependency if you want to use Jackson, or you can depend on logback-json-groovy if you want to use the built-in JSON support in a Groovy 1.8+ environment. The 'loggly' extension could depend on logback-json-common.
The idea is that you can depend on a dependency that is copacetic with your intended runtime environment. I think this makes a lot of sense - we use it in Apache Shiro (http://svn.apache.org/repos/asf/shiro/trunk/support/) and it works very well for us.
Before I go off and create my own 'logback-extensions' project on GitHub, I'd rather contribute this back to Logback proper as a pull request if this is something you are willing to implement.
Thoughts?
Cheers,
On Fri, Mar 9, 2012 at 5:56 AM, ceki <ceki@qos.ch> wrote:
Hi Les,
Thank you for considering making a contribution to the logback project. The modularization scheme for logback extensions you propose sounds quite reasonable. However, I should mention that logback is already split by logging event type (logback-access, logback-classic) with logback-core providing shared code, applying the core/classic/access separation to the modularization scheme for logback extensions, we could end up in 18 (=3x6) modules (core/access/classic x extensions/json/commmon/groovy/jackson/loggly/). If logback-classic is the only target for logback-extensions, this combinatorial problem obviously does not apply.
I would think that would be at the discretion of the extension module author if they want to support both types of events. At least that makes things a little more decentralized and easier to manage.
More importantly though, I personally cannot and do not wish to commit to the maintenance of logback-extensions. Thus, I would prefer to support logback-extensions as a separate project as far as the code is concerned. However, at the web-site level (http://logback.qos.ch), the two projects could be integrated by allowing you to manage on your own the branch under say http://logback.qos.ch/extensions/.
Thoughts?
I think this is a great idea - it is similar in nature to what many Apache projects are doing these days: there is the main project and also a separate extensions project for community owned/maintained integration. The benefit here is that it provides a central place for the community to work together and provide new features without adding volatility or maintenance overhead to the core project - much nicer than having to fish through Google and random Github projects that may or may not work. (There is an added benefit in that the extension project usually doesn't require any CLA/ICLA to be signed). For starters, I just did the following: 1. I created the 'logback' organization on Github (https://github.com/logback) and made you Owner so you can own/manage it. (Even if we didn't use this mechanism, I figured you'd want to reserve that Github namespace anyway so no one else can squat it) 2. Created an 'extensions-dev' team that initially includes you and I. 3. Created a new 'extensions' repository. 4. Granted the 'extensions-dev' team push and pull access to the 'extensions' repository. This way, the only thing to do to give people push access to the extensions repository is to just add them to the 'extensions-dev' team, and they can start contributing. Please let me know if you have any objections to this and I can revert whatever you wish. In any event, you are Owner of the space, so you can do whatever you like. Whatever your decisions, I'm happy to oblige. Cheers, Les P.S. Another benefit of this namespace is that - if you wanted - you can move the logback codebase to the space, create a separate team for that repository and add/remove users as desired if you want to enable development duties for logback proper to anyone you trust.
On 09.03.2012 21:37, Les Hazlewood wrote:
On Fri, Mar 9, 2012 at 5:56 AM, ceki<ceki@qos.ch> wrote:
Hi Les,
Thank you for considering making a contribution to the logback project. The modularization scheme for logback extensions you propose sounds quite reasonable. However, I should mention that logback is already split by logging event type (logback-access, logback-classic) with logback-core providing shared code, applying the core/classic/access separation to the modularization scheme for logback extensions, we could end up in 18 (=3x6) modules (core/access/classic x extensions/json/commmon/groovy/jackson/loggly/). If logback-classic is the only target for logback-extensions, this combinatorial problem obviously does not apply.
I would think that would be at the discretion of the extension module author if they want to support both types of events. At least that makes things a little more decentralized and easier to manage.
More importantly though, I personally cannot and do not wish to commit to the maintenance of logback-extensions. Thus, I would prefer to support logback-extensions as a separate project as far as the code is concerned. However, at the web-site level (http://logback.qos.ch), the two projects could be integrated by allowing you to manage on your own the branch under say http://logback.qos.ch/extensions/.
Thoughts?
I think this is a great idea - it is similar in nature to what many Apache projects are doing these days: there is the main project and also a separate extensions project for community owned/maintained integration. The benefit here is that it provides a central place for the community to work together and provide new features without adding volatility or maintenance overhead to the core project - much nicer than having to fish through Google and random Github projects that may or may not work. (There is an added benefit in that the extension project usually doesn't require any CLA/ICLA to be signed).
Glad you like the approach. I was not familiar with the concept of github organizations. Anyway, inspired by what you have done with the "logback" organization, I've created the "qos-ch" organization (see https://github.qcom/qos-ch/) containing a single repo named logback-extensions with you and me having admin rights. Assuming projects like slf4j, cal10n, logback-*, mistletoe, etc move under that organization, I rather have it named qos-ch rather than logback. Anyway, as mentioned, I am not very familiar with github organizations, and if I've made a mistake, please let me know and I'll correct it promptly.
For starters, I just did the following:
1. I created the 'logback' organization on Github (https://github.com/logback) and made you Owner so you can own/manage it. (Even if we didn't use this mechanism, I figured you'd want to reserve that Github namespace anyway so no one else can squat it)
2. Created an 'extensions-dev' team that initially includes you and I.
3. Created a new 'extensions' repository.
4. Granted the 'extensions-dev' team push and pull access to the 'extensions' repository.
This way, the only thing to do to give people push access to the extensions repository is to just add them to the 'extensions-dev' team, and they can start contributing.
Please let me know if you have any objections to this and I can revert whatever you wish. In any event, you are Owner of the space, so you can do whatever you like. Whatever your decisions, I'm happy to oblige.
Cheers,
Les
P.S. Another benefit of this namespace is that - if you wanted - you can move the logback codebase to the space, create a separate team for that repository and add/remove users as desired if you want to enable development duties for logback proper to anyone you trust.
Github organizations seem like less chaotic way of managing projects. One advantage of person-based approach is the lack of the 300MB barrier which exists in github "organizations". Cheers, -- Ceki http://twitter.com/#!/ceki
Assuming projects like slf4j, cal10n, logback-*, mistletoe, etc move under that organization, I rather have it named qos-ch rather than logback.
This will work great as well - thanks for setting this up! Please feel free to do whatever you wish with the 'logback' organization - delete it, etc. You may wish to just keep it to prevent anyone from creating a naming conflict at a later date.
Anyway, as mentioned, I am not very familiar with github organizations, and if I've made a mistake, please let me know and I'll correct it promptly.
Everything looks great - I'll check in my initial JSON work asap. Thanks! Best, Les
+1 (see below) On Fri, Mar 9, 2012 at 4:35 PM, ceki <ceki@qos.ch> wrote:
Glad you like the approach.
I was not familiar with the concept of github organizations. Anyway, inspired by what you have done with the "logback" organization, I've created the "qos-ch" organization (see https://github.qcom/qos-ch/) containing a single repo named logback-extensions with you and me having admin rights.
Assuming projects like slf4j, cal10n, logback-*, mistletoe, etc move under that organization, I rather have it named qos-ch rather than logback.
I like the idea of pooling the logback extensions in a central location. I currently manage logback-android <https://github.com/tony19/logback-android> in Github and would like to join this organization. Let me know what to do. Thanks :-)
Anyway, as mentioned, I am not very familiar with github
organizations, and if I've made a mistake, please let me know and I'll correct it promptly.
Github organizations seem like less chaotic way of managing projects. One advantage of person-based approach is the lack of the 300MB barrier which exists in github "organizations".
Cheers,
-- Ceki http://twitter.com/#!/ceki
Hi Tony, What's your Github username? Cheers, Les On Fri, Mar 9, 2012 at 1:53 PM, Tony Trinh <tony19@gmail.com> wrote:
+1 (see below)
On Fri, Mar 9, 2012 at 4:35 PM, ceki <ceki@qos.ch> wrote:
Glad you like the approach.
I was not familiar with the concept of github organizations. Anyway, inspired by what you have done with the "logback" organization, I've created the "qos-ch" organization (see https://github.qcom/qos-ch/) containing a single repo named logback-extensions with you and me having admin rights.
Assuming projects like slf4j, cal10n, logback-*, mistletoe, etc move under that organization, I rather have it named qos-ch rather than logback.
I like the idea of pooling the logback extensions in a central location. I currently manage logback-android in Github and would like to join this organization. Let me know what to do. Thanks :-)
Anyway, as mentioned, I am not very familiar with github organizations, and if I've made a mistake, please let me know and I'll correct it promptly.
Github organizations seem like less chaotic way of managing projects. One advantage of person-based approach is the lack of the 300MB barrier which exists in github "organizations".
Cheers,
-- Ceki http://twitter.com/#!/ceki
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
Oops - my apologies - I just clicked the Github link. I'll add you asap. On Fri, Mar 9, 2012 at 2:35 PM, Les Hazlewood <les@hazlewood.com> wrote:
Hi Tony,
What's your Github username?
Cheers,
Les
On Fri, Mar 9, 2012 at 1:53 PM, Tony Trinh <tony19@gmail.com> wrote:
+1 (see below)
On Fri, Mar 9, 2012 at 4:35 PM, ceki <ceki@qos.ch> wrote:
Glad you like the approach.
I was not familiar with the concept of github organizations. Anyway, inspired by what you have done with the "logback" organization, I've created the "qos-ch" organization (see https://github.qcom/qos-ch/) containing a single repo named logback-extensions with you and me having admin rights.
Assuming projects like slf4j, cal10n, logback-*, mistletoe, etc move under that organization, I rather have it named qos-ch rather than logback.
I like the idea of pooling the logback extensions in a central location. I currently manage logback-android in Github and would like to join this organization. Let me know what to do. Thanks :-)
Anyway, as mentioned, I am not very familiar with github organizations, and if I've made a mistake, please let me know and I'll correct it promptly.
Github organizations seem like less chaotic way of managing projects. One advantage of person-based approach is the lack of the 300MB barrier which exists in github "organizations".
Cheers,
-- Ceki http://twitter.com/#!/ceki
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
On 09.03.2012 22:53, Tony Trinh wrote:
+1 (see below)
On Fri, Mar 9, 2012 at 4:35 PM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Glad you like the approach.
I was not familiar with the concept of github organizations. Anyway, inspired by what you have done with the "logback" organization, I've created the "qos-ch" organization (see https://github.qcom/qos-ch/) containing a single repo named logback-extensions with you and me having admin rights.
Assuming projects like slf4j, cal10n, logback-*, mistletoe, etc move under that organization, I rather have it named qos-ch rather than logback.
I like the idea of pooling the logback extensions in a central location. I currently manage logback-android <https://github.com/tony19/logback-android> in Github and would like to join this organization. Let me know what to do. Thanks :-)
Hi Tony, I've added tony19 as the only member of the logback-android-team with push/pull/admin privileges. The logback-android-team manages the qos-ch/logback-android repository [1]. You should be able to move/transfer the existing logback-android repo at [2] to [1]. I've never tried doing this but if you run into trouble let me know. Cheers, [1] https://github.com/qos-ch/logback-android [2] https://github.com/tony19/logback-android -- Ceki http://twitter.com/#!/ceki
On Fri, Mar 9, 2012 at 5:51 PM, ceki <ceki@qos.ch> wrote:
Hi Tony,
I've added tony19 as the only member of the logback-android-team with push/pull/admin privileges. The logback-android-team manages the qos-ch/logback-android repository [1]. You should be able to move/transfer the existing logback-android repo at [2] to [1].
I had to delete the project you created in order to transfer my repo over (otherwise, Github complains that the project already exists). Unfortunately, I've lost my admin rights on logback-android. Can you please correct that? Thanks.
For anyone else interested in moving their repo, see this page: http://help.github.com/move-a-repo/
I've never tried doing this but if you run into trouble let me know.
Cheers,
[1] https://github.com/qos-ch/**logback-android<https://github.com/qos-ch/logback-android> [2] https://github.com/tony19/**logback-android<https://github.com/tony19/logback-android>
-- Ceki http://twitter.com/#!/ceki
Quick note to all: The 'Logback Extensions' project is under way: https://github.com/qos-ch/logback-extensions/wiki Feedback, suggestions and contributions welcome! Also, Tony, would it make sense to have the Android work you've done to be part of the logback-extensions like the other modules (see the wiki link above). Cheers, Les On Fri, Mar 9, 2012 at 3:31 PM, Tony Trinh <tony19@gmail.com> wrote:
On Fri, Mar 9, 2012 at 5:51 PM, ceki <ceki@qos.ch> wrote:
Hi Tony,
I've added tony19 as the only member of the logback-android-team with push/pull/admin privileges. The logback-android-team manages the qos-ch/logback-android repository [1]. You should be able to move/transfer the existing logback-android repo at [2] to [1].
I had to delete the project you created in order to transfer my repo over (otherwise, Github complains that the project already exists). Unfortunately, I've lost my admin rights on logback-android. Can you please correct that? Thanks.
For anyone else interested in moving their repo, see this page: http://help.github.com/move-a-repo/
I've never tried doing this but if you run into trouble let me know.
Cheers,
[1] https://github.com/qos-ch/logback-android [2] https://github.com/tony19/logback-android
-- Ceki http://twitter.com/#!/ceki
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
On Sat, Mar 10, 2012 at 1:39 AM, Les Hazlewood <les@hazlewood.com> wrote:
Quick note to all:
The 'Logback Extensions' project is under way:
https://github.com/qos-ch/logback-extensions/wiki
Feedback, suggestions and contributions welcome!
Good stuff :)
Also, Tony, would it make sense to have the Android work you've done to be part of the logback-extensions like the other modules (see the wiki link above).
I think logback-android is already in the right spot. To me, logback-android isn't really an extension of logback. It's actually a fork of logback, customized to run on Android; and one should be able to use logback-extensions from logback-android.
Cheers,
Les
I think logback-android is already in the right spot. To me, logback-android isn't really an extension of logback. It's actually a fork of logback, customized to run on Android; and one should be able to use logback-extensions from logback-android.
Gotcha - makes sense. Thanks for clarifying. Best, Les
participants (3)
-
ceki -
Les Hazlewood -
Tony Trinh