Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 30 07:41

    dependabot[bot] on gradle

    (compare)

  • Jul 30 07:41

    xvik on master

    Bump dropwizard-dependencies fr… Merge pull request #176 from xv… (compare)

  • Jul 30 07:41
    xvik closed #176
  • Jul 29 23:40
    codecov-commenter commented #176
  • Jul 29 23:39
    codecov-commenter commented #176
  • Jul 29 23:39
    codecov-commenter commented #176
  • Jul 29 23:35
    codecov-commenter commented #176
  • Jul 29 23:35
    codecov-commenter commented #176
  • Jul 29 23:35
    codecov-commenter commented #176
  • Jul 29 23:34
    codecov-commenter commented #176
  • Jul 29 23:34
    codecov-commenter commented #176
  • Jul 29 23:34
    codecov-commenter commented #176
  • Jul 29 23:09
    dependabot[bot] labeled #176
  • Jul 29 23:09
    dependabot[bot] opened #176
  • Jul 29 23:09

    dependabot[bot] on gradle

    Bump dropwizard-dependencies fr… (compare)

  • Jul 12 21:17

    xvik on master

    use direct dependency versions … (compare)

  • Jul 02 23:59
    codecov-commenter commented #175
  • Jul 02 23:58
    codecov-commenter commented #175
  • Jul 02 23:58
    codecov-commenter commented #175
  • Jul 02 23:58
    codecov-commenter commented #175
John LaBarge
@johnlabarge
err data in the DB?
Vyacheslav Rusakov
@xvik
but it will not work with junit5
i'm sure there are some easy ways to do such tests: for sure there are general 3rd party db extensions for junit5 which could be used. I just never need this so never searched
John LaBarge
@johnlabarge
so when making Jdbi3 repositories what if I have a concrete implementation?
John LaBarge
@johnlabarge
Ok I guess I converted to interface but now I still have an exception "Extension not found: interface"
found something about installing SqlObject plugin, but I don't know where to put the call to installPlugin
John LaBarge
@johnlabarge
looks like docs say that is already installed
not sure why it barfs on the repo
Vyacheslav Rusakov
@xvik
@johnlabarge It should work. Your reporsitory must be an interface or abstract class (otherwise it makes no sense), it must be annotated with @JdbiRepository, and classpath scan must include this packages (or extensions specified directly in GuiceBundle). Of course jdbi bundle must be registered.
hard to tell what is wrong in your case, need more info (how you declare repositories, what errors appear)
Vyacheslav Rusakov
@xvik
regarding SqlObjectPlugin it is insdeed registered because guicey-jdbi integration invokes new JdbiFactory().build(...) which internally calls
protected void configure(final Jdbi jdbi) {
        jdbi.installPlugin(new SqlObjectPlugin());
        jdbi.installPlugin(new JodaTimePlugin());
        jdbi.installPlugin(new GuavaPlugin());
    }
John LaBarge
@johnlabarge
Ok another question I was trying to use the JDBI object in my DAO but I can't seem to because this is requiring my DAO to be an interface. Does anyone have an example of how to do this with DW?
Vyacheslav Rusakov
@xvik
@johnlabarge Sorry, but I don't understand your question. If you need to inject other bean inside interface then there is a way (usage in the example project)
Shachar Levy
@levyshachar2
@xvik question, we used Guicey until now per test class , so each test class will fire up our server.
Is there a way to fire up the server per test and not test class?
We are using Junit 4
Vyacheslav Rusakov
@xvik
@levyshachar2 yes, it should be possible to use @Rule instead of @ClassRule to apply context per test.
Note that junit 5 extensions will work only per class, so once you want to migrate you'll have to rewrite your tests.
Shachar Levy
@levyshachar2
awesome thanks , ill try that
Yutian Wu
@cielowu

Hi I'm doing some migration from dropwizard-guice to dropwizard-guicey.
So I'm still using Dropwizard 1.3.5 and Guice 4.2.2, so I'm using dropwizard-guicey 4.2.2.
I followed the migration guide http://xvik.github.io/dropwizard-guicey/4.2.2/guide/dg-migration/, but one thing I'm not sure about is: I'm still trying to use environment.jersey().register() to register my implementation of ValueFactoryProfiver, but it seems not works and keep complaining me:

org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at SystemInjecteeImpl(...),

so except using the installer and extension, is there a way for me to keep the old dropwizard way? (because otherwise, it would be a huge change for me).

