I was curious about the uri's for html/xml files which resemble "http://.../..."
For instance a web.xml file has this boilerplate stuff
<web-app version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
So the uri specifies a web resource for the xml file that tells it what schema to use/etc right? Then what if you were to run this code locally without an internet connection? How would the xml file figure out what to do? Why do I not need to download all this stuff like I would need to for jar files instead of citing some uri? I mean I can use jstl tags, spring tags just by citing the uri. What kind of behind the scenes stuff is happening?
I can't say for http, only for XML. The W3C Specification says:
The namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists).
If the program reading your XML can't find the SchemaLocation, it will not check against that schema and probably provide you a warning. The XML itself doesn't know at all what to do.
Related
In Apache Karaf, before I install my features.xml file I need to type.
feature:repo-add camel 2.17.3
Is there any way to express in the features.xml file some command which makes this occur ? So that I can avoid typing it on the command line inside Karaf.
The motivation for this question is that it is nice that generally when I add a features.xml file to the deploy directory of Karaf that it can pull down all the dependent bundles by itself automatically. I like the fact that it has this automatic feature and the only thing I need to send is the features.xml. So this leads to my desire to encapsulate all the work in the features.xml file so that I do not need to type anything into the Karaf console.
This works. You need to refer to the camel feature xml using the repository tag.
See the cxf-dosgi samples feature xml.
The repository xml tag must appear within the features XML tag. So its like:
<?xml version="1.0" encoding="UTF-8"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0" name="jump_micro">
<repository>mvn:org.apache.camel.karaf/apache-camel/2.17.3/xml/features</repository>
<feature description="jump_micro" version="1.0.0" name="jump_micro">
...
This is a shortcut for feature:repo-add mvn:org.apache.camel.karaf/apache-camel/2.17.3/xml/features
so no, this can't really be skipped as you somehow need to tell which feature file to use. If you skip the version it'll be that latest available version.
All,This question may be ignored everyday by us asp.net developer like air. If you think it is dumb, Please don't laugh. Thanks,
We knew the web.config is hosted in every Asp.Net web application. And It's syntax is restricted by the xml and DotNetConfig.xsd. The schema will describe what can be allowed in the web.config.
But When we look in a specified web.config.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
....
</configuration>
We didn't see any place to show this xml is based on the DotNetConfig.xsd.I mean any xml need to be validated should be documented which schema it is from
So that It can be validated in the runtime. Is that right ?
How does the validation works ? Could someone please tell me something about it .
Thanks.
web.config is not strictly validated against the XSD file at runtime. The XSD file is used by Visual Studio as an assistance to developers to avoid typos and other errors in known parts of the configuration file, however because .NET configuration is entirely extensible there is little point in performing XSD-based validation at runtime.
Some validation is performed by System.Configuration classes in the class library when they load configuration data, however per-element validation (in this sense) is the responsibility of the consuming configuration classes rather than the web.config loader/parser itself.
I have a send port with a pipeline with an XML assembler. All my files that it creates look like this:
<?xml version="1.0" encoding="utf-8"?>
<Root xmlns="http://LMS.OIv2.Sierra.SierraRouteUpdate">
<Orders OrderCode="" SCAC="" CarrierName=" />
<Orders OrderCode="" SCAC="" CarrierName="" />
</Root>
How can I get rid of that xmlns attribute from the root node?
The use-case for this type of message processing is when integrating with legacy systems that do not implement a fully compliant XML parser. While "in theory", all systems should be able to handle valid XML, back in the real world I find a lot of applications still treat XML in the same way they treat a string or flat-file.
I've updated my blog post to include a sample Visual Studio project, showing the implementation of the code inside a BizTalk pipeline component. I hope this helps.
So as you may or may not know, BlazeDS (open source version of LiveCycle Data Services) is a nice way to get your server-side Java and client-side Flex application to play together. Unfortunately, it does have several pitfalls that need to be corrected. I'll try to explain one of them here.
All of BlazeDS's configuration is written via XML files in the flex/ folder of your webapp. The default names are separated for clarity, such as services-config.xml, remoting-config.xml, messaging-config.xml, etc. In these configuration files (particularly services-config.xml), Channels are defined; these setup URIs and objects used to capture and send information between the server and the client. In these config files, it is quite common to use a syntax like so:
<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
<properties>
<add-no-cache-headers>false</add-no-cache-headers>
</properties>
</channel-definition>
Unfortunately, what they don't tell you is that some of these key-in replacements (ie: {context.root}) are not replaced dynamically upon execution but upon compilation of the WAR file you intend to distribute. Obviously not a good idea when switching domains.
So, instead I seek to dynamically define these channels. According to the documentation, that's all good and fine, but it only works if the channel already exists when the webapp is launched. I feel like that sort of defeats the point.
So my question is, how do you truly create channels dynamically so that both the client and the server recognize their existence?
Read this blog post; I believe it is what you're after.
I believe these xml config files have no direct relation to the server at all. They are used to tell the SWF how to find the server.
During Compile time of your Flex App; the services-config information is, in essence, hard coded into the SWF.
I'm developing a webapp using tiles and spring mvc. With the use of xsd and dtd validation on the definition of tiles and bean declaration of spring mvc, each time the web app is start/restart, then requests are sent to external server for xsd and dtd files. I notice that because my webapp failed to start casually due to failed request to external server (!!!).
I wonder if there is a way to tell my app to stop doing that? Like place a cached version of these files somewhere, or tell the Xml Processor to not valid these xml files at run time?
I'm facing a similar problem (but with xsd files.) After a little research, it appears that generally, foo-1.0.jar will contain foo-schema-1.0.xsd and therefore when foo goes to validate its foo-config.xml, it doesn't need to ask the Internet for the xsd.
The problem comes when you upgrade to foo-1.1.jar (which includes the new foo-schema-1.1.xsd) without changing your foo-config.xml to reference the new version of the schema. foo-1.1.jar doesn't contain foo-schema-1.0.xsd, so the parser looks for it on the Internet. If the site is trying to look at is down, you have problems.
So check your xml files to make sure they're referencing the version of the xsd/dtd appropriate for the jar version which is validating them.