Remove dependencies to entity & plugin API, use container parameters instead [#2651808]

Problem/Motivation

A logging system should keep its dependencies to minimum so that it can keep working even when those dependencies fail.
Right now we have dependencies on two big core systems, Plugin and Entity.

Proposed resolution

Drop those dependencies by using container parameters.
This also means drop the UI as well. If someone wants to configure monolog, settings.php and/or services.yml should be used

Remaining tasks

Write patch/commit

User interface changes

Monolog no longer can be configured from UI.

API changes

...a lot

Data model changes

...a lot

Comments

Comment #1

17 January 2016 at 23:03

ParisLiakos created an issue. See original summary.

Comment #2

ParisLiakos CreditAttribution: ParisLiakos commented 17 January 2016 at 23:03

Priority:

Normal

» Major

Comment #3

1 February 2016 at 02:07

ParisLiakos committed a6c0343 on 8.x-1.x

Issue #2651808 by ParisLiakos: Remove dependencies to entity...

Comment #4

ParisLiakos CreditAttribution: ParisLiakos commented 1 February 2016 at 02:08

Status:

Active

» Fixed

This needs some documentation now

Comment #5

lussoluca

he/him

Italian

Italy

CreditAttribution: lussoluca as a volunteer commented 1 February 2016 at 07:14

Just a couple of note:

1) IMHO it's better to use tagged services instead of rely on service name
2) with this patch we are loosing the possibilty to set level and bubbling to handlers, maybe we should use yaml file to do this configurations? (some like monolog.yml near to settings.php)?

Comment #6

ParisLiakos CreditAttribution: ParisLiakos commented 1 February 2016 at 09:51

Thanks for the feedback!

1) I thought about it a lot. I know its cleaner architecturally, but doing it this way means we have to subclass *all* processors that ship with monolog to be able to use them :/ which probably doesnt scale for the future...imagine monolog adding a new processor, one would have to update this module to be able to use it.. => more maintenance burden.

2) You can still provide bubbling and level, just by changing the service parameters to service.yml (right now it just uses the defaults)..maybe i should add an example of this in homepage.

# in your site's services.yml
services:
  monolog.handler.browser_console:
    class: Monolog\Handler\BrowserConsoleHandler
    # Set alert as the minimum level (ignores emergency) and disable bubbling for this Handler
    arguments: ['1', false]

Comment #7

lussoluca

he/him

Italian

Italy

CreditAttribution: lussoluca as a volunteer commented 6 February 2016 at 15:47

1) I thought about it a lot. I know its cleaner architecturally, but doing it this way means we have to subclass *all* processors that ship with monolog to be able to use them :/ which probably doesnt scale for the future...imagine monolog adding a new processor, one would have to update this module to be able to use it.. => more maintenance burden.

Ok, I can live with this :-)

2) You can still provide bubbling and level, just by changing the service parameters to service.yml (right now it just uses the defaults)..maybe i should add an example of this in homepage.

Perfect!