[jira] [Closed] (PLUTO-794) Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final in order to conform to Java EE 7
[
https://issues.apache.org/jira/browse/PLUTO-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin closed PLUTO-794.
--
Resolution: Fixed
> Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final
> in order to conform to Java EE 7
>
>
> Key: PLUTO-794
> URL: https://issues.apache.org/jira/browse/PLUTO-794
> Project: Pluto
> Issue Type: Task
> Components: build system, demo portlets, maven archetypes
>Reporter: Neil Griffin
>Assignee: Neil Griffin
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: stacktrace.txt
>
>
> Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
> Enterprise Edition" states:
> {quote}The Portlet API v3.0 is based on the Java Standard Edition 7.0 and
> Java Enterprise Edition v7.0. Portlet containers should at least meet the
> requirements described by the Java EE 7.0 specification for executing in a
> Java EE environment.{quote}
> Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which
> includes the CDI 1.2 API and the Bean Validation 1.1
> API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it
> relies on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
> When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
> attached [^stacktrace.txt] started happening when trying to onblur out of the
> "Postal Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This
> revealed that hibernate-validator-6.0.20.Final was attempting to call the
> [javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
> method, which the Javadoc indicates was introduced in CDI 2.0.
> Upon closer examination, the [Hibernate Validator Releases
> page|https://hibernate.org/validator/releases/6.0/] states that version 6.0
> targets Bean Validation 2.0, which explains why the Hibernate Validator
> implementation of the Bean Validation API would be permitted to call version
> 2.0 method signatures in the Bean Validation API.
> The [Hibernate Validator FAQ
> page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
> states that Hibernate Validator 5.x is the reference implementation of Bean
> Validation 1.1 (JSR 349). In addition, the project's main
> [pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
> descriptor corroborates the FAQ. Therefore, in order to be compatible with
> CDI 1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to
> the newest version of Hibernate Validator 5.x (which is
> hibernate-validator-5.4.3.Final at the time of this writing) and
> validation-api-1.1.0.Final
> This task involves downgrading from the following dependency versions:
> {code:xml|title=pom.xml (before)}
>
> javax.validation
> validation-api
> 2.0.1.Final
> provided
>
>
> org.hibernate
> hibernate-validator
> 6.0.14.Final
>
>
> javax.validation
> validation-api
>
>
>
>
> org.hibernate
> hibernate-validator-cdi
> 6.0.14.Final
>
> {code}
> {code:xml|title=pom.xml (after)}
>
> javax.validation
> validation-api
> 1.1.0.Final
> provided
>
>
> org.hibernate
> hibernate-validator
> 5.4.3.Final
>
>
> javax.validation
> validation-api
>
>
>
>
> org.hibernate
> hibernate-validator-cdi
> 5.4.3.Final
>
> {code}
> In addition, since the demo and archetypes use Bean Validation 2.0
> annotations such as:
> -
> @[javax.validation.constraints.NotBlank|https://javaee.github.io/javaee-spec/javadocs/javax/validation/constraints/NotBlank.html]
> -
> @[javax.validation.constraints.Email|https://javaee.github.io/javaee-spec/javadocs/javax/validation/constraints/Email.html]
> -
> @[javax.validation.constraints.Positive|https://javaee.github.io/javaee-spec/javadocs/javax/validation/constraints/Positive.html]
> ... it will be necessary to use their Bean Validation 1.2 counterparts, which
> are vendor-specific to Hibernate Validator:
> -
> @[org.hibernate.validator.constraints.NotBlank|https://docs.jboss.org/hibernate/validator/5.1/api/org/hibernate/validator/constraints/NotBlank.html]
> -
> @[org.hibernate.validator.constraints.Email|https://docs.jboss.org/hibernate/validator/5.1/api/org/hibernate/validator/constraints/Email.html]
> -
>
[jira] [Updated] (PLUTO-794) Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final in order to conform to Java EE 7
[
https://issues.apache.org/jira/browse/PLUTO-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin updated PLUTO-794:
---
Description:
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
attached [^stacktrace.txt] started happening when trying to onblur out of the
"Postal Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This
revealed that hibernate-validator-6.0.20.Final was attempting to call the
[javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
method, which the Javadoc indicates was introduced in CDI 2.0.
Upon closer examination, the [Hibernate Validator Releases
page|https://hibernate.org/validator/releases/6.0/] states that version 6.0
targets Bean Validation 2.0, which explains why the Hibernate Validator
implementation of the Bean Validation API would be permitted to call version
2.0 method signatures in the Bean Validation API.
The [Hibernate Validator FAQ
page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
states that Hibernate Validator 5.x is the reference implementation of Bean
Validation 1.1 (JSR 349). In addition, the project's main
[pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
descriptor corroborates the FAQ. Therefore, in order to be compatible with CDI
1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to the
newest version of Hibernate Validator 5.x (which is
hibernate-validator-5.4.3.Final at the time of this writing) and
validation-api-1.1.0.Final
This task involves downgrading from the following dependency versions:
{code:xml|title=pom.xml (before)}
javax.validation
validation-api
2.0.1.Final
provided
org.hibernate
hibernate-validator
6.0.14.Final
javax.validation
validation-api
org.hibernate
hibernate-validator-cdi
6.0.14.Final
{code}
{code:xml|title=pom.xml (after)}
javax.validation
validation-api
1.1.0.Final
provided
org.hibernate
hibernate-validator
5.4.3.Final
javax.validation
validation-api
org.hibernate
hibernate-validator-cdi
5.4.3.Final
{code}
In addition, since the demo and archetypes use Bean Validation 2.0 annotations
such as:
-
@[javax.validation.constraints.NotBlank|https://javaee.github.io/javaee-spec/javadocs/javax/validation/constraints/NotBlank.html]
-
@[javax.validation.constraints.Email|https://javaee.github.io/javaee-spec/javadocs/javax/validation/constraints/Email.html]
-
@[javax.validation.constraints.Positive|https://javaee.github.io/javaee-spec/javadocs/javax/validation/constraints/Positive.html]
... it will be necessary to use their Bean Validation 1.2 counterparts, which
are vendor-specific to Hibernate Validator:
-
@[org.hibernate.validator.constraints.NotBlank|https://docs.jboss.org/hibernate/validator/5.1/api/org/hibernate/validator/constraints/NotBlank.html]
-
@[org.hibernate.validator.constraints.Email|https://docs.jboss.org/hibernate/validator/5.1/api/org/hibernate/validator/constraints/Email.html]
-
@[org.hibernate.validator.constraints.Range|https://docs.jboss.org/hibernate/validator/5.1/api/org/hibernate/validator/constraints/Range.html]
was:
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to
[jira] [Updated] (PLUTO-794) Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final in order to conform to Java EE 7
[
https://issues.apache.org/jira/browse/PLUTO-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin updated PLUTO-794:
---
Description:
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
attached [^stacktrace.txt] started happening when trying to onblur out of the
"Postal Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This
revealed that hibernate-validator-6.0.20.Final was attempting to call the
[javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
method, which the Javadoc indicates was introduced in CDI 2.0.
Upon closer examination, the [Hibernate Validator Releases
page|https://hibernate.org/validator/releases/6.0/] states that version 6.0
targets Bean Validation 2.0, which explains why the Hibernate Validator
implementation of the Bean Validation API would be permitted to call version
2.0 method signatures in the Bean Validation API.
The [Hibernate Validator FAQ
page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
states that Hibernate Validator 5.x is the reference implementation of Bean
Validation 1.1 (JSR 349). In addition, the project's main
[pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
descriptor corroborates the FAQ. Therefore, in order to be compatible with CDI
1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to the
newest version of Hibernate Validator 5.x (which is
hibernate-validator-5.4.3.Final at the time of this writing) and
validation-api-1.1.0.Final
This task involves downgrading from the following dependency versions:
{code:xml|title=pom.xml (before)}
javax.validation
validation-api
2.0.1.Final
provided
org.hibernate
hibernate-validator
6.0.14.Final
javax.validation
validation-api
org.hibernate
hibernate-validator-cdi
6.0.14.Final
{code}
{code:xml|title=pom.xml (after)}
javax.validation
validation-api
1.1.0.Final
provided
org.hibernate
hibernate-validator
5.4.3.Final
javax.validation
validation-api
org.hibernate
hibernate-validator-cdi
5.4.3.Final
{code}
In addition, since the demo and archetypes use Bean Validation annotations like
@
was:
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
attached [^stacktrace.txt] started happening when trying to onblur out of the
"Postal Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This
revealed that hibernate-validator-6.0.20.Final was attempting to call the
[javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
method, which the Javadoc indicates was introduced in CDI 2.0.
Upon closer examination, the Hibernate Validator Releases page states that
version 6.0 targets Bean Validation 2.0, which explains why the Hibernate
Validator implementation of the Bean Validation API would be permitted to call
version 2.0 method signatures in the Bean Validation API.
The [Hibernate Validator FAQ
page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
states that Hibernate Validator 5.x is the reference
[jira] [Closed] (PLUTO-791) Upgrade to hibernate-validator-6.0.20.Final due to CVE-2020-10693 and CVE-2019-10219
[ https://issues.apache.org/jira/browse/PLUTO-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin closed PLUTO-791. -- Resolution: Won't Fix It is not possible to perform the upgrade at this time due to PLUTO-794. > Upgrade to hibernate-validator-6.0.20.Final due to CVE-2020-10693 and > CVE-2019-10219 > > > Key: PLUTO-791 > URL: https://issues.apache.org/jira/browse/PLUTO-791 > Project: Pluto > Issue Type: Task > Components: build system, demo portlets >Reporter: Neil Griffin >Assignee: Neil Griffin >Priority: Major > > This task involves upgrading to hibernate-validator-6.0.20.Final due to > [CVE-2020-10693|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10693] > and > [CVE-2019-10219|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10219]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (PLUTO-791) Upgrade to hibernate-validator-6.0.20.Final due to CVE-2020-10693 and CVE-2019-10219
[ https://issues.apache.org/jira/browse/PLUTO-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin reopened PLUTO-791: > Upgrade to hibernate-validator-6.0.20.Final due to CVE-2020-10693 and > CVE-2019-10219 > > > Key: PLUTO-791 > URL: https://issues.apache.org/jira/browse/PLUTO-791 > Project: Pluto > Issue Type: Task > Components: build system, demo portlets >Reporter: Neil Griffin >Assignee: Neil Griffin >Priority: Major > Fix For: 3.1.1 > > > This task involves upgrading to hibernate-validator-6.0.20.Final due to > [CVE-2020-10693|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10693] > and > [CVE-2019-10219|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10219]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PLUTO-791) Upgrade to hibernate-validator-6.0.20.Final due to CVE-2020-10693 and CVE-2019-10219
[ https://issues.apache.org/jira/browse/PLUTO-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-791: --- Fix Version/s: (was: 3.1.1) > Upgrade to hibernate-validator-6.0.20.Final due to CVE-2020-10693 and > CVE-2019-10219 > > > Key: PLUTO-791 > URL: https://issues.apache.org/jira/browse/PLUTO-791 > Project: Pluto > Issue Type: Task > Components: build system, demo portlets >Reporter: Neil Griffin >Assignee: Neil Griffin >Priority: Major > > This task involves upgrading to hibernate-validator-6.0.20.Final due to > [CVE-2020-10693|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10693] > and > [CVE-2019-10219|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10219]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PLUTO-794) Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final in order to conform to Java EE 7
[
https://issues.apache.org/jira/browse/PLUTO-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin updated PLUTO-794:
---
Description:
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
attached [^stacktrace.txt] started happening when trying to onblur out of the
"Postal Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This
revealed that hibernate-validator-6.0.20.Final was attempting to call the
[javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
method, which the Javadoc indicates was introduced in CDI 2.0.
Upon closer examination, the Hibernate Validator Releases page states that
version 6.0 targets Bean Validation 2.0, which explains why the Hibernate
Validator implementation of the Bean Validation API would be permitted to call
version 2.0 method signatures in the Bean Validation API.
The [Hibernate Validator FAQ
page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
states that Hibernate Validator 5.x is the reference implementation of Bean
Validation 1.1 (JSR 349). In addition, the project's main
[pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
descriptor corroborates the FAQ. Therefore, in order to be compatible with CDI
1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to the
newest version of Hibernate Validator 5.x (which is
hibernate-validator-5.4.3.Final at the time of this writing) and
validation-api-1.1.0.Final
was:
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
attached !stacktrace.txt! started happening when trying to onblur out of the
"Postal Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This
revealed that hibernate-validator-6.0.20.Final was attempting to call the
[javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
method, which the Javadoc indicates was introduced in CDI 2.0.
Upon closer examination, the Hibernate Validator Releases page states that
version 6.0 targets Bean Validation 2.0, which explains why the Hibernate
Validator implementation of the Bean Validation API would be permitted to call
version 2.0 method signatures in the Bean Validation API.
The [Hibernate Validator FAQ
page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
states that Hibernate Validator 5.x is the reference implementation of Bean
Validation 1.1 (JSR 349). In addition, the project's main
[pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
descriptor corroborates the FAQ. Therefore, in order to be compatible with CDI
1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to the
newest version of Hibernate Validator 5.x (which is
hibernate-validator-5.4.3.Final at the time of this writing) and
validation-api-1.1.0.Final
> Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final
> in order to conform to Java EE 7
>
>
> Key: PLUTO-794
> URL: https://issues.apache.org/jira/browse/PLUTO-794
> Project: Pluto
> Issue Type: Task
> Components: build system, demo portlets, maven archetypes
>Reporter: Neil Griffin
>Assignee: Neil Griffin
>Priority:
[jira] [Updated] (PLUTO-794) Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final in order to conform to Java EE 7
[
https://issues.apache.org/jira/browse/PLUTO-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin updated PLUTO-794:
---
Description:
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
attached !stacktrace.txt! started happening when trying to onblur out of the
"Postal Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This
revealed that hibernate-validator-6.0.20.Final was attempting to call the
[javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
method, which the Javadoc indicates was introduced in CDI 2.0.
Upon closer examination, the Hibernate Validator Releases page states that
version 6.0 targets Bean Validation 2.0, which explains why the Hibernate
Validator implementation of the Bean Validation API would be permitted to call
version 2.0 method signatures in the Bean Validation API.
The [Hibernate Validator FAQ
page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
states that Hibernate Validator 5.x is the reference implementation of Bean
Validation 1.1 (JSR 349). In addition, the project's main
[pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
descriptor corroborates the FAQ. Therefore, in order to be compatible with CDI
1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to the
newest version of Hibernate Validator 5.x (which is
hibernate-validator-5.4.3.Final at the time of this writing) and
validation-api-1.1.0.Final
was:
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}
The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.
{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
attached stacktrace started happening when trying to onblur out of the "Postal
Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This revealed that
hibernate-validator-6.0.20.Final was attempting to call the
[javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
method, which the Javadoc indicates was introduced in CDI 2.0.
Upon closer examination, the Hibernate Validator Releases page states that
version 6.0 targets Bean Validation 2.0, which explains why the Hibernate
Validator implementation of the Bean Validation API would be permitted to call
version 2.0 method signatures in the Bean Validation API.
The [Hibernate Validator FAQ
page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
states that Hibernate Validator 5.x is the reference implementation of Bean
Validation 1.1 (JSR 349). In addition, the project's main
[pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
descriptor corroborates the FAQ. Therefore, in order to be compatible with CDI
1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to the
newest version of Hibernate Validator 5.x (which is
hibernate-validator-5.4.3.Final at the time of this writing) and
validation-api-1.1.0.Final
> Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final
> in order to conform to Java EE 7
>
>
> Key: PLUTO-794
> URL: https://issues.apache.org/jira/browse/PLUTO-794
> Project: Pluto
> Issue Type: Task
> Components: build system, demo portlets, maven archetypes
>Reporter: Neil Griffin
>Assignee: Neil Griffin
>Priority: Major
[jira] [Updated] (PLUTO-794) Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final in order to conform to Java EE 7
[
https://issues.apache.org/jira/browse/PLUTO-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin updated PLUTO-794:
---
Attachment: stacktrace.txt
> Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final
> in order to conform to Java EE 7
>
>
> Key: PLUTO-794
> URL: https://issues.apache.org/jira/browse/PLUTO-794
> Project: Pluto
> Issue Type: Task
> Components: build system, demo portlets, maven archetypes
>Reporter: Neil Griffin
>Assignee: Neil Griffin
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: stacktrace.txt
>
>
> Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
> Enterprise Edition" states:
> {quote}
> The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
> Enterprise Edition v7.0. Portlet containers should at least meet the
> requirements described by the Java EE 7.0 specification for executing in a
> Java EE environment.
> {quote}
> Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which
> includes the CDI 1.2 API and the Bean Validation 1.1
> API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it
> relies on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
> When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
> attached stacktrace started happening when trying to onblur out of the
> "Postal Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This
> revealed that hibernate-validator-6.0.20.Final was attempting to call the
> [javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
> method, which the Javadoc indicates was introduced in CDI 2.0.
> Upon closer examination, the Hibernate Validator Releases page states that
> version 6.0 targets Bean Validation 2.0, which explains why the Hibernate
> Validator implementation of the Bean Validation API would be permitted to
> call version 2.0 method signatures in the Bean Validation API.
> The [Hibernate Validator FAQ
> page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
> states that Hibernate Validator 5.x is the reference implementation of Bean
> Validation 1.1 (JSR 349). In addition, the project's main
> [pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
> descriptor corroborates the FAQ. Therefore, in order to be compatible with
> CDI 1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to
> the newest version of Hibernate Validator 5.x (which is
> hibernate-validator-5.4.3.Final at the time of this writing) and
> validation-api-1.1.0.Final
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (PLUTO-794) Downgrade to hibernate-validator-5.4.3.Final and validation-api-1.1.0.Final in order to conform to Java EE 7
Neil Griffin created PLUTO-794:
--
Summary: Downgrade to hibernate-validator-5.4.3.Final and
validation-api-1.1.0.Final in order to conform to Java EE 7
Key: PLUTO-794
URL: https://issues.apache.org/jira/browse/PLUTO-794
Project: Pluto
Issue Type: Task
Components: build system, demo portlets, maven archetypes
Reporter: Neil Griffin
Assignee: Neil Griffin
Fix For: 3.1.1
Section 1.8 of the Portlet 3.0 Specification titled "Relationship to Java
Enterprise Edition" states:
{quote}
The Portlet API v3.0 is based on the Java Standard Edition 7.0 and Java
Enterprise Edition v7.0. Portlet containers should at least meet the
requirements described by the Java EE 7.0 specification for executing in a Java
EE environment.
{quote}
Pluto 3.x implements the Portlet 3.0 API and [targets Java EE 7, which includes
the CDI 1.2 API and the Bean Validation 1.1
API|https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile]. . As such, it relies
on JBoss Weld 2.3.1.Final (which implements the CDI 1.2 API).
When trying to upgrade to hibernate-validator-6.0.20.Final via PLUTO-791, the
attached stacktrace started happening when trying to onblur out of the "Postal
Code" field of the applicant-mvcbean-cdi-jsp-portlet demo. This revealed that
hibernate-validator-6.0.20.Final was attempting to call the
[javax.enterprise.inject.spi.BeanManager.createInstance()|https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/inject/spi/BeanManager.html#createInstance--]
method, which the Javadoc indicates was introduced in CDI 2.0.
Upon closer examination, the Hibernate Validator Releases page states that
version 6.0 targets Bean Validation 2.0, which explains why the Hibernate
Validator implementation of the Bean Validation API would be permitted to call
version 2.0 method signatures in the Bean Validation API.
The [Hibernate Validator FAQ
page|https://hibernate.org/validator/faq/#whats-the-difference-between-hibernate-validator-3-4-and-5]
states that Hibernate Validator 5.x is the reference implementation of Bean
Validation 1.1 (JSR 349). In addition, the project's main
[pom.xml|https://github.com/hibernate/hibernate-validator/blob/5.4/pom.xml#L133]
descriptor corroborates the FAQ. Therefore, in order to be compatible with CDI
1.2 and Bean Validation 1.1 (Java EE 7), it is necessary to downgrade to the
newest version of Hibernate Validator 5.x (which is
hibernate-validator-5.4.3.Final at the time of this writing) and
validation-api-1.1.0.Final
--
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=17460884#comment-17460884 ] Steve Potter commented on PLUTO-781: [~ngriffin7a] - many thanks. Just what I was hoping for! > 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.1 > > 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.1 (was: 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.1 > > 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 > 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.1 > > 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] [Reopened] (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 reopened PLUTO-781: > 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-782) Default "tomcat" and "pluto" users are granted "manager-gui" role
[ https://issues.apache.org/jira/browse/PLUTO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-782: --- Fix Version/s: 3.1.1 (was: 3.1.2) > Default "tomcat" and "pluto" users are granted "manager-gui" role > - > > Key: PLUTO-782 > URL: https://issues.apache.org/jira/browse/PLUTO-782 > Project: Pluto > Issue Type: Bug >Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 3.0.0, 3.0.1, 3.1.0 >Reporter: Louis >Assignee: Neil Griffin >Priority: Critical > Fix For: 3.1.1 > > > Hi, > I just downloaded your software and saw that the passwords used to protect > the local tomcat users are very predictable. It would be better to disable > those accounts as they basically allow anyone to get command execution on the > underlying server. > > People in charge can then add those accounts based on their requirements. > Regards, > Louis -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (PLUTO-782) Default "tomcat" and "pluto" users are granted "manager-gui" role
[
https://issues.apache.org/jira/browse/PLUTO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460849#comment-17460849
]
Neil Griffin edited comment on PLUTO-782 at 12/16/21, 4:29 PM:
---
@[~snyff]: Thank you for reporting this issue. Please see commit
[4c80c6b051343c5c2cb7a34230f125d21a7901b7|https://github.com/apache/portals-pluto/commit/4c80c6b051343c5c2cb7a34230f125d21a7901b7]
for the fix, which will appear in the 3.1.1 release of Apache Pluto.
The solution was to comment-out the default "tomcat" and "pluto" logins as they
currently are, and replace them with a "pluto" login that does not have the
Tomcat "manager-gui" role.
For example:
{code:xml|title=tomcat-users.xml}
http://tomcat.apache.org/xml;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://tomcat.apache.org/xml
tomcat-users.xsd"
version="1.0">
{code}
was (Author: ngriffin7a):
@[~snyff]: Thank you for reporting this issue. Please see commit
[4c80c6b051343c5c2cb7a34230f125d21a7901b7|https://github.com/apache/portals-pluto/commit/4c80c6b051343c5c2cb7a34230f125d21a7901b7]
for the fix, which will appear in the 3.1.2 release of Apache Pluto.
The solution was to comment-out the default "tomcat" and "pluto" logins as they
currently are, and replace them with a "pluto" login that does not have the
Tomcat "manager-gui" role.
For example:
{code:xml|title=tomcat-users.xml}
http://tomcat.apache.org/xml;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://tomcat.apache.org/xml
tomcat-users.xsd"
version="1.0">
{code}
> Default "tomcat" and "pluto" users are granted "manager-gui" role
> -
>
> Key: PLUTO-782
> URL: https://issues.apache.org/jira/browse/PLUTO-782
> Project: Pluto
> Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 3.0.0, 3.0.1, 3.1.0
>Reporter: Louis
>Assignee: Neil Griffin
>Priority: Critical
> Fix For: 3.1.1
>
>
> Hi,
> I just downloaded your software and saw that the passwords used to protect
> the local tomcat users are very predictable. It would be better to disable
> those accounts as they basically allow anyone to get command execution on the
> underlying server.
>
> People in charge can then add those accounts based on their requirements.
> Regards,
> Louis
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (PLUTO-782) Default "tomcat" and "pluto" users are granted "manager-gui" role
[ https://issues.apache.org/jira/browse/PLUTO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin closed PLUTO-782. -- Resolution: Fixed > Default "tomcat" and "pluto" users are granted "manager-gui" role > - > > Key: PLUTO-782 > URL: https://issues.apache.org/jira/browse/PLUTO-782 > Project: Pluto > Issue Type: Bug >Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 3.0.0, 3.0.1, 3.1.0 >Reporter: Louis >Assignee: Neil Griffin >Priority: Critical > Fix For: 3.1.1 > > > Hi, > I just downloaded your software and saw that the passwords used to protect > the local tomcat users are very predictable. It would be better to disable > those accounts as they basically allow anyone to get command execution on the > underlying server. > > People in charge can then add those accounts based on their requirements. > Regards, > Louis -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (PLUTO-782) Default "tomcat" and "pluto" users are granted "manager-gui" role
[ https://issues.apache.org/jira/browse/PLUTO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin reopened PLUTO-782: > Default "tomcat" and "pluto" users are granted "manager-gui" role > - > > Key: PLUTO-782 > URL: https://issues.apache.org/jira/browse/PLUTO-782 > Project: Pluto > Issue Type: Bug >Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 3.0.0, 3.0.1, 3.1.0 >Reporter: Louis >Assignee: Neil Griffin >Priority: Critical > Fix For: 3.1.2 > > > Hi, > I just downloaded your software and saw that the passwords used to protect > the local tomcat users are very predictable. It would be better to disable > those accounts as they basically allow anyone to get command execution on the > underlying server. > > People in charge can then add those accounts based on their requirements. > Regards, > Louis -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (PLUTO-782) Default "tomcat" and "pluto" users are granted "manager-gui" role
[
https://issues.apache.org/jira/browse/PLUTO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin closed PLUTO-782.
--
Resolution: Fixed
@[~snyff]: Thank you for reporting this issue. Please see commit
[4c80c6b051343c5c2cb7a34230f125d21a7901b7|https://github.com/apache/portals-pluto/commit/4c80c6b051343c5c2cb7a34230f125d21a7901b7]
for the fix, which will appear in the 3.1.2 release of Apache Pluto.
The solution was to comment-out the default "tomcat" and "pluto" logins as they
currently are, and replace them with a "pluto" login that does not have the
Tomcat "manager-gui" role.
For example:
{code:xml|title=tomcat-users.xml}
http://tomcat.apache.org/xml;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://tomcat.apache.org/xml
tomcat-users.xsd"
version="1.0">
{code}
> Default "tomcat" and "pluto" users are granted "manager-gui" role
> -
>
> Key: PLUTO-782
> URL: https://issues.apache.org/jira/browse/PLUTO-782
> Project: Pluto
> Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 3.0.0, 3.0.1, 3.1.0
>Reporter: Louis
>Assignee: Neil Griffin
>Priority: Critical
> Fix For: 3.1.2
>
>
> Hi,
> I just downloaded your software and saw that the passwords used to protect
> the local tomcat users are very predictable. It would be better to disable
> those accounts as they basically allow anyone to get command execution on the
> underlying server.
>
> People in charge can then add those accounts based on their requirements.
> Regards,
> Louis
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (PLUTO-782) Default "tomcat" and "pluto" users are granted "manager-gui" role
[ https://issues.apache.org/jira/browse/PLUTO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-782: --- Summary: Default "tomcat" and "pluto" users are granted "manager-gui" role (was: Passwords on tomcat manager) > Default "tomcat" and "pluto" users are granted "manager-gui" role > - > > Key: PLUTO-782 > URL: https://issues.apache.org/jira/browse/PLUTO-782 > Project: Pluto > Issue Type: Bug >Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 3.0.0, 3.0.1, 3.1.0 >Reporter: Louis >Assignee: Neil Griffin >Priority: Critical > Fix For: 3.1.2 > > > Hi, > I just downloaded your software and saw that the passwords used to protect > the local tomcat users are very predictable. It would be better to disable > those accounts as they basically allow anyone to get command execution on the > underlying server. > > People in charge can then add those accounts based on their requirements. > Regards, > Louis -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PLUTO-782) Passwords on tomcat manager
[ https://issues.apache.org/jira/browse/PLUTO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-782: --- Fix Version/s: 3.1.2 > Passwords on tomcat manager > --- > > Key: PLUTO-782 > URL: https://issues.apache.org/jira/browse/PLUTO-782 > Project: Pluto > Issue Type: Bug >Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 3.0.0, 3.0.1, 3.1.0 >Reporter: Louis >Assignee: Neil Griffin >Priority: Critical > Fix For: 3.1.2 > > > Hi, > I just downloaded your software and saw that the passwords used to protect > the local tomcat users are very predictable. It would be better to disable > those accounts as they basically allow anyone to get command execution on the > underlying server. > > People in charge can then add those accounts based on their requirements. > Regards, > Louis -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PLUTO-782) Passwords on tomcat manager
[ https://issues.apache.org/jira/browse/PLUTO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PLUTO-782: --- Affects Version/s: 3.0.1 3.0.0 2.0.3 2.0.2 2.0.1 2.0.0 > Passwords on tomcat manager > --- > > Key: PLUTO-782 > URL: https://issues.apache.org/jira/browse/PLUTO-782 > Project: Pluto > Issue Type: Bug >Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 3.0.0, 3.0.1, 3.1.0 >Reporter: Louis >Assignee: Neil Griffin >Priority: Critical > > Hi, > I just downloaded your software and saw that the passwords used to protect > the local tomcat users are very predictable. It would be better to disable > those accounts as they basically allow anyone to get command execution on the > underlying server. > > People in charge can then add those accounts based on their requirements. > Regards, > Louis -- 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=17460841#comment-17460841 ] Neil Griffin commented on PLUTO-781: [~riverbed2] Done, see commit [391a6a33249173c3e07f5622deff6784fe656cd7|https://github.com/apache/portals-pluto/commit/391a6a33249173c3e07f5622deff6784fe656cd7]. It will first check the portal level, and if not enabled for all, then it checks individually at the portlet level. > 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] [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=17460781#comment-17460781 ] Steve Potter commented on PLUTO-781: [~ngriffin7a] , Thanks for looking at the issue. However I think the issue is at the portal level and not at the portlet level and therefore the option should be at the portal level rather than on the individual portlet. For us it means setting the same parameter on 74 portlet definitions. Steve > 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)
