[JBoss JIRA] (WFLY-4627) Issue when connecting to JBoss 7.1.1 queues installed in Linux from custom application installed in HP-UX
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4627?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4627:
-----------------------------------
We no longer do any development on 7.1 of code, so it is pretty much impossible for us to test or supply a fix.
Current development is focused on version 10, which 9 final coming out shortly.
Keep in mind that JBoss AS now renamed to WildFly is community driven effort where we try to make it work on as many platforms as we can, but we don't have access to all kinds of hardware enterprises use. So usually most testing is done on intel x86 with linux & windows being main target. We do try to fix problems if folks in community find on various platforms but fixes for that always go to latest "master" stream and are than available as part of next releases.
I would recommend you try commercially supported JBoss EAP 6 which was originally based of 7.1 and is tested and certified on platforms like this.
EAP undergoes much more rigourus testing on bigger set of platforms for which support is later offered.
See list of all supported platforms/JDKs at: https://access.redhat.com/articles/111663
> Issue when connecting to JBoss 7.1.1 queues installed in Linux from custom application installed in HP-UX
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4627
> URL: https://issues.jboss.org/browse/WFLY-4627
> Project: WildFly
> Issue Type: Bug
> Environment: JBoss AS 7.1.1
> JDK: 1.6.0_13
> Operating System: Linux
> Reporter: Carmen Rodriguez Leon
> Assignee: Jason Greene
>
> I have a JBoss AS 7.1.1 deployed in a machine with the environment detailed above. In this JBoss I have 4 queues deployed.
> I run Jboss as follows:
> ./standalone.sh -c standalone-full.xml -b xxx.xxx.xx.xxx -bmanagement=xxx.xxx.xx.xxx &
> I have successfully connected HermesJMS from a remote machine (also using Linux) to the JBoss queues.
> However, when I try to connect to the queues from a custom application hosted in a remote machine using HP-UX, I get the following error:
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:615)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:121)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:116)
> Caused by: HornetQException[errorCode=2 message=Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:619)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:611)
> ... 6 more
> I'm quite sure that it is not a connectivity issue because if I configure a wrong username/password it says: Invalid username or password so it's connecting properly to JBoss. The problem is when connecting to the queues.
> Regarding the configuration of our custom application, it is exactly the same than the one used in HermesJMS (also the same libraries), so it should be ok as HermesJMS connects properly.
> The only difference is in the Operating System: JBoss and HermesJMS are installed in Linux while our custom application is installed in HP-UX. May this be an issue?
> Regards
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4690) Include in Jsp cause StackOverflow
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4690?page=com.atlassian.jira.plugin.... ]
Stuart Douglas closed WFLY-4690.
--------------------------------
Resolution: Out of Date
> Include in Jsp cause StackOverflow
> ----------------------------------
>
> Key: WFLY-4690
> URL: https://issues.jboss.org/browse/WFLY-4690
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: JDK 8.45
> Reporter: Bertrand Cedric
> Assignee: Tomaz Cerar
> Attachments: sample.war, sample2.war
>
>
> When i made an include in a jsp an other jsp, I get a stackoverflow.
> I think that wildfly don't include the seconde jsp but the first and cause a infinity loop
> I also try to update the version of undertown to the latest jar found (undertow-core-1.1.4.Final, undertow-servlet-1.1.4.Final, undertow-websockets-jsr-1.1.4.Final)
> And a stuck of the stacktrace
> {noformat}
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fotherwise_005f1(OneColumn_jsp.java:726)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fchoose_005f2(OneColumn_jsp.java:671)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fif_005f2(OneColumn_jsp.java:639)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspService(OneColumn_jsp.java:239)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198)
> at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
> at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:940)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fotherwise_005f1(OneColumn_jsp.java:726)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fchoose_005f2(OneColumn_jsp.java:671)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fif_005f2(OneColumn_jsp.java:639)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspService(OneColumn_jsp.java:239)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198)
> at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
> at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:940)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fotherwise_005f1(OneColumn_jsp.java:726)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fchoose_005f2(OneColumn_jsp.java:671)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspx_meth_c_005fif_005f2(OneColumn_jsp.java:639)
> at org.apache.jsp.WEB_002dINF.jsp.templates.OneColumn_jsp._jspService(OneColumn_jsp.java:239)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (AS7-3940) bundled jsf deployment fails when org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL true
by Siva P (JIRA)
[ https://issues.jboss.org/browse/AS7-3940?page=com.atlassian.jira.plugin.s... ]
Siva P commented on AS7-3940:
-----------------------------
Hello Mr.Stuart,
I am still getting the same error in the JBoss AS:7.3.0 Final and Component:EAP 6.2.0.
Migrating Technology:
Richfaces: 4.5.5
Seam:2.2.3
JSF:2.1
Server:Jboss Eap 6.2
A bug in Mojarra (JAVASERVERFACES-3157) affects the ExtendedPartialViewContext in RichFaces 4.5. As such we’ve implemented a check that you are running a patched version of Mojarra ≥ 2.1.28 or ≥ 2.2.6.
{quote}
16:46:43,607 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 61) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! Class org.jboss.as.jsf.injection.JandexAnnotationProvider is not an instance of com.sun.faces.spi.AnnotationProvider
{quote}
I have attached the log file ,deployment-structure and module.xml file.
Thank you.
> bundled jsf deployment fails when org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL true
> --------------------------------------------------------------------------------
>
> Key: AS7-3940
> URL: https://issues.jboss.org/browse/AS7-3940
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.0.Final
> Reporter: Juergen Hoffmann
> Assignee: Stuart Douglas
> Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
> Attachments: faces-config.xml, jboss-deployment-structure.xml, jsf-api-2.1.28.jar, jsf-impl-2.1.28.jar, LogFile.txt, module-jsf-api.xml, module-jsf-impl.xml, web.xml
>
>
> It is impossible for Applications to bundle their own JSF Implementations even with org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL defined in web.xml, because jboss-as-web provides META-INF/services/com.sun.faces.spi.annotationprovider and injectionprovider please see https://github.com/jbossas/jboss-as/tree/master/web/src/main/resources/ME... and therefor will always try to use the JandexAnnotationProvider, which cannot work on different JSF Versions
> 12:29:30,105 SCHWERWIEGEND [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! Class org.jboss.as.web.deployment.jsf.JandexAnnotationProvider is not an instance of com.sun.faces.spi.AnnotationProvider
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (AS7-3940) bundled jsf deployment fails when org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL true
by Siva P (JIRA)
[ https://issues.jboss.org/browse/AS7-3940?page=com.atlassian.jira.plugin.s... ]
Siva P updated AS7-3940:
------------------------
Attachment: faces-config.xml
jboss-deployment-structure.xml
jsf-api-2.1.28.jar
jsf-impl-2.1.28.jar
LogFile.txt
module-jsf-api.xml
module-jsf-impl.xml
web.xml
> bundled jsf deployment fails when org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL true
> --------------------------------------------------------------------------------
>
> Key: AS7-3940
> URL: https://issues.jboss.org/browse/AS7-3940
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.0.Final
> Reporter: Juergen Hoffmann
> Assignee: Stuart Douglas
> Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
> Attachments: faces-config.xml, jboss-deployment-structure.xml, jsf-api-2.1.28.jar, jsf-impl-2.1.28.jar, LogFile.txt, module-jsf-api.xml, module-jsf-impl.xml, web.xml
>
>
> It is impossible for Applications to bundle their own JSF Implementations even with org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL defined in web.xml, because jboss-as-web provides META-INF/services/com.sun.faces.spi.annotationprovider and injectionprovider please see https://github.com/jbossas/jboss-as/tree/master/web/src/main/resources/ME... and therefor will always try to use the JandexAnnotationProvider, which cannot work on different JSF Versions
> 12:29:30,105 SCHWERWIEGEND [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! Class org.jboss.as.web.deployment.jsf.JandexAnnotationProvider is not an instance of com.sun.faces.spi.AnnotationProvider
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4712) Old session id in request crashes servlet handler before reaching rest endpoint
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4712?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4712:
------------------------------------
Assignee: Paul Ferraro (was: Stuart Douglas)
> Old session id in request crashes servlet handler before reaching rest endpoint
> -------------------------------------------------------------------------------
>
> Key: WFLY-4712
> URL: https://issues.jboss.org/browse/WFLY-4712
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Clustering, Web (Undertow), Web Services
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: SmartOS, CentOS 7, Oracle JDK 7
> Reporter: Michael Noack
> Assignee: Paul Ferraro
> Priority: Critical
>
> Clients with old/wrong JSESSIONIDs in requests will get a 500 internal server error. The rest endpoint they call won't be reached, even if no session information is required to process the request.
> This is particularly annoying in A/B-deployments where two or more server-groups are used for role-out of new deployments of the same web application. Clients that are connected to "server-group A" will get a 500 for their request, once the load-balancer switches them to "server-group B".
> 2015-06-01 12:37:19,642 ERROR [io.undertow.request] (default task-339) UT005023: Exception handling request to /myApp/status: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:319)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:308)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:163)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:688) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:364) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:212) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:160) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:260) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0-internal]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0-internal]
> 2015-06-01 12:37:19,648 ERROR [io.undertow.servlet.request] (default task-339) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.NullPointerException
> at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:71) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.context.http.HttpRequestContextImpl.deactivate(HttpRequestContextImpl.java:72) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:282) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:143) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:304) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0-internal]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0-internal]
> The expected behavior is that:
> A) wildfly should simply create a new session (which it already does)
> B) wildfly should process the request as if the user came with no session information at all (instead of returning a 500 server error)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4712) Old session id in request crashes servlet handler before reaching rest endpoint
by Michael Noack (JIRA)
Michael Noack created WFLY-4712:
-----------------------------------
Summary: Old session id in request crashes servlet handler before reaching rest endpoint
Key: WFLY-4712
URL: https://issues.jboss.org/browse/WFLY-4712
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Clustering, Web (Undertow), Web Services
Affects Versions: 8.2.0.Final, 8.1.0.Final
Environment: SmartOS, CentOS 7, Oracle JDK 7
Reporter: Michael Noack
Assignee: Stuart Douglas
Priority: Critical
Clients with old/wrong JSESSIONIDs in requests will get a 500 internal server error. The rest endpoint they call won't be reached, even if no session information is required to process the request.
This is particularly annoying in A/B-deployments where two or more server-groups are used for role-out of new deployments of the same web application. Clients that are connected to "server-group A" will get a 500 for their request, once the load-balancer switches them to "server-group B".
2015-06-01 12:37:19,642 ERROR [io.undertow.request] (default task-339) UT005023: Exception handling request to /myApp/status: java.lang.NullPointerException
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:319)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:308)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:163)
at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:688) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:364) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:212) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:160) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:260) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0-internal]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0-internal]
2015-06-01 12:37:19,648 ERROR [io.undertow.servlet.request] (default task-339) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.NullPointerException
at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:71) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.context.http.HttpRequestContextImpl.deactivate(HttpRequestContextImpl.java:72) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:282) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:143) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:304) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0-internal]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0-internal]
The expected behavior is that:
A) wildfly should simply create a new session (which it already does)
B) wildfly should process the request as if the user came with no session information at all (instead of returning a 500 server error)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4711) Invalid Last-Modified header
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-4711:
------------------------------------
Summary: Invalid Last-Modified header
Key: WFLY-4711
URL: https://issues.jboss.org/browse/WFLY-4711
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Environment: Windows Server 2008
Reporter: Davy De Durpel
Assignee: Stuart Douglas
After 2 months of use Wildfly suddenly started to send an invalid Last-Modified header. Normally it should be in the format:
Fri, 10 Oct 2014 19:35:55 GMT
But sometimes it sends:
Fri, 10 Oct 2014 21:35:55 CEST
Or even:
Fri, 10 Oct 2014 21:35:55 CEST GMT
The URLConnection.getLastModified() method cannot handle these 2 last formats as it uses an old and deprecated Date.parse(..) method.
A restart of the service fixes the issue for a few hours after which it reappears but not for all requests. We switched back to JBoss 7.1.1 and the issue disappeared completely so we're pretty sure that it's a bug in WildFly. No updates were done to windows, java and Wildfly that could have triggered the issue. We noticed the issue because we have a java applet running at the customer side. We use URLConnection to download some files based on the last modification date of these files. Browsers don't seem to be affected by the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFCORE-725) Remove ClassIndex from the server module
by Stuart Douglas (JIRA)
Stuart Douglas created WFCORE-725:
-------------------------------------
Summary: Remove ClassIndex from the server module
Key: WFCORE-725
URL: https://issues.jboss.org/browse/WFCORE-725
Project: WildFly Core
Issue Type: Task
Components: Server
Reporter: Stuart Douglas
Assignee: Stuart Douglas
ClassIndex is only used in a couple of places, and it is confusing to have two different indexes. It should be merged into ClassReflectionIndex.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months