You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Chris Wilder-Smith <cw...@cast.org> on 2004/02/05 22:08:18 UTC
Multipart form upload
Hi,
We're trying to use a multipart/form-data post to upload audio files
recorded on the client machine to our cocoon-based backend. All of the
web.xml file upload params seem to be set correctly:
request-factory=org.apache.cocoon.components.request.MultipartRequestFactoryImpl
enable-uploads=true
upload-directory=WEB-INF/work/upload-dir
autosave-uploads=true
overwrite-uploads=rename
upload-max-size=10000000
According to the wiki pages, I should see the request type as
MultipartHttpServletRequest when it comes through, but it is a regular
cocoon HttpRequest. According to the example, this implies that uploads
still aren't enabled.
I do see other parameters that come through on the request, it's picking
up the correct generator, etc.
Anybody have any insights?
Thanks in advance,
Chris
--
Chris Wilder-Smith
Principal Technical Architect
mailto:cws@cast.org http://www.cast.org
CAST: 781-245-2212 Home Office: 508-650-8885
AIM ChrisWSatWork ICQ: 95325318
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Chris Wilder-Smith <ch...@wilder-smith.org>.
Geoff,
Maybe a bit more pertinent info:
After the correct request object is returned from the RequestFactory, I
see these request.get(str) calls:
request.get('cocoon-reload')
request.get('cocoon-form-encoding')
request.get('cocoon-view')
request.get('cocoon-action')
request.get('fileID') -- part of the post
request.get('MAX_FILE_SIZE') -- part of the post
request.get('file') -- from the multipart?
Then I see the next getServletRequest() and things go awry
Chris
On Fri, 2004-02-06 at 11:42, Geoff Howard wrote:
> Chris Wilder-Smith wrote:
> > Geoff,
> >
> > On Thu, 2004-02-05 at 19:45, Geoff Howard wrote:
> >
> >>Chris Wilder-Smith wrote:
> >
> > <snip>
> >
> >>>I get
> >>>
> >>> ** request class: org.apache.cocoon.environment.http.HttpRequest
> >>
> >>Right - and that's the point. Sorry I didn't explain more, but a change
> >>was made to the environment and request abstraction handling such that
> >>the assumption in the wiki that you can tell whether uploads are
> >>successfully enabled is no longer correct.
> >>
> >>So, you'll notice in my proposed code that I ignore the type of request.
> >> Try it and let me know what happens. If you just println inside each
> >>condition block you'll have a major clue.
> >
> >
> > I took a look through the HttpRequest code and can see how that is
> > supposed to work on the request wrapper inside the HttpRequest.
> >
> > I checked the content type and get multipart/form-data so that seems
> > correct:
> >
> > content-type=multipart/form-data;boundary=--------------------------7d41541f902a8
> >
> >
> > If I instrument the MultipartHttpServletRequest code so I can see what's
> > in the 'values' Hashtable - I just get two parameters with string values
> > - there are no Part objects in there.
> >
> > Do you think that means that the form-data really isn't getting parsed?
> > I also just threw it at a requestgenerator but don't get any insights
> > there.
>
> hmmm, I would be suspicious that uploads were broken in 2.1.3 but I
> really don't think so.
>
> Can you triple check that the web.xml used in this case really has
> enable-uploads set properly?
>
> After that, i'd break out a debugger, set a break point on cocoon
> servlet where it creates the request, or RequestFactory, etc. and see
> what is going on.
>
> Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Geoff Howard <co...@leverageweb.com>.
Chris Wilder-Smith wrote:
> Geoff,
>
> On Fri, 2004-02-06 at 14:08, Geoff Howard wrote:
> <snip>
>
>>Are you using cinclude or something like it? Can you send the relevant
>>bit of your pipeline? Also, try the upload sample if you have it or can
>>hack it into your set up (really just a pipeline and associated xsp file).
>
> No, we're not using cinclude in here. It was wrapped by an action, but
> it reacts the same with or without the action. I tried the upload
> sample xsp and of course, it works as specified - so something else is
> going on.
>
> Next, I hacked on the file upload example to have it send to my
> pipeline. Here, it appears to work as expected -- the file path is in
> the parameters and I can access it.
>
> So, that leads me to believe that there's something unique on the client
> side. This piece of the application we're building uses an audio
> recording applet to record student responses to activities, then sends
> the audio file to the server where it is stored. The applet is
> something of a blackbox from freedom audio. We have it working
> successfully in a pure servlet environment, but perhaps there are
> nuances to the way it does the request that cocoon doesn't like. I
> still don't understand the mechanism by which two requests could come
> through and only have one get to the
I don't remember everything in the request generator output but I have
in the past posted to it to determine issues like this (I think you
tried something like this earlier). Do you see any interesting
difference between the request gen output if you point the upload sample
to it, and then point the applet at it?
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Chris Wilder-Smith <ch...@wilder-smith.org>.
Geoff,
On Fri, 2004-02-06 at 14:08, Geoff Howard wrote:
<snip>
>
> Are you using cinclude or something like it? Can you send the relevant
> bit of your pipeline? Also, try the upload sample if you have it or can
> hack it into your set up (really just a pipeline and associated xsp file).
>
No, we're not using cinclude in here. It was wrapped by an action, but
it reacts the same with or without the action. I tried the upload
sample xsp and of course, it works as specified - so something else is
going on.
Next, I hacked on the file upload example to have it send to my
pipeline. Here, it appears to work as expected -- the file path is in
the parameters and I can access it.
So, that leads me to believe that there's something unique on the client
side. This piece of the application we're building uses an audio
recording applet to record student responses to activities, then sends
the audio file to the server where it is stored. The applet is
something of a blackbox from freedom audio. We have it working
successfully in a pure servlet environment, but perhaps there are
nuances to the way it does the request that cocoon doesn't like. I
still don't understand the mechanism by which two requests could come
through and only have one get to the pipeline.
Thanks,
Chris
> Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Geoff Howard <co...@leverageweb.com>.
Chris Wilder-Smith wrote:
> Geoff,
>
> On Fri, 2004-02-06 at 11:42, Geoff Howard wrote:
> <snip>
>
>>hmmm, I would be suspicious that uploads were broken in 2.1.3 but I
>>really don't think so.
>>
>>Can you triple check that the web.xml used in this case really has
>>enable-uploads set properly?
>>
>>After that, i'd break out a debugger, set a break point on cocoon
>>servlet where it creates the request, or RequestFactory, etc. and see
>>what is going on.
>
>
> Okay, this seems pretty weird, or at least counter-intuitive...
>
> This is what I'm seeing. When I post the audio file to cocoon, I can
> see a RequestFactory.getServletRequest() occur. Then, it goes through
> the parsing process until it finds the file part and then appears to
> save the file to disk at the appropriate place. (it puts an attribute
> in place called 'file' whose value is the resolved path to the file it
> saves.
>
> Now, I'd expect that the next thing I'd see would be my custom generator
> that is sitting on this pipeline get the request object, but that
> doesn't happen. Instead, I see a second getServletRequest() call, also
> with multipart/form-data encoding, but a different boundary and as such
> I think a completely different request. (Actually I know it's a
> different one, because I can see the constructor call) The whole
> parsing routine takes place and there is no file part to this request.
>
> It is the result of this second getServletRequest that arrives at the
> generator, and it doesn't have the 'file' attribute. In addition, the
> file has been deleted, one way or another (I know it is transient - only
> for the life of the request, which must already have been cleaned up)
>
> Clearly something odd is going on... Any ideas?
Are you using cinclude or something like it? Can you send the relevant
bit of your pipeline? Also, try the upload sample if you have it or can
hack it into your set up (really just a pipeline and associated xsp file).
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Chris Wilder-Smith <ch...@wilder-smith.org>.
Geoff,
On Fri, 2004-02-06 at 11:42, Geoff Howard wrote:
<snip>
>
> hmmm, I would be suspicious that uploads were broken in 2.1.3 but I
> really don't think so.
>
> Can you triple check that the web.xml used in this case really has
> enable-uploads set properly?
>
> After that, i'd break out a debugger, set a break point on cocoon
> servlet where it creates the request, or RequestFactory, etc. and see
> what is going on.
Okay, this seems pretty weird, or at least counter-intuitive...
This is what I'm seeing. When I post the audio file to cocoon, I can
see a RequestFactory.getServletRequest() occur. Then, it goes through
the parsing process until it finds the file part and then appears to
save the file to disk at the appropriate place. (it puts an attribute
in place called 'file' whose value is the resolved path to the file it
saves.
Now, I'd expect that the next thing I'd see would be my custom generator
that is sitting on this pipeline get the request object, but that
doesn't happen. Instead, I see a second getServletRequest() call, also
with multipart/form-data encoding, but a different boundary and as such
I think a completely different request. (Actually I know it's a
different one, because I can see the constructor call) The whole
parsing routine takes place and there is no file part to this request.
It is the result of this second getServletRequest that arrives at the
generator, and it doesn't have the 'file' attribute. In addition, the
file has been deleted, one way or another (I know it is transient - only
for the life of the request, which must already have been cleaned up)
Clearly something odd is going on... Any ideas?
Thanks again,
Chris
>
> Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Chris Wilder-Smith <ch...@wilder-smith.org>.
Nicolas,
I wish that were it, but it is something else. It turns out that the
request is coming through and is being handled correctly, but the applet
that is sending the data is producing a request that the sitemap isn't
seeing just right.
Thanks,
Chris
On Fri, 2004-02-06 at 17:00, Nicolas Toper wrote:
> Well it is probably stupid but have you laucnhed it
> with the rights authorization?
>
> I just had this error in the day. It didn"t print
> anything. But I launched it as root and it... worked
> :=)
>
>
> --- Chris Wilder-Smith <ch...@wilder-smith.org> a
> écrit : > Nicolas,
> >
> > linux primarily.
> >
> >
> > On Fri, 2004-02-06 at 16:19, Nicolas Toper wrote:
> > > Sorry, but are you using linux or win32 ?
> > >
> > > nico
> > > --- Geoff Howard <co...@leverageweb.com> a écrit
> > : >
> > > Chris Wilder-Smith wrote:
> > > > > Geoff,
> > > > >
> > > > > On Thu, 2004-02-05 at 19:45, Geoff Howard
> > wrote:
> > > > >
> > > > >>Chris Wilder-Smith wrote:
> > > > >
> > > > > <snip>
> > > > >
> > > > >>>I get
> > > > >>>
> > > > >>> ** request class:
> > > > org.apache.cocoon.environment.http.HttpRequest
> > > > >>
> > > > >>Right - and that's the point. Sorry I didn't
> > > > explain more, but a change
> > > > >>was made to the environment and request
> > > > abstraction handling such that
> > > > >>the assumption in the wiki that you can tell
> > > > whether uploads are
> > > > >>successfully enabled is no longer correct.
> > > > >>
> > > > >>So, you'll notice in my proposed code that I
> > > > ignore the type of request.
> > > > >> Try it and let me know what happens. If
> > you
> > > > just println inside each
> > > > >>condition block you'll have a major clue.
> > > > >
> > > > >
> > > > > I took a look through the HttpRequest code and
> > can
> > > > see how that is
> > > > > supposed to work on the request wrapper inside
> > the
> > > > HttpRequest.
> > > > >
> > > > > I checked the content type and get
> > > > multipart/form-data so that seems
> > > > > correct:
> > > > >
> > > > >
> > > >
> > >
> >
> content-type=multipart/form-data;boundary=--------------------------7d41541f902a8
> > > > >
> > > > >
> > > > > If I instrument the
> > MultipartHttpServletRequest
> > > > code so I can see what's
> > > > > in the 'values' Hashtable - I just get two
> > > > parameters with string values
> > > > > - there are no Part objects in there.
> > > > >
> > > > > Do you think that means that the form-data
> > really
> > > > isn't getting parsed?
> > > > > I also just threw it at a requestgenerator but
> > > > don't get any insights
> > > > > there.
> > > >
> > > > hmmm, I would be suspicious that uploads were
> > broken
> > > > in 2.1.3 but I
> > > > really don't think so.
> > > >
> > > > Can you triple check that the web.xml used in
> > this
> > > > case really has
> > > > enable-uploads set properly?
> > > >
> > > > After that, i'd break out a debugger, set a
> > break
> > > > point on cocoon
> > > > servlet where it creates the request, or
> > > > RequestFactory, etc. and see
> > > > what is going on.
> > > >
> > > > Geoff
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > > users-unsubscribe@cocoon.apache.org
> > > > For additional commands, e-mail:
> > > > users-help@cocoon.apache.org
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Mail : votre e-mail personnel et gratuit
> > qui vous suit partout !
> > > Créez votre Yahoo! Mail sur
> > http://fr.benefits.yahoo.com/
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > users-unsubscribe@cocoon.apache.org
> > > For additional commands, e-mail:
> > users-help@cocoon.apache.org
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail:
> > users-help@cocoon.apache.org
> >
>
>
>
>
>
>
> Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
> Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Nicolas Toper <nt...@yahoo.fr>.
Well it is probably stupid but have you laucnhed it
with the rights authorization?
I just had this error in the day. It didn"t print
anything. But I launched it as root and it... worked
:=)
--- Chris Wilder-Smith <ch...@wilder-smith.org> a
écrit : > Nicolas,
>
> linux primarily.
>
>
> On Fri, 2004-02-06 at 16:19, Nicolas Toper wrote:
> > Sorry, but are you using linux or win32 ?
> >
> > nico
> > --- Geoff Howard <co...@leverageweb.com> a écrit
> : >
> > Chris Wilder-Smith wrote:
> > > > Geoff,
> > > >
> > > > On Thu, 2004-02-05 at 19:45, Geoff Howard
> wrote:
> > > >
> > > >>Chris Wilder-Smith wrote:
> > > >
> > > > <snip>
> > > >
> > > >>>I get
> > > >>>
> > > >>> ** request class:
> > > org.apache.cocoon.environment.http.HttpRequest
> > > >>
> > > >>Right - and that's the point. Sorry I didn't
> > > explain more, but a change
> > > >>was made to the environment and request
> > > abstraction handling such that
> > > >>the assumption in the wiki that you can tell
> > > whether uploads are
> > > >>successfully enabled is no longer correct.
> > > >>
> > > >>So, you'll notice in my proposed code that I
> > > ignore the type of request.
> > > >> Try it and let me know what happens. If
> you
> > > just println inside each
> > > >>condition block you'll have a major clue.
> > > >
> > > >
> > > > I took a look through the HttpRequest code and
> can
> > > see how that is
> > > > supposed to work on the request wrapper inside
> the
> > > HttpRequest.
> > > >
> > > > I checked the content type and get
> > > multipart/form-data so that seems
> > > > correct:
> > > >
> > > >
> > >
> >
>
content-type=multipart/form-data;boundary=--------------------------7d41541f902a8
> > > >
> > > >
> > > > If I instrument the
> MultipartHttpServletRequest
> > > code so I can see what's
> > > > in the 'values' Hashtable - I just get two
> > > parameters with string values
> > > > - there are no Part objects in there.
> > > >
> > > > Do you think that means that the form-data
> really
> > > isn't getting parsed?
> > > > I also just threw it at a requestgenerator but
> > > don't get any insights
> > > > there.
> > >
> > > hmmm, I would be suspicious that uploads were
> broken
> > > in 2.1.3 but I
> > > really don't think so.
> > >
> > > Can you triple check that the web.xml used in
> this
> > > case really has
> > > enable-uploads set properly?
> > >
> > > After that, i'd break out a debugger, set a
> break
> > > point on cocoon
> > > servlet where it creates the request, or
> > > RequestFactory, etc. and see
> > > what is going on.
> > >
> > > Geoff
> > >
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > users-unsubscribe@cocoon.apache.org
> > > For additional commands, e-mail:
> > > users-help@cocoon.apache.org
> > >
> >
> >
> >
> >
> >
> >
> > Yahoo! Mail : votre e-mail personnel et gratuit
> qui vous suit partout !
> > Créez votre Yahoo! Mail sur
> http://fr.benefits.yahoo.com/
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail:
> users-help@cocoon.apache.org
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail:
> users-help@cocoon.apache.org
>
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Chris Wilder-Smith <ch...@wilder-smith.org>.
Nicolas,
linux primarily.
On Fri, 2004-02-06 at 16:19, Nicolas Toper wrote:
> Sorry, but are you using linux or win32 ?
>
> nico
> --- Geoff Howard <co...@leverageweb.com> a écrit : >
> Chris Wilder-Smith wrote:
> > > Geoff,
> > >
> > > On Thu, 2004-02-05 at 19:45, Geoff Howard wrote:
> > >
> > >>Chris Wilder-Smith wrote:
> > >
> > > <snip>
> > >
> > >>>I get
> > >>>
> > >>> ** request class:
> > org.apache.cocoon.environment.http.HttpRequest
> > >>
> > >>Right - and that's the point. Sorry I didn't
> > explain more, but a change
> > >>was made to the environment and request
> > abstraction handling such that
> > >>the assumption in the wiki that you can tell
> > whether uploads are
> > >>successfully enabled is no longer correct.
> > >>
> > >>So, you'll notice in my proposed code that I
> > ignore the type of request.
> > >> Try it and let me know what happens. If you
> > just println inside each
> > >>condition block you'll have a major clue.
> > >
> > >
> > > I took a look through the HttpRequest code and can
> > see how that is
> > > supposed to work on the request wrapper inside the
> > HttpRequest.
> > >
> > > I checked the content type and get
> > multipart/form-data so that seems
> > > correct:
> > >
> > >
> >
> content-type=multipart/form-data;boundary=--------------------------7d41541f902a8
> > >
> > >
> > > If I instrument the MultipartHttpServletRequest
> > code so I can see what's
> > > in the 'values' Hashtable - I just get two
> > parameters with string values
> > > - there are no Part objects in there.
> > >
> > > Do you think that means that the form-data really
> > isn't getting parsed?
> > > I also just threw it at a requestgenerator but
> > don't get any insights
> > > there.
> >
> > hmmm, I would be suspicious that uploads were broken
> > in 2.1.3 but I
> > really don't think so.
> >
> > Can you triple check that the web.xml used in this
> > case really has
> > enable-uploads set properly?
> >
> > After that, i'd break out a debugger, set a break
> > point on cocoon
> > servlet where it creates the request, or
> > RequestFactory, etc. and see
> > what is going on.
> >
> > Geoff
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail:
> > users-help@cocoon.apache.org
> >
>
>
>
>
>
>
> Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
> Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Nicolas Toper <nt...@yahoo.fr>.
Sorry, but are you using linux or win32 ?
nico
--- Geoff Howard <co...@leverageweb.com> a écrit : >
Chris Wilder-Smith wrote:
> > Geoff,
> >
> > On Thu, 2004-02-05 at 19:45, Geoff Howard wrote:
> >
> >>Chris Wilder-Smith wrote:
> >
> > <snip>
> >
> >>>I get
> >>>
> >>> ** request class:
> org.apache.cocoon.environment.http.HttpRequest
> >>
> >>Right - and that's the point. Sorry I didn't
> explain more, but a change
> >>was made to the environment and request
> abstraction handling such that
> >>the assumption in the wiki that you can tell
> whether uploads are
> >>successfully enabled is no longer correct.
> >>
> >>So, you'll notice in my proposed code that I
> ignore the type of request.
> >> Try it and let me know what happens. If you
> just println inside each
> >>condition block you'll have a major clue.
> >
> >
> > I took a look through the HttpRequest code and can
> see how that is
> > supposed to work on the request wrapper inside the
> HttpRequest.
> >
> > I checked the content type and get
> multipart/form-data so that seems
> > correct:
> >
> >
>
content-type=multipart/form-data;boundary=--------------------------7d41541f902a8
> >
> >
> > If I instrument the MultipartHttpServletRequest
> code so I can see what's
> > in the 'values' Hashtable - I just get two
> parameters with string values
> > - there are no Part objects in there.
> >
> > Do you think that means that the form-data really
> isn't getting parsed?
> > I also just threw it at a requestgenerator but
> don't get any insights
> > there.
>
> hmmm, I would be suspicious that uploads were broken
> in 2.1.3 but I
> really don't think so.
>
> Can you triple check that the web.xml used in this
> case really has
> enable-uploads set properly?
>
> After that, i'd break out a debugger, set a break
> point on cocoon
> servlet where it creates the request, or
> RequestFactory, etc. and see
> what is going on.
>
> Geoff
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail:
> users-help@cocoon.apache.org
>
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Geoff Howard <co...@leverageweb.com>.
Chris Wilder-Smith wrote:
> Geoff,
>
> On Thu, 2004-02-05 at 19:45, Geoff Howard wrote:
>
>>Chris Wilder-Smith wrote:
>
> <snip>
>
>>>I get
>>>
>>> ** request class: org.apache.cocoon.environment.http.HttpRequest
>>
>>Right - and that's the point. Sorry I didn't explain more, but a change
>>was made to the environment and request abstraction handling such that
>>the assumption in the wiki that you can tell whether uploads are
>>successfully enabled is no longer correct.
>>
>>So, you'll notice in my proposed code that I ignore the type of request.
>> Try it and let me know what happens. If you just println inside each
>>condition block you'll have a major clue.
>
>
> I took a look through the HttpRequest code and can see how that is
> supposed to work on the request wrapper inside the HttpRequest.
>
> I checked the content type and get multipart/form-data so that seems
> correct:
>
> content-type=multipart/form-data;boundary=--------------------------7d41541f902a8
>
>
> If I instrument the MultipartHttpServletRequest code so I can see what's
> in the 'values' Hashtable - I just get two parameters with string values
> - there are no Part objects in there.
>
> Do you think that means that the form-data really isn't getting parsed?
> I also just threw it at a requestgenerator but don't get any insights
> there.
hmmm, I would be suspicious that uploads were broken in 2.1.3 but I
really don't think so.
Can you triple check that the web.xml used in this case really has
enable-uploads set properly?
After that, i'd break out a debugger, set a break point on cocoon
servlet where it creates the request, or RequestFactory, etc. and see
what is going on.
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Chris Wilder-Smith <cw...@cast.org>.
Geoff,
On Thu, 2004-02-05 at 19:45, Geoff Howard wrote:
> Chris Wilder-Smith wrote:
<snip>
> > I get
> >
> > ** request class: org.apache.cocoon.environment.http.HttpRequest
>
> Right - and that's the point. Sorry I didn't explain more, but a change
> was made to the environment and request abstraction handling such that
> the assumption in the wiki that you can tell whether uploads are
> successfully enabled is no longer correct.
>
> So, you'll notice in my proposed code that I ignore the type of request.
> Try it and let me know what happens. If you just println inside each
> condition block you'll have a major clue.
I took a look through the HttpRequest code and can see how that is
supposed to work on the request wrapper inside the HttpRequest.
I checked the content type and get multipart/form-data so that seems
correct:
content-type=multipart/form-data;boundary=--------------------------7d41541f902a8
If I instrument the MultipartHttpServletRequest code so I can see what's
in the 'values' Hashtable - I just get two parameters with string values
- there are no Part objects in there.
Do you think that means that the form-data really isn't getting parsed?
I also just threw it at a requestgenerator but don't get any insights
there.
Thanks again for your help,
Chris
--
Chris Wilder-Smith
Principal Technical Architect
mailto:cws@cast.org http://www.cast.org
CAST: 781-245-2212
IM ChrisWSatWork ICQ: 95325318
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Geoff Howard <co...@leverageweb.com>.
Chris Wilder-Smith wrote:
> On Thu, 2004-02-05 at 17:23, Geoff Howard wrote:
>
>>Chris Wilder-Smith wrote:
snip the sanity check stuff. all sounds right.
>>4) Did you say you were getting a HttpRequest? That brings up a change
>>to the Request stored in the objectModel which may make that code on the
>>wiki no longer work as written. Try this:
>>
>>Request request = ObjectModelHelper.getRequest(obj);
>>Object o = request.get("blah");
>>if (o == null) {
>> // parameter missing from request
>>} else if (o instanceof Part) {
>> Part part = (Part) o;
>> // do something with it
>>} else if (o instanceof String) {
>> // upload is disabled - I think.
>>}
>
>
> this is basically what I'm doing. When I print out something like this:
>
> System.err.println(" ** request class: " +
> "request.getClass().getName());
>
> I get
>
> ** request class: org.apache.cocoon.environment.http.HttpRequest
Right - and that's the point. Sorry I didn't explain more, but a change
was made to the environment and request abstraction handling such that
the assumption in the wiki that you can tell whether uploads are
successfully enabled is no longer correct.
So, you'll notice in my proposed code that I ignore the type of request.
Try it and let me know what happens. If you just println inside each
condition block you'll have a major clue.
> I'm assuming that request.get(str) is functionally different from
> request.getAttribute(str) - is there an equivalent to
> request.getAtrributeNames() - I would like to verify that I'm not just
> doing something stupid, like using the wrong key on the 'get'. I'll go
> dig through the source.
First, don't confuse request attributes with parameters. Parameters are
the things that come in via GET or POST. But yes, there is an imporant
difference. Use getParameter(String key) to get at normal string
parameters. get(String key) returns Object and so has to be used to get
at uploaded Files which have been parsed by Cocoon and added to the
request parameter collection as Part objects. Use Enumeration
request.getParameterNames() (not request.getAttributeNames()! ) if you
want to check that the field is present at all.
Geoff
>>>On Thu, 2004-02-05 at 16:35, Geoff Howard wrote:
>>>
>>>
>>>>Chris Wilder-Smith wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>We're trying to use a multipart/form-data post to upload audio files
>>>>>recorded on the client machine to our cocoon-based backend. All of the
>>>>>web.xml file upload params seem to be set correctly:
>>>>>
>>>>>request-factory=org.apache.cocoon.components.request.MultipartRequestFactoryImpl
>>>>>enable-uploads=true
>>>>>upload-directory=WEB-INF/work/upload-dir
>>>>>autosave-uploads=true
>>>>>overwrite-uploads=rename
>>>>>upload-max-size=10000000
>>>>>
>>>>>
>>>>>According to the wiki pages, I should see the request type as
>>>>>MultipartHttpServletRequest when it comes through, but it is a regular
>>>>>cocoon HttpRequest. According to the example, this implies that uploads
>>>>>still aren't enabled.
>>>>>
>>>>>I do see other parameters that come through on the request, it's picking
>>>>>up the correct generator, etc.
>>>>
>>>>Which Cocoon version, which wiki page?
>>>>
>>>>Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Chris Wilder-Smith <ch...@wilder-smith.org>.
Geoff,
On Thu, 2004-02-05 at 17:23, Geoff Howard wrote:
> Chris Wilder-Smith wrote:
> > Sorry,
> >
> > Cocoon 2.1.3
> >
> > and this wiki page...
> >
> > http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithFlow
>
> 1) request-factory should be ignored in 2.1, but get rid of it in case
> it was left in for compatibility and is screwing you up. The fact that
> you have it in implies that you are basing your understanding off a mix
> of 2.0 and 2.1 documents. Make sure you read the note at the top of
> http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithCocoon, ignore
> the rest of that page and follow the link to the 2.1 specific info.
I actually tried the factory stuff after not getting anywhere the first
few times - in hopes it would help. I have been working off the 2.1
wiki pages.
> 2) Did you change web.xml in the src/webapps directory (wrong) or the
> build/webapps directory (right) or some other deployed directory
> (right)? There is also a build property in build.properties to set this
> automatically. You can run just the config changes by changing that
> setting (via local.build.properties - see INSTALL.txt) and just running
> build custom-conf. See
> http://wiki.cocoondev.org/Wiki.jsp?page=CustomConfigTarget.
We actually deploy a bit differently, via maven - but the correct
web.xml is getting deployed.
> 3) Did you restart the servlet container after editing web.xml?
Yes.
> 4) Did you say you were getting a HttpRequest? That brings up a change
> to the Request stored in the objectModel which may make that code on the
> wiki no longer work as written. Try this:
>
> Request request = ObjectModelHelper.getRequest(obj);
> Object o = request.get("blah");
> if (o == null) {
> // parameter missing from request
> } else if (o instanceof Part) {
> Part part = (Part) o;
> // do something with it
> } else if (o instanceof String) {
> // upload is disabled - I think.
> }
this is basically what I'm doing. When I print out something like this:
System.err.println(" ** request class: " +
"request.getClass().getName());
I get
** request class: org.apache.cocoon.environment.http.HttpRequest
I'm assuming that request.get(str) is functionally different from
request.getAttribute(str) - is there an equivalent to
request.getAtrributeNames() - I would like to verify that I'm not just
doing something stupid, like using the wrong key on the 'get'. I'll go
dig through the source.
Thanks for all your help!
Chris
>
> Geoff
>
> > On Thu, 2004-02-05 at 16:35, Geoff Howard wrote:
> >
> >>Chris Wilder-Smith wrote:
> >>
> >>>Hi,
> >>>
> >>>We're trying to use a multipart/form-data post to upload audio files
> >>>recorded on the client machine to our cocoon-based backend. All of the
> >>>web.xml file upload params seem to be set correctly:
> >>>
> >>>request-factory=org.apache.cocoon.components.request.MultipartRequestFactoryImpl
> >>>enable-uploads=true
> >>>upload-directory=WEB-INF/work/upload-dir
> >>>autosave-uploads=true
> >>>overwrite-uploads=rename
> >>>upload-max-size=10000000
> >>>
> >>>
> >>>According to the wiki pages, I should see the request type as
> >>>MultipartHttpServletRequest when it comes through, but it is a regular
> >>>cocoon HttpRequest. According to the example, this implies that uploads
> >>>still aren't enabled.
> >>>
> >>>I do see other parameters that come through on the request, it's picking
> >>>up the correct generator, etc.
> >>
> >>Which Cocoon version, which wiki page?
> >>
> >>Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Geoff Howard <co...@leverageweb.com>.
Chris Wilder-Smith wrote:
> Sorry,
>
> Cocoon 2.1.3
>
> and this wiki page...
>
> http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithFlow
1) request-factory should be ignored in 2.1, but get rid of it in case
it was left in for compatibility and is screwing you up. The fact that
you have it in implies that you are basing your understanding off a mix
of 2.0 and 2.1 documents. Make sure you read the note at the top of
http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithCocoon, ignore
the rest of that page and follow the link to the 2.1 specific info.
2) Did you change web.xml in the src/webapps directory (wrong) or the
build/webapps directory (right) or some other deployed directory
(right)? There is also a build property in build.properties to set this
automatically. You can run just the config changes by changing that
setting (via local.build.properties - see INSTALL.txt) and just running
build custom-conf. See
http://wiki.cocoondev.org/Wiki.jsp?page=CustomConfigTarget.
3) Did you restart the servlet container after editing web.xml?
4) Did you say you were getting a HttpRequest? That brings up a change
to the Request stored in the objectModel which may make that code on the
wiki no longer work as written. Try this:
Request request = ObjectModelHelper.getRequest(obj);
Object o = request.get("blah");
if (o == null) {
// parameter missing from request
} else if (o instanceof Part) {
Part part = (Part) o;
// do something with it
} else if (o instanceof String) {
// upload is disabled - I think.
}
Geoff
> On Thu, 2004-02-05 at 16:35, Geoff Howard wrote:
>
>>Chris Wilder-Smith wrote:
>>
>>>Hi,
>>>
>>>We're trying to use a multipart/form-data post to upload audio files
>>>recorded on the client machine to our cocoon-based backend. All of the
>>>web.xml file upload params seem to be set correctly:
>>>
>>>request-factory=org.apache.cocoon.components.request.MultipartRequestFactoryImpl
>>>enable-uploads=true
>>>upload-directory=WEB-INF/work/upload-dir
>>>autosave-uploads=true
>>>overwrite-uploads=rename
>>>upload-max-size=10000000
>>>
>>>
>>>According to the wiki pages, I should see the request type as
>>>MultipartHttpServletRequest when it comes through, but it is a regular
>>>cocoon HttpRequest. According to the example, this implies that uploads
>>>still aren't enabled.
>>>
>>>I do see other parameters that come through on the request, it's picking
>>>up the correct generator, etc.
>>
>>Which Cocoon version, which wiki page?
>>
>>Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Chris Wilder-Smith <ch...@wilder-smith.org>.
Sorry,
Cocoon 2.1.3
and this wiki page...
http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithFlow
On Thu, 2004-02-05 at 16:35, Geoff Howard wrote:
> Chris Wilder-Smith wrote:
> > Hi,
> >
> > We're trying to use a multipart/form-data post to upload audio files
> > recorded on the client machine to our cocoon-based backend. All of the
> > web.xml file upload params seem to be set correctly:
> >
> > request-factory=org.apache.cocoon.components.request.MultipartRequestFactoryImpl
> > enable-uploads=true
> > upload-directory=WEB-INF/work/upload-dir
> > autosave-uploads=true
> > overwrite-uploads=rename
> > upload-max-size=10000000
> >
> >
> > According to the wiki pages, I should see the request type as
> > MultipartHttpServletRequest when it comes through, but it is a regular
> > cocoon HttpRequest. According to the example, this implies that uploads
> > still aren't enabled.
> >
> > I do see other parameters that come through on the request, it's picking
> > up the correct generator, etc.
>
> Which Cocoon version, which wiki page?
>
> Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Multipart form upload
Posted by Geoff Howard <co...@leverageweb.com>.
Chris Wilder-Smith wrote:
> Hi,
>
> We're trying to use a multipart/form-data post to upload audio files
> recorded on the client machine to our cocoon-based backend. All of the
> web.xml file upload params seem to be set correctly:
>
> request-factory=org.apache.cocoon.components.request.MultipartRequestFactoryImpl
> enable-uploads=true
> upload-directory=WEB-INF/work/upload-dir
> autosave-uploads=true
> overwrite-uploads=rename
> upload-max-size=10000000
>
>
> According to the wiki pages, I should see the request type as
> MultipartHttpServletRequest when it comes through, but it is a regular
> cocoon HttpRequest. According to the example, this implies that uploads
> still aren't enabled.
>
> I do see other parameters that come through on the request, it's picking
> up the correct generator, etc.
Which Cocoon version, which wiki page?
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org