Also, it feels weird to add an interface which is basically the same as the existing Application class. This doesn't bring any benefit for the user from an API perspective. It looks like it just addresses an implementation concern.
Yeah, fair enough. Really, I'm thinking that Application should have been defined as an interface in the first place, which would make it consistent with all of the other @Context injectible types. Clearly, it's too late to turn Application into an interface, so I was just thinking of a possible solution.
Yeah, maybe an interface would have been a better option. But maybe there are good arguments for a class that I'm not aware of?
I sincerely doubt that, at least at the beginning, there was any intent to support more than one Application instance. There are a number of areas which would need to be clarified if multiple instances were supported (an example would be automatic discovery of resources/providers). I can see how this use case is becoming more appealing, but I don’t think it is a portable feature at the moment.
The premise of this request is the existence of more than one Application instance. I think this premise should be discussed first to make sure everyone is on the same page. I also agree with the CDI comments made by others.
— Santiago
|
