You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "ZHENG Zhong (JIRA)" <pl...@jakarta.apache.org> on 2005/08/04 14:07:34 UTC
[jira] Created: (PLUTO-151) New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
--------------------------------------------------------------------------------------------------------------
Key: PLUTO-151
URL: http://issues.apache.org/jira/browse/PLUTO-151
Project: Pluto
Type: Improvement
Components: portlet container
Versions: 1.1.0-ALPHA
Reporter: ZHENG Zhong
Attachments: pluto-container-core-modif.zip
I made some changes in the org.apache.pluto.core and org.apache.pluto.core.impl packages to implement the new hierarchy and resolve the PortletRequestDispatcher problem (I think this problem may be resolved in a better way). Here is a summary of all the changes I made:
InternalActionRequest and InternalRenderRequest both extends interface InternalPortletRequest. Methods setIncluded() and isIncluded() are moved to InternalRenderRequest. New method setAppendedParams() is added (request parameters are only appended when we do a dispatching, like the included flag, so i think it will be better to put the included methods and the appended parameters method together).
PortletRequestImpl is updated to remove all included-related methods. It does no longer check the included flag (because it does no longer have that flag). RenderRequestImpl is updated to implement the setIncluded() , isIncluded() and addAppendedParams() methods. It also checks the included flag to behave differently by overwriting its parent's method (like getContentType(), getContentLength() , getParameterMap(), etc.)
The same thing also happens to InternalPortletResponse, InternalActionResponse, InternalRenderResponse, PortletResponseImpl, ActionResponseImpl and RenderResponseImpl.
PortletRequestDispatcherImpl is updated. Now it does not need to create IncludedRenderRequestImpl any more (that class may be deleted since all its functionalities are integrated in the RenderRequestImpl class). Instead, it uses the InternalRenderRequest interface and add appended parameters to it.
For the InternalPortletRequest interface, methods getPortletContainer() and getHttpServletRequest() do not need to be declared. They will never be called.
Some other changes include:
In class PortletRequestImpl, method getWindow() is removed since it is a duplicate method of getInternalPortletWindow().
Added some javadocs, and some @see tags.
I rebuilt Pluto with all the changes above, and then tested all the testsuite. They all work well (except the last test in the left portlet. It fails just because resource bundle is not defined in portlet.xml for it.)
Regards
ZHENG Zhong
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (PLUTO-151) New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
Posted by "David DeWolf (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-151?page=comments#action_12317636 ]
David DeWolf commented on PLUTO-151:
------------------------------------
Would you please post these changes as svn diffs. I appreciate the patch!.
> New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
> --------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-151
> URL: http://issues.apache.org/jira/browse/PLUTO-151
> Project: Pluto
> Type: Improvement
> Components: portlet container
> Versions: 1.1.0-ALPHA
> Reporter: ZHENG Zhong
> Attachments: pluto-container-core-modif.zip
>
> I made some changes in the org.apache.pluto.core and org.apache.pluto.core.impl packages to implement the new hierarchy and resolve the PortletRequestDispatcher problem (I think this problem may be resolved in a better way). Here is a summary of all the changes I made:
> InternalActionRequest and InternalRenderRequest both extends interface InternalPortletRequest. Methods setIncluded() and isIncluded() are moved to InternalRenderRequest. New method setAppendedParams() is added (request parameters are only appended when we do a dispatching, like the included flag, so i think it will be better to put the included methods and the appended parameters method together).
> PortletRequestImpl is updated to remove all included-related methods. It does no longer check the included flag (because it does no longer have that flag). RenderRequestImpl is updated to implement the setIncluded() , isIncluded() and addAppendedParams() methods. It also checks the included flag to behave differently by overwriting its parent's method (like getContentType(), getContentLength() , getParameterMap(), etc.)
> The same thing also happens to InternalPortletResponse, InternalActionResponse, InternalRenderResponse, PortletResponseImpl, ActionResponseImpl and RenderResponseImpl.
> PortletRequestDispatcherImpl is updated. Now it does not need to create IncludedRenderRequestImpl any more (that class may be deleted since all its functionalities are integrated in the RenderRequestImpl class). Instead, it uses the InternalRenderRequest interface and add appended parameters to it.
> For the InternalPortletRequest interface, methods getPortletContainer() and getHttpServletRequest() do not need to be declared. They will never be called.
> Some other changes include:
> In class PortletRequestImpl, method getWindow() is removed since it is a duplicate method of getInternalPortletWindow().
> Added some javadocs, and some @see tags.
> I rebuilt Pluto with all the changes above, and then tested all the testsuite. They all work well (except the last test in the left portlet. It fails just because resource bundle is not defined in portlet.xml for it.)
> Regards
> ZHENG Zhong
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (PLUTO-151) New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
Posted by "ZHENG Zhong (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-151?page=all ]
ZHENG Zhong updated PLUTO-151:
------------------------------
Attachment: pluto-container-core-modif.zip
Attachment including all the changes i've made. Just unzip it to the pluto container subproject's src/main/java/org/apache/pluto/core directory.
> New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
> --------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-151
> URL: http://issues.apache.org/jira/browse/PLUTO-151
> Project: Pluto
> Type: Improvement
> Components: portlet container
> Versions: 1.1.0-ALPHA
> Reporter: ZHENG Zhong
> Attachments: pluto-container-core-modif.zip
>
> I made some changes in the org.apache.pluto.core and org.apache.pluto.core.impl packages to implement the new hierarchy and resolve the PortletRequestDispatcher problem (I think this problem may be resolved in a better way). Here is a summary of all the changes I made:
> InternalActionRequest and InternalRenderRequest both extends interface InternalPortletRequest. Methods setIncluded() and isIncluded() are moved to InternalRenderRequest. New method setAppendedParams() is added (request parameters are only appended when we do a dispatching, like the included flag, so i think it will be better to put the included methods and the appended parameters method together).
> PortletRequestImpl is updated to remove all included-related methods. It does no longer check the included flag (because it does no longer have that flag). RenderRequestImpl is updated to implement the setIncluded() , isIncluded() and addAppendedParams() methods. It also checks the included flag to behave differently by overwriting its parent's method (like getContentType(), getContentLength() , getParameterMap(), etc.)
> The same thing also happens to InternalPortletResponse, InternalActionResponse, InternalRenderResponse, PortletResponseImpl, ActionResponseImpl and RenderResponseImpl.
> PortletRequestDispatcherImpl is updated. Now it does not need to create IncludedRenderRequestImpl any more (that class may be deleted since all its functionalities are integrated in the RenderRequestImpl class). Instead, it uses the InternalRenderRequest interface and add appended parameters to it.
> For the InternalPortletRequest interface, methods getPortletContainer() and getHttpServletRequest() do not need to be declared. They will never be called.
> Some other changes include:
> In class PortletRequestImpl, method getWindow() is removed since it is a duplicate method of getInternalPortletWindow().
> Added some javadocs, and some @see tags.
> I rebuilt Pluto with all the changes above, and then tested all the testsuite. They all work well (except the last test in the left portlet. It fails just because resource bundle is not defined in portlet.xml for it.)
> Regards
> ZHENG Zhong
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (PLUTO-151) New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
Posted by "ZHENG Zhong (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-151?page=comments#action_12317811 ]
ZHENG Zhong commented on PLUTO-151:
-----------------------------------
How about this solution:
Based on the patch I attached, in class RenderRequestImpl, modify the constructor as well as setIncluded() and addAppendedParameters():
public RenderRequestImpl(PortletContainer container,
InternalPortletWindow internalPortletWindow,
HttpServletRequest servletRequest) {
super(container, internalPortletWindow, servletRequest);
}
/**
* Add appended parameters. Parameters can only be appended when the render request is included
* in a dispatch.
* @throws IllegalStateException if this method is called while the included flag is not set to true.
*/
public void addAppendedParams(Map params) {
if (!included) {
throw new IllegalStateException("Cannot add parameters when render request is not included.");
}
if (params != null) {
queryParams.putAll(params);
}
}
/**
* When the render request is set to be included in a dispatch, copy all parameters from its parent.
* When the render request is out of the included scope, clear the query parameters.
*/
public void setIncluded(boolean included) {
this.included = included;
if (included) {
queryParams = new HashMap(super.getParameterMap());
} else {
queryParams = null;
}
Sorry but I don't have svn installed on this machine.
Regards
ZHENG Zhong
> New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
> --------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-151
> URL: http://issues.apache.org/jira/browse/PLUTO-151
> Project: Pluto
> Type: Improvement
> Components: portlet container
> Versions: 1.1.0-ALPHA
> Reporter: ZHENG Zhong
> Attachments: pluto-container-core-modif.zip, svndiff-container-core.zip
>
> I made some changes in the org.apache.pluto.core and org.apache.pluto.core.impl packages to implement the new hierarchy and resolve the PortletRequestDispatcher problem (I think this problem may be resolved in a better way). Here is a summary of all the changes I made:
> InternalActionRequest and InternalRenderRequest both extends interface InternalPortletRequest. Methods setIncluded() and isIncluded() are moved to InternalRenderRequest. New method setAppendedParams() is added (request parameters are only appended when we do a dispatching, like the included flag, so i think it will be better to put the included methods and the appended parameters method together).
> PortletRequestImpl is updated to remove all included-related methods. It does no longer check the included flag (because it does no longer have that flag). RenderRequestImpl is updated to implement the setIncluded() , isIncluded() and addAppendedParams() methods. It also checks the included flag to behave differently by overwriting its parent's method (like getContentType(), getContentLength() , getParameterMap(), etc.)
> The same thing also happens to InternalPortletResponse, InternalActionResponse, InternalRenderResponse, PortletResponseImpl, ActionResponseImpl and RenderResponseImpl.
> PortletRequestDispatcherImpl is updated. Now it does not need to create IncludedRenderRequestImpl any more (that class may be deleted since all its functionalities are integrated in the RenderRequestImpl class). Instead, it uses the InternalRenderRequest interface and add appended parameters to it.
> For the InternalPortletRequest interface, methods getPortletContainer() and getHttpServletRequest() do not need to be declared. They will never be called.
> Some other changes include:
> In class PortletRequestImpl, method getWindow() is removed since it is a duplicate method of getInternalPortletWindow().
> Added some javadocs, and some @see tags.
> I rebuilt Pluto with all the changes above, and then tested all the testsuite. They all work well (except the last test in the left portlet. It fails just because resource bundle is not defined in portlet.xml for it.)
> Regards
> ZHENG Zhong
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (PLUTO-151) New class hierarchy to implement
portlet request and response, and resolve the dispatching parameters
problem.
Posted by "ZHENG Zhong (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-151?page=all ]
ZHENG Zhong updated PLUTO-151:
------------------------------
Assign To: ZHENG Zhong
> New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
> --------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-151
> URL: http://issues.apache.org/jira/browse/PLUTO-151
> Project: Pluto
> Type: Improvement
> Components: portlet container
> Versions: 1.1.0-alpha1
> Reporter: @deprecated ZHENG Zhong
> Assignee: ZHENG Zhong
> Fix For: 1.1.0
> Attachments: pluto-container-core-modif.zip, svndiff-container-core.zip
>
> I made some changes in the org.apache.pluto.core and org.apache.pluto.core.impl packages to implement the new hierarchy and resolve the PortletRequestDispatcher problem (I think this problem may be resolved in a better way). Here is a summary of all the changes I made:
> InternalActionRequest and InternalRenderRequest both extends interface InternalPortletRequest. Methods setIncluded() and isIncluded() are moved to InternalRenderRequest. New method setAppendedParams() is added (request parameters are only appended when we do a dispatching, like the included flag, so i think it will be better to put the included methods and the appended parameters method together).
> PortletRequestImpl is updated to remove all included-related methods. It does no longer check the included flag (because it does no longer have that flag). RenderRequestImpl is updated to implement the setIncluded() , isIncluded() and addAppendedParams() methods. It also checks the included flag to behave differently by overwriting its parent's method (like getContentType(), getContentLength() , getParameterMap(), etc.)
> The same thing also happens to InternalPortletResponse, InternalActionResponse, InternalRenderResponse, PortletResponseImpl, ActionResponseImpl and RenderResponseImpl.
> PortletRequestDispatcherImpl is updated. Now it does not need to create IncludedRenderRequestImpl any more (that class may be deleted since all its functionalities are integrated in the RenderRequestImpl class). Instead, it uses the InternalRenderRequest interface and add appended parameters to it.
> For the InternalPortletRequest interface, methods getPortletContainer() and getHttpServletRequest() do not need to be declared. They will never be called.
> Some other changes include:
> In class PortletRequestImpl, method getWindow() is removed since it is a duplicate method of getInternalPortletWindow().
> Added some javadocs, and some @see tags.
> I rebuilt Pluto with all the changes above, and then tested all the testsuite. They all work well (except the last test in the left portlet. It fails just because resource bundle is not defined in portlet.xml for it.)
> Regards
> ZHENG Zhong
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (PLUTO-151) New class hierarchy to implement
portlet request and response, and resolve the dispatching parameters
problem.
Posted by "ZHENG Zhong (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-151?page=all ]
ZHENG Zhong resolved PLUTO-151:
-------------------------------
Resolution: Fixed
Done.
> New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
> --------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-151
> URL: http://issues.apache.org/jira/browse/PLUTO-151
> Project: Pluto
> Type: Improvement
> Components: portlet container
> Versions: 1.1.0-alpha1
> Reporter: @deprecated ZHENG Zhong
> Assignee: ZHENG Zhong
> Fix For: 1.1.0
> Attachments: pluto-container-core-modif.zip, svndiff-container-core.zip
>
> I made some changes in the org.apache.pluto.core and org.apache.pluto.core.impl packages to implement the new hierarchy and resolve the PortletRequestDispatcher problem (I think this problem may be resolved in a better way). Here is a summary of all the changes I made:
> InternalActionRequest and InternalRenderRequest both extends interface InternalPortletRequest. Methods setIncluded() and isIncluded() are moved to InternalRenderRequest. New method setAppendedParams() is added (request parameters are only appended when we do a dispatching, like the included flag, so i think it will be better to put the included methods and the appended parameters method together).
> PortletRequestImpl is updated to remove all included-related methods. It does no longer check the included flag (because it does no longer have that flag). RenderRequestImpl is updated to implement the setIncluded() , isIncluded() and addAppendedParams() methods. It also checks the included flag to behave differently by overwriting its parent's method (like getContentType(), getContentLength() , getParameterMap(), etc.)
> The same thing also happens to InternalPortletResponse, InternalActionResponse, InternalRenderResponse, PortletResponseImpl, ActionResponseImpl and RenderResponseImpl.
> PortletRequestDispatcherImpl is updated. Now it does not need to create IncludedRenderRequestImpl any more (that class may be deleted since all its functionalities are integrated in the RenderRequestImpl class). Instead, it uses the InternalRenderRequest interface and add appended parameters to it.
> For the InternalPortletRequest interface, methods getPortletContainer() and getHttpServletRequest() do not need to be declared. They will never be called.
> Some other changes include:
> In class PortletRequestImpl, method getWindow() is removed since it is a duplicate method of getInternalPortletWindow().
> Added some javadocs, and some @see tags.
> I rebuilt Pluto with all the changes above, and then tested all the testsuite. They all work well (except the last test in the left portlet. It fails just because resource bundle is not defined in portlet.xml for it.)
> Regards
> ZHENG Zhong
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (PLUTO-151) New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
Posted by "ZHENG Zhong (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-151?page=all ]
ZHENG Zhong updated PLUTO-151:
------------------------------
Attachment: svndiff-container-core.zip
svndiff files for org.apache.pluto.core and org.apache.pluto.core.impl, as well as some new classes i added (with extension .java).
Class IncludedRenderRequestImpl.java is removed.
Also, PortletContextImpl.parseQueryParams() is updated to allow parameters of the same name.
Regards.
ZHENG Zhong
> New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
> --------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-151
> URL: http://issues.apache.org/jira/browse/PLUTO-151
> Project: Pluto
> Type: Improvement
> Components: portlet container
> Versions: 1.1.0-ALPHA
> Reporter: ZHENG Zhong
> Attachments: pluto-container-core-modif.zip, svndiff-container-core.zip
>
> I made some changes in the org.apache.pluto.core and org.apache.pluto.core.impl packages to implement the new hierarchy and resolve the PortletRequestDispatcher problem (I think this problem may be resolved in a better way). Here is a summary of all the changes I made:
> InternalActionRequest and InternalRenderRequest both extends interface InternalPortletRequest. Methods setIncluded() and isIncluded() are moved to InternalRenderRequest. New method setAppendedParams() is added (request parameters are only appended when we do a dispatching, like the included flag, so i think it will be better to put the included methods and the appended parameters method together).
> PortletRequestImpl is updated to remove all included-related methods. It does no longer check the included flag (because it does no longer have that flag). RenderRequestImpl is updated to implement the setIncluded() , isIncluded() and addAppendedParams() methods. It also checks the included flag to behave differently by overwriting its parent's method (like getContentType(), getContentLength() , getParameterMap(), etc.)
> The same thing also happens to InternalPortletResponse, InternalActionResponse, InternalRenderResponse, PortletResponseImpl, ActionResponseImpl and RenderResponseImpl.
> PortletRequestDispatcherImpl is updated. Now it does not need to create IncludedRenderRequestImpl any more (that class may be deleted since all its functionalities are integrated in the RenderRequestImpl class). Instead, it uses the InternalRenderRequest interface and add appended parameters to it.
> For the InternalPortletRequest interface, methods getPortletContainer() and getHttpServletRequest() do not need to be declared. They will never be called.
> Some other changes include:
> In class PortletRequestImpl, method getWindow() is removed since it is a duplicate method of getInternalPortletWindow().
> Added some javadocs, and some @see tags.
> I rebuilt Pluto with all the changes above, and then tested all the testsuite. They all work well (except the last test in the left portlet. It fails just because resource bundle is not defined in portlet.xml for it.)
> Regards
> ZHENG Zhong
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (PLUTO-151) New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
Posted by "ZHENG Zhong (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-151?page=comments#action_12317797 ]
ZHENG Zhong commented on PLUTO-151:
-----------------------------------
Hi,
I think there may be a problem in the patch: when dispatching, the appended parameters should exist only in the dispatching scope. That is to say, if I create two PortletRequestDispatcher instances and dispatch two times the same request and response, appended parameters in the first dispatcher should not appear in the second dispatcher.
But in the patch, appended parameters are injected directly into the internal render request, they will always stay there, even when the internal render request is out of the dispatching scope.
One solution may be that we add back the IncludedRenderRequest class. But I don't consider that to be a good solution, because I think the appended parameters and the included flag should not be separated in two different classes.
I will manage to fix the class RenderRequestImpl to resolve that problem in a more beautiful way, when I have time.
Regards.
ZHENG Zhong
> New class hierarchy to implement portlet request and response, and resolve the dispatching parameters problem.
> --------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-151
> URL: http://issues.apache.org/jira/browse/PLUTO-151
> Project: Pluto
> Type: Improvement
> Components: portlet container
> Versions: 1.1.0-ALPHA
> Reporter: ZHENG Zhong
> Attachments: pluto-container-core-modif.zip, svndiff-container-core.zip
>
> I made some changes in the org.apache.pluto.core and org.apache.pluto.core.impl packages to implement the new hierarchy and resolve the PortletRequestDispatcher problem (I think this problem may be resolved in a better way). Here is a summary of all the changes I made:
> InternalActionRequest and InternalRenderRequest both extends interface InternalPortletRequest. Methods setIncluded() and isIncluded() are moved to InternalRenderRequest. New method setAppendedParams() is added (request parameters are only appended when we do a dispatching, like the included flag, so i think it will be better to put the included methods and the appended parameters method together).
> PortletRequestImpl is updated to remove all included-related methods. It does no longer check the included flag (because it does no longer have that flag). RenderRequestImpl is updated to implement the setIncluded() , isIncluded() and addAppendedParams() methods. It also checks the included flag to behave differently by overwriting its parent's method (like getContentType(), getContentLength() , getParameterMap(), etc.)
> The same thing also happens to InternalPortletResponse, InternalActionResponse, InternalRenderResponse, PortletResponseImpl, ActionResponseImpl and RenderResponseImpl.
> PortletRequestDispatcherImpl is updated. Now it does not need to create IncludedRenderRequestImpl any more (that class may be deleted since all its functionalities are integrated in the RenderRequestImpl class). Instead, it uses the InternalRenderRequest interface and add appended parameters to it.
> For the InternalPortletRequest interface, methods getPortletContainer() and getHttpServletRequest() do not need to be declared. They will never be called.
> Some other changes include:
> In class PortletRequestImpl, method getWindow() is removed since it is a duplicate method of getInternalPortletWindow().
> Added some javadocs, and some @see tags.
> I rebuilt Pluto with all the changes above, and then tested all the testsuite. They all work well (except the last test in the left portlet. It fails just because resource bundle is not defined in portlet.xml for it.)
> Regards
> ZHENG Zhong
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira