Documentation formatting fix

Removed unnecessary quotation marks that caused improper rendering
of in-line code.

Closes gh-1180

src/asciidoc/core-resources.adoc

@@ -494,8 +494,8 @@ When the path location contains an Ant-style pattern, for example:
 
 ... the resolver follows a more complex but defined procedure to try to resolve the
 wildcard. It produces a Resource for the path up to the last non-wildcard segment and
-obtains a URL from it. If this URL is not a "jar:" URL or container-specific variant
-(e.g. " `zip:`" in WebLogic, " `wsjar`" in WebSphere, etc.), then a `java.io.File` is
+obtains a URL from it. If this URL is not a `jar:` URL or container-specific variant
+(e.g. `zip:` in WebLogic, `wsjar` in WebSphere, etc.), then a `java.io.File` is
 obtained from it and used to resolve the wildcard by traversing the filesystem. In the
 case of a jar URL, the resolver either gets a `java.net.JarURLConnection` from it or
 manually parses the jar URL and then traverses the contents of the jar file to resolve
@@ -555,9 +555,9 @@ inappropriate result is returned, check the application server documentation for
 settings that might affect the classloader behavior.
 ====
 
-The " `classpath*:`" prefix can also be combined with a `PathMatcher` pattern in the
-rest of the location path, for example " `classpath*:META-INF/*-beans.xml`". In this
-case, the resolution strategy is fairly simple: a ClassLoader.getResources() call is
+The `classpath*:` prefix can also be combined with a `PathMatcher` pattern in the
+rest of the location path, for example `classpath*:META-INF/*-beans.xml`. In this
+case, the resolution strategy is fairly simple: a `ClassLoader.getResources()` call is
 used on the last non-wildcard path segment to get all the matching resources in the
 class loader hierarchy, and then off each resource the same PathMatcher resolution
 strategy described above is used for the wildcard subpath.
@@ -567,13 +567,13 @@ strategy described above is used for the wildcard subpath.
 ==== Other notes relating to wildcards
 Please note that `classpath*:` when combined with Ant-style patterns will only work
 reliably with at least one root directory before the pattern starts, unless the actual
-target files reside in the file system. This means that a pattern like "
-`classpath*:*.xml`" will not retrieve files from the root of jar files but rather only
+target files reside in the file system. This means that a pattern like
+`classpath*:*.xml` will not retrieve files from the root of jar files but rather only
 from the root of expanded directories. This originates from a limitation in the JDK's
 `ClassLoader.getResources()` method which only returns file system locations for a
 passed-in empty string (indicating potential roots to search).
 
-Ant-style patterns with " `classpath:`" resources are not guaranteed to find matching
+Ant-style patterns with `classpath:` resources are not guaranteed to find matching
 resources if the root package to search is available in multiple class path locations.
 This is because a resource such as