[jira] [Commented] (PLUTO-784) When a portlet is maximized portlets after it are still visible
[ https://issues.apache.org/jira/browse/PLUTO-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460458#comment-17460458 ] Mehdi Javan commented on PLUTO-784: --- [~ngriffin7a] thank you for the response :) > When a portlet is maximized portlets after it are still visible > --- > > Key: PLUTO-784 > URL: https://issues.apache.org/jira/browse/PLUTO-784 > Project: Pluto > Issue Type: Bug > Components: portlet container >Affects Versions: 3.1.0 > Environment: Chrome 78 >Reporter: Mehdi Javan >Assignee: Neil Griffin >Priority: Major > Attachments: image-2019-12-11-11-21-04-421.png, > image-2019-12-11-11-21-18-565.png > > > For example, on the following page, if *PH Color Selection Portlet* is > maximized two other portlets are still visible; see the next image below. > My expectation is that the maximized portlet fit to the whole page and all > the other portlets are hidden. > !image-2019-12-11-11-21-18-565.png! > > !image-2019-12-11-11-21-04-421.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (PLUTO-781) PortletRequestDispatcherImpl forwards to incorrect path
[
https://issues.apache.org/jira/browse/PLUTO-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460384#comment-17460384
]
Neil Griffin commented on PLUTO-781:
Detailed test failures:
{noformat}
V2DispatcherTests5_SPEC2_19_IncThenForwardServletResource_invoke7 results:
Test Failed
Details: In a servlet forwarded to by the target of an include, the path
elements of the request object exposed to the target servlet must reflect the
path used to obtain the RequestDispatcher. Error:
"/DispatcherTests5_SPEC2_19_IncThenForwardServletResource_servlet"from
getServletPath does not equal "/IncluderForwarderServlet" from origin.
V2DispatcherTests6_SPEC2_19_FwdThenForwardServletResource_invoke7 results:
Test Failed
Details: In a servlet forwarded to by the target of a forward, the path
elements of the request object exposed to the target servlet must reflect the
path used to obtain the RequestDispatcher. Error:
"/DispatcherTests6_SPEC2_19_FwdThenForwardServletResource_servlet"from
getServletPath does not equal "/IncluderForwarderServlet" from origin.
{noformat}
> PortletRequestDispatcherImpl forwards to incorrect path
> ---
>
> Key: PLUTO-781
> URL: https://issues.apache.org/jira/browse/PLUTO-781
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
>Affects Versions: 3.0.1
> Environment: Pluto Container 3.0.1, Spring 4.0.9.RELEASE, Wildfly
> 14.0.1
>Reporter: Steve Potter
>Assignee: Neil Griffin
>Priority: Major
> Fix For: 3.1.2
>
> Attachments: pluto-debug.txt, test-portlet-mvc.zip, test-portlet.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a serveResource method forwards to a servlet which then forwards to a
> jsp, the HttpServletPortletRequestWrapper provides the path from the first
> forward rather than the second forward and the jsp is not rendered.
> This is the process used by Spring Portlet MVC to locate JSP 'views'
> resulting in the failure of all our portlets when trying to serve JSP's in
> response to resource requests.
> The attached file contains a DEBUG log of the processing flow attempting to
> serve '/WEB-INF/jsp/resource2.jsp' in response to a resource request.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (PLUTO-781) PortletRequestDispatcherImpl forwards to incorrect path
[
https://issues.apache.org/jira/browse/PLUTO-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin closed PLUTO-781.
--
Resolution: Fixed
@[~riverbed2]: Thanks so much for reporting this issue, and for being so
patient. I apologize that it has taken so long to incorporate a fix for this
issue.
When I changed the one line of code in HttpServletPortletRequestWrapper.java
and ran the Portlet 3.0 TCK, it caused the following test failures:
- V2DispatcherTests5_SPEC2_19_IncThenForwardServletResource_invoke7
- V2DispatcherTests6_SPEC2_19_FwdThenForwardServletResource_invoke7
So instead, I decided to make the fix an "opt-in" and implemented it as an
init-param, so that it could be enabled on a per-portlet basis:
{code:xml|title=WEB-INF/portlet.xml}
org.apache.pluto.enable.nested.resource.forwards
true
{code}
For more information, see commit [b06210fa513c25503607204c7df56e728093bf92|
https://github.com/apache/portals-pluto/commit/b06210fa513c25503607204c7df56e728093bf92].
> PortletRequestDispatcherImpl forwards to incorrect path
> ---
>
> Key: PLUTO-781
> URL: https://issues.apache.org/jira/browse/PLUTO-781
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
>Affects Versions: 3.0.1
> Environment: Pluto Container 3.0.1, Spring 4.0.9.RELEASE, Wildfly
> 14.0.1
>Reporter: Steve Potter
>Assignee: Neil Griffin
>Priority: Major
> Fix For: 3.1.2
>
> Attachments: pluto-debug.txt, test-portlet-mvc.zip, test-portlet.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a serveResource method forwards to a servlet which then forwards to a
> jsp, the HttpServletPortletRequestWrapper provides the path from the first
> forward rather than the second forward and the jsp is not rendered.
> This is the process used by Spring Portlet MVC to locate JSP 'views'
> resulting in the failure of all our portlets when trying to serve JSP's in
> response to resource requests.
> The attached file contains a DEBUG log of the processing flow attempting to
> serve '/WEB-INF/jsp/resource2.jsp' in response to a resource request.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (PLUTO-781) PortletRequestDispatcherImpl forwards to incorrect path
[ https://issues.apache.org/jira/browse/PLUTO-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-781: --- Fix Version/s: 3.1.2 > PortletRequestDispatcherImpl forwards to incorrect path > --- > > Key: PLUTO-781 > URL: https://issues.apache.org/jira/browse/PLUTO-781 > Project: Pluto > Issue Type: Bug > Components: portlet container >Affects Versions: 3.0.1 > Environment: Pluto Container 3.0.1, Spring 4.0.9.RELEASE, Wildfly > 14.0.1 >Reporter: Steve Potter >Assignee: Neil Griffin >Priority: Major > Fix For: 3.1.2 > > Attachments: pluto-debug.txt, test-portlet-mvc.zip, test-portlet.zip > > Time Spent: 10m > Remaining Estimate: 0h > > When a serveResource method forwards to a servlet which then forwards to a > jsp, the HttpServletPortletRequestWrapper provides the path from the first > forward rather than the second forward and the jsp is not rendered. > This is the process used by Spring Portlet MVC to locate JSP 'views' > resulting in the failure of all our portlets when trying to serve JSP's in > response to resource requests. > The attached file contains a DEBUG log of the processing flow attempting to > serve '/WEB-INF/jsp/resource2.jsp' in response to a resource request. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (PLUTO-793) TCK: Contesting assumptions of PortletContext.getRealPath(String) in V2EnvironmentTests_PortletContext_ApiRender_getRealPath3
[
https://issues.apache.org/jira/browse/PLUTO-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin closed PLUTO-793.
--
Resolution: Fixed
> TCK: Contesting assumptions of PortletContext.getRealPath(String) in
> V2EnvironmentTests_PortletContext_ApiRender_getRealPath3
> -
>
> Key: PLUTO-793
> URL: https://issues.apache.org/jira/browse/PLUTO-793
> Project: Pluto
> Issue Type: Bug
> Components: tck
>Affects Versions: 3.0.2-TCK
>Reporter: Neil Griffin
>Assignee: Neil Griffin
>Priority: Major
> Fix For: 3.0.3-TCK
>
>
> Section 8.3.1 of the Portlet 3.0 Specification titled "Correspondence between
> ServletContext and PortletContext methods" states:
> {quote}
> The following methods of the PortletContext should provide the same
> functionality as the
> methods of the ServletContext of similar name, but applied to the deployed
> portlet 5 application: getAttribute, getAttributeNames, getInitParameter,
> getInitParameterNames, getMimeType, getResourcePaths, getResourceAsStream,
> getClassLoader, getContextPath, getEffectiveMinorVersion.
> {quote}
> In corresponding fashion, the Javadoc for
> {{PortletContext.getRealPath(String)}} states:
> {quote}
> Returns a String containing the real path for a given virtual path. For
> example, the path /index.html returns the absolute file path of the portlet
> container file system.
> The real path returned will be in a form appropriate to the computer and
> operating system on which the portlet container is running, including the
> proper path separators. This method returns null if the portlet container
> cannot translate the virtual path to a real path for any reason (such as when
> the content is being made available from a .war archive).
> Parameters:
> path - a String specifying a virtual path
> Returns:
> a String specifying the real path, or null if the transformation cannot be
> performed.
> {quote}
> As such, the implementation for Apache Pluto simply delegates to the
> underlying {{ServletContext.getRealPath(String)}}:
> {code:java|title=PortletContextImpl.java}
> public String getRealPath(String path) {
> return servletContext.getRealPath(path);
> }
> {code}
> And the [corresponding Java EE 7 Javadoc for
> ServletContext.getRealPath(String)|https://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getRealPath-java.lang.String-]
> states:
> {quote}
> This method returns null if the servlet container is unable to translate the
> given virtual path to a real path.
> {quote}
> Given that background, the TCK test for
> V2EnvironmentTests_PortletContext_ApiRender_getRealPath3 looks like the
> following
> {code:java|title=EnvironmentTests_PortletContext_ApiRender.java}
> try {
> String realPath =
>
> pc.getRealPath("&^*#\\/V2EnvironmentTests_PortletContext_ApiRender_getMimeType4.invalid");
> if (realPath == null) {
> tr18.setTcSuccess(true);
> } else {
> tr18.appendTcDetail("Failed because real path is not null but " +
> realPath);
> }
> } catch (Exception e) {
> tr18.appendTcDetail(e.toString());
> }
> {code}
> The basic assumption of the test is that leading characters (such as those
> that are invalid for a filename like {{*}} would cause the underlying
> {{ServletContext.getRealPath(String)}} to return null. However, the Javadoc
> does not explicitly say that -- in fact, the Javadoc doesn't even require the
> "real path" of the file to physically exist.
> This issue is contesting the validity of this test, because it assumes the
> behavior of the underlying servlet container implementation. In the case of
> Apache Pluto, that would be Apache Tomcat.
> Case-in-point: When Pluto 3.1.1 was upgraded to Tomcat 8.5.69 via PLUTO-788,
> this TCK test started to fail. The reason why is because of [Tomcat Bugzilla
> Issue#56890|https://bz.apache.org/bugzilla/show_bug.cgi?id=56890] in which
> Tomcat versions 8.5.61 (and above) to automatically prepend a forward slash
> (/) character to the specified virtual path. It turns out that the lack of a
> leading forward slash was the only reason for Tomcat's implementation of
> {{{ServetlContext.getRealPath(String)}} to ever return {{null}}. And this was
> done in response to [Servlet API
> Issue#105|https://github.com/eclipse-ee4j/servlet-api/issues/105#issuecomment-734729939],
> where the Tomcat developer states:
> {quote}
> [I will] update Tomcat to be less strict (Tomcat currently requires a "/")"
> {quote}
> In all my attempts running Pluto with Tomcat 8.5.69, I have not been able to
> pass a non-null String value to the Pluto
> {{PortletContext.getRealPath(String)}} method and get {{null}}
[jira] [Created] (PLUTO-793) TCK: Contesting assumptions of PortletContext.getRealPath(String) in V2EnvironmentTests_PortletContext_ApiRender_getRealPath3
Neil Griffin created PLUTO-793:
--
Summary: TCK: Contesting assumptions of
PortletContext.getRealPath(String) in
V2EnvironmentTests_PortletContext_ApiRender_getRealPath3
Key: PLUTO-793
URL: https://issues.apache.org/jira/browse/PLUTO-793
Project: Pluto
Issue Type: Bug
Components: tck
Affects Versions: 3.0.2-TCK
Reporter: Neil Griffin
Assignee: Neil Griffin
Fix For: 3.0.3-TCK
Section 8.3.1 of the Portlet 3.0 Specification titled "Correspondence between
ServletContext and PortletContext methods" states:
{quote}
The following methods of the PortletContext should provide the same
functionality as the
methods of the ServletContext of similar name, but applied to the deployed
portlet 5 application: getAttribute, getAttributeNames, getInitParameter,
getInitParameterNames, getMimeType, getResourcePaths, getResourceAsStream,
getClassLoader, getContextPath, getEffectiveMinorVersion.
{quote}
In corresponding fashion, the Javadoc for
{{PortletContext.getRealPath(String)}} states:
{quote}
Returns a String containing the real path for a given virtual path. For
example, the path /index.html returns the absolute file path of the portlet
container file system.
The real path returned will be in a form appropriate to the computer and
operating system on which the portlet container is running, including the
proper path separators. This method returns null if the portlet container
cannot translate the virtual path to a real path for any reason (such as when
the content is being made available from a .war archive).
Parameters:
path - a String specifying a virtual path
Returns:
a String specifying the real path, or null if the transformation cannot be
performed.
{quote}
As such, the implementation for Apache Pluto simply delegates to the underlying
{{ServletContext.getRealPath(String)}}:
{code:java|title=PortletContextImpl.java}
public String getRealPath(String path) {
return servletContext.getRealPath(path);
}
{code}
And the [corresponding Java EE 7 Javadoc for
ServletContext.getRealPath(String)|https://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getRealPath-java.lang.String-]
states:
{quote}
This method returns null if the servlet container is unable to translate the
given virtual path to a real path.
{quote}
Given that background, the TCK test for
V2EnvironmentTests_PortletContext_ApiRender_getRealPath3 looks like the
following
{code:java|title=EnvironmentTests_PortletContext_ApiRender.java}
try {
String realPath =
pc.getRealPath("&^*#\\/V2EnvironmentTests_PortletContext_ApiRender_getMimeType4.invalid");
if (realPath == null) {
tr18.setTcSuccess(true);
} else {
tr18.appendTcDetail("Failed because real path is not null but " +
realPath);
}
} catch (Exception e) {
tr18.appendTcDetail(e.toString());
}
{code}
The basic assumption of the test is that leading characters (such as those that
are invalid for a filename like {{*}} would cause the underlying
{{ServletContext.getRealPath(String)}} to return null. However, the Javadoc
does not explicitly say that -- in fact, the Javadoc doesn't even require the
"real path" of the file to physically exist.
This issue is contesting the validity of this test, because it assumes the
behavior of the underlying servlet container implementation. In the case of
Apache Pluto, that would be Apache Tomcat.
Case-in-point: When Pluto 3.1.1 was upgraded to Tomcat 8.5.69 via PLUTO-788,
this TCK test started to fail. The reason why is because of [Tomcat Bugzilla
Issue#56890|https://bz.apache.org/bugzilla/show_bug.cgi?id=56890] in which
Tomcat versions 8.5.61 (and above) to automatically prepend a forward slash (/)
character to the specified virtual path. It turns out that the lack of a
leading forward slash was the only reason for Tomcat's implementation of
{{{ServetlContext.getRealPath(String)}} to ever return {{null}}. And this was
done in response to [Servlet API
Issue#105|https://github.com/eclipse-ee4j/servlet-api/issues/105#issuecomment-734729939],
where the Tomcat developer states:
{quote}
[I will] update Tomcat to be less strict (Tomcat currently requires a "/")"
{quote}
In all my attempts running Pluto with Tomcat 8.5.69, I have not been able to
pass a non-null String value to the Pluto
{{PortletContext.getRealPath(String)}} method and get {{null}} as a return
value.
The only way I can get it to return {{null}} is by passing {{null}}. In order
to fix the problem, I will modify TCK test to pass {{null}}, but that might
also be an assumption of the behavior of the underlying servlet container
implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (PLUTO-787) Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228
[ https://issues.apache.org/jira/browse/PLUTO-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin closed PLUTO-787. -- Resolution: Fixed > Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228 > > > Key: PLUTO-787 > URL: https://issues.apache.org/jira/browse/PLUTO-787 > Project: Pluto > Issue Type: Task > Components: demo portlets, maven archetypes >Reporter: Neil Griffin >Assignee: Neil Griffin >Priority: Major > Fix For: 3.1.1 > > > This task involves migrating the following dependencies from Log4j 1.x to > Log4j 2.x due to > [CVE-2019-17571|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]: > - log4j:log4j -> org.apache.logging.log4j:log4j-api-2.16.0 > - org.slf4j:slf4j-log4j12 -> org.apache.logging.log4j:log4j-slf4j-impl-2.16.0 > Also, due to > [CVE-2021-44228|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228] > (which only affects Log4j2) it is necessary to use version 2.16.0 at a > minimum. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PLUTO-787) Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228
[ https://issues.apache.org/jira/browse/PLUTO-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-787: --- Component/s: maven archetypes > Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228 > > > Key: PLUTO-787 > URL: https://issues.apache.org/jira/browse/PLUTO-787 > Project: Pluto > Issue Type: Task > Components: demo portlets, maven archetypes >Reporter: Neil Griffin >Assignee: Neil Griffin >Priority: Major > Fix For: 3.1.1 > > > This task involves migrating the following dependencies from Log4j 1.x to > Log4j 2.x due to > [CVE-2019-17571|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]: > - log4j:log4j -> org.apache.logging.log4j:log4j-api-2.16.0 > - org.slf4j:slf4j-log4j12 -> org.apache.logging.log4j:log4j-slf4j-impl-2.16.0 > Also, due to > [CVE-2021-44228|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228] > (which only affects Log4j2) it is necessary to use version 2.16.0 at a > minimum. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (PLUTO-784) When a portlet is maximized portlets after it are still visible
[
https://issues.apache.org/jira/browse/PLUTO-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin closed PLUTO-784.
--
Resolution: Not A Bug
[~mehdi.javan] Thanks for reporting this issue, and sorry it took so long to
get back to you.
h2. TL;DR
Things are working as designed, so I'm closing this issue with status "Not A
Bug"
h2. Detailed Explanation
The "meaning" of {{WindowState.MAXIMIZED}} is left open for interpretation by
the implementer of the portlet container (Pluto, Jetspeed, Liferay, etc.)
Actually, the rendering/display of portlets and their window states is not
handled by the portlet container, but by the page engine of the portal. So
that's why it's left open for interpretation.
In the case of Apache Pluto, pluto-default-theme.jsp will [render a single
column of
portlets|https://github.com/apache/portals-pluto/blob/pluto-3.1.0/pluto-portal/src/main/webapp/WEB-INF/themes/pluto-default-theme.jsp#L111-L117]
if one of them is maximized. [Otherwise, it will render two
columns|https://github.com/apache/portals-pluto/blob/pluto-3.1.0/pluto-portal/src/main/webapp/WEB-INF/themes/pluto-default-theme.jsp#L119-L137].
In either case, there is a {{...}} that iterates
through ALL of the portlets on the page and invokes each one for rendering via
the [ tag in
portlet-skin.jsp|https://github.com/apache/portals-pluto/blob/pluto-3.1.0/pluto-portal/src/main/webapp/WEB-INF/themes/portlet-skin.jsp#L24].
This will in turn cause {{PortletTag.doStartTag()}} to be invoked for each
portlet. [And that's where Pluto determines whether or not the markup of a
portlet should be
rendered|https://github.com/apache/portals-pluto/blob/pluto-3.1.0/pluto-portal-driver/src/main/java/org/apache/pluto/driver/tags/PortletTag.java#L179-L181].
The key is the [iteration over
portalURL.getWindowStates(|https://github.com/apache/portals-pluto/blob/pluto-3.1.0/pluto-portal-driver/src/main/java/org/apache/pluto/driver/tags/PortletTag.java#L175]).
The reason why the returned map contains some portlets, and not all portlets,
is determined by the Portal URL.
So for example, when you click on the "Maximize" link for the "PH Color
Selection Portlet", the reason why only the following 3 portlets are rendered,
is because all three care about the {{"color"}} public render parameter:
- PH Color Selection Portlet, see
[ColorSelPortlet.java|https://github.com/apache/portals-pluto/blob/pluto-3.1.0/demo/hub-demo-portlet/src/main/java/org/apache/portals/pluto/demo/hub/ColorSelPortlet.java#L57])
- PH Message Box Portlet, see
[MessageBoxPortlet.java|https://github.com/apache/portals-pluto/blob/pluto-3.1.0/demo/hub-demo-portlet/src/main/java/org/apache/portals/pluto/demo/hub/MessageBoxPortlet.java#L53]
- Partial Action Portlet, see
[PartialActionPortlet.java|https://github.com/apache/portals-pluto/blob/pluto-3.1.0/demo/hub-demo-portlet/src/main/java/org/apache/portals/pluto/demo/hub/PartialActionPortlet.java#L48]
And that's reflected in the URL that was requested by the browser:
http://localhost:9080/pluto/portal/V3.0%20Portlet%20Hub%20Demo/__pdhub-demo-portlet.ImageSelPortlet%21-1503889707%7C0;0/__pdhub-demo-portlet.PH-ColorSelPortlet%21-1503889707%7C2;1/__pdhub-demo-portlet.MessageBoxPortlet%21-1503889707%7C3;2/__pdhub-demo-portlet.PH-ResourcePortlet-PRP%21-1503889707%7C1;3/__pdhub-demo-portlet.PartialActionPortlet%21-1503889707%7C4;4/__ws0;normal/__ws1;maximized
> When a portlet is maximized portlets after it are still visible
> ---
>
> Key: PLUTO-784
> URL: https://issues.apache.org/jira/browse/PLUTO-784
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
>Affects Versions: 3.1.0
> Environment: Chrome 78
>Reporter: Mehdi Javan
>Assignee: Neil Griffin
>Priority: Major
> Attachments: image-2019-12-11-11-21-04-421.png,
> image-2019-12-11-11-21-18-565.png
>
>
> For example, on the following page, if *PH Color Selection Portlet* is
> maximized two other portlets are still visible; see the next image below.
> My expectation is that the maximized portlet fit to the whole page and all
> the other portlets are hidden.
> !image-2019-12-11-11-21-18-565.png!
>
> !image-2019-12-11-11-21-04-421.png!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (PLUTO-787) Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228
[ https://issues.apache.org/jira/browse/PLUTO-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-787: --- Description: This task involves migrating the following dependencies from Log4j 1.x to Log4j 2.x due to [CVE-2019-17571|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]: - log4j:log4j -> org.apache.logging.log4j:log4j-api-2.16.0 - org.slf4j:slf4j-log4j12 -> org.apache.logging.log4j:log4j-slf4j-impl-2.16.0 Also, due to [CVE-2021-44228|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228] (which only affects Log4j2) it is necessary to use version 2.16.0 at a minimum. was: This task involves migrating the following dependencies from Log4j 1.x to Log4j 2.x due to [CVE-2019-17571|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]: - log4j:log4j -> org.apache.logging.log4j:log4j-api-2.15.0 - org.slf4j:slf4j-log4j12 -> org.apache.logging.log4j:log4j-slf4j-impl-2.15.0 Also, due to [CVE-2021-44228|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228] (which only affects Log4j2) it is necessary to use version 2.15.0 at a minimum. > Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228 > > > Key: PLUTO-787 > URL: https://issues.apache.org/jira/browse/PLUTO-787 > Project: Pluto > Issue Type: Task > Components: demo portlets >Reporter: Neil Griffin >Assignee: Neil Griffin >Priority: Major > Fix For: 3.1.1 > > > This task involves migrating the following dependencies from Log4j 1.x to > Log4j 2.x due to > [CVE-2019-17571|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]: > - log4j:log4j -> org.apache.logging.log4j:log4j-api-2.16.0 > - org.slf4j:slf4j-log4j12 -> org.apache.logging.log4j:log4j-slf4j-impl-2.16.0 > Also, due to > [CVE-2021-44228|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228] > (which only affects Log4j2) it is necessary to use version 2.16.0 at a > minimum. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PLUTO-787) Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228
[ https://issues.apache.org/jira/browse/PLUTO-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-787: --- Summary: Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228 (was: Migrate to Log4j 2.15.0 due to CVE-2019-17571 and CVE-2021-44228) > Migrate to Log4j 2.16.0 due to CVE-2019-17571 and CVE-2021-44228 > > > Key: PLUTO-787 > URL: https://issues.apache.org/jira/browse/PLUTO-787 > Project: Pluto > Issue Type: Task > Components: demo portlets >Reporter: Neil Griffin >Assignee: Neil Griffin >Priority: Major > Fix For: 3.1.1 > > > This task involves migrating the following dependencies from Log4j 1.x to > Log4j 2.x due to > [CVE-2019-17571|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]: > - log4j:log4j -> org.apache.logging.log4j:log4j-api-2.15.0 > - org.slf4j:slf4j-log4j12 -> org.apache.logging.log4j:log4j-slf4j-impl-2.15.0 > Also, due to > [CVE-2021-44228|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228] > (which only affects Log4j2) it is necessary to use version 2.15.0 at a > minimum. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (PLUTO-787) Migrate to Log4j 2.15.0 due to CVE-2019-17571 and CVE-2021-44228
[ https://issues.apache.org/jira/browse/PLUTO-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin reopened PLUTO-787: > Migrate to Log4j 2.15.0 due to CVE-2019-17571 and CVE-2021-44228 > > > Key: PLUTO-787 > URL: https://issues.apache.org/jira/browse/PLUTO-787 > Project: Pluto > Issue Type: Task > Components: demo portlets >Reporter: Neil Griffin >Assignee: Neil Griffin >Priority: Major > Fix For: 3.1.1 > > > This task involves migrating the following dependencies from Log4j 1.x to > Log4j 2.x due to > [CVE-2019-17571|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]: > - log4j:log4j -> org.apache.logging.log4j:log4j-api-2.15.0 > - org.slf4j:slf4j-log4j12 -> org.apache.logging.log4j:log4j-slf4j-impl-2.15.0 > Also, due to > [CVE-2021-44228|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228] > (which only affects Log4j2) it is necessary to use version 2.15.0 at a > minimum. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (PLUTO-783) applicant-mvcbean-cdi-jsp-portlet demo labels and drop down items are not shown
[ https://issues.apache.org/jira/browse/PLUTO-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin closed PLUTO-783. -- Resolution: Cannot Reproduce [~mehdi.javan] Thanks again for taking the time to report this issue. Note that I just tried using the latest commit of the Apache Pluto master branch, and I am not able to reproduce the issue. I will close this as "Cannot Reproduce" but feel free to re-open it in the future if you find a consistent way for us all to reproduce the issue. > applicant-mvcbean-cdi-jsp-portlet demo labels and drop down items are not > shown > --- > > Key: PLUTO-783 > URL: https://issues.apache.org/jira/browse/PLUTO-783 > Project: Pluto > Issue Type: Bug > Components: demo portlets >Affects Versions: 3.1.0 >Reporter: Mehdi Javan >Assignee: Neil Griffin >Priority: Major > Attachments: image-2019-10-28-12-58-02-548.png > > > The attached screenshot shows the issue. > !image-2019-10-28-12-58-02-548.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PLUTO-785) Some portlets are not registered with the portlet container when a portlet.xml descriptor contains multiple entries
[
https://issues.apache.org/jira/browse/PLUTO-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin updated PLUTO-785:
---
Fix Version/s: 3.1.2
(was: 3.1.1)
> Some portlets are not registered with the portlet container when a
> portlet.xml descriptor contains multiple entries
> -
>
> Key: PLUTO-785
> URL: https://issues.apache.org/jira/browse/PLUTO-785
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
>Affects Versions: 3.1.0
>Reporter: Neil Griffin
>Assignee: Neil Griffin
>Priority: Major
> Fix For: 3.1.2
>
>
> h2. Problem Background
> There is a bug in Apache Pluto 3.1.x that prevents portlets from being
> registered with the portlet container when a portlet.xml descriptor contains
> multiple {{}} entries. This is not a problem on Liferay Portal / DXP
> or Pluto 2.0.3.
> h2. Steps to Reproduce
> - Checkout ([the 5.x branch of
> liferay-faces-bridge.impl.git|https://github.com/liferay/liferay-faces-bridge-impl/tree/5.x])
> - Build the jsf-ipc-pub-render-params-portlet with the {{-P pluto}} profile
> - Copy the resulting WAR to Apache Pluto 3.x
> - Visit the following URL: http://localhost:9080/pluto/portal/jsf-prp
> (/) Expected Results
> Both the {{jsf-ipc-pub-render-params-customers}} and
> {{jsf-ipc-pub-render-params-bookings}} portlets are rendered
> (x) Actual Results
> The {{jsf-ipc-pub-render-params-bookings}} portlet is rendered twice
> Note that when adding the Customers portlet to a page by itself, it still
> renders as the {{jsf-ipc-pub-render-params-bookings}} portlet.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (PLUTO-778) change String.replaceAll() to replace() to improve performance.
[ https://issues.apache.org/jira/browse/PLUTO-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-778: --- Fix Version/s: 3.1.2 (was: 3.1.1) > change String.replaceAll() to replace() to improve performance. > --- > > Key: PLUTO-778 > URL: https://issues.apache.org/jira/browse/PLUTO-778 > Project: Pluto > Issue Type: Bug >Affects Versions: 3.0.0, 3.0.1, 3.1.0 >Reporter: bd2019us >Assignee: Neil Griffin >Priority: Major > Labels: pull-request-available > Fix For: 3.1.2 > > Attachments: 1.patch > > Time Spent: 40m > Remaining Estimate: 0h > > Location: > (1) > pluto-container/src/main/java/org/apache/pluto/container/impl/RenderResponseImpl.java > (2) pluto-taglib/src/main/java/org/apache/pluto/tags/BaseURLTag.java > Since the string to be replaced is simple string literal that does not need > to be compiled, i.e., not regular expression. Another API String.replace() > should be used and recommended for better performance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
