Re: Feedback request: usage of "EmbulkEmbed" and "EmbulkService" / "BINARY" type
(Copied from an old post in the embulk-announce mailing list.)
Hi Embulk users,
As mentioned in the previous e-mail, we are going to change the usage of
EmbulkEmbed users, please check the following list, stay tuned on next announcements, and take care when you are upgrading
embulk-core versions. (All the following changes will not affect Embulk CLI usage. Then, I believe most users are not affected.)
org.embulk.EmbulkService will be removed soon. Users need to switch to
2. Drop support for JSR-250 LifeCycle annotations (
As mentioned in https://github.com/embulk/embulk/issues/1047, we are going to drop support for
@PreDestroy. If you’re using them, please leave your comments in https://github.com/embulk/embulk/issues/1047.
EmbulkEmbed#destroy() will be unsupported as well.
v0.9.12 shows warning messages for use of
@PreDestroy before actual drop. If you’re concerned, please try Embulk
3. Change the usage of SLF4J
Logback (SLF4J backend) has been included in
embulk-core’s dependencies, Logback has been configured in the beginning of
EmbulkEmbed. Those will be changed.
EmbulkEmbed users will have to include and configure some SLF4J backend library by themselves.
4. Change the way to load dependency libraries from
Dependency libraries of
embulk-core are currently to be located in
CLASSPATH, and to be loaded simultaneously with
embulk-core. But this way exposes these libraries to plugins, and it has caused complicated dependency problems with plugins.
We are going to change the way to load dependency libraries.
EmbulkEmbed users will have to call Embulk’s
static method to specify paths to those dependency libraries before initializing
- Author: @dmikurube
- Created at: December 28, 2018