René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Spring RequestScope breaks SpringComponentProvider","articleBody":"Utilizing the new(ish) `@RequestScope` annotation causes integration issues as Spring is registering multiple bean names when this annotation is present. You now end up with `originalBeanName` and `scopedTarget.originalBeanName` as bean name entries in the context for the affected class.\r\n\r\nThe specific piece that breaks is: \r\n\r\n    if (beanNames == null || beanNames.length != 1) {\r\n        LOGGER.severe(LocalizationMessages.NONE_OR_MULTIPLE_BEANS_AVAILABLE(component));\r\n        return false;\r\n    }\r\n\r\nThe application still actually works in my parituclar case as Jersey was able to use the constructor and populate the other requested beans (from spring). This is dangerous though, as it will  have hidden side affects as the resources is not actually being provided by Spring when we expect to be and things like `@Transactional` or other Spring specific things will fail. This seems like a red flag as well, should something more severe be done in these cases? Fail faster?\r\n\r\n**Note:** There is a valid workaround, just use the old `@Scope` annotation. That does not register another bean name\r\n","author":{"url":"https://github.com/nick-pww","@type":"Person","name":"nick-pww"},"datePublished":"2018-03-21T19:49:03.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/3789/jersey/issues/3789"}