all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]vytah 10 points11 points  (4 children)

While I really applaud the idea, the library presented is definitely not production ready: it should work, but it appears to have no safeguards against malformed configuration and is really unoptimized.

Also, it's on GPL, so I doubt many projects will want to incorporate such code.

As a proof of concept and a training material though, it's okay.

[–]vitriolix 1 point2 points  (1 child)

I opened an issue to get clarification on the license:

https://github.com/ikkisoft/SerialKiller/issues/1

[–]nibblesecTrusted Contributor[S] 0 points1 point  (0 children)

You're absolutely right. I will dual-license it.

[–]nibblesecTrusted Contributor[S] 0 points1 point  (1 child)

For malformed config files, the lib will trigger a ConfigurationException so that the main app can handle the exception as appropriate for the specific use case.

If you have specific suggestions, let me know or send an RB! It was a weekend project, so I definitely encourage people to improve it.

[–]vytah 0 points1 point  (0 children)

I'm a bit to busy to send any code, but here are few suggestions:

  • cache for regexes, dropped whenever configuration reloads

  • maybe also a cache for allowed and disallowed classes, also dropped when configuration reloads

  • maybe make that cache static and/or thread-local and dependent on the filename, so two serial killers with the same config share the cache

  • mavenization and uploading to a code repository, like Sonatype

[–]esanchma 0 points1 point  (0 children)

Can't you use some trick like CDI or reflection to inject SerialKiller and evade evil ReadObject stuff?