New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add FrameworkListener and improve Framework logging #40

Closed
saschazelzer opened this Issue Sep 23, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@saschazelzer
Member

saschazelzer commented Sep 23, 2015

The logging facility uses a singleton for managing log levels. Initialization is not thread-safe on compilers not supporting magic statics and multiple framework instances cannot be handled.

@saschazelzer saschazelzer added the bug label Sep 23, 2015

@saschazelzer saschazelzer added this to the Release 3.0 milestone Sep 23, 2015

@saschazelzer saschazelzer self-assigned this Oct 11, 2015

@jeffdiclemente

This comment has been minimized.

Show comment
Hide comment
@jeffdiclemente

jeffdiclemente Feb 29, 2016

Contributor

These are the requirements for any solution to this issue:

  • Logging is thread safe when using a compiler without support for C++ magic statics
  • Each framework instance can have its own log level
Contributor

jeffdiclemente commented Feb 29, 2016

These are the requirements for any solution to this issue:

  • Logging is thread safe when using a compiler without support for C++ magic statics
  • Each framework instance can have its own log level
@jeffdiclemente

This comment has been minimized.

Show comment
Hide comment
@jeffdiclemente

jeffdiclemente Feb 29, 2016

Contributor

@saschazelzer Is it a requirement that any arbitrary bundle, excluding CppMicroServices itself, can use the logger?

I would imagine that this is not a requirement and that the US_DEBUG, US_INFO, US_WARN, and US_ERROR log macros are for internal Framework use only.
A Log service could be created for use by arbitrary bundles if its needed.

Contributor

jeffdiclemente commented Feb 29, 2016

@saschazelzer Is it a requirement that any arbitrary bundle, excluding CppMicroServices itself, can use the logger?

I would imagine that this is not a requirement and that the US_DEBUG, US_INFO, US_WARN, and US_ERROR log macros are for internal Framework use only.
A Log service could be created for use by arbitrary bundles if its needed.

@saschazelzer

This comment has been minimized.

Show comment
Hide comment
@saschazelzer

saschazelzer Mar 1, 2016

Member

Initially, the log macros were intended to be used by the framework implementation only. However, it proved to be too convenient and is now used in test bundles and other bundles as well.

I think it would be good to have a simple log service and some public log macros take advantage of it. Some internal log macro usage would probably need to be redone and use some other framework internal mechanism though.

Member

saschazelzer commented Mar 1, 2016

Initially, the log macros were intended to be used by the framework implementation only. However, it proved to be too convenient and is now used in test bundles and other bundles as well.

I think it would be good to have a simple log service and some public log macros take advantage of it. Some internal log macro usage would probably need to be redone and use some other framework internal mechanism though.

@jeffdiclemente

This comment has been minimized.

Show comment
Hide comment
@jeffdiclemente

jeffdiclemente Mar 4, 2016

Contributor

Thanks @saschazelzer. I'm working on a set of requirements and at least one design based on this information. I'll share the google doc with you soon for discussion and agreement on what to do.

Contributor

jeffdiclemente commented Mar 4, 2016

Thanks @saschazelzer. I'm working on a set of requirements and at least one design based on this information. I'll share the google doc with you soon for discussion and agreement on what to do.

@saschazelzer

This comment has been minimized.

Show comment
Hide comment
@saschazelzer

saschazelzer Mar 4, 2016

Member

Great. I believe this is known / clear, but just in case: The framework requires some logging facility during initialization, before any log service could potentially be available. The typical solution (as in the OSGi specs) are framework events in combination with some implementation specific log mechanism which could make the log entries available to a log service being published later in time. It could also route the log message to the service if available and if not fall back to some internal backend.

Member

saschazelzer commented Mar 4, 2016

Great. I believe this is known / clear, but just in case: The framework requires some logging facility during initialization, before any log service could potentially be available. The typical solution (as in the OSGi specs) are framework events in combination with some implementation specific log mechanism which could make the log entries available to a log service being published later in time. It could also route the log message to the service if available and if not fall back to some internal backend.

@jeffdiclemente jeffdiclemente changed the title from Framework specific log levels to Add FrameworkListener and improve Framework logging Jul 15, 2016

jeffdiclemente added a commit that referenced this issue Jul 28, 2016

Framework Listener and logging support (#96)
Implement FrameworkEvent, Framework Listeners and an internal Framework logger.
Closes #40 

Signed-off-by: The MathWorks, Inc. Roy.Lurie@mathworks.com
@jeffdiclemente

This comment has been minimized.

Show comment
Hide comment
@jeffdiclemente

jeffdiclemente Jul 28, 2016

Contributor

fixed in PR #96

Contributor

jeffdiclemente commented Jul 28, 2016

fixed in PR #96

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment