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 missing @Named annotations for CoinFormatter injection #3658

Merged
merged 1 commit into from Nov 22, 2019

Conversation

bodymindarts
Copy link

@bodymindarts bodymindarts commented Nov 21, 2019

I missed a few places where @Named(BTC_FORMATTER_KEY) annotation should be added in my recent PR #3634.

@@ -139,7 +142,7 @@
public DisputeView(DisputeManager<? extends DisputeList<? extends DisputeList>> disputeManager,
KeyRing keyRing,
TradeManager tradeManager,
CoinFormatter formatter,
@Named(FormattingUtils.BTC_FORMATTER_KEY) CoinFormatter formatter,
Copy link
Contributor

Choose a reason for hiding this comment

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

I think in this case it's unnecessary, because this constructor is not annotated with @Inject

Copy link
Author

Choose a reason for hiding this comment

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

That is what I thought too, which is why I left these out originally. But it turns out @inject is not infact mandatory and the program crashes on these views without this annotation. Thanks to @stejbac for discovering this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Are you sure that app crash when you ommit @Named annotation on this particular file (DisputeView) ? It's an abstract class and it does not "participate" in dependency injection.

Copy link
Contributor

Choose a reason for hiding this comment

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

On second thought, I might have been wrong about @Inject not being mandatory for Guice, since looking closer the modified Dispute* classes all have subclasses with @Inject-annotated constructors - probably only TransactionsView and TakeOfferView actually needed fixing. (I'm pretty sure it isn't mandatory by default for Spring, but perhaps Guice is stricter.)

Also, there are (probably leftover) @FxmlView annotations on the 3 Dispute* classes which mislead me to think that they were concrete components - perhaps those annotations can be removed?

Copy link
Member

Choose a reason for hiding this comment

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

I think here it is not necessary as mentioned by @lusarz. At least it didn't crash for me here.

Copy link
Member

Choose a reason for hiding this comment

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

But it turns out @inject is not infact mandatory and the program crashes on these views without this annotation.

Did it crash for you while testing?

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that probably only these two views needs to be annotated.

Yeah, I suppose @FxmlView on abstract views are leftovers, and it would be nice to remove them.

Copy link
Contributor

Choose a reason for hiding this comment

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

Inject annotation is needed for the concrete classes but not for the base classes (should not be used there). It probably crashed due some nullpointers caused if the annotation is missing but with view classed you don't get proper error logs.

Copy link
Contributor

Choose a reason for hiding this comment

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

Inject annotation is needed for the concrete classes but not for the base classes (should not be used there). It probably crashed due some nullpointers caused if the annotation is missing but with view classed you don't get proper error logs.

Copy link
Member

@ripcurlx ripcurlx left a comment

Choose a reason for hiding this comment

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

NACK - please see my comments

@@ -139,7 +142,7 @@
public DisputeView(DisputeManager<? extends DisputeList<? extends DisputeList>> disputeManager,
KeyRing keyRing,
TradeManager tradeManager,
CoinFormatter formatter,
@Named(FormattingUtils.BTC_FORMATTER_KEY) CoinFormatter formatter,
Copy link
Member

Choose a reason for hiding this comment

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

I think here it is not necessary as mentioned by @lusarz. At least it didn't crash for me here.

@@ -48,7 +49,7 @@
public DisputeAgentView(DisputeManager<? extends DisputeList<? extends DisputeList>> disputeManager,
KeyRing keyRing,
TradeManager tradeManager,
CoinFormatter formatter,
@Named(FormattingUtils.BTC_FORMATTER_KEY) CoinFormatter formatter,
Copy link
Member

Choose a reason for hiding this comment

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

I think here it is not necessary.

@FxmlView
public abstract class DisputeClientView extends DisputeView {
public DisputeClientView(DisputeManager<? extends DisputeList<? extends DisputeList>> DisputeManager,
KeyRing keyRing,
TradeManager tradeManager,
CoinFormatter formatter,
@Named(FormattingUtils.BTC_FORMATTER_KEY) CoinFormatter formatter,
Copy link
Member

Choose a reason for hiding this comment

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

I think here it is not necessary.

@ripcurlx
Copy link
Member

One more question: Is there a reason why we use for these injects the Named annotation from javax.inject.Named and on other places com.google.inject.name.Named?

@ripcurlx
Copy link
Member

One more question: Is there a reason why we use for these injects the Named annotation from javax.inject.Named and on other places com.google.inject.name.Named?

It seems both work the same as described in https://github.com/google/guice/wiki/JSR330

@lusarz
Copy link
Contributor

lusarz commented Nov 22, 2019

@ripcurlx I think there is no reason - I suppose everyone use autoimport feature in Intellij and no one cares which one is imported :)

@ripcurlx
Copy link
Member

@bodymindarts It looks like you still left the unused imports in and a small typo in the commit message @nAmed 😉

@bodymindarts
Copy link
Author

I have force pushed removing the annotation from the abstract classes.

I have consistently used

import javax.inject.Named;

To mirror the usage of

import javax.inject.Inject;

These are library agnostic and should still be effective if a different DI framework is used. I didn't notice that another import was used elsewhere.

@ripcurlx
Copy link
Member

I have force pushed removing the annotation from the abstract classes.

I have consistently used

import javax.inject.Named;

To mirror the usage of

import javax.inject.Inject;

These are library agnostic and should still be effective if a different DI framework is used. I didn't notice that another import was used elsewhere.

I guess we should get rid of the Guice bound annotations in favor of the generic one at some point.

@bodymindarts
Copy link
Author

Removed the unused imports

@bodymindarts
Copy link
Author

And commit message is no typo. If you look at the message locally its fine. It seems to be a display bug in github.

@ripcurlx
Copy link
Member

It seems to be a display bug in github.

Yes it looks like GitHub tries to be clever finding a user with that name 🤦‍♂

Copy link
Member

@ripcurlx ripcurlx left a comment

Choose a reason for hiding this comment

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

ACK

@ripcurlx ripcurlx merged commit 90bf138 into bisq-network:master Nov 22, 2019
@lusarz
Copy link
Contributor

lusarz commented Nov 22, 2019

@bodymindarts Would you prepare pull request that removes unnecessary @FxmlView annotations from abstract views ? You should be able to find them using @FxmlView[\s\n]*public abstract regex.

@bodymindarts
Copy link
Author

@lusarz #3661

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.

None yet

5 participants