Skip to content
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

Support for logs dir #28

Open
pwinckles opened this issue Feb 3, 2021 · 6 comments
Open

Support for logs dir #28

pwinckles opened this issue Feb 3, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@pwinckles
Copy link
Collaborator

How should the logs directory be used? Currently, nothing is written to the logs directory. How do people want to use it?

@bcail
Copy link

bcail commented Jun 22, 2021

I could see using logs/ for events like object verification and fixity checks. It'd be nice to have an API for writing some text to a certain file in logs/. There could also be a logger-like API, that would take the text and write it to the file with the current timestamp.

@pwinckles
Copy link
Collaborator Author

pwinckles commented Jun 22, 2021

@bcail Are you imagining something like:

interface OcflRepository {

    void log(String objectId, String logFileName, String message);

}

Or something like:

interface OcflObjectUpdater {

   void log(String logFileName, String message);

}

Or both? Or something else?

Would you want/need anything more structured than a string message?

@bcail
Copy link

bcail commented Jun 22, 2021

I think I'd lean toward the former, since these log messages would be happening separate from object updates. We shouldn't need anything more than a string message.

However, I could see it being useful to be able to specify the log level (INFO, ERROR, ...), and have ocfl-java put that into the log, with the current UTC timestamp. We could add that info to the message ourselves, but if you have a nice way of handling that in ocfl-java, we'd probably use it.

@pwinckles
Copy link
Collaborator Author

Okay, so the current proposal is:

interface OcflRepository {

    void log(String objectId, String logFileName, String message);

    InputStream readLogFile(String objectId, String logFileName);

}

I am slightly hesitant to do something like:

    void logInfo(String objectId, String logFileName, String message);
    void logWarn(String objectId, String logFileName, String message);
    void logError(String objectId, String logFileName, String message);

To produce log lines like:

2021-06-22T18:05:32+00:00 [INFO] message

Because it is much more prescriptive than I care to be. For example, what if someone wants to put JSON objects in their log?

That said, the proposed API also has a problem that it does not support non-line based logging. For example, what if I want my logs to be an XML document with log entries represented as elements within the document (perhaps it's a PREMIS document )? To support something like that it would seem like we'd need an API like:

void writeLogFile(String objectId, String logFileName, InputStream content);

That would overwrite the log file rather than append to it.

Perhaps something like this could make everyone happy?

interface OcflRepository {

    enum Mode {
        APPEND, OVERWRITE
    }

    enum Level {
        DEBUG, INFO, WARN, ERROR
    }

    void log(String objectId, String logFileName, Mode mode, String content);

    void log(String objectId, String logFileName, Level level, String message);

    InputStream readLogFile(String objectId, String logFileName);

}

@pwinckles
Copy link
Collaborator Author

Note, overwriting the file is a little dangerous as concurrent updates have a race condition.

@bcail
Copy link

bcail commented Jun 22, 2021

That final example interface looks OK to me - I think we would just use the log message with the level and the timestamp. I think if we created a PREMIS document, we would put it in the object itself, not the logs directory - but others may want to.

@pwinckles pwinckles added the enhancement New feature or request label Sep 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants