In Spring Framework, for the #PropertySource, according with its API or javadoc it has the name attribute
Indicate the name of this property source.
If omitted, the factory() will generate a name based on the underlying resource
(in the case of DefaultPropertySourceFactory:
derived from the resource description through a
corresponding name-less ResourcePropertySource constructor).
Ok, is clear that is possible define the name such as:
#PropertySource(name="infra",
value={"classpath:/com/.../infrastructure.properties"})
But How and where use that name? What is its purpose?
Related
I am looking a solution to retrieve full endpoint URLs within Quarkus application to use it in tests to avoid hard-coding the paths.
The official guide suggests using the #TestHTTPEndpoint and #TestHTTPResource annotations.
If I annotate my test class with #TestHTTPEndpoint(MyResource::class), then all calls via RestAssured without specifying the path work just fine. The problem is, when I try to retrieve the endpoint URL like this (let's say, I need to call multiple endpoints in one test):
#TestHTTPEndpoint(MyResource::class)
#TestHTTPResource
lateinit var myResourceUrl: URL
it kind of works, but the injected URL does not include the quarkus.http.root-path value.
Instead of http://localhost:8081/root-path/my-resource I get just http://localhost:8081/my-resource.
Is there a way to retrieve a full endpoint path that includes the quarkus.http.root-path value?
Introduction
Let's consider the following versions as the current versions.
Quarkus: 2.11.2.Final.
Root cause analysis
The io.quarkus.test.common.http.TestHTTPResourceManager (TestHTTPResourceManager for short) class performs the value injection into the fields annotated with the io.quarkus.test.common.http.TestHTTPEndpoint (TestHTTPEndpoint for short) annotation:
The TestHTTPResourceManager class retrieves an instance of the org.eclipse.microprofile.config.Config (Config for short) from the org.eclipse.microprofile.config.ConfigProvider (ConfigProvider for short) class and uses the test.url configuration property value retrieved from the Config instance (the Config.getValue(…) method call) as the base URL.
The retrieved test.url configuration property value seems to correspond to the test.url system property value that was provided by the io.quarkus.test.common.http.TestHTTPConfigSourceProvider (TestHTTPConfigSourceProvider for short) class.
Possible root cause
For some reason the TestHTTPConfigSourceProvider class does not take into account the quarkus.http.root-path property value, when providing the test.url system property value, which seems to be used as the base URL: quarkus/TestHTTPConfigSourceProvider.java at 2.11.2.Final · quarkusio/quarkus:
static final String TEST_URL_VALUE = "http://${quarkus.http.host:localhost}:${quarkus.http.test-port:8081}${quarkus.servlet.context-path:}";
static final String TEST_URL_KEY = "test.url";
Therefore, it looks like a Quarkus issue: a defect (a bug) or a lack of a feature (or a lack of the feature implementation).
Therefore, it is worth reporting it as a Quarkus issue.
OK, so it seems to be a bug in Quarkus and will be fixed soon.
#TestHTTPResource annotation injects endpoint URL without the quarkus.http.root-path segment · Issue #27416 · quarkusio/quarkus · GitHub.
As a workaround, one could set the quarkus.servlet.context-path property in the test/resources/application.properties file like this:
quarkus.servlet.context-path=${quarkus.http.root-path}
I've an entity with property name qYear. I tried creating a findByIdAndQYear method in repository but that did not work. I ran into IllegalArgumentException: Unable to locate Attribute with the the given name [QYear] on this ManagedType).
However findByIdAndqYear works. Any idea how single letter abbreviations like this are expanded please?
Spring Data (not just the JPA module) base this on the Java Bean Specification.
In order to avoid misinterpretation of the specification this is actually implemented using [java.beans.Introspector][1].
See also https://jira.spring.io/browse/DATACMNS-1589
All over the Internet I find code examples of JAX-WS beans being defined in this fashion:
<jaxws:client name="{http://cxf.apache.org/}MyService" createdFromAPI="true">
What is the meaning of the curly braces here exactly?
You might need to specify individual examples of where you've seen it, but from what you've shared here, this seems to be erroneous use of that naming convention.
See, the schema for the Spring-CXF XML configuration document supports two types of "name" attributes:
name: use this to name just the bean within the spring context - treat it no differently as you would adding id to a spring bean. No need for a namespace or prefixing of any kind
serviceName: this name should come from the WSDL as part of the name attribute from the definitions root element. It's this one that uses the QName format - what you have here as {http://cxf.apache.org/}MyService which the CXF API will try to match with what's in the WSDL of the SOAP service you're consuming.
TL;DR: that naming convention with the URL prefix doesn't belong on the name attribute but on the serviceName attribute and its value ought to come from the WSDL file.
I need to create bean with id or name with class name with it's package.
e.g
<bean class="org.chameleon.commons.context.resolver.impl.UserContextResolver" scope="prototype"
/>
and I want it to be like this
org.chameleon.commons.context.resolver.impl.UserContextResolver
but it shows me like this.
org.chameleon.commons.context.resolver.impl.UserContextResolver#if
What to do to get bean as my required name.
You should add an "id" or a "name" attribute to the bean definition, e.g.
<bean id="org.chameleon.commons.context.resolver.impl.UserContextResolver" class="org.chameleon.commons.context.resolver.impl.UserContextResolver" scope="prototype" />
As stated in Spring reference doc 5.3.1 Naming beans1
In XML-based configuration metadata, you use the id and/or name attributes to specify the bean identifier(s). The id attribute allows you to specify exactly one id. Conventionally these names are alphanumeric (myBean, fooService, etc.), but may contain special characters as well. If you want to introduce other aliases to the bean, you can also specify them in the name attribute, separated by a comma (,), semicolon (;), or white space. As a historical note, in versions prior to Spring 3.1, the id attribute was defined as an xsd:ID type, which constrained possible characters. As of 3.1, it is defined as an xsd:string type. Note that bean id uniqueness is still enforced by the container, though no longer by XML parsers.
You are not required to supply a name or id for a bean. If no name or id is supplied explicitly, the container generates a unique name for that bean. However, if you want to refer to that bean by name, through the use of the ref element or Service Locator style lookup, you must provide a name.
In a spring configuration, what is the difference between using name vs id? I'm aware that XML restricts the "id" attribute to be unique in a document and limits the characters for using in the id. But otherwise when declaring a bean, what is the difference between using the "name" attribute vs the "id" attribute?
Essentially, this is really just a XML matter. But you can also use the name attribute to specify aliases for a bean using characters which would be illegal in an id, I think.
In general, you should try to use id instead of name when you can. That way, the parser can catch duplicates for you.