You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by "Brian J. Sayatovic" <tr...@one.net> on 2004/07/14 04:33:00 UTC
Upgrading James
I'm feeling like a n00b to James even though I've been using it for well
over a year now. I've been running 2.2.0a for some time now on my
Windows XP box. Tonight, I had planned to upgrade to the final 2.2.0
release.
My suaul plan of action is to stop the James NT service, rename my
F:\Program Files\James folder to F:\Program Files\James.old and then
extract the new James. I compare and edit the new wrapper.conf to use
my latest JRE. I then add my three custom JARs to the james.sar in the
apps folder. Next, I start James, and check the logs. If everything
looks ok, I stop James, move over the old repositories, then start it
again and check the logs one last time.
This, time, though, thinsg went terribly wrong. My Zip program,
UltimateZip, seemed to be corrupting james.sar when I added my 3 cusotm
JARs to it. Once I got past that, the wrapper.log would contain errors
describing as MalformedURLException stemming from "no protocol" when
looking for ENTITY declarations located in relative files. I suspected
this was from the space in my folder name, so I hacked the registry
entry for the service to point to wrapper.exe and wrapper.conf using the
8.3 naming. When this didn't work, I moved my whole James folder to
F:\James. That fixed that problem, but then the vanilla config.xml from
james.sar led to more errors stemming froma ClassNotFoundException for
some file stream store repository class.
I've given up for the night. I deleted all my new stuff, renamed my old
folder back, unhacked the registry and now my old 2.2.0a version is
runnong fine.
A few points I'd like to share with people:
1. There is no excuse for a program NOT to work with spaces in paths.
Unix supports them. Windows supports them. So should you!
2. A free, decent ZIP utility is hard to come by
3. Adding custom libs/classes to James is a pain in the butt -- is there
an easier way???
4. There needs to be a simpler way to upgrade James in place, or at
least an automated tool to help do all of the above. Or, at least, how
about a Wiki page on this subject?
Anyone have some advice before I start again tomorrow?
Regards,
Brian.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Upgrading James
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Brian J. Sayatovic wrote:
> FWIW, a related problem someone had (found via GOogle) directed me to
> the Xerces FAQ (http://xml.apache.org/xerces-j/faq-common.html#faq-5):
>
>
> Q: I used to be able to use DOS filenames with the parser and now they
> don't work. Why not?
> A: DOS filenames are not legal URIs as required by the XML 1.0
> specification. Therefore, it was an error for the parser to accept DOS
> filenames. This bug is now fixed. DOS filenames can be converted to
> legal URIs, however. For example, the DOS filename
> "c:\xerces\data\personal.xml" would become
> "file:///c:/xerces/data/personal.xml", which is a legal URI.
In this example, better would be to code
"file:///c|/xerces/data/personal.xml".
See http://www.cs.tut.fi/~jkorpela/fileurl.html.
The browsers (for example IE and Mozilla) accept either way, but - if I recall well - Java requires the "|" instead of the ":".
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Upgrading James
Posted by "Brian J. Sayatovic" <tr...@one.net>.
FWIW, a related problem someone had (found via GOogle) directed me to
the Xerces FAQ (http://xml.apache.org/xerces-j/faq-common.html#faq-5):
Q: I used to be able to use DOS filenames with the parser and now they
don't work. Why not?
A: DOS filenames are not legal URIs as required by the XML 1.0
specification. Therefore, it was an error for the parser to accept DOS
filenames. This bug is now fixed. DOS filenames can be converted to
legal URIs, however. For example, the DOS filename
"c:\xerces\data\personal.xml" would become
"file:///c:/xerces/data/personal.xml", which is a legal URI.
However, I suspect it might be in the Avalon configuraiton builder where
it is turning things into filenames? I intend to look in the source and
see, lest someone can come up with a better explanation sooner.
Regards,
Brian.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Upgrading James
Posted by "Brian J. Sayatovic" <tr...@one.net>.
I did some tinkering. In Phoenix's
org.apache.avalon.phoenix.components.deployer.installer.Installer class
is the following method:
/**
* Utility method to extract URL from file in safe manner.
*
* @param file the file
* @return the URL representation of file
*/
private String getURLAsString( final File file )
{
try
{
return file.toURL().toExternalForm();
}
catch( final MalformedURLException mue )
{
return null;
//should never occur
}
}
As you can see, it relies on the java.io.File.toURL() method to convert
the file into a URL suitable for an InputSource. It has always been a
misnomer that a File can be turned into a URL beause a URL requires a
protocol (i.e. http, ftp, etc.). Instead, the "file://" URLs are not
URLs at all, but URIs which are a more general form. That is the 'L' in
URL is for Locator and carries with it the definition of what protocol
to use, whereas a the 'I' in URI for, I think, Indicator, and carries no
such requirement of a protocol. After all, "file:" is not an actual
protocol.
Anyways, through experimentation, I've determined that the above code,
as used in Phoenix's ConfigurationBuilder to read XML files, will cause
certain XML parsers to fail in my situation. My situation is that my
XML file's path has a space in it. Certain XML parsers means the newer
versions of Xerces. Ths is specifically what the FAQ I mentioned in my
earlier messages talks about, but without a reasonable solution.
There are two solutions I've found:
1. Do not use a path with spaces. In this case, that means don't
install James into a path with spaces. Using a path with spaces and
always using the 8.3 naming (i.e. C:\Progra~1 instead of C:\Program
Files) will not work. I tried that, but Java still somehow manages to
get the OS to turnit into the real non-8.3 pathname so the spaces re-appear.
2. Change the code in Phoenix. Now, I'm not sure because
Phoenix.Excalibur/Avalon/etc.'s relationships confuses the heck out of
me, but I think Phoenix is defunct. Anyways, if not, or if it is but we
pretendedit isn't, I have to solutions to fix this:
2a. JDK 1.4 added a 'toURI()' method to File which returns a URI.
Calling .toString() on a URI properly escapes spaces as '%20'. Here's
my test code:
private static String getURLAsString3( final File file )
{
return file.toURI().toString();
}
2b. Before JDK 1.4, the escaping must be done manually. My code snippet
below takes care of spaces, but a more general escaping solution would
really be needed:
private static String getURLAsString2( final File file )
{
String url = getURLAsString(file);
StringBuffer fixedUpUrl = new StringBuffer();
int lastIndex = 0;
while(true) {
int spaceIndex = url.indexOf(' ', lastIndex);
// Tail?
if(spaceIndex < 0) {
fixedUpUrl.append(url.substring(lastIndex));
break;
}
fixedUpUrl.append(url.substring(lastIndex, spaceIndex));
fixedUpUrl.append("%20");
lastIndex = spaceIndex + 1;
}
return fixedUpUrl.toString();
}
There may be one other solution. Older versions of Xerces didn't
exhibit this problem. I'm not sure if they tightened things up, or
removed an intentional work around, but according to the XML
specifications, it never should've worked (as far as I understand it).
But, if we were to switch to an older, less-proper version of Xerces, it
should work. But does Phoenix/James need the features of the latest Xerces?
Regards,
Brian.
Noel J. Bergman wrote:
>>java.net.MalformedURLException: no protocol: ../conf/james-fetchmail.xml
>>
>>
>
>Some people have reported that error. I can't reproduce it here. I am
>wondering if the people who are reproducing it have done something different
>in their Java environment.
>
>I plan to take a look at it with the newer Avalon code, and see what we need
>to do there.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>For additional commands, e-mail: server-user-help@james.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: Upgrading James
Posted by "Noel J. Bergman" <no...@devtech.com>.
> java.net.MalformedURLException: no protocol: ../conf/james-fetchmail.xml
Some people have reported that error. I can't reproduce it here. I am
wondering if the people who are reproducing it have done something different
in their Java environment.
I plan to take a look at it with the newer Avalon code, and see what we need
to do there.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Upgrading James
Posted by "Brian J. Sayatovic" <tr...@one.net>.
I'm attempting my upgrade with a fresh mind this evening. I've made a
new James folder, F:\Program Files\Apache Group\James, separate from my
other one. When I used wrapper.exe to install this as a service, I
specified the short 8.3 path, F:\Progra~1\Apache~1\James. I've
confirmed this took by checking the registry for the service:
ImagePath: F:\PROGRA~1\APACHE~1\James\bin\Wrapper.exe -s
F:\Progra~1\Apache~1\James\conf\wrapper.conf
However, the wrapper.log contains the stack trace below showing that it
is *still* getting the non-8.3 path which has spaces. From earlier
testing, it seems it is the spaces that causes problems. But I'm
confident that I'm not having this problem in my existing, working James
2.2.0a installation in F:\Program Files\James (note there's no 'Apache
Group' in that path).
INFO | jvm 1 | 2004/07/14 18:46:37 | There was an uncaught exception:
INFO | jvm 1 | 2004/07/14 18:46:37 |
---------------------------------------------------------
INFO | jvm 1 | 2004/07/14 18:46:37 | --- Message ---
INFO | jvm 1 | 2004/07/14 18:46:37 | Error building configuration
from file:/F:/Program Files/Apache
Group/James/apps/james/SAR-INF/config.xml.
INFO | jvm 1 | 2004/07/14 18:46:37 | --- Stack Trace ---
INFO | jvm 1 | 2004/07/14 18:46:37 |
org.apache.avalon.phoenix.interfaces.DeploymentException: Error building
configuration from file:/F:/Program Files/Apache
Group/James/apps/james/SAR-INF/config.xml.
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.getConfigurationFor(DefaultDeployer.java:499)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy(DefaultDeployer.java:325)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:498)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:491)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFiles(DefaultEmbeddor.java:476)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployDefaultApplications(DefaultEmbeddor.java:466)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.execute(DefaultEmbeddor.java:224)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:158)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
java.lang.Thread.run(Thread.java:534)
INFO | jvm 1 | 2004/07/14 18:46:37 | Caused by:
java.net.MalformedURLException: no protocol: ../conf/james-fetchmail.xml
INFO | jvm 1 | 2004/07/14 18:46:37 | at
java.net.URL.<init>(URL.java:537)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
java.net.URL.<init>(URL.java:434)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
java.net.URL.<init>(URL.java:383)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:796)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:725)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(XMLDocumentFragmentScannerImpl.java:1073)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1489)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1169)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.tools.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:129)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.tools.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:116)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.tools.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:97)
INFO | jvm 1 | 2004/07/14 18:46:37 | at
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.getConfigurationFor(DefaultDeployer.java:493)
INFO | jvm 1 | 2004/07/14 18:46:37 | ... 8 more
Any help would be appreciated!
Regards,
Brian.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org