cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 27013] New: - [PATCH] fixed ContextSourceFactory
Date Tue, 17 Feb 2004 19:45:34 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27013>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27013

[PATCH] fixed ContextSourceFactory

           Summary: [PATCH] fixed ContextSourceFactory
           Product: Cocoon 2
           Version: 2.1.3
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: core
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: m_rolappe@web.de
                CC: m_rolappe@web.de


this patch resolves several problems:

- chicken-and-egg-problem: SourceResolverImpl looks up SourceFactorySelector,
which holds (among others) ContextSourceFactory, which obtains a SourceResolver
when it needs one, but only disposes it in dispose(). the latter depends on
SourceFactorySelector being released and disposed, which in turn requires
SourceResolverImpl to release SourceFactorySelector. this would be done in
SourceResolverImpl's dispose, but this won't be done without forcing disposal,
since ContextSourceFactory still holds a reference to the resolver.
- the original ContextSourceFactory doesn't return a Source belonging to the
factory, but the Source it resolves to. this means you'll get the scheme and URI
of the resolved source, which is 'wrong'. returning the wrong scheme also means
being unable to correctly release the source, since release() depends on the
SourceFactory (which is chosen based on the scheme)
- although the source states otherwise the first '/' wouldn't be removed from
the path
- in the rarest cases (when context.getRealPath() would return null) would a
resource have been tried; in most cases a File is created and its URL is
resolved. this is then returned as the result source. the fact that the file
might not even exist, would only show up later. the fixed version's behavior is:
try file first and if the file exists, resolve the file's URI and use the
resulting source as delegate source, otherwise try resource and if it exists,
resolve the resource's URI and use the result as delegate Source, otherwise
throw a SourceNotFoundException

Mime
View raw message