[JBoss JIRA] (WFLY-12701) JSTL EL Evulation not working properly throwing NoClassDefFoundError
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12701?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-12701:
--------------------------------------
[~akash5551] I've found a workaround. Instead of wildcard import if you import the full type it works.
{code}
<%@ page import="com.akash.Person" %>
{code}
> JSTL EL Evulation not working properly throwing NoClassDefFoundError
> ---------------------------------------------------------------------
>
> Key: WFLY-12701
> URL: https://issues.jboss.org/browse/WFLY-12701
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 16.0.0.Final
> Environment: Windows
> Reporter: Akash Gupta
> Priority: Major
> Attachments: sample-NCDFE-1.0.war, sample-NCDFE-1.0.war, simple-servlet.war
>
>
> Following is the stacktrace of server running on wildlfy
> {code}
> 2019/10/21 17:02:09 WARN [org.jboss.modules.define] Failed to define class com.akash.web.beans.deviceBean in Module "deployment.sample.ear.sample1.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link com/akash/web/beans/deviceBean (Module "deployment.sample.ear.sample1.war" from Service Module Loader): com/akash/web/beans/deviceBean (wrong name: com/akash/web/beans/DeviceBean)
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_212]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) [rt.jar:1.8.0_212]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:839) [rt.jar:1.8.0_212]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:731) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) [jboss-modules.jar:1.9.0.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.8.0_212]
> at java.lang.Class.forName(Class.java:348) [rt.jar:1.8.0_212]
> at javax.el.ImportHandler.getClassFor(ImportHandler.java:176) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at javax.el.ImportHandler.resolveClassFor(ImportHandler.java:165) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at javax.el.ImportHandler.resolveClass(ImportHandler.java:128) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at org.wildfly.extension.undertow.ImportedClassELResolver.getValue(ImportedClassELResolver.java:83)
> at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:96) [jastow-2.0.7.Final.jar:2.0.7.Final]
> at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.parser.AstValue.getBase(AstValue.java:150) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:199) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at javax.el.ImportHandler.resolveClassFor(ImportHandler.java:161) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at javax.el.ImportHandler.resolveClass(ImportHandler.java:128) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at org.wildfly.extension.undertow.ImportedClassELResolver.getValue(ImportedClassELResolver.java:83)
> at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:96) [jastow-2.0.7.Final.jar:2.0.7.Final]
> at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.parser.AstValue.getBase(AstValue.java:150) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:199) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:917) [jastow-2.0.7.Final.jar:2.0.7.Final]
> at org.apache.jsp.task_frames_jsp._jspService(task_frames_jsp.java:2641)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4485?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4485:
--------------------------------
Fix Version/s: 11.0.0.Beta3
(was: 11.0.0.Beta2)
> Support for multiple security realms - Distributed Identities
> -------------------------------------------------------------
>
> Key: WFCORE-4485
> URL: https://issues.jboss.org/browse/WFCORE-4485
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19, Previous_RFE
> Fix For: 11.0.0.Beta3
>
>
> By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list.
> This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together.
> Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged.
> This RFE is not about fail over in the event of a realm being unavailable although it may be related.
> This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-4482) Out of the box SSL with Wildfly Elytron
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4482?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4482:
--------------------------------
Fix Version/s: 11.0.0.Beta3
(was: 11.0.0.Beta2)
> Out of the box SSL with Wildfly Elytron
> ---------------------------------------
>
> Key: WFCORE-4482
> URL: https://issues.jboss.org/browse/WFCORE-4482
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
> Labels: EAP-CD19
> Fix For: 11.0.0.Beta3
>
>
> The details of this RFE will be explored within the analysis, presently Undertow depends on a security-realm that generates a self signed cert on start up so we will require an Elytron equivalent.
> There may be opportunities to tie this in in some way with the new CA integration support but that can be explored in the analysis.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-944?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFCORE-944:
-------------------------------
Fix Version/s: 11.0.0.Beta3
(was: 11.0.0.Beta2)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.jboss.org/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Priority: Major
> Fix For: 11.0.0.Beta3
>
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months