Комментарии 12
Мы для удаленной консоли взяли CRaSH и дописали туда пару своих команд. Выглядит так: заходишь по ssh в приложение, запускаешь команду выполнения произвольного кода, вставляешь код на groovy, получаешь ответ.
Скриншот
Код на Java, а для скриптов Python, Bash или иногда Groovy. До настоящего момента у меня все было примерно так. Не могу сказать, что я сильно этим не доволен и мне срочно нужен интерпретатор Java.
А не проще будет вместо всех этих мучений код скомпилировать и загрузить класс-файлы (возможно в jar)?
Вопрос в том, что эти классы еще надо как-то доставить до приложения — а там докер, «облако» — другой уровень начинается
М.б. какой-нибудь свой classloader написать для этого?..
classloader, который делает что?
загрузить байтики в класс не проблема — вопрос откуда они возьмутся и что это будут за байтики
Предлагаю просто прикинуть скольким критериям удовлетворяет выполнение скомпиленных классов — как скомпилить класс, чтобы перенаправить I/O, чтобы можно было снаружи в него контекст передать…
загрузить байтики в класс не проблема — вопрос откуда они возьмутся и что это будут за байтики
Предлагаю просто прикинуть скольким критериям удовлетворяет выполнение скомпиленных классов — как скомпилить класс, чтобы перенаправить I/O, чтобы можно было снаружи в него контекст передать…
Groovy один из самых адекватных? И почему я ни разу не удивлен?
Впрочем, автор сознательно себя ограничивает одинаковым или похожим синтаксисом, в то время как часто (но не обязательно всегда) синтаксис удобно иметь как раз другой. Кложа, условно.
Впрочем, автор сознательно себя ограничивает одинаковым или похожим синтаксисом, в то время как часто (но не обязательно всегда) синтаксис удобно иметь как раз другой. Кложа, условно.
Я так и не понял, для чего код руками в проде нужно запускать?
Типичные кейсы:
- нестандартное обращение пользователя в поддержку: ради одного случая писать боевой код — не хочется, а помочь человеку — хочется
- ускорение запуска функционала: админка для фичи еще не готова, а сервисный слой уже вполне работает. можем сегодня запускать фичу в script-driven режиме, а завтра доделаем админку
Спасибо за ответ.
Я к тому что это все очень небезопасно выглядит. Вы по сути запускаете нетестированный код на проде, я подозреваю что в CVS тоже скрипт не добавляется до запуска.
Конечно это может пригодиться, например в стартапе, или если уже и так все сломано и через 5 мин фирма обанкротится. Но если это рутина, то явно сломаны процессы разработки.
Я к тому что это все очень небезопасно выглядит. Вы по сути запускаете нетестированный код на проде, я подозреваю что в CVS тоже скрипт не добавляется до запуска.
Конечно это может пригодиться, например в стартапе, или если уже и так все сломано и через 5 мин фирма обанкротится. Но если это рутина, то явно сломаны процессы разработки.
Да, это угроза безопасности, но т.к. мы об этом знаем, то все не так страшно.
Понятно, что функционал закрыт разрешениями и доступен только нескольким людям.
А что до процесса, то ревьюить, тестировать и складывать скрипты в VCS — можно и нужно, так же как и весь остальной код.
Просто тут все это работает на доверии. В кейсах, которые я описал, польза окупает этот риск
Понятно, что функционал закрыт разрешениями и доступен только нескольким людям.
А что до процесса, то ревьюить, тестировать и складывать скрипты в VCS — можно и нужно, так же как и весь остальной код.
Просто тут все это работает на доверии. В кейсах, которые я описал, польза окупает этот риск
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java REPL вам не ScriptEngine