[
https://issues.apache.org/jira/browse/POLYGENE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niclas Hedhman updated POLYGENE-307:
------------------------------------
Description:
Polygene has better infrastructure for supporting its own logging framework,
rather than having users selecting their own.
If we make this an extension, we and other people can simply create multiple
implementations and that is automatically used by both Polygene Core, its
libraries and extensions, as well as user code.
If this is introduced, we can scrap the library-logging impl since it is both
incomplete as well as trying to solve too many things at the same time.
However, the lessons learned there should probably be incorporated in the this
extension.
Features;
* Separation of Debugging, Application Log and Application Audit
* Enable trace per Composite at bootstrap (even runtime?)
* Strongly typed Log Events
* Custom Log Event types, defined by Application Code and not only extension
implementation.
* Allow Log Events to be entities, and allow the Entity Store used for those
events to still emit Log Events, which then needs to be directed to the
secondary target.
* Cleaning up of stacktraces, so that all Polygene magic is removed, and a
configurable policy for that. (i.e. collaboration with
FragmentInvocationHandler and possibly making that better)
was:
Polygene has better infrastructure for supporting its own logging framework,
rather than having users selecting their own.
If we make this an extension, we and other people can simply create multiple
implementations and that is automatically used by both Polygene Core, its
libraries and extensions, as well as user code.
If this is introduced, we can scrap the library-logging impl since it is both
incomplete as well as trying to solve too many things at the same time.
However, the lessons learned there should probably be incorporated in the this
extension.
Features;
* Separation of Debugging, Application Log and Application Audit
* Enable trace per Composite at bootstrap (even runtime?)
* Strongly typed Log Events
* Custom Log Event types, defined by Application Code and not only extension
implementation.
* Allow Log Events to be entities, and allow the Entity Store used for those
events to still emit Log Events, which then needs to be directed to the
secondary target.
> Debug, Trace and Logging Extension
> ----------------------------------
>
> Key: POLYGENE-307
> URL: https://issues.apache.org/jira/browse/POLYGENE-307
> Project: Polygene
> Issue Type: New Feature
> Reporter: Niclas Hedhman
> Priority: Major
>
> Polygene has better infrastructure for supporting its own logging framework,
> rather than having users selecting their own.
> If we make this an extension, we and other people can simply create multiple
> implementations and that is automatically used by both Polygene Core, its
> libraries and extensions, as well as user code.
> If this is introduced, we can scrap the library-logging impl since it is both
> incomplete as well as trying to solve too many things at the same time.
> However, the lessons learned there should probably be incorporated in the
> this extension.
>
> Features;
> * Separation of Debugging, Application Log and Application Audit
> * Enable trace per Composite at bootstrap (even runtime?)
> * Strongly typed Log Events
> * Custom Log Event types, defined by Application Code and not only extension
> implementation.
> * Allow Log Events to be entities, and allow the Entity Store used for those
> events to still emit Log Events, which then needs to be directed to the
> secondary target.
> * Cleaning up of stacktraces, so that all Polygene magic is removed, and a
> configurable policy for that. (i.e. collaboration with
> FragmentInvocationHandler and possibly making that better)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
