Logger 3.1.0: Adding Level to Additional Procedures

Prior to Logger 3.1.0, the following procedures would only log data when the Logger level was set to DEBUG:

  • log_apex_items
  • log_userenv
  • log_cgi_env
  • log_character_codes

This introduced an additional issue. What happens when I want to call these functions when the Logger level was set to ERROR? For example, suppose in a production environment you set the Logger level to ERROR (this is a pretty standard case). When an error occurs you call the usual logger.log_error call in the exception block. What if you wanted to also log all the APEX item values? If you called logger.log_apex_items it would not run since it had a hard coded validation to only log in DEBUG mode.

Each of the above functions now take in a new optional parameter called p_level. If defined, it will always log up to the defined level and store the entry in LOGGER_LOGS as that level. The best way to think of this paramater is if it is defined you're calling the equivialnt of logger.log_apex_items_error (if p_level => logger.g_error). If it is not defined, it will continue to only log in DEBUG mode and use the associated value for logger_level in LOGGER_LOGS.


-- Dev environment where Logger level is "DEBUG"
exec logger.set_level(p_level => logger.g_debug);

exec logger.log_userenv;

select id, logger_level, substr(text, 1, 45) text
from logger_logs_5_min
order by id desc;

-- Note: The "64" refers to the "SYS_CONTEXT" level. See the API docs for more info
---------- ------------ ---------------------------------------------
    890647           64 USERENV values stored in the EXTRA column

-- Production: Logger level is set to "ERROR"
exec logger.set_level(p_level => logger.g_error);
exec logger.log_userenv;

-- No rows will be returned since Logger level is "ERROR"
select id, logger_level, substr(text, 1, 45) text
from logger_logs_5_min
order by id desc;

no rows selected

-- Using new parameter, store log_userenv even when Logger level is "ERROR"
exec logger.log_userenv(p_level => logger.g_error);

select id, logger_level, substr(text, 1, 45) text
from logger_logs_5_min
order by 1 desc;

-- Note: The "2" refers to the "ERROR" level. This happens since it uses the value stored in p_level
---------- ------------ ---------------------------------------------
    890648            2 USERENV values stored in the EXTRA column

Logger 3.1.0: Beta

Logger 3.1.0 beta is now available for download in the releases folder (3.1.0_beta.zip).

This release is primarily focused around bug fixes, documentation, and some minor changes (i.e. it's not the most splashiest release we've had to date). We must thank the community for submitting all the bugs and suggestions.

As usual with each beta release of Logger, there will be a series of blog posts highlighting the changes:

You can review a complete list of changes for this release here.

Oracle XE / APEX: Release 0.3.0

We're pleased to announce that we've released 0.3.0 of the Oracle XE / APEX build scripts a few weeks ago. The release information is available here.

The following major changes were done to the build scripts:

  • Lots of script changes
    • Though not visible to the someone using the script, this will make things a lot easier for future releases of the script.
  • Suppress standard output
  • Support for APEX 5.0
  • Configuration file changed
    • Previously the configuration file was config.sh and all changes were made in there. The issue was that this file also contained some additional system configurations that made the file a bit messsy and complicated to read. To make things easier we've added a new config.properties which is the only thing that needs to be modified.
  • Node4ORDS Update
    • There was a bug which caused the webserver to keep crashing. This has been fixed. If you already have an existing installation using the build script read this article to update Node4ORDS.
  • Additional Documentaiton
    • One common question we get is "How do I connect to Oracle". To help out we've created a /docs folder with detailed information about various topics (including how to connect to Oracle). We'll be looking to add more documents in the future.

You can view the full list of changes here and you can download the current 0.3.0 release here. Thanks to Trent Schafer and Adrian Png for all their help with this release!

We're actively working on the 0.4.0 release. You can keep track of those changes on the issues page.

Trust and Open Source

They're a few train of thoughts people have regarding open source projects and trust:

  1. Don't trust them at all since it's community driven and their could be malicious code.
  2. Trust them blindly since the community would have removed any malicious code.
  3. Spend some time, review and audit the code, then install if it passes.

Most people seem to align with statements #1 and #2. The real answer should be #3; audit first. 

To those in the "Don't trust" camp. I believe this is a naive approach to the situation. Since open source code is, well open source, you can do a complete audit on the project before integrating it into your system. Of course you need to estimate the time it would take to audit it vs. building a similar tool from scratch. In most cases, auditing will be the cheaper option.

You also need to remember that most people in the community are not "bad" people and will put in good code. Since all the checkins are public and visible to everyone there's usually a second person that looks over the code before it actually is merged into the project. In most cases this "second person" is the project owner.

At OraOpenSource, if we receive any pull requests for our projects (i.e. 3rd party code submissions) we look over each of them to ensure there's not malicious code amongst other things.

To those in the "Blind Trust" camp. If you're installing an open source project in your system you should spend some time to look it over. Of course there's also the inherited trust associated to reputable projects. One example comes to mind (besides our own projects) is jQuery. I doubt most people have the time to review each line of jQuery. You just assume (and it's a fair assumption) that the code will not be malicious since it's developed by a very active community and backed by large organizations.


Have other thoughts on this topic? Feel free to leave a comment below.

Restrict Logger's Access to Your Data

Some DBAs and organizations may have issues with installing Logger in a schema with their existing data. The reason being that they don't want 3rd party code sitting alongside their data. The good news is that this concern can easily be resolved. Logger doesn't need to see your data/schema. Rather, your schema needs to see Logger.

Update 1: I've created a new issue for this so that these scripts will be available as part of Logger 3.1.0 onwards.

Update 2: This is now in Logger 3.1.0. Documentation here.

Here's how to setup Logger so that it can't see your data:

  1. Create a new user (for this example logger_user) with the appropriate permissions. You can review this in the Installation documentation. There's already a script to create a user in the install folder.

  2. Install Logger in the newly created schema.

  3. Grant execute and select permissions from logger_user to your schema:

-- Run as logger_user
grant execute on logger to my_user;
grant select on logger_logs to my_user;
grant select on logger_logs_apex_items to my_user;
grant select on logger_logs_5_min to my_user;
-- Add any additional grants to other Logger views
  1. In your schema, create the appropriate synonyms:
-- Run as my_user
create or replace synonym logger for logger_user.logger;
create or replace synonym logger_logs for logger_user.logger_logs;
create or replace synonym logger_logs_apex_items for logger_user.logger_logs_apex_items;
create or replace synonym logger_logs_5_min for logger_user.logger_logs_5_min;

After doing these steps your schema can see Logger's tables and views, and run the logger package. Assuming you don't grant public access to your tables/packages then Logger can't see your data.