[JBoss JIRA] (WFLY-2708) Solr fails to deploy on CR1
by Rich Midwinter (JIRA)
Rich Midwinter created WFLY-2708:
------------------------------------
Summary: Solr fails to deploy on CR1
Key: WFLY-2708
URL: https://issues.jboss.org/browse/WFLY-2708
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.CR1
Reporter: Rich Midwinter
Solr (4.6) fails to deploy on CR1. I've had it working previously on Alpha builds and I gather it worked previously on Beta builds for someone else experiencing this issue - https://issues.apache.org/jira/browse/SOLR-5578
2014-01-04 12:59:34,138 WARN [org.jboss.modules] (weld-worker-1) Failed to define class org.apache.hadoop.hdfs.web.resources.UserProvider in Module "deployment.solr.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/apache/hadoop/hdfs/web/re
sources/UserProvider (Module "deployment.solr.war:main" from Service Module Loader)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:428) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:106) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:94) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.NoClassDefFoundError: com/sun/jersey/spi/inject/InjectableProvider
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_25]
at java.lang.ClassLoader.defineClass(ClassLoader.java:792) [rt.jar:1.7.0_25]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final]
... 20 more
Caused by: java.lang.ClassNotFoundException: com.sun.jersey.spi.inject.InjectableProvider from [Module "deployment.solr.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
... 24 more
2014-01-04 12:59:34,148 INFO [org.jboss.weld.Bootstrap] (weld-worker-1) WELD-000119: Not generating any bean definitions from org.apache.hadoop.hdfs.web.resources.UserProvider because of underlying class loading error: Type com.sun.jersey.spi.inject.InjectableProvider from [Module "deployment.solr.war:main" from Service Module Loader] not found. If this is unexpected, enable DEBUG logging to see the full error.
2014-01-04 12:59:34,893 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."solr.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."solr.war".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:361)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
... 3 more
2014-01-04 12:59:34,901 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "solr.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"solr.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"solr.war\".WeldStartService: Failed to start service
--
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, 4 months
[JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work with Wildfly CR1
by Otávio Garcia (JIRA)
[ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.... ]
Otávio Garcia commented on WFLY-2690:
-------------------------------------
Matus Zamborsky, I've tested with your commit from github, and works fine for me.
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
> Key: WFLY-2690
> URL: https://issues.jboss.org/browse/WFLY-2690
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
> Reporter: Otávio Garcia
> Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
> <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
> some code
> <jsp:doBody />
> more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
> <jsp:output omit-xml-declaration="yes" />
> my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730
--
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, 4 months
[JBoss JIRA] (WFLY-2704) FORM authentication credentials lost on failover
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-2704?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-2704:
------------------------------------
It seems like this is most easily addressed by allowing replication of the user principal stored with the session. Currently, Undertow's AuthenticatedSession is part of the local context of a session and is not replicated.
> FORM authentication credentials lost on failover
> ------------------------------------------------
>
> Key: WFLY-2704
> URL: https://issues.jboss.org/browse/WFLY-2704
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Final
>
>
> Unlike BASIC, DIGEST, and CERT authentication, FORM authentication requires an additional server side mechanism to store the credentials from the login form so that a user does not need to reauthenticate on failover.
> Traditionally, clustered SSO was the mechanism of choice (see https://issues.jboss.org/browse/JBAS-1900 )
> An analogous strategy is needed for Undertow.
--
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, 4 months
[JBoss JIRA] (WFLY-1351) Incorrect exception handling in CoreGroupCommunicationService#handle
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1351?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1351:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 963448|https://bugzilla.redhat.com/show_bug.cgi?id=963448] from NEW to POST
> Incorrect exception handling in CoreGroupCommunicationService#handle
> --------------------------------------------------------------------
>
> Key: WFLY-1351
> URL: https://issues.jboss.org/browse/WFLY-1351
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Dennis Reed
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Alpha3
>
>
> org/jboss/as/clustering/impl/CoreGroupCommunicationService#handle catches and hides any internal exceptions, and just returns null instead.
> This breaks callers of CoreGroupCommunicationService when they get a null value where it's not expected (after verifying that the response was not flagged as an exception)
> java.lang.NullPointerException
> at org.jboss.as.clustering.lock.AbstractClusterLockSupport.lock(AbstractClusterLockSupport.java:157)
> It also catches an exception from the called method, and returns it as the return value, instead of just throwing it as an exception so it can be properly returned as an exception inside JGroups' RequestCorrelator.
--
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, 4 months
[JBoss JIRA] (WFLY-898) SharedLocalYieldingLockManager.LocalLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-898?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-898:
----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 1039585|https://bugzilla.redhat.com/show_bug.cgi?id=1039585] from NEW to POST
> SharedLocalYieldingLockManager.LocalLock
> ----------------------------------------
>
> Key: WFLY-898
> URL: https://issues.jboss.org/browse/WFLY-898
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: MJ Kim
> Assignee: Paul Ferraro
>
> Hi,
>
> Recently my system has been in the QA. (includes Stress test, Endurance test)
> During the endurance test, I found that the heap space was getting exausted, and not removed after full gc.
> When the heap space got close to 90%, the gabage collection was happend every 2 min, and my system was stopped reponding.
> The heap space was not cleaned up, nevertheless I ended the test (no request during a few hours)
>
>
> I downloaded some heap dumps, and found that the SharedLocalYieldingLockManage.LocalLock() resided much of heap space. (above 60%)
> I think the session expiration doesn't operate porperly.
>
> If the SessionBasesClusteredSession class raises the expiration signals with "LocalOnly=True", the lock would not be removed.
>
> Addionally, I reviewed our source code and did a leakage discory test, anything was matter.
>
> Here is my environment. If you want to see my standalone.xml, please post a reply thread.
>
> <Cluster>
> - 8 JVM (4 machine, each 2)
> - JDK : 1.6u31
> - OS : Amazon Linux 64bit
> - JGroups : FILE_PING (The shared storage is GlusterFS volume)
> - Infinispan operation mode : L1 + Distribution / ASYNC / expiration 1min
> - Session handling : web.xml (expiration every 1min)
> (Originally our setting was 30 min. Beacuse the load generator was sending too many requests with new session, I lowered the threshold to 1min)
> - Source code : 7.1.3 Final tag (downloaded from Github)
--
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, 4 months
[JBoss JIRA] (WFLY-406) Redesign web session clustering
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-406?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-406:
----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 1039585|https://bugzilla.redhat.com/show_bug.cgi?id=1039585] from NEW to POST
> Redesign web session clustering
> -------------------------------
>
> Key: WFLY-406
> URL: https://issues.jboss.org/browse/WFLY-406
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Alpha2
>
>
> The current web session replication code has been around for ages and suffers from a number of issues:
> * By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
> * Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
> * Extra logic/locking is required to invalidate the local session map is required per request
> * AtomicMaps, on which the current implementation relies, have proven buggy
> * Session access outside of the scope of the replication valve is possible and problematic
> * Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
> * The current code base is tightly coupled to JBoss Web. Migrating the code to support Undertow will inevitably introduce issues and code duplication.
> The new design will incorporate a proper SPI for the servlet container. Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.
--
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, 4 months
[JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work with Wildfly CR1
by Matus Zamborsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.... ]
Matus Zamborsky commented on WFLY-2690:
---------------------------------------
Here is the reproducer. Its a simple web app, not a test case (sorry for that).
https://github.com/backslash47/wfly2690.git
To reproduce the error, try http://localhost:8080/wfly2690/index.jsp and then http://localhost:8080/wfly2690/index2.jsp
As of the possible fix I propose, please, look at this [Commit | https://github.com/backslash47/core/commit/22005cb9b9f561949f8490286c28b8...]
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
> Key: WFLY-2690
> URL: https://issues.jboss.org/browse/WFLY-2690
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
> Reporter: Otávio Garcia
> Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
> <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
> some code
> <jsp:doBody />
> more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
> <jsp:output omit-xml-declaration="yes" />
> my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730
--
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, 4 months