Self intro and Guice 4.0 Upgrade

[Yun Zhi Lin]

Hi GWizards,

I first heard about Gwizard whilst helping out with dropwizard-guice Jersey2 upgrade. Recently I've taken a closer look and am quite impressed: 

• Everything is a Guice module. No more DW Bundles.
• Everything is injected, no deep inheritance layers, Builders nor FactoryFactorys. DB logic can be tested easily without boilerplate codes to create SessionFactory
• Simplicity, I can understand what's going on by tracing through the code just once and not get lost.
• RestEasy might actually be good, considering Jersey2 seems less performant than expected: https://github.com/dropwizard/dropwizard/issues/1010

I have started to use this project and would like to make some contributions. A few things I had in mind are, in order to priority:

1. Upgrade dependencies, mainly Guice4 and Hibernate. Raised PR#9
   
2. Add techempower tests for gwizard - started 
   
3. Add mongodb support using mongojack - quite faimilar with the steps involved.
4. Added reflection based AutoConfig similar to dropwizard-guice, with similar test suite.
5. Add support for swapping out the WebServer, replacing Jetty with another implementation such as Undertow

I noticed most of the tests are actually example code and not junit tests. I wrote a couple as part of PR#9 and plan to add more tests as I go. Let me know if that fits with how things are done around here?

Cheers,

Yunspace

[Jeff Schnitzer]

Hi, great to have you aboard! PR#9 merged.

All of this sounds great. I'm somewhat nervous about leaving some opinions unexpressed (like jetty vs undertow) but if the "default" configuration just works then I don't see harm in it. It also brings up a question of whether this should be one large repository with a zillion components (including mongo, for example) or should be split out into separate builds... but that would certainly complicate things. For now let's roll along; we can always split later.

Re testing: Yeah, I haven't really come up with a good story around how to test the gwizard components themselves. Would love some suggestions. Testing of a gwizard-using app is quite elegant (IMHO) and the gwizard code itself is very simple so I haven't been concerned, but it would be good to get this locked down sooner rather than later.

FWIW, I generally prefer TestNG and Hamcrest (it is reminiscent of rspec, which I like quite a bit). I hope you don't mind if I convert the tests at some point.

Also one minor nit: Hard tabs instead of spaces please :)

Cheers,

Jeff

--
You received this message because you are subscribed to the Google Groups "GWizard Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwizard+u...@googlegroups.com.
To post to this group, send email to gwi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gwizard/43618fee-0a32-45cc-99a1-5d62e6f125f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yun Zhi Lin]

Awesome thanks. I agree for now just keep things in the same project and split later. Perhaps when there are say, multiple modules that does the same thing (ie 2 web modules), then the default should be kept in gwizard and the alternative can sit outside. At the moment the web module has jetty hard baked inside, so it's more of a "iron fisted" opinion :) I was thinking maybe there could be a "WebServer" interface, to which there would be a default Jetty implementation and free to be swapped out.

I think unit tests are easier to run via maven or IDE. For example, after updating a whole bunch of dependencies, it's much easier to just run `mvn test` rather than running each self-contained main() method. A well written test can also serve as example code.

Sure, will stick to TestNG and Hamcrest, and also set my IDE to use hard tabs :P

[Jeff Schnitzer]

On Sat, Aug 8, 2015 at 7:31 AM, Yun Zhi Lin <yun.z...@gmail.com> wrote:

Awesome thanks. I agree for now just keep things in the same project and split later. Perhaps when there are say, multiple modules that does the same thing (ie 2 web modules), then the default should be kept in gwizard and the alternative can sit outside. At the moment the web module has jetty hard baked inside, so it's more of a "iron fisted" opinion :) I was thinking maybe there could be a "WebServer" interface, to which there would be a default Jetty implementation and free to be swapped out.

Sure, but I want to be clear - this is because you specifically want to use Undertow, right? I would prefer that features only be implemented to meet specific needs. If you have that need - great - otherwise let's wait until it comes up, that way we'll know that we're doing it right. I'm a stickler for the YAGNI principle.

 

I think unit tests are easier to run via maven or IDE. For example, after updating a whole bunch of dependencies, it's much easier to just run `mvn test` rather than running each self-contained main() method. A well written test can also serve as example code.

Believe me, I'm in total agreement :)

The existing "tests" are just examples directly linked to by the documentation. They're in the 'tests' directory because there wasn't an obvious better place to put them. The truth is, other than the tests in gwizard-example, there are very few real tests for gwizard itself (I think you just doubled their number). This is not a happy state of affairs, and I'm somewhat embarrassed by that. The only reason I find it vaguely tolerable is that this project currently has very little code in it. Of course that is slowly changing.

