help pls! myfaces portlet ignoring web.xml init-params

[Jim the Standing Bear-2]

Hello,

It seems that the myfaces webapp as a portlet is not reading the
init-params defined in web.xml.  I have a myfaces webapps that uses
inputFileUpload.  While testing it as a standalone, I was able to
control the max upload size by changing the init-param in web.xml.
However, after putting everything together as a portlet war and
deploying it to gridsphere,  the file upload keeps using the default
value of 100m regardless of what web.xml says.

I have been spending hours and hours testing file uploads and this
100m seems like a curse.  Has anyone run into similar situations?
Would it be possible to initialize the max upload size within the
code?  I tried to find some info from the wiki, but didn't see
anything relevant.

I would appreciate any help!

-- Jim

[Mike Kienenberger]

Maybe the web.xml isn't valid?   Some containers are more forgiving of
errors than others.   Other containers silently ignore bad elements.
If you're still using 2.3 dtd, then order of elements is important.

On Mon, Oct 5, 2009 at 9:24 PM, Jim the Standing Bear
<standingbear@...> wrote:

> Hello,
>
> It seems that the myfaces webapp as a portlet is not reading the
> init-params defined in web.xml.  I have a myfaces webapps that uses
> inputFileUpload.  While testing it as a standalone, I was able to
> control the max upload size by changing the init-param in web.xml.
> However, after putting everything together as a portlet war and
> deploying it to gridsphere,  the file upload keeps using the default
> value of 100m regardless of what web.xml says.
>
> I have been spending hours and hours testing file uploads and this
> 100m seems like a curse.  Has anyone run into similar situations?
> Would it be possible to initialize the max upload size within the
> code?  I tried to find some info from the wiki, but didn't see
> anything relevant.
>
> I would appreciate any help!
>
> -- Jim
>

[Jim the Standing Bear-2]

Hi Mike,

Thank you for the suggestion - however, the same web.xml worked fine
as a standalone, but not as a portlet.

In the source code of tomahawk 1.1.9, there is a class
TomahawkFacesContextWrapper.java, which has a block of comments saying
the following:

 * One use that has this wrapper is in portlets (there is no PortletFilter
 * on portlet api 1.0, so to take all tomahawk advantages (components
 * that uses some javascript handled by AddResource api and fileupload
 * support) users must configure this alternative.
 * </p>
 * <p>
 * When it is used this alternative, the params used to configure
 * MultipartRequestWrapper (file upload support) are set using this
 * web.xml config params:
 * </p>
 * <ul>
 * <li>org.apache.myfaces.UPLOAD_MAX_FILE_SIZE</li>
 * <li>org.apache.myfaces.UPLOAD_THRESHOLD_SIZE</li>
 * <li>org.apache.myfaces.UPLOAD_MAX_REPOSITORY_PATH</li>
 * <li>org.apache.myfaces.UPLOAD_MAX_SIZE</li>
 * <li>org.apache.myfaces.UPLOAD_CACHE_FILE_SIZE_ERRORS</li>
 * </ul>
 *

and in ExtensionsFilter.java, I saw the following comments under init().

  public void init(FilterConfig filterConfig) {
        // Note that the code here to extract FileUpload configuration
params is not actually used.
        // The handling of multipart requests was moved from this
Filter into a custom FacesContext
        // (TomahawkFacesContextWrapper) so that Portlets could be
supported (Portlets cannot use
        // servlet filters).
        //
        // For backwards compatibility, the
TomahawkFacesContextWrapper class *parses* the
        // web.xml to retrieve these same filter config params. That
is IMO seriously ugly
        // and hopefully will be fixed.


so my interpretation is that the init() is not being used at all when
running as a portlet (please correct me if this interpretation is not
correct).

However, we are still using tomahawk v1.1.3 and tomahawk-bridge
0.9.2(?) because our jars have been customized (hacked) to work around
the issue of gridsphere naming.  And in tomahawk v1.1.3, the class
TomahawkFacesContextWrapper.java didn't exist.

Please see this blog for details on the hack/customization

http://marcus-christie.blogspot.com/2006/10/myfaces-jsf-and-gridsphere.html

I am just wondering what would happen if I upgraded to v1.1.9 - would
tomahawk-bridge 0.9.2 still work?  I don't think we can use the
portlet-bridge jar provided by apache because we are still using
gridsphere v2.1.5.

Any other suggestions/insights?  Thanks.

-- Jim

On Wed, Oct 7, 2009 at 12:58 PM, Mike Kienenberger <mkienenb@...> wrote:
> Maybe the web.xml isn't valid?

[Mike Kienenberger]

Like I said, just because it works in one container standalone doesn't
mean that it will work in a different container.

Standalone containers tend to be more forgiving and self-correcting of errors.

On Wed, Oct 7, 2009 at 1:54 PM, Jim the Standing Bear
<standingbear@...> wrote:
> Thank you for the suggestion - however, the same web.xml worked fine
> as a standalone, but not as a portlet.

[Jim the Standing Bear-2]

Hi Mike,

In that case, it is certainly worth finding out.  Could you please
give me a pointer or two how to go about verifying that?  Thanks!

-- Jim

[Mike Kienenberger]

Yes, there's no guarantee this will be the problem, but it's the only
thing I can think of.

Most xml editors and IDEs have the ability to automatically validate
xml, so just pick one.

If you do a search for "online xml validator", you probably will be
able to find something if you don't already have a local application.

This is most likely going to be a problem if your web.xml file starts
with a 2.3 dtd rather than a 2.4 xsd since dtd files are
order-dependent. but xsd files can be order independent.

<!DOCTYPE web-app PUBLIC
  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
  "http://java.sun.com/dtd/web-app_2_3.dtd">

vs

<web-app id="WebApp_9" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">


On Wed, Oct 7, 2009 at 3:05 PM, Jim the Standing Bear
<standingbear@...> wrote:
> Hi Mike,
>
> In that case, it is certainly worth finding out.  Could you please
> give me a pointer or two how to go about verifying that?  Thanks!
>
> -- Jim
>

[Jim the Standing Bear-2]

Hi Mike,

The web.xml turned out to be valid, so I must look else where to find
out exactly what the problem is.  There doesn't seem to be any log
statements in the init() method, so there is no way to see what params
it ingested or if it ingested any params at all.

-- Jim

On Wed, Oct 7, 2009 at 3:15 PM, Mike Kienenberger <mkienenb@...> wrote:

> Yes, there's no guarantee this will be the problem, but it's the only
> thing I can think of.
>
> Most xml editors and IDEs have the ability to automatically validate
> xml, so just pick one.
>
> If you do a search for "online xml validator", you probably will be
> able to find something if you don't already have a local application.
>
> This is most likely going to be a problem if your web.xml file starts
> with a 2.3 dtd rather than a 2.4 xsd since dtd files are
> order-dependent. but xsd files can be order independent.
>
> <!DOCTYPE web-app PUBLIC
>  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>  "http://java.sun.com/dtd/web-app_2_3.dtd">
>
> vs
>
> <web-app id="WebApp_9" version="2.4"
> xmlns="http://java.sun.com/xml/ns/j2ee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
>
>
> On Wed, Oct 7, 2009 at 3:05 PM, Jim the Standing Bear
> <standingbear@...> wrote:
>> Hi Mike,
>>
>> In that case, it is certainly worth finding out.  Could you please
>> give me a pointer or two how to go about verifying that?  Thanks!
>>
>> -- Jim
>>
>

--
--------------------------------------
Standing Bear Has Spoken
--------------------------------------

[Leonardo Uribe]

Hi

Take a look at

http://issues.apache.org/jira/browse/TOMAHAWK-1381

specially this resource:

http://issues.apache.org/jira/secure/attachment/12410100/testUsedForSolveTOMAHAWK1381.zip

This zip has a simple test for file upload portlet and filter case. Also shows how to configure them correctly. I hope this helps.

regards

Leonardo Uribe

2009/10/7 Jim the Standing Bear <standingbear@...>

Hi Mike,

The web.xml turned out to be valid, so I must look else where to find
out exactly what the problem is.  There doesn't seem to be any log
statements in the init() method, so there is no way to see what params
it ingested or if it ingested any params at all.

-- Jim

On Wed, Oct 7, 2009 at 3:15 PM, Mike Kienenberger <mkienenb@...> wrote:
> Yes, there's no guarantee this will be the problem, but it's the only
> thing I can think of.
>
> Most xml editors and IDEs have the ability to automatically validate
> xml, so just pick one.
>
> If you do a search for "online xml validator", you probably will be
> able to find something if you don't already have a local application.
>
> This is most likely going to be a problem if your web.xml file starts
> with a 2.3 dtd rather than a 2.4 xsd since dtd files are
> order-dependent. but xsd files can be order independent.
>
> <!DOCTYPE web-app PUBLIC
>  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>  "http://java.sun.com/dtd/web-app_2_3.dtd">
>
> vs
>
> <web-app id="WebApp_9" version="2.4"
> xmlns="http://java.sun.com/xml/ns/j2ee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
>
>
> On Wed, Oct 7, 2009 at 3:05 PM, Jim the Standing Bear
> <standingbear@...> wrote:
>> Hi Mike,
>>
>> In that case, it is certainly worth finding out.  Could you please
>> give me a pointer or two how to go about verifying that?  Thanks!
>>
>> -- Jim
>>
>

--
--------------------------------------
Standing Bear Has Spoken
--------------------------------------

[Jim the Standing Bear-2]

Hi Leonardo,

Thank you for pointing me to the JIRA, however, I am not sure if this
applies to our situation because we are still using myfaces 1.1.4 with
tomahawk 1.1.3.  This JIRA issue seems to affect some later versions.
 To make the matters worse, our myfaces jar as well as the original
tomahawk-bridge jar were patched to fix the gridsphere namespace
issues since we are stuck with gridsphere v2.1.x.  See
http://issues.apache.org/jira/browse/MYFACES-1358

I am not an expert in this area (portals, gridsphere etc), but I found
out that in tomahawk-bridge v.0.9.1,  the PortletFilterConfig object
passed to ExtensionsPorletFilter.init() method contains no init params
at all, and thus it defaults to the 100MB.  To find out why this is
the case, I need to look into portals-bridges jar.

I am pretty sure these issues had gone away with the more recent
versions of myfaces, only that our odd situation prevents us from
upgrading. :-S

-- Jim