Steve,
Thank you for your elaborate answer.
Although I still don't understand why URL resolving fails if there is a space in the
path name (shouldn't the resolver URL-encode the path?), I accept it to be problematic.
In my work I deal a lot with Windows system administrators. They are usually are a bit
reluctant to install new software. I have found that it is important for their
confidence in the product that the installation is 'predictable'. So the product
should have a windows installer; the files go into a directory under "program files";
there is a windows GUI (small as it may be -- a couple of buttons can be enough);
servers are installed as Windows NT services, etc.
A deviation of the norm makes the product look less professional -- merited or not.
Cheers,
Hes.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: dinsdag 10 augustus 2004 0:31
To: [EMAIL PROTECTED]
Subject: [jira] Commented: (JAMES-307) james 2.2.0 run.bat Error building configuration
The following comment has been added to this issue:
Author: Steve Brewin
Created: Mon, 9 Aug 2004 3:31 PM
Body:
It is true that a URL can use %20 to escape spaces, thus a fully qualified URL such as
"file:///c:/Program%20Files/whatever%20%you%20want" will work.
James' config.xml uses a relative URI to include documents so as not to bind the
installed project to a specific protocol or location. The starting assumptions are:
- The included documents are served using the same protocol as the config.xml, be that
file:, http:, ldap: or whatever.
- The 'config.xml' document can be stored anywhere in the hierarchy made accessible
via the protocol.
- Documents included by 'config.xml' are stored in a fixed shape hierarchy relative to
'config.xml'.
The user is free to override any of these assumptions by changing the declarations in
config.xml. Such changes may include anything which conforms to the URL/URI specs.,
including using alternative protocols for some documents, changing the shape of the
subtree, or <bold>using a fully qualified URL to work around the embedded space
problem</bold>.
For that matter, the includes can be replaced entirely by inserting the contents of
the relevant documents into the places they are referenced in 'config.xml' and
removing the associated entity declarations. This is how it used to be until
'config.xml' grew so large as to be barely intelligible.
The real world cost of this flexibility, based on bug reports and mailing list
questions, seems to be that the default 'out of the box' configuration causes a small
minority of users problems.
Should we consider this a 'bug'?
No, as previously noted, James and the XML parser it relies on are behaving as
they should.
Should we abandon this flexibility in order to circumvent the problem?
No, the benefits for the many far outweigh the problems for the few.
Should we ignore this problem?
No. Though we are technically correct we cannot expect all users to understand the
issues involved and navigate themselves to a solution based on developing a deeper
understanding of URIs and URLs.
What should we do to help?
The run scripts could check for installation into a path with embedded spaces,
warn about the problem and point to an entry in the FAQ regarding circumventions. If
anyone thinks that this is the right way to go, why not make a feature request,
linking it to this issue?
Better, develop enhancements to the existing scripts and submit them as patches,
or write the missing FAQ.
Finally, unprofessional? Try searching the knowledge bases and mailing lists of the
commercial J2EE server vendors, or open source solutions such as Tomcat. Their
solutions for this issue vary between "install it where we told you" to "YYGT" (yes,
you get that). So we are as unprofessional as the market leaders :)
-- Steve
