You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
io.ifar.skidroad.dropwizard provides: CLI & tasks, *Managed wrappers, and config beans. Nothing outside of the package depends on anything inside it. Can just move it to a separate optional JAR. To use in Play instead, might want to add an io.ifar.skidroad.play package that provides analogous Play hooks.
io.ifar.skidroad.jdbi is similar. Can move to separate JAR, provide alternate LogFileTracker implementation. LogFileTracker is basically a sink for log file events. A file based implementation could be provided. The minimal amount of state to track is whether a file has been uploaded or not, which could be handled with file system operations rather than database. Also the dropwizard CLI uses the JDBI DAO directly to list files. This should probably be routed through the tracker to make things more modular. Postpone totally breaking dropwizard -> JDBI dependency though, since the dropwizard CLI tasks also take care of constructing the JDBI layer.
Weaving through alternate encryption would be straight-forward via PrepWorkerFactory interface.
The text was updated successfully, but these errors were encountered:
io.ifar.skidroad.dropwizard provides: CLI & tasks, *Managed wrappers, and config beans. Nothing outside of the package depends on anything inside it. Can just move it to a separate optional JAR. To use in Play instead, might want to add an io.ifar.skidroad.play package that provides analogous Play hooks.
io.ifar.skidroad.jdbi is similar. Can move to separate JAR, provide alternate LogFileTracker implementation. LogFileTracker is basically a sink for log file events. A file based implementation could be provided. The minimal amount of state to track is whether a file has been uploaded or not, which could be handled with file system operations rather than database. Also the dropwizard CLI uses the JDBI DAO directly to list files. This should probably be routed through the tracker to make things more modular. Postpone totally breaking dropwizard -> JDBI dependency though, since the dropwizard CLI tasks also take care of constructing the JDBI layer.
Weaving through alternate encryption would be straight-forward via PrepWorkerFactory interface.
The text was updated successfully, but these errors were encountered: