[
https://issues.apache.org/jira/browse/ISIS-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Keir Haywood updated ISIS-2758:
--------------------------------------
Description:
stack trace due to: ExceptionInInitializerError
"java.util.MissingResourceException: Can't find javax.faces.LogStrings bundle
from"
where call to currentUserName() brings in ImpersonatedUserHolder and ultimately
its proxy results in going down a code path to attempt to bring in JSF:
{code:java}
public abstract class RequestContextHolder {
private static final boolean jsfPresent =
ClassUtils.isPresent("javax.faces.context.FacesContext",
RequestContextHolder.class.getClassLoader());
{code}
this class is part of
{code:java}
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
</dependency>
{code}
referenced by both isis-commons and isis-applib.
*UPDATE:*
first attempt to solve this was to exclude the JSF classes. However, as they
are part of the overall javaee-api jar file (for JavaEE v8), this is
suprisingly difficult to do ... that is not a simple aggregator of the
respective specs in the JavaEE. And that approach increases the maintenance
effort.
And in any case, it just moved the exception but didn't completely resolve it
... the exception was being thrown in a static initializer of a proxy for
`ImpersonatedUserHolderWithSession`, as this latter class is annotated as
`@RequestScoped` but was called outside of an http request.
The fix I've used is to remove that annotation and instead to use
RequestContextHolder that can check if there's a thread-local that contains an
HttpRequest. This allows us to keep the dependency on javaee-api.
was:
stack trace due to: ExceptionInInitializerError
"java.util.MissingResourceException: Can't find javax.faces.LogStrings bundle
from"
where call to currentUserName() brings in ImpersonatedUserHolder and ultimately
its proxy results in going down a code path to attempt to bring in JSF:
{code:java}
public abstract class RequestContextHolder {
private static final boolean jsfPresent =
ClassUtils.isPresent("javax.faces.context.FacesContext",
RequestContextHolder.class.getClassLoader());
{code}
this class is part of
{code:java}
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
</dependency>
{code}
referenced by both isis-commons and isis-applib.
> Initial fixture scripts can fail to load due to JSF not present exception.
> --------------------------------------------------------------------------
>
> Key: ISIS-2758
> URL: https://issues.apache.org/jira/browse/ISIS-2758
> Project: Isis
> Issue Type: Bug
> Components: Isis Core
> Affects Versions: 2.0.0-M5
> Reporter: Daniel Keir Haywood
> Assignee: Daniel Keir Haywood
> Priority: Major
> Fix For: 2.0.0-M6
>
>
> stack trace due to: ExceptionInInitializerError
> "java.util.MissingResourceException: Can't find javax.faces.LogStrings bundle
> from"
> where call to currentUserName() brings in ImpersonatedUserHolder and
> ultimately its proxy results in going down a code path to attempt to bring in
> JSF:
> {code:java}
> public abstract class RequestContextHolder {
> private static final boolean jsfPresent =
> ClassUtils.isPresent("javax.faces.context.FacesContext",
> RequestContextHolder.class.getClassLoader());
> {code}
> this class is part of
> {code:java}
> <dependency>
> <groupId>javax</groupId>
> <artifactId>javaee-api</artifactId>
> </dependency>
> {code}
> referenced by both isis-commons and isis-applib.
> *UPDATE:*
> first attempt to solve this was to exclude the JSF classes. However, as they
> are part of the overall javaee-api jar file (for JavaEE v8), this is
> suprisingly difficult to do ... that is not a simple aggregator of the
> respective specs in the JavaEE. And that approach increases the maintenance
> effort.
> And in any case, it just moved the exception but didn't completely resolve it
> ... the exception was being thrown in a static initializer of a proxy for
> `ImpersonatedUserHolderWithSession`, as this latter class is annotated as
> `@RequestScoped` but was called outside of an http request.
> The fix I've used is to remove that annotation and instead to use
> RequestContextHolder that can check if there's a thread-local that contains
> an HttpRequest. This allows us to keep the dependency on javaee-api.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
