source: GTP/trunk/Lib/Vis/Preprocessing/src/GzFileInputSource.cpp @ 975

Revision 975, 4.6 KB checked in by mattausch, 18 years ago (diff)
RevLine 
[971]1/*
2 * Copyright 1999-2000,2004 The Apache Software Foundation.
3 *
4 * Licensed under the Apache License, Version 2.0 (the "License");
5 * you may not use this file except in compliance with the License.
6 * You may obtain a copy of the License at
7 *
8 *      http://www.apache.org/licenses/LICENSE-2.0
9 *
10 * Unless required by applicable law or agreed to in writing, software
11 * distributed under the License is distributed on an "AS IS" BASIS,
12 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13 * See the License for the specific language governing permissions and
14 * limitations under the License.
15 */
16
17
18// ---------------------------------------------------------------------------
19//  Includes
20// ---------------------------------------------------------------------------
21#include <xercesc/framework/LocalFileInputSource.hpp>
22#include <xercesc/util/BinFileInputStream.hpp>
23#include <xercesc/util/PlatformUtils.hpp>
24#include <xercesc/util/XMLString.hpp>
25#include <xercesc/util/XMLUniDefs.hpp>
26
27#include "GzFileInputSource.h"
28#include "GzBinFileInputStream.h"
29
30XERCES_CPP_NAMESPACE_BEGIN
31
32/***
33 *
34 * Originated by Chris larsson
35 *
36 * Issue:
37 *
38 * There is an inconsistency in URI resolution in the case where the file itself is a
39 * symbolic link to another path (or the path has path segment which is a symbolic
40 * link to another path). So, is the base path the directory where the symbolic link resides
41 * or the directory where the real file resides? I'm sure one could argue either way,
42 * but I think that having the base path be the directory where the symbolic link resides
43 * is more intuitive.
44 *
45 * Defining it this way would then make the behavior consistent with using an absolute
46 * path as well as with the java behavior.
47 *
48 * Proposal:
49 *
50 * The URI is resolved within the parser code, and is somewhat independant of the OS.
51 *
52 * A relative path is resolved by querying the current directory and appending the
53 * relative part onto the returned current directory string to obtain the base URI.
54 * An absolute path is simply used as the base URI.
55 * Then remove all "./" and "../" path segments using an algorithm like weavepath to obtain
56 * the resolved base URI.
57 *
58 * When you need to access another file such as a dtd, use the resolved base URI and add on
59 * the relative URI of the dtd file. Then resolve it using the same weavepath algorithm.
60 *
61 * Note:
62 *
63 *   Java parser behaves differently for a path containning symbolic path segment. When
64 *   it is given an absolute path, it can locate the primary instance document, while given
65 *   relative path, it might not.
66 *
67 *   It is because Java parser uses URI solution where "/segment/../" is required to be removed
68 *   from the resultant path if a relative URI is merged to a baseURI. While this is NOT required
69 *   for an absolute URI.
70 *   
71 *   So if a path segment, which is symbolic link, happen to be followed by the '/../', it is
72 *   NOT removed from the path if it is given in absolute form, and the underlying file system
73 *   will locate the file, if in relative form, that symbolic link path segment together with
74 *   '../' is removed from the resultant path, and the file system may NOT be able to locate
75 *   the file, if there is a one, it is definitely not the one expected, in fact by accident.
76 *
77 *   Therefore, to keep consistent with Java parser, for now, we do not apply removeDotDotSlash()
78 *   for absolute path.
79 * 
80 ***/
81
82// ---------------------------------------------------------------------------
83//  LocalFileInputSource: Constructors and Destructor
84// ---------------------------------------------------------------------------
[975]85GzFileInputSource::GzFileInputSource(const XMLCh* const basePath,
86                                                                         const XMLCh* const relativePath,
87                                                                         MemoryManager* const manager)
88: LocalFileInputSource(basePath, relativePath, manager)
[971]89{
90}
91
92GzFileInputSource::GzFileInputSource(const XMLCh* const filePath,
93                                                                         MemoryManager* const manager)
[975]94: LocalFileInputSource(filePath, manager)
[971]95{
96}
97
98
99GzFileInputSource::~GzFileInputSource()
100{
101}
102
103
104// ---------------------------------------------------------------------------
105//  LocalFileInputSource: InputSource interface implementation
106// ---------------------------------------------------------------------------
107BinInputStream* GzFileInputSource::makeStream() const
108{
109        GzBinFileInputStream* retStrm = new (getMemoryManager()) GzBinFileInputStream(getSystemId(), getMemoryManager());
[975]110
[971]111        if (!retStrm->getIsOpen())
112    {
113        delete retStrm;
114        return 0;
115    }
116    return retStrm;
117}
118
119XERCES_CPP_NAMESPACE_END
120
Note: See TracBrowser for help on using the repository browser.