Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 21 15:23
    xvik closed #178
  • Oct 21 15:23
    xvik commented #178
  • Oct 21 15:08

    xvik on gh-pages

    Publish 5.4.0 documentation (compare)

  • Oct 21 15:08

    xvik on master

    fix doc typos (compare)

  • Oct 21 15:06

    xvik on gh-pages

    Publish 5.4.0 documentation (compare)

  • Oct 21 15:06

    xvik on master

    fix doc typos (compare)

  • Oct 21 15:01

    xvik on gh-pages

    Publish 5.4.0 documentation (compare)

  • Oct 21 10:42

    xvik on master

    [Gradle Release Plugin] - new v… (compare)

  • Oct 21 10:41

    xvik on 5.4.0

    (compare)

  • Oct 21 10:41

    xvik on master

    [Gradle Release Plugin] - pre t… (compare)

  • Oct 21 10:33

    xvik on master

    update docs (compare)

  • Oct 21 09:10

    xvik on master

    update docs for new version (compare)

  • Oct 20 20:40

    xvik on master

    update docs for new version (compare)

  • Oct 16 10:04

    xvik on master

    unify shared state access metho… (compare)

  • Oct 15 11:44

    xvik on master

    fix typos (compare)

  • Oct 15 11:31

    xvik on master

    add shortcuts to SharedConfigur… (compare)

  • Oct 13 08:30

    dependabot[bot] on gradle

    (compare)

  • Oct 13 08:29

    xvik on master

    Bump spotbugs-annotations from … Merge pull request #185 from xv… (compare)

  • Oct 13 08:29
    xvik closed #185
  • Oct 12 23:39
    codecov-commenter commented #185
Vyacheslav Rusakov
@xvik
John LaBarge
@johnlabarge
thanks for your help!
Vyacheslav Rusakov
@xvik
you are welcome!
John LaBarge
@johnlabarge
Anyone have an example of using c3p0 connection pool?
Vyacheslav Rusakov
@xvik
It's hard because dropwizard's DataSourceFactory is tightly integrated with tomcat pool. You can see maintained hikaricp bundle (https://github.com/mtakaki/dropwizard-hikaricp) which have to replace dropwizard db and hibernate modules in order to change used pool. If you really need c3p0 it could be an implementation example
John LaBarge
@johnlabarge
yeah really just for jdbi3 though not using hibernate
perhaps it's worth starting a new OSS project
Vyacheslav Rusakov
@xvik
I would suggest to go with the default. In most cases changing of connection pool have no sense (most likely you'll not have such load to gain anything from it)
John LaBarge
@johnlabarge
is there an example project somewhere I can look at that has the full repository/service/controller bits?
John LaBarge
@johnlabarge
yep! thanks!
John LaBarge
@johnlabarge
Are there any testing equivalents to the @Sql annotation which can load sql into a test db pre running a test?
(@Sql annotation comes with spring)
Vyacheslav Rusakov
@xvik
no
its not hard to do something like that, but not done yet
John LaBarge
@johnlabarge
so do folks not test with real data?
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.