You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Dave Newton <ne...@yahoo.com> on 2008/01/19 17:29:26 UTC
Fileupload dependency, https://issues.apache.org/struts/browse/WW-2446
The <s:file.../> tag depends on an upload dependency being in place.
The default S2 configuration uses commons-fileupload, which won't work with
the standard distribution, because we don't include fileupload.
If we don't want to ship fileupload, then we should not make the default S2
configuration use it, because anybody using <s:file.../> will experience
failure at run-time because of the missing dependency.
AFAIK this is the only situation in S2 where something provided in the
standard distro that isn't a plugin simply won't work until another
dependency is satisfied.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fileupload dependency, https://issues.apache.org/struts/browse/WW-2446
Posted by Dave Newton <ne...@yahoo.com>.
--- James Mitchell <jm...@apache.org> wrote:
> (I renamed the subject to attract the attention of any devs who would
> likely have something to say about increasing the size of the distribution,
> but are probably not following this discussion)
Looks the same.
> I could be wrong (it's happened in the past, rarely :) , but that setting
> is not an out-of-the-box configuration. It is simply a default setting
> as to which multipart request impl to use.
Meh; "default" means "out-of-the-box" to me.
> If you create a Struts project and you drop in a <s:file> tag so that you
> can have file uploading in your app. To me this means that you have
> "decided" to use File Upload functionality which (again, to me) is the
> same as "deciding" to use jasper reports or "deciding" to use the jsf
> plugin.
If file uploading required the conscious decision to use a specific plugin,
I'd agree. But it doesn't, as it stands now. The way things stand now (modulo
your new file upload interceptor comment documentation) there's nothing in
the documentation that implies anything special must be done to support a
common-enough usecase.
> I think the confusion here is because file upload should be pulled into
> it's own plugin.
That's fine, although I still have to agree with Antonio that uploading a
file is common enough that it *should* work out of the the box without
additional dependencies. Pulling it in to a plugin would at least make it
clear that S2 doesn't support file uploading out of the box.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fileupload dependency, https://issues.apache.org/struts/browse/WW-2446
Posted by James Mitchell <jm...@apache.org>.
(I renamed the subject to attract the attention of any devs who would likely
have something to say about increasing the size of the distribution, but are
probably not following this discussion)
I could be wrong (it's happened in the past, rarely :) , but that setting is
not an out-of-the-box configuration. It is simply a default setting as to
which multipart request impl to use.
If you create a Struts project and you drop in a <s:file> tag so that you can
have file uploading in your app. To me this means that you have "decided"
to use File Upload functionality which (again, to me) is the same as
"deciding" to use jasper reports or "deciding" to use the jsf plugin. Just
because the code for JakartaMultiPartRequest hasn't been pulled out into
a plugin yet doesn't change the fact that it is an optional dependency.
Also, if you change the properties to use 'pell', then you will see a similar
run-time exception. Seeing the exception, if you add the struts2-pell-multi-
part-plugin.jar you will still not be able use it. Why?
### Here's the important part ###
-- because the dependency on Pell (from the s2 pell plugin) assumes that
you have already added it to your project (<scope>provided</scope>).
Effectively, this means that you have to tell your [whatever-build-tool-
you-use] that you want to use those jars and you also must either download
them auto-matically (via Maven, Ant<get>, Ivy, whatever).
I think the confusion here is because file upload should be pulled into
it's own plugin.
On Jan 19, 2008 11:51 AM, Dave Newton <ne...@yahoo.com> wrote:
> You asked that the discussion be moved to struts-dev, so I did.
>
> S2 *does* have an out-of-the-box configuration; it's in default.properties.
> It uses commons-fileupload, and it won't fail until runtime when using
> <s:file.../>.
>
> While your comment added to the upload interceptor is useful, it should be in
> a {note} that says something along the lines of "the S2 <s:file...> tag will
> not work until you've downloaded the default commons-fileupload dependency"
> and added to the "how do we upload files?" FAQ entry.
>
> This isn't a compile-time dependency; I'll get a runtime error as soon as I
> use <s:file.../> with the default stack (that includes the interceptor).
>
> d.
>
>
> --- James Mitchell <jm...@gmail.com> wrote:
>
> > My comments on this can be found here:
> > https://issues.apache.org/struts/browse/WW-2446
> >
> > On Jan 19, 2008 11:29 AM, Dave Newton <ne...@yahoo.com> wrote:
> > > The <s:file.../> tag depends on an upload dependency being in place.
> > >
> > > The default S2 configuration uses commons-fileupload, which won't work
> > with
> > > the standard distribution, because we don't include fileupload.
> > >
> > > If we don't want to ship fileupload, then we should not make the default
> > S2
> > > configuration use it, because anybody using <s:file.../> will experience
> > > failure at run-time because of the missing dependency.
> > >
> > > AFAIK this is the only situation in S2 where something provided in the
> > > standard distro that isn't a plugin simply won't work until another
> > > dependency is satisfied.
> > >
> > > d.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> >
> > --
> > James Mitchell
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
James Mitchell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fileupload dependency, https://issues.apache.org/struts/browse/WW-2446
Posted by Dave Newton <ne...@yahoo.com>.
You asked that the discussion be moved to struts-dev, so I did.
S2 *does* have an out-of-the-box configuration; it's in default.properties.
It uses commons-fileupload, and it won't fail until runtime when using
<s:file.../>.
While your comment added to the upload interceptor is useful, it should be in
a {note} that says something along the lines of "the S2 <s:file...> tag will
not work until you've downloaded the default commons-fileupload dependency"
and added to the "how do we upload files?" FAQ entry.
This isn't a compile-time dependency; I'll get a runtime error as soon as I
use <s:file.../> with the default stack (that includes the interceptor).
d.
--- James Mitchell <jm...@gmail.com> wrote:
> My comments on this can be found here:
> https://issues.apache.org/struts/browse/WW-2446
>
> On Jan 19, 2008 11:29 AM, Dave Newton <ne...@yahoo.com> wrote:
> > The <s:file.../> tag depends on an upload dependency being in place.
> >
> > The default S2 configuration uses commons-fileupload, which won't work
> with
> > the standard distribution, because we don't include fileupload.
> >
> > If we don't want to ship fileupload, then we should not make the default
> S2
> > configuration use it, because anybody using <s:file.../> will experience
> > failure at run-time because of the missing dependency.
> >
> > AFAIK this is the only situation in S2 where something provided in the
> > standard distro that isn't a plugin simply won't work until another
> > dependency is satisfied.
> >
> > d.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> James Mitchell
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fileupload dependency, https://issues.apache.org/struts/browse/WW-2446
Posted by James Mitchell <jm...@gmail.com>.
My comments on this can be found here:
https://issues.apache.org/struts/browse/WW-2446
On Jan 19, 2008 11:29 AM, Dave Newton <ne...@yahoo.com> wrote:
> The <s:file.../> tag depends on an upload dependency being in place.
>
> The default S2 configuration uses commons-fileupload, which won't work with
> the standard distribution, because we don't include fileupload.
>
> If we don't want to ship fileupload, then we should not make the default S2
> configuration use it, because anybody using <s:file.../> will experience
> failure at run-time because of the missing dependency.
>
> AFAIK this is the only situation in S2 where something provided in the
> standard distro that isn't a plugin simply won't work until another
> dependency is satisfied.
>
> d.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
James Mitchell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org