[JBoss JIRA] (WFLY-1796) Creating a pooled-connection-factory via the CLI requires confusing syntax
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1796?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1796:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1178229|https://bugzilla.redhat.com/show_bug.cgi?id=1178229] from MODIFIED to ON_QA
> Creating a pooled-connection-factory via the CLI requires confusing syntax
> --------------------------------------------------------------------------
>
> Key: WFLY-1796
> URL: https://issues.jboss.org/browse/WFLY-1796
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.0.0.Alpha3
> Reporter: Justin Bertram
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Alpha4
>
>
> When creating a pooled-connection factory via the CLI the syntax for the "connector" is confusing. Here is a simple example:
> {noformat}
> /subsystem=messaging/hornetq-server=default/pooled-connection-factory=my-pooled-connection-factory/:add(connector={"in-vm" => "xyz"}, entries=["java:/MyPooledCF"])
> {noformat}
> The "connector" wants a list of name-value pairs, but only the name is taken into consideration. This command results in this XML:
> {noformat}
> <pooled-connection-factory name="my-pooled-connection-factory">
> <connectors>
> <connector-ref connector-name="in-vm"/>
> </connectors>
> <entries>
> <entry name="java:/MyPooledCF"/>
> </entries>
> </pooled-connection-factory>
> {noformat}
> The "xyz" is completely unnecessary.
> I believe this is because {{org.jboss.as.messaging.jms.ConnectionFactoryAttributes.Common#CONNECTOR}} is defined as a {{org.jboss.as.controller.SimpleMapAttributeDefinition}} and it should probably just be a {{org.jboss.as.controller.PrimitiveListAttributeDefinition}} when used in the pooled-connection-factory.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1088463|https://bugzilla.redhat.com/show_bug.cgi?id=1088463] from MODIFIED to ON_QA
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4160) ConcurrentModificationException while deploy JSF application (8.2.0)
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4160?page=com.atlassian.jira.plugin.... ]
Farah Juma resolved WFLY-4160.
------------------------------
Resolution: Rejected
> ConcurrentModificationException while deploy JSF application (8.2.0)
> --------------------------------------------------------------------
>
> Key: WFLY-4160
> URL: https://issues.jboss.org/browse/WFLY-4160
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.2.0.Final
> Environment: WildFly (8.2.0 - Final)
> Reporter: Devendra Bargujar
> Assignee: Farah Juma
> Labels: new_and_noteworthy
> Attachments: jsf-sample-.ear, Log.txt
>
>
> While deploying 2 JSF application getting ConcurrentModificationException on NavigationHandlerImpl$NavigationMap$. App also uses seam 3.1.0. Please refer below stack trace.
> 11:57:21,898 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-2) Initializing Mojarra 2.2.8-jbossorg-1 20140822-1131 for context '/com'
> 11:57:21,898 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-6) Initializing Mojarra 2.2.8-jbossorg-1 20140822-1131 for context '/sof'
> 11:57:26,218 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-2) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:449) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:221) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:193) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) [rt.jar:1.8.0_25]
> at java.util.HashMap$EntryIterator.next(HashMap.java:1463) [rt.jar:1.8.0_25]
> at java.util.HashMap$EntryIterator.next(HashMap.java:1461) [rt.jar:1.8.0_25]
> at com.sun.faces.application.NavigationHandlerImpl$NavigationMap$4$1.next(NavigationHandlerImpl.java:1523) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.NavigationHandlerImpl$NavigationMap$4$1.next(NavigationHandlerImpl.java:1511) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at java.util.AbstractMap.get(AbstractMap.java:185) [rt.jar:1.8.0_25]
> at com.sun.faces.config.processor.NavigationConfigProcessor.addNavigationCasesForRule(NavigationConfigProcessor.java:323) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.NavigationConfigProcessor.addNavigationRules(NavigationConfigProcessor.java:224) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.NavigationConfigProcessor.process(NavigationConfigProcessor.java:167) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.RenderKitConfigProcessor.process(RenderKitConfigProcessor.java:196) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ManagedBeanConfigProcessor.process(ManagedBeanConfigProcessor.java:270) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ValidatorConfigProcessor.process(ValidatorConfigProcessor.java:120) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ConverterConfigProcessor.process(ConverterConfigProcessor.java:126) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ComponentConfigProcessor.process(ComponentConfigProcessor.java:117) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:344) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:116) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:239) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:435) [jsf-impl-2.2.8-jbossorg-1.jar:]
> Caused by: java.lang.NullPointerException
> at com.sun.faces.facelets.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:77) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.init(DefaultFaceletFactory.java:170) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationAssociate.createFaceletFactory(ApplicationAssociate.java:866) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationAssociate.initializeFacelets(ApplicationAssociate.java:327) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationAssociate.getCompiler(ApplicationAssociate.java:410) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:251) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:437) [jsf-impl-2.2.8-jbossorg-1.jar:]
> ... 10 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4160) ConcurrentModificationException while deploy JSF application (8.2.0)
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4160?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-4160:
----------------------------------
It turns out that this isn't a WildFly/JSF issue. The problem is related to some classes included in a shared library in the EAR. In particular, including SeamApplicationWrapper and SeamApplicationFactory in a shared library in the EAR (they're included in lib/seam-faces-3.1.0.Final.jar) ends up causing both WARs in the EAR to share the same com.sun.faces.application.ApplicationImpl instance (thus, the WARs share the same NavigationHandler instance). This is incorrect and seems to be what's causing the ConcurrentModificationException here.
> ConcurrentModificationException while deploy JSF application (8.2.0)
> --------------------------------------------------------------------
>
> Key: WFLY-4160
> URL: https://issues.jboss.org/browse/WFLY-4160
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.2.0.Final
> Environment: WildFly (8.2.0 - Final)
> Reporter: Devendra Bargujar
> Assignee: Farah Juma
> Labels: new_and_noteworthy
> Attachments: jsf-sample-.ear, Log.txt
>
>
> While deploying 2 JSF application getting ConcurrentModificationException on NavigationHandlerImpl$NavigationMap$. App also uses seam 3.1.0. Please refer below stack trace.
> 11:57:21,898 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-2) Initializing Mojarra 2.2.8-jbossorg-1 20140822-1131 for context '/com'
> 11:57:21,898 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-6) Initializing Mojarra 2.2.8-jbossorg-1 20140822-1131 for context '/sof'
> 11:57:26,218 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-2) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:449) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:221) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:193) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) [rt.jar:1.8.0_25]
> at java.util.HashMap$EntryIterator.next(HashMap.java:1463) [rt.jar:1.8.0_25]
> at java.util.HashMap$EntryIterator.next(HashMap.java:1461) [rt.jar:1.8.0_25]
> at com.sun.faces.application.NavigationHandlerImpl$NavigationMap$4$1.next(NavigationHandlerImpl.java:1523) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.NavigationHandlerImpl$NavigationMap$4$1.next(NavigationHandlerImpl.java:1511) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at java.util.AbstractMap.get(AbstractMap.java:185) [rt.jar:1.8.0_25]
> at com.sun.faces.config.processor.NavigationConfigProcessor.addNavigationCasesForRule(NavigationConfigProcessor.java:323) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.NavigationConfigProcessor.addNavigationRules(NavigationConfigProcessor.java:224) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.NavigationConfigProcessor.process(NavigationConfigProcessor.java:167) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.RenderKitConfigProcessor.process(RenderKitConfigProcessor.java:196) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ManagedBeanConfigProcessor.process(ManagedBeanConfigProcessor.java:270) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ValidatorConfigProcessor.process(ValidatorConfigProcessor.java:120) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ConverterConfigProcessor.process(ConverterConfigProcessor.java:126) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ComponentConfigProcessor.process(ComponentConfigProcessor.java:117) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:344) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:116) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:239) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:435) [jsf-impl-2.2.8-jbossorg-1.jar:]
> Caused by: java.lang.NullPointerException
> at com.sun.faces.facelets.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:77) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.init(DefaultFaceletFactory.java:170) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationAssociate.createFaceletFactory(ApplicationAssociate.java:866) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationAssociate.initializeFacelets(ApplicationAssociate.java:327) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationAssociate.getCompiler(ApplicationAssociate.java:410) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:251) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:437) [jsf-impl-2.2.8-jbossorg-1.jar:]
> ... 10 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-491) Improve ManagedAuditLoggerImpl.log() performance when disabled
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-491?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-491:
---------------------------------------
Assignee: (was: Brian Stansberry)
> Improve ManagedAuditLoggerImpl.log() performance when disabled
> --------------------------------------------------------------
>
> Key: WFCORE-491
> URL: https://issues.jboss.org/browse/WFCORE-491
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha15
> Reporter: James Livingston
> Priority: Minor
>
> org.jboss.as.controller.audit.ManagedAuditLoggerImpl.log/logJmxMethodAccess() does some work such as creating the log item which will just be thrown away if getLoggerStatus()==DISABLED.
> It may be worth checking if that is the case and skipping the work that will not be needed. If it was not for the applyHandlerUpdates() call, I think an "isDisabled" volatile flag could be used to avoid taking the lock at all there, which can be expensive due to it being a fair lock.
> This does not appear to show up as a issue unless you are performing a lot (thousands) of management operations in quick succession.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (ELY-20) Where does OTP fit into realms?
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-20?page=com.atlassian.jira.plugin.sys... ]
David Lloyd commented on ELY-20:
--------------------------------
This may tie in to adding verification-only support for realms.
> Where does OTP fit into realms?
> -------------------------------
>
> Key: ELY-20
> URL: https://issues.jboss.org/browse/ELY-20
> Project: WildFly Elytron
> Issue Type: Sub-task
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> Will investigate further once we have a pure LDAP impl in.
> We could have an architecture where we have an LDAP server that is then referenced by an OTP server or we could have the two somehow combined into one.
> There are also requirements related to marking a token as used or token invalidation after too many bad attempts - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months