Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Fri, 8 Feb 2002 20:06:16 -0500
From: Tim Myers <phantom@stserv.hcf.jhu.edu>
To: cocoon-dev@xml.apache.org
Subject: Re: AbstractComplementaryConfigurableAction bug?
Message-ID: <20020208200616.A8622@stserv.hcf.jhu.edu>
References: <007101c1b031$5698dff0$3c10a8c0@hobbit>
 <3C63D47E.9070205@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3C63D47E.9070205@apache.org>;
 from bloritsch@apache.org on Fri, Feb 08, 2002 at 08:37:02AM -0500

Hi Berin,

I'm responsible for the code and consider it an ugly hack.
It makes it possible to use database/validation descriptors placed relative to 
the current sitemap by doing <... src="file:relative/path"/>

It used to be that if you did <... src="file:relative/path"/> it would give 
you a file relative to the toplevel sitemap-- which doesn't seem to be the
 right behavior.  Now, if you do src="relative/path" or src="/absolute/path"
 it acts the old way, and if you do file: it short circuits it and is causing 
Colin a problem.

i don't think that src="file:..." should act any different from src="" even 
though i introduced this discrepency.  I remember that whichever implementation 
of sourceHandler.getSource isn't handling the URI correctly-- it didn't have a match for file: and there was no good place to add one.

The other part of the hack (and you may remember it since i screwed up the 
interface and wasn't wise enough to deprecate the old), was to add a Resolver
to the configure method which passes the Resolver that the calling action 
recieved from the sitemap in act().  My impression from this list is that some 
work has been done to the sourceResolver (isn't there an avalon component for that now?) since i wrote this hack and the part he quotes may no longer be necesarry.

Shouldn't every resolve be able to take the environment into consideration?

Tim Myers


On Fri, Feb 08, 2002 at 08:37:02AM -0500, Berin Loritsch wrote:
> Colin Hall wrote:
> > Hi Berin,
> > I am in the process of upgrading to cocoon 2.0.1 and have discovered what I
> > think is a problem in the latest version of
> > AbstractComplementaryConfigurableAction.
> > 
> > I noticed that the actions that I wrote were breaking when trying to load
> > the descriptor.
> > I use the file:///g:/some/file/named/foo.xml uri syntax to indicate the
> > location of the descriptor (on Win32) which resulted in the following
> > exception being thrown:
> > 
> > org.apache.avalon.framework.configuration.ConfigurationException: Error
> > trying to load configurations for resource: null
> > 
> > Looking at the AbstractComplementaryConfigurableAction code I noticed the
> > following in getConfiguration:
> > ...
> >    if (descriptor.startsWith("file:")) {
> >     resource =
> > sourceHandler.getSource((Environment)resolver,((Environment)resolver).getCon
> > text(), descriptor.substring(5));
> >    } else
> >      resource = sourceHandler.getSource(null, descriptor);
> > ...
> > 
> > Isn't this reverse of what it should be?  This logic will resolve all file:
> > uris to the webapp context rather than to an absolute path.
> > 
> > I think that the code should read as follows...
> > 
> >    if (descriptor.startsWith("file:")) {
> >      resource = sourceHandler.getSource(null, descriptor);
> >    } else
> >     resource =
> > sourceHandler.getSource((Environment)resolver,((Environment)resolver).getCon
> > text(), descriptor.substring(5));
> > 
> > Am I correct in this, or is there something that I am not considering here?
> 
> This is something for the Cocoon developer's list.  I haven't been actively
> developing Cocoon code for a while now (a little here and there), but nothing
> like I used to.  That change was done by someone else, and the problem might
> be in the resolver code.
> 
> 
> 
> -- 
> 
> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org