> On second thought, FilePartArray vs FilePartFile shouldn't matter
> - the code
> is looking for the superclass FilePart and is only using getSize() and
> getInputStream(). I can't find where the action is getting the parameter,
> probably because of the input module abstraction.
Ok, I think I have it (thanks to eclipse which made finding the exact right
lines of code almost effortless - so far it's worth every penny!).
o.a.c.components.modules.input.RequestParameterModule line 80:
public Object getAttribute( String name, Configuration modeConf, Map
objectModel ) throws ConfigurationException {
String pname = name;
if ( modeConf != null ) {
pname = modeConf.getAttribute( "parameter", pname );
}
return ObjectModelHelper.getRequest(objectModel).getParameter(
pname );
}
Shouldn't that use:
return ObjectModelHelper.getRequest(objectModel).get( pname ); ?
getParameter() returns String - get() returns Object.
I haven't managed to get output from JDBCTypeConversions yet (no logger
available and System.out is not showing up in the console - or it's never
getting to the lines I've done the poorman's debug). But, I'd be willing to
bet that for whatever reason, I'm getting a FilePartFile and the toString is
giving a usable system id somewhere and that's causing it to work by
accident? I haven't done debug tracing with eclipse yet - maybe it's time
to learn.
>
> Normally, one does a org.apache.cocoon.environment.Request.get() on the
> parameter name which gets a (FilePart)Object. I'm not clear enough on
> InputModule internals to know what it's doing.>
Still not real deep on the InputModule internals - is it using
RequestParameterModule as I've guessed??
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
