[JBoss JIRA] (WFLY-2684) Security Domains not accessible throught web console
by Kenneth Jaeger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2684?page=com.atlassian.jira.plugin.... ]
Kenneth Jaeger commented on WFLY-2684:
--------------------------------------
I can confirm I am seeing this same behavior on Wildfly 8.0.0 CR1 running on Windows 7 SP using the following Java version:
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b121)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b63, mixed mode)
> Security Domains not accessible throught web console
> ----------------------------------------------------
>
> Key: WFLY-2684
> URL: https://issues.jboss.org/browse/WFLY-2684
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Console
> Affects Versions: 8.0.0.CR1
> Environment: Linux 2.6.32-358.23.2.el6.x86_64 (CentOS 6.4) with 1.7.0_45-mockbuild_2013_10_23_08_18-b00 (OpenJDK 7) or Windows 7 64bit with Oracle Java 7
> Reporter: Marko Mrvelj
> Assignee: Heiko Braun
>
> When trying to access Security Domains under Profile/Security tree, the call blocks. Tested on CentOS 6 and Windows 7 machine, and behaviour seems to be the same. Did not see problems with other parts of web console. Also security domains seem to be working when configured from CLI.
> Also once you click on "Security Domain" the whole console stops responding to the mouse, and web refresh is needed to get it back.
> On the same (Linux) machine this works in Beta1.
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-1950) Problems with connector 1.7
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-1950?page=com.atlassian.jira.plugin.... ]
Frank Langelage commented on WFLY-1950:
---------------------------------------
I don't see any progress.
To reproduce problems:
add
<resource-adapter>
<archive>filesystem.rar</archive>
<transaction-support>NoTransaction</transaction-support>
<config-property name="Path">/</config-property>
<connection-definitions>
<connection-definition jndi-name="java:/Filesystem" class-name="biz.mbisoftware.fn.jca.filesystem.FilesystemManagedConnectionFactory"/>
</connection-definitions>
</resource-adapter>
to standalone.xml.
Then remove
<reauthentication-support>false</reauthentication-support>
from META-INF/ra.xml.
Then
04.01. 20:37:39,452 ERROR [org.jboss.msc.service.fail#failed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar": JBAS010446: Failed to start RA deployment [filesystem.rar]
at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService$1.run(AbstractResourceAdapterDeploymentService.java:281) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60-ea]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60-ea]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_60-ea]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp/temp758703a19ace030c/filesystem.rar-b2b028622686a714/contents/
at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2611) [ironjacamar-deployers-common-1.1.2.Final.jar:1.1.2.Final]
at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:192) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:107) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [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_60-ea]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60-ea]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_60-ea]
Caused by: java.lang.NullPointerException
at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182) [ironjacamar-common-impl-1.1.2.Final.jar:1.1.2.Final]
at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2120) [ironjacamar-deployers-common-1.1.2.Final.jar:1.1.2.Final]
... 7 more
If you use filesystem-ra.xml.before as META-INF/ra.xml then you get irritating error:
04.01. 20:47:32,049 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar": org.jboss.msc.service.DuplicateServiceException: Service jboss.ra.filesystem is already registered
at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:137)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [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_60-ea]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60-ea]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_60-ea]
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.ra.filesystem is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:131)
... 5 more
> Problems with connector 1.7
> ---------------------------
>
> Key: WFLY-1950
> URL: https://issues.jboss.org/browse/WFLY-1950
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Frank Langelage
> Assignee: Jeff Zhang
> Attachments: filesystem-ra.xml.1.6.1.7, filesystem-ra.xml.1.7, filesystem-ra.xml.before, filesystem.rar
>
>
> Usually I see this when deploying my RA:
> 21:30:53,599 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:30:53,745 INFO [org.jboss.as.connector.deployment#bindConnectionFactory] JBAS010406: Registered connection factory java:/Filesystem
> 21:30:53,750 INFO [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] IJ020002: Deployed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-acf9504f544e0a1d/contents/
> 21:30:53,764 INFO [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> 21:30:53,822 INFO [org.jboss.as.server#handleResult] JBAS018559: Deployed "filesystem.rar" (runtime-name : "filesystem.rar")
> Because JCA 1.7 was introduced to head at github I changed header of ra.xml to 1.7 version.
> But then I no longer see the line
> 21:30:53,764 INFO [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> I did not specify the <outbound-resourceadapter> in ra.xml.
> Another adapter is working fine after version upgrade.
> So I added the <outbound-resourceadapter> also to the now failing one.
> But this gives this now:
> 21:35:57,797 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:35:57,941 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:136)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:120)
> ... 5 more
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2564)
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:197)
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:113)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182)
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2073)
> ... 7 more
> 21:35:57,962 ERROR [org.jboss.as.controller.management-operation#executeStep] JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "filesystem.rar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
> Caused by: java.lang.NullPointerException"}}
> 21:35:57,982 ERROR [org.jboss.as.server#handleResult] JBAS015870: Deploy of deployment "filesystem.rar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
> Caused by: java.lang.NullPointerException"}}
> 21:35:58,011 INFO [org.jboss.as.server.deployment#stop] JBAS015877: Stopped deployment filesystem.rar (runtime-name: filesystem.rar) in 24ms
> Adding also <reauthentication-support>false</reauthentication-support> solves this NPE, the RA gets deployed and bound to JNDI again.
--
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
10 years, 4 months
[JBoss JIRA] (JBLOGGING-100) JBossLogManagerLogger unconditionally does string conversion
by Philippe Marschall (JIRA)
Philippe Marschall created JBLOGGING-100:
--------------------------------------------
Summary: JBossLogManagerLogger unconditionally does string conversion
Key: JBLOGGING-100
URL: https://issues.jboss.org/browse/JBLOGGING-100
Project: JBoss Logging
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: jboss-logging-logmanager
Affects Versions: 3.1.3.GA
Reporter: Philippe Marschall
Assignee: James Perkins
{{JBossLogManagerLogger#doLog}} always converts the message to a String even if the level isn't loggable. This can have a negative performance impact and result in a lot of unnecessary allocations.
For example {{LogAuditProvider#audit}} does trace logging which ends up calling {{AuditEvent#toString}} even if trace logging isn't enabled. In our case this results in a lot of allocations outside of TLABs.
--
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
10 years, 4 months
[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
10 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
10 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
10 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
10 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
10 years, 4 months