I'll make a TODO to move the examples to src/example, and tell maven to use "example" as a test directory so they compile. That will probably clear up the confusion, and encourage everyone (read: me) to write more tests.

Jeff

[Jeff Schnitzer]

On Sat, Aug 8, 2015 at 8:17 AM, Jeff Schnitzer <je...@infohazard.org> wrote:

I'll make a TODO to move the examples to src/example, and tell maven to use "example" as a test directory so they compile. That will probably clear up the confusion, and encourage everyone (read: me) to write more tests.

Sigh. Maven does not allow multiple testSourceDirectory entries. Is there are better Maven solution that:

 * Keeps the example code compiled (and refactored) along with the base library module code in the IDE

 * Keeps the example code out of the final build

 * Keeps the example code under the same src directory as the relevant module (ideally src/example)

 * Does not require creating additional maven submodules (we have plenty already)

?

Dumping the examples in the test dir accomplishes this, but is not ideal.

Thanks,

Jeff

[Yun Zhi Lin]

It's probably best not to fight with maven. If all the "real tests" are inside gwizard-example, maybe it would be reasonable to move gwizard-example into a submodule under gwizard (similar to dropwizard/dropwizard-example). That way when all unit tests are run, the "real tests" inside gwizard-example will be picked up.

--
You received this message because you are subscribed to a topic in the Google Groups "GWizard Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gwizard/62qJHM3zx1Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gwizard+u...@googlegroups.com.

To post to this group, send email to gwi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gwizard/CADK-0ui8KDbSZXeVdsu0ap12%3D9QntOdpvOQUN3CuOaLUwf6n3Q%40mail.gmail.com.

[Yun Zhi Lin]

Also even if the test directory can be set to "src/example" inside every existing module, just compiling all of the examples isn't enough for testing. Maybe add a Test() method that calls the Main() method in each example code? That way all Main() methods can be called via a test runner, and proper unit tests can be added in the future as new features are being worked on.

By the way, I've been putting together a mongodb-module using mongojack. It integrates well with Jackson BSON and I'd assume performs better compared to Morphia.

The code will be a cut lighter version (thanks to Guice) of what I put in here. I'm planning to replace: 

final JacksonDBCollection<Student, Integer> students=
 JacksonDBCollection.wrap(db.getCollection("Students"), Fortune.class, Integer.class, mongoJackMapper);

with:

@DBCollection("Students") final JacksonDBCollection<Student, Integer> students

to inject in the different JacksonDBCollections wrappers. Guice-AOP seems like the best option. Static injection and assisted inject factory aren't very suitable for this scenario. Any thoughts?

On Sunday, August 9, 2015 at 8:55:14 PM UTC+10, Yun Zhi Lin wrote:

It's probably best not to fight with maven. If all the "real tests" are inside gwizard-example, maybe it would be reasonable to move gwizard-example into a submodule under gwizard (similar to dropwizard/dropwizard-example). That way when all unit tests are run, the "real tests" inside gwizard-example will be picked up.

I'll make a TODO to move the examples to src/example, and tell maven to use "example" as a test directory so they compile. That will probably clear up the confusion, and encourage everyone (read: me) to write more tests.

[Jeff Schnitzer]

The tests for gwizard-example are not really designed to test gwizard itself, and don't really belong in gwizard. The examples in gwizard/src/test are designed to be part of the documentation and don't really lend themselves to automation... plus, changing them to be test-friendly would make them less useful as "pure examples".

So yeah, the current state of affairs is that there are (almost) no tests. This will be corrected, although I'm in crunch mode on another project right now - probably for the next couple months. All PRs welcome, of course :)

WRT mongojack: Would this make more sense to put under https://github.com/gwizard/gwizard-mongojack, instead of as part of the main repository? I can just create the repo for you. It feels to me like there isn't an obvious strong consensus in the java/mongo community as to which API is "the winner" - for example, I've used Jongo and Morphia in past projects, both with positive results (they cover different use cases). At some point the gwizard repo needs to split up a little... maybe this is the time to start doing it?

Another possibility is to have a gwizard-mongo repo that has modules for gwizard-mongojack, gwizard-jongo, etc. But I suspect the single repository will be simpler and easier, avoid multimodule maven.

Jeff

--

You received this message because you are subscribed to the Google Groups "GWizard Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gwizard+u...@googlegroups.com.

To post to this group, send email to gwi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gwizard/e46ae0dd-25d3-4de9-be7a-0c8ca991a082%40googlegroups.com.

[Yun Zhi Lin]

Ok got it, I'll raise PR when I come across any complicated features that needs testing.

Yep if you create a gwizard-mongojack I'll contribute to that. The different APIs are all quite similar actually, get a DBCollection from the vanillar Mongo Java driver and do something with it. I think for now a single repo will be suffice, can always add more/refactor later on.