In an OSGi environment ClassLoader.getResource() typically returns a bundle-entry/bundle-resource URL (using a corresponding protocol).
The OSGi specification chapter 3.9.6 - "Resource Loading" specifies only a few aspects how those URLs have to be constructed (for example the path) and leafs everything else to the implementation.
Is it possible, and if yes how, to obtain the Bundle to which a bundle-entry URL is pointing, using only implementation-independent OSGi API?
For example for a jar-URL one can open a connection, cast it to JarURLConnection and use JarURLConnection.getJarFile() to obtain the JarFile.
Is it possible, and if yes how, to obtain the Bundle to which a bundle-entry URL is pointing, using only implementation-independent OSGi API?
Not in a specified way. The OSGi specification deliberately leaves URL details opaque to allow implementation freedom to the framework.
For specific framework implementations, you may be able to discern the bundle id in the URL. But this is subject to change at the desires of the framework implementation.
Related
We are running set of micro-services and each are exposing open-api spec to url like the following.
https://{domain}/v1/membership/v3/api-docs
https://{domain}/v1/storage/v3/api-docs
https://{domain}/v1/order/v3/api-docs
The url opens open-api json (not UI).
Does anyone know of a tool where I can combine these and be able serve all the apis via url like https://{domain}/v1/apis with UI?
I looked Google and all I saw required me to create a single json file with all apis instead of dynamically serving these.
You can use the property urls:
springdoc.swagger-ui.urls[0].name = first
springdoc.swagger-ui.urls[0].url = /firstAPI.yaml
springdoc.swagger-ui.urls[1].name = second
springdoc.swagger-ui.urls[1].url = /secondAPI.yaml
You can find this property in the documentation. There is also a nice FAQ for this question:
The properties springdoc.swagger-ui.urls.*, are suitable to configure external (/v3/api-docs url). For example if you want to agreagte all the endpoints of other services, inside one single application. Don’t forget that CORS needs to be enabled as well.
Recently I came across a lot of code from analytics plugins where they specify the URL as //fonts.googleapis.com or //www.google.com.
Basically it starts with two forward slashes and then the domain or subdomain. These links work fine in browsers. I have read the following documents, but I am still not sure if above can be called valid URLs (basically should these be reported as broken URLs or not).
https://developer.mozilla.org/en-US/docs/Web/API/URL and
https://url.spec.whatwg.org/
Is there a standard specification that I can refer to?
They're both valid scheme-relative-URL strings, although they need to be in the context of a Base URL to be meaningful. When used within a web page, the web page will provide the Base URL context.
Although there are other, earlier standards for URLs, the whatwg document represents the most up-to-date, web compatible definition.
from the documentation it seems that I have to edit the server.xml file to set: proxyName, proxyPort, scheme.
Not only doesn't it explain what those settings are for, but I also can't find any motivation behind it. Doesn't the usual apache reverse proxy configuration just suffices?
The specific parameters you refer to in server.xml file are Tomcat <Connector> attributes.
The practical impact is that Jira or third-party apps will sometimes use these attributes to construct fully-qualified URLs to refer back to Jira, and which also sometimes get passed on to the client browser. The attributes configured here should match the base URL configured in the main Jira system configuration.
For example, Jira may send redirects to the user's browser if it detects that you are accessing Jira from something other than the canonical URL as configured here. It will also occasionally construct fully-qualified URLs (rather than relative URLs) in certain parts of the application.
You also generally need to have correct values set for these attributes (as well as the base URL) if you want Application Links and the UPM (app manager) to work correctly.
For local testing or development purposes, it is generally acceptable to remove these attributes entirely (it will stop auto-redirection from happening), so long as you're always accessing Jira from the base URL, and knowing that you may have issues with AppLinks or the UPM. Removing them is certainly better than having an incorrectly-configured proxyName, which would otherwise generate redirects to the wrong place.
I sometimes see people refer to file system paths (POSIX/Windows) as both URIs and URLs. I'm no file system buff, but I have yet to find a file system path that conflicts with my understanding of the URL format. That is, of course, given that it includes the scheme name (e.g. file://localhost/path/to/file.txt).
File system paths are most definitely URIs - I mean, what's not - so everyone referring to file system paths as URIs is inside the safe zone. But is it safe to call them URLs?
If the URL was defined by a single (non-obsolete) RFC, rather than being comprised of half a dozen specialized ones, I wouldn't have to ask this question.
file is a registered URI scheme (for "Host-specific file names").
It links to RFC 1738, which is called "Uniform Resource Locators (URL)", in which file is specified:
A file URL takes the form:
file://<host>/<path>
So yes, file URIs are URLs.
However, the subdivision from URIs into URLs, URNs and "Other" (like data) is not that useful anyway. FWIW, the WHATWG URL spec tries to standardize on the term "URL" for all kind of URIs (even those that aren't URLs today, following the RFC). The W3C Note "URIs, URLs, and URNs: Clarifications and Recommendations 1.0" tries to summarize the confusion about the terms:
The body of documents (RFCs, etc) covering URI architecture, syntax, registration, etc., spans both the classical and contemporary periods. People who are well-versed in URI matters tend to use "URL" and "URI" in ways that seem to be interchangable. Among these experts, this isn't a problem. But among the Internet community at large, it is. People are not convinced that URI and URL mean the same thing, in documents where they (apparently) do. […]
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What's the difference between a URI and a URL?
Is there any difference? I'm talking about URI for identifying, but URL for locating. Aren't both the same thing?
They can look the same, but they're not the same thing. A URL identifies something that can be transferred over some protocol (often http). A URI, can be used to identify a namespace (for example) but there might not be any content at the address.
Where is the difference between locating a ressource and identifying a ressource?
Knowing who I am doesn't tell you anything about where I am.
A URI identifies a resource either by location, or a name, or both. More often than not, most of us use URIs that defines a location to a resource.
A URL is a specialization of URI that defines the network location of a specific resource.
Generally, if the URL describes both the location and name of a resource, the term to use is URI.
This article might help:
URI vs. URL
Excerpt:
"...a URL is a type of URI that
identifies a resource via a
representation of its primary access
mechanism (e.g., its network
"location"), rather than by some other
attributes it may have. Thus as we
noted, "http:" is a URI scheme. An
http URI is a URL. The phrase "URL
scheme" is now used infrequently,
usually to refer to some subclass of
URI schemes..."
An identifier is a unique name for something, so we can be sure that we talk about the same thing. For example the Atom namespace is 'http://www.w3.org/2005/Atom'. This is a URI. This doesnt mean that you can put this URI in a browser and have a document there (well, in case of Atom, yes, you have a document, but it's a simple presentation of Atom for convenience, it's not the Atom namespace itself).
A URL is the location of a document. This is what you can put in your browser. It is confusing that both use the same format (http://...) but that is mostly annecdotic ...
A URL is a URI which is not a URN. (see)