and I know it is very good to try to use auto-config, but if I don't want to used it where should I include the configuration file? (I'm just trying to split my change into smaller pieces to make the migration smoothy)
Vyacheslav Rusakov
@xvik
Hi @cielowu ! First of all, there was a special guicey (maintennance) release 4.2.3 a week ago actualizing all dependencies.
When you use environment.jersey().register() you are just registering object within dropwizard, but not in guice. So if this object requiring other guice beans, it would complain.
Instead register everything as extensions: GuiceBundle.builder().extensions(MyValueFactoryProfiver.class). This way guicey will instantiate it as guice bean an register properly in jersey.
Auto config (.enableAutoConfig(getClass().getPackage().getName())) only allows you to avoid manual extension registration: it would search them in classpath automatically. But essentially, it would be the same as manual registration.
6 replies
Vyacheslav Rusakov
@xvik
If you already have too many registrations with environment.jersey().register() then you can only try to enable hk2 bridge so hk could see your guice beans http://xvik.github.io/dropwizard-guicey/4.2.3/guide/configuration/#hk2-bridge
Can't guarantee that everything would work (depends on beans implementation), but it's the only chance. But, if possible, it would be much better to replace all such manual registrations into guicey extensions registration (or just enable auto config)
Note that auto configuration would not be a "black box" for you: you can always enable diagnostic logs (.printDiagnosticInfo()) and see all recognized items.
Yutian Wu
@cielowu
cool, thanks for the explanation, I'll give it a shot.
Yutian Wu
@cielowu

When you use environment.jersey().register() you are just registering object within dropwizard, but not in guice. So if this object requiring other guice beans, it would complain.

So what we did previously is we wait for the injector is created and then do a post initialization using environment.jersey().register() after the guice injector is created. It seems like after using .printLifecyclePhasesDetailed(), the injector has already been created, because it shows me

Guice started, app running

In this case, if the object requires some guice beans, will it still complain?
Using HK2 to manage jersey extension seems works, just want to understand more.

Yes, I'm thinking about moving to use extensions, but that would be MVP1.
One more followup question, if in my application, we've already have a bunch of environment.jersey().register() and environment.lifecycle().manage(). Is is okay for me, first only move the register pieces and keep the other one as it is?
Vyacheslav Rusakov
@xvik

So what we did previously is we wait for the injector is created and then do a post initialization using environment.jersey().register() after the guice injector is created.

Yes, you can do the same with guicey: injector is created before application.run method so you can reference injector there (to obtain guice-managed instance and register it manually in jersey). http://xvik.github.io/dropwizard-guicey/4.2.3/guide/injector/#access-injector

Vyacheslav Rusakov
@xvik

One more followup question, if in my application, we've already have a bunch of environment.jersey().register() and environment.lifecycle().manage(). Is is okay for me, first only move the register pieces and keep the other one as it is?

The main guicey idea was to hide this manual registrations, becuase with guice you always have to reference injector - obtain instance - and register it somewhere. Guicey approach: give me all your extension classes (with classpath scan it would be "i'll find everything myself") and I'll figure out how to register them in dropwizard.

So, with classpath scan enabled, all you need to do is to implement extension (e.g. create MyValueFactoryProfiver class) - everything else (registration) would be automatic.
Vyacheslav Rusakov
@xvik
Of course it would be ok to call environment.jersey().register() or
environment.lifecycle().manage()manually (in some cases it's event required). You gust need to understand what you do.

For example, time-to-time I receive questions like: I do environment.jersey().register(new MySomething()) and inside MySomething I use @Inject to inject other beans; why it doesn't work?

If you clearly understand what is injector and what instances are "guice managed" you can do whatever you want.

Yutian Wu
@cielowu

If you clearly understand what is injector and what instances are "guice managed" you can do whatever you want.

I see. This is very helpful! Thanks!

meryeme0506
@meryeme0506

Hello @xvik, actually I'm working on a project which selects data from multiple databases and inserts it on another one, so I have different DAO classes. I created my own @inTransaction annotation for each DB :
bootstrap.addBundle(GuiceBundle.builder() .enableAutoConfig(monitoringoverviewApplication.class.getPackage().getName()) .bundles(JdbiBundle.<MoConfiguration>forDatabase((conf, env) -> conf.getMO()).withTxAnnotations(MOTransaction.class)) .bundles(JdbiBundle.<MOConfiguration>forDatabase((conf, env) -> conf.getMS()).withTxAnnotations(MStatTransaction.class)) .build());

Then in each DAO classe, I declared the @JdbiRepository and the @InTransaction specific :
Select DAO class :
@JdbiRepository @MStTransaction @RegisterBeanMapper(User.class) public interface FirstDAO { @SqlQuery("SELECT * FROM users") List<User> selectUser(); }

Insert DAO class :
@JdbiRepository @MOTransaction public interface SecondDAO { @SqlBatch("INSERT INTO something values(...)") void insertUser(@BindBean("user") List<User> user); }

In my services class, I'm calling the two functions :

`@Inject FirstDAO firstDAO;
@Inject SecondDAO secondDAO;

public List<User> getData() {
return firstDAO.select();
}

public void insertData(){
secondDAO.insert(this.getDATA());
}

In my resources classs, I'a using my services :
`public class UserResource {

@Inject UserService userService;

public List<User> selectData(){
    return this.userService.getData();
}
public void insert() throws SQLException {  this.userService.insertData(); }

}`

I don't understand why I'm getting this error :
Error in custom provider, java.lang.IllegalStateException: Unit of work not started yet ! while locating ru.vyarus.guicey.jdbi3.unit.UnitManager ! while locating org.jdbi.v3.core.Handle

Vyacheslav Rusakov
@xvik
Hello @meryeme0506 ! Unfortunately, it can't work like this: integration supports only one database.
If you look guice JdbiModule registered by bundle, you can see that it can't bind different instances (no qualifiers used)
I'm not sure why it allow you to start application at all (need to verify this, should fail on binding conflict), but most likley it accepts the latest registered module which is not aware of other transaction annotations (registered in previous modules), so it can't recognize transaction scope.
Vyacheslav Rusakov
@xvik
You'll have to build your own integration module, probably using my integration as example.
Also, you could create a github issue for this feature. I plan to prepare new minor version soon, maybe I'll look this feature too. but can't promise (not sure if it could be done without breaking compatibility).
Shachar Levy
@levyshachar2

@xvik Hi!
we are having some issues with Guicey (dropwizard) and junit with running tests in parallel.
we have many test classes that are all running in parallel (around 14 test classes)
We use dropwizard logging util to write logs to Logz.io

we noticed that we have a random issue when tests are sharing an executer service between multiple threads causing the executer throw a RejectedExecutionException

Our theory of what is happening is as follows

One thread is starting a CT class and initialise a context with a executer service which he submit tasks to
while another thread is in his closing phase so he called the same executer shutdown method.

I wonder if you (or anyone else) encountered this issue.

some references:
getLoggerContext in LoggingUtil (they also reference a workaround Dropwizard did for a concurrency issue)

public DefaultLoggingFactory() { this(LoggingUtil.getLoggerContext(), System.err); } in DefaultLoggingFactory

and finally

LogzioSender.builder() .setDrainTimeoutSec(drainTimeoutSec) .setDebug(debug) .setReporter(LogzioStatusReporter(appender)) .setTasksExecutor(context.scheduledExecutorService) .setHttpsRequestConfiguration(httpsRequestConfiguration) .withDiskQueue() .setFsPercentThreshold(fileSystemFullPercentThreshold) .setQueueDir(bufferDirFile) .setGcPersistedQueueFilesIntervalSeconds(gcPersistedQueueFilesIntervalSeconds) .endDiskQueue() .build()

thank you for any help

my suspicious is that the .setTasksExecutor(context.scheduledExecutorService) retrieve the same scheduledExecutorService for multiple threads causing the issues
Vyacheslav Rusakov
@xvik

@levyshachar2 hi! I agrre that the problem caused by shared executor:
DropwizardTestSupport resets logging context after test

        if (configuration != null) {
            configuration.getLoggingFactory().reset();
        }

which stops LoggerContext and attached executor service
ch.qos.logback.core.ContextBase#stopExecutorService:

if (scheduledExecutorService != null) {
            ExecutorServiceUtil.shutdown(scheduledExecutorService);
            scheduledExecutorService = null;
        }

So one test could init LogzioSender just before executor shutdown and try to use it after.

The actual problem is here:

public DefaultLoggingFactory() {
        this(LoggingUtil.getLoggerContext(), System.err);
    }

which falls into final ILoggerFactory iLoggerFactory = LoggerFactory.getILoggerFactory();
One soulutino could be to use a custom logger factory, instantiating different logger contexts, but not sure if its possible (probably would ruin loggers).

Vyacheslav Rusakov
@xvik
The simplier option would be to apply custom executor in testst.
Shachar Levy
@levyshachar2
we will try it @xvik thank you for the help!