[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3144:
--------------------------------------
This is a Weld issue. See WELD-1635 for fix.
The fix in WildFly will require a Weld upgrade.
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Clustering, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Radoslav Husar
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3144:
---------------------------------
Fix Version/s: 8.0.1.Final
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Clustering, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Radoslav Husar
> Fix For: 8.0.1.Final
>
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Jason Kim (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Jason Kim commented on WFLY-3033:
---------------------------------
I just enabled "path" configuration and am using it on my wildfly. Figured, some others may not want to wait for the update so I put in a pull request. Pull request - https://github.com/wildfly/wildfly/pull/6099
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3185) Strip cluster name from node names
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3185:
----------------------------------
Summary: Strip cluster name from node names
Key: WFLY-3185
URL: https://issues.jboss.org/browse/WFLY-3185
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 9.0.0.CR1
Currently, we generate cluster node names using the following format:
node-name/cluster-name
Including the cluster-name in the node name is redundant and only serves to add unnecessary bytes to messages.
We just need to make sure to include the cluster name in any log messages that refer to the node name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (DROOLS-458) Drools lock in StatelessKnowledgeSessionImpl.
by Desmond Silveira (JIRA)
[ https://issues.jboss.org/browse/DROOLS-458?page=com.atlassian.jira.plugin... ]
Desmond Silveira commented on DROOLS-458:
-----------------------------------------
I looked through the relevant Drools source code in detail, and I would agree that the synchronization _seems_ to be implemented correctly. But the fact that I had so many threads blocked for a long period of time certainly seems to indicate that there's a problem in the code.
> Drools lock in StatelessKnowledgeSessionImpl.
> ---------------------------------------------
>
> Key: DROOLS-458
> URL: https://issues.jboss.org/browse/DROOLS-458
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Tomcat 7
> Reporter: Desmond Silveira
> Assignee: Mario Fusco
> Attachments: la3ldspg05b.txt
>
>
> My Tomcat HTTP BIO connector threads (129 of them) got BLOCKED in my production Tomcat 7 instance because Drool 6.0.1 wasn't releasing a lock.
> Here is a snippet of the thread dump:
> {noformat}
> "http-bio-172.16.216.19-80-exec-37513" - Thread t@6245360
> java.lang.Thread.State: BLOCKED
> at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:20)
> - waiting to lock <219dcd77> (a java.lang.Class) owned by "http-bio-172.16.216.19-80-exec-37511" t@6245358
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> at com.local.lds.LdsBean.search(LdsBean.java:200)
> at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> - locked <3575a054> (a org.apache.tomcat.util.net.SocketWrapper)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Locked ownable synchronizers:
> - locked <719df963> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37511" - Thread t@6245358
> java.lang.Thread.State: RUNNABLE
> at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:212)
> - locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:207)
> - locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.loadProvider(ProcessRuntimeFactory.java:27)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:21)
> - locked <219dcd77> (a java.lang.Class)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> at com.local.lds.LdsBean.search(LdsBean.java:200)
> at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> - locked <474f2464> (a org.apache.tomcat.util.net.SocketWrapper)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Locked ownable synchronizers:
> - locked <339f344e> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37447" - Thread t@6233953
> java.lang.Thread.State: BLOCKED
> at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> - waiting to lock <555896b3> (a org.drools.core.common.ProjectClassLoader) owned by "http-bio-172.16.216.19-80-exec-37519" t@6245366
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> at org.drools.core.common.AbstractWorkingMemory.initInitialFact(AbstractWorkingMemory.java:385)
> at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:378)
> at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:261)
> at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:15)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:134)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> at com.local.lds.LdsBean.search(LdsBean.java:200)
> at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> - locked <57e6b780> (a org.apache.tomcat.util.net.SocketWrapper)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Locked ownable synchronizers:
> - locked <726294fc> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37519" - Thread t@6245366
> java.lang.Thread.State: RUNNABLE
> at java.lang.ClassLoader.findLoadedClass0(Native Method)
> at java.lang.ClassLoader.findLoadedClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> - locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> at org.drools.core.common.ProjectClassLoader.internalLoadClass(ProjectClassLoader.java:99)
> at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> - locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:164)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:400)
> at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> at com.local.lds.LdsBean.search(LdsBean.java:200)
> at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> - locked <43c2901> (a org.apache.tomcat.util.net.SocketWrapper)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Locked ownable synchronizers:
> - locked <88f8fa9> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> Here is the code that I use to call Drools:
> {code:java}
> public static Collection<ResultSet> applyRule(String rule,
> KieBase kb, Collection<ResultSet> resultSets, SearchParameters params) {
> try {
> if (kb == null) {
> return resultSets;
> }
> StatelessKieSession ksession = kb.newStatelessKieSession();
> ksession.setGlobal(OUTPUT, new ArrayList<>());
> Collection<Object> collection = new ArrayList<Object>(resultSets);
> collection.add(params);
> ksession.execute(collection);
> return (Collection<ResultSet>) ksession.getGlobals().get(OUTPUT);
> } catch (ConsequenceException e) {
> LOG.error("Error in rule: " + rule + " " + e.getRule(), e);
> throw e;
> } catch (RuntimeException e) {
> LOG.error("Error in rule: " + rule, e);
> throw e;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3100) ClassCastException in JSPs where spring-web tags and jstl tags are used
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3100.
-------------------------------
Assignee: Shelly McGowan (was: Remy Maucherat)
Fix Version/s: 8.0.1.Final
Resolution: Done
Fixed version of spec jsp api was merged to master.
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
> Key: WFLY-3100
> URL: https://issues.jboss.org/browse/WFLY-3100
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE, Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: abhishek vijra
> Assignee: Shelly McGowan
> Labels: jsp, jstl
> Fix For: 8.0.1.Final
>
> Attachments: spring-fun.war
>
>
> Following JSP with spring tags
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
> <head><title>Simple jsp page</title></head>
> <body>
>
> <c:set var="hasError" value="${param.hasError}" />
> <c:set var="msg" value="${param.msg}" />
>
> <c:if test="${param.hasError=='true'}">
> Message: <spring:message text="${param.msg}"/>
> </c:if>
>
> </body>
> </html>
> breaks following error
> ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3177) wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3177?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-3177:
------------------------------------
In the wildfly/modules/system/layers/base/org/eclipse/persistence/main folder is the jipijapa-eclipselink-1.0.1.Final.jar file. Contents of jipijapa-eclipselink-1.0.1.Final.jar are:
{quote}
META-INF/
META-INF/MANIFEST.MF
org/
org/jipijapa/
org/jipijapa/eclipselink/
META-INF/services/
org/jipijapa/eclipselink/JBossAS7ServerPlatform.class
org/jipijapa/eclipselink/VFSArchive.class
org/jipijapa/eclipselink/VFSArchive$1.class
org/jipijapa/eclipselink/JBossAS7ServerPlatform$JBossAS7TransactionController.class
org/jipijapa/eclipselink/EclipseLinkPersistenceProviderAdaptor.class
org/jipijapa/eclipselink/JBossArchiveFactoryImpl.class
org/jipijapa/eclipselink/JBossLogger.class
META-INF/services/org.jipijapa.plugin.spi.PersistenceProviderAdaptor
META-INF/maven/
META-INF/maven/org.jipijapa/
META-INF/maven/org.jipijapa/jipijapa-eclipselink/
META-INF/maven/org.jipijapa/jipijapa-eclipselink/pom.xml
META-INF/maven/org.jipijapa/jipijapa-eclipselink/pom.properties
{quote}
In [https://github.com/jipijapa/jipijapa/blob/master/eclipselink/src/main/jav...], the "eclipselink.logging.logger" property should be set to org.jipijapa.eclipselink.JBossLogger which looks right to me.
What are your persistence.xml contents?
> wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3177
> URL: https://issues.jboss.org/browse/WFLY-3177
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Ravshan Samandarov
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3184) Accept non-list params for deployment add command's 'content' param
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3184:
--------------------------------------
Summary: Accept non-list params for deployment add command's 'content' param
Key: WFLY-3184
URL: https://issues.jboss.org/browse/WFLY-3184
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
The deployment resource's 'content' attribute is of type list, but it only accepts a single element. Changing this would break compatibility, but it would be nice if CLI users could skip the useless [].
This could be handled server-side using a ParameterCorrector, but we'd need to figure out how to prevent validation problems when the user tries it in the CLI.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month