Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CUSTCOM-154 Ship Payara with newer version of JSF (2.3.13+) #4424

Closed
scolapasta opened this issue Jan 10, 2020 · 9 comments · Fixed by #4492
Closed

CUSTCOM-154 Ship Payara with newer version of JSF (2.3.13+) #4424

scolapasta opened this issue Jan 10, 2020 · 9 comments · Fixed by #4492
Milestone

Comments

@scolapasta
Copy link

scolapasta commented Jan 10, 2020

Description


While upgrading our project (Dataverse) from running on Glassfish 4.1 to Payara 5, one of the issues we've encountered is that partial submits that include javascript with <![CDATA[ and ]]> tags with do not work.

From some further analysis, this seems to be a bug that was introduced in JSF 2.3, but has since been fixed in the latest 2.3 (2.3.13) - see this issue: eclipse-ee4j/mojarra#4392

Expected Outcome

Pages with partial submits that include javascript with <![CDATA[ and ]]> tags should work.

Current Outcome

As described above, pages with partial submits that include javascript with <![CDATA[ and ]]> tags with do not work.

Steps to reproduce (Only for bug reports)

I haven't had time to create a simple test, but as this seems to already be a solved issue in a later version of JSF, it didn't seem necessary.

But you can see it in action on our payara 5 test server:
http://payara5.odum.unc.edu/

On a specific dataset, click the versions tab:
e.g. http://payara5.odum.unc.edu/dataset.xhtml?persistentId=doi:10.33563/FK2/WCD6TZ

(If you use Firefox, you'll see the '''XML Parsing Error: mismatched tag. Expected: .''' error in the console)

Context (Optional)

Here is the github issue in our project where we our tracking this:
IQSS/dataverse#6463

Without a fix for this, we cannot upgrade. That said, there are other ways to fix (move the javascript and remove CDATA tags), but the ideal for us in this upgrade is to minimize code change, especially in a case like this where the issue seems to be a bug in earlier versions of JSF 2.3.

Environment

  • Payara Version: 5.193, 5.194
  • JDK Version: 8
  • Operating System: Mac / Linux
  • Database: PostGres
@scolapasta scolapasta changed the title Ship Payara with newer version of JSF (2.3.13) Ship Payara with newer version of JSF (2.3.13+) Jan 12, 2020
@scolapasta
Copy link
Author

Note JSF 2.3.14 is now available, as well.

@rdebusscher rdebusscher self-assigned this Jan 13, 2020
@rdebusscher
Copy link

Hi,

I have created internal issue CUSTCOM-154 to upgrade to the latest Mojarra version.

Regards
Rudy.

@rdebusscher rdebusscher added the Status: Accepted Confirmed defect or accepted improvement to implement, issue has been escalated to Platform Dev label Jan 13, 2020
@scolapasta
Copy link
Author

Great! Is there any timeline for when this would happen? This feature is critical for our upgrade, so we need to decide if we will wait for this release or patch our app server with JSF 2.3.14.

@rdebusscher
Copy link

Hi,

No timeline determined yet.

You can include the recent Mojarra version into your war and use the enhanced classloading described in the document as a workaround.

Rudy

@scolapasta
Copy link
Author

Thanks @rdebusscher.

We did try that, but it didn't work for us - we got errors (I think I tried twice, and got a different error each time!). Here is one of the errors:

[#|2019-12-20T18:12:28.858+0000|SEVERE|Payara 5.194|javax.enterprise.system.core|_ThreadID=42;_ThreadName=admin-thread-pool::admin-listener(1);_TimeMillis=1576865548858;_LevelValue=1000;| Exception while loading the app : CDI deployment failure:WELD-001477: The bean Managed Bean [class edu.harvard.iq.dataverse.authorization.providers.oauth2.OAuth2LoginBackingBean] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class org.hibernate.validator.cdi.internal.interceptor.ValidationInterceptor intercepts @MethodValidated] with a non-passivation-capable dependency null -- WELD-001477: The bean Managed Bean [class edu.harvard.iq.dataverse.authorization.providers.oauth2.OAuth2LoginBackingBean] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class org.hibernate.validator.cdi.internal.interceptor.ValidationInterceptor intercepts @MethodValidated] with a non-passivation-capable dependency null|#]

What I did get to work (hence "patched app server") was to get the JSF 2.3.14 jar and replace jakarta,faces,jar in the payara5/glassfish/modules directory.

@smillidge
Copy link
Contributor

I think we should aim to get it into 201 as we tend to upgrade upstream components pretty regularly and more so at the start of the year.

@scolapasta
Copy link
Author

@smillidge is there any roadmap reference for upcoming Payara releases? So we can evaluate a) if this will be in that release and b) when that release is expected?

@smillidge
Copy link
Contributor

Still hoping for 201 near the end of Feb

@dmatej dmatej changed the title Ship Payara with newer version of JSF (2.3.13+) CUSTCOM-154 Ship Payara with newer version of JSF (2.3.13+) Feb 4, 2020
@rdebusscher
Copy link

Mojarra 2.3.14 will be part of version 5.201.

@rdebusscher rdebusscher removed the Status: Accepted Confirmed defect or accepted improvement to implement, issue has been escalated to Platform Dev label Feb 17, 2020
@rdebusscher rdebusscher removed their assignment Feb 17, 2020
@rdebusscher rdebusscher added this to the 5.201 milestone Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants