Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DI, remove static code and many code duplications, add DI usage e… #71

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

yotamoron
Copy link

…xample

*/
public class Main {
public static void main(String[] args) throws IOException, MandrillApiError {
final ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:applicationContext-LutungMandrill-all.xml");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kind of disagree adding a Main class to the repo to show how to "wire" it all up together. I think if you want to have an example, you can better have this as a part of the README.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, makes sense. I'll move it.

@billoneil
Copy link
Collaborator

We are not going to make this library depend on Guava, Spring core and Spring context. Not everyone uses DI and those who do not everyone uses Spring. What exactly are you trying to solve here? The only issue I see this resolving is the ability to pass in the mandrill root url which was requested once before. If you want the ability to proxy to some other server we can expose a constructor where you pass in a HttpClient which can be configured to use a proxy. Then you can use your own DI framework to construct MandrillApis that proxy to some test server or the prod server.

@lc-nyovchev
Copy link
Contributor

Maybe that's correct, it shouldn't actually depend on Spring core/Context it was depending for it for the Main class to run I guess, but the abundance of static methods make it hard for people to change the internals so at least that I see as a good thing. The guava is more or less meh for me.

@yotamoron
Copy link
Author

I fixed most of the stuff and removed the spring dep (it was a bad idea - I agree).
Current code is much more testable, can be used with a DI framework properly, and - most important for us - the user can now inject their own http implementation (most big projects will have their own means of sending and receiving http requests).

@lc-nyovchev
Copy link
Contributor

I'd also remove the lutung-mandrill-all.xml in the resources folder. I think everybody knows how to wire their stuff, the important thing is removing the statics.

@Override
public void accept(final QueryExecutor queryExecutor) {
addContent(templateContent, queryExecutor);
addContent(mergeVars, queryExecutor);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addContent(mergeVars, queryExecutor) will overwrite "template_contents" set by executing addContent(templateContent, queryExecutor)

@@ -55,11 +52,9 @@ public MandrillExportJobInfo info(final String id)
*/
public MandrillExportJobInfo list()
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should return array

@@ -33,12 +32,9 @@ public MandrillInboundApi(final String key) {
*/
MandrillInboundDomain[] domains()
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all the calls are package-private, perhaps should be public?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants