[JBoss JIRA] (WFLY-3758) Unable to run JSF applications deployed to "/"
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3758?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3758:
------------------------------------
Assignee: Stuart Douglas (was: Tomaz Cerar)
> Unable to run JSF applications deployed to "/"
> -----------------------------------------------
>
> Key: WFLY-3758
> URL: https://issues.jboss.org/browse/WFLY-3758
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Environment: WildFly master at 50a830205c, JDK 1.7
> Reporter: Ken H
> Assignee: Stuart Douglas
>
> I don't think the patch in pull request 6338 is right. I experienced the issue defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x).
> From web.xml:
> {code}
> <welcome-file-list>
> <welcome-file>/</welcome-file>
> </welcome-file-list>
> {code}
> From jboss-web.xml:
> {code}
> <jboss-web>
> <context-root>/</context-root>
> </jboss-web>
> {code}
> My app is packaged as a war, so no application.xml exists to define context-root.
> I would say this is a regression caused by the resolution to WLFY-3448
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3758) Unable to run JSF applications deployed to "/"
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3758?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3758:
--------------------------------------
This will be fixed in Undertow 1.1.0.Beta7
> Unable to run JSF applications deployed to "/"
> -----------------------------------------------
>
> Key: WFLY-3758
> URL: https://issues.jboss.org/browse/WFLY-3758
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Environment: WildFly master at 50a830205c, JDK 1.7
> Reporter: Ken H
> Assignee: Stuart Douglas
>
> I don't think the patch in pull request 6338 is right. I experienced the issue defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x).
> From web.xml:
> {code}
> <welcome-file-list>
> <welcome-file>/</welcome-file>
> </welcome-file-list>
> {code}
> From jboss-web.xml:
> {code}
> <jboss-web>
> <context-root>/</context-root>
> </jboss-web>
> {code}
> My app is packaged as a war, so no application.xml exists to define context-root.
> I would say this is a regression caused by the resolution to WLFY-3448
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-2859:
---------------------------------
Thanks, Stuart. I'm just looking for things to close.
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
> Key: WFLY-2859
> URL: https://issues.jboss.org/browse/WFLY-2859
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.CR1
> Reporter: Matt Drees
> Assignee: Stuart Douglas
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2859:
--------------------------------------
AFAIK my proposed patch is ok, but I have not had time to do any sort of extensive testing (i.e. run the WF test suite with a patched resteasy)
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
> Key: WFLY-2859
> URL: https://issues.jboss.org/browse/WFLY-2859
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.CR1
> Reporter: Matt Drees
> Assignee: Stuart Douglas
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-2859:
---------------------------------
Any progress on this?
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
> Key: WFLY-2859
> URL: https://issues.jboss.org/browse/WFLY-2859
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.CR1
> Reporter: Matt Drees
> Assignee: Stuart Douglas
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-2770) CDI Decorator should be enable on Websocket enpoint
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2770?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2770:
--------------------------------------
If the resolution fails then injection etc will still work, just not decorators.
> CDI Decorator should be enable on Websocket enpoint
> ----------------------------------------------------
>
> Key: WFLY-2770
> URL: https://issues.jboss.org/browse/WFLY-2770
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Reporter: Antoine Sabot-Durand
> Assignee: Stuart Douglas
> Attachments: websocket-decorator.zip
>
>
> Defining a CDI decorator on Websocket Endpoint doesn't work. I know it's not strictly required by websocket spec (it only mentions interceptors) but as it's working in Glassfish 4, it could be nice and less confusing to add this feature to Wildfly
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3778:
-----------------------------------
try cleaning up your /tmp/* this problem could occur when there are some leftover files from previous test runs.
> Tests in Manualmode test suite fail occasionally
> ------------------------------------------------
>
> Key: WFLY-3778
> URL: https://issues.jboss.org/browse/WFLY-3778
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remoting, Test Suite
> Affects Versions: 9.0.0.Beta1
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67.
> Reporter: Frank Langelage
> Assignee: David Lloyd
> Attachments: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt, TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml
>
>
> I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
> But I saw a very similar failure today on Linux first time for PR 6638.
> See https://github.com/wildfly/wildfly/pull/6638.
> Last failure on my machine:
> Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
> java.lang.AssertionError: Password should be right and authentication successful
> Expected: a string containing "\"outcome\" => \"success\""
> but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
> INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
> INFO [org.xnio] XNIO version 3.3.0.Beta1
> INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
> INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
> "
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3632) @Inject broken for parameterized interfaces
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3632?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3632:
---------------------------------
Assignee: Jozef Hartinger (was: Jason Greene)
> @Inject broken for parameterized interfaces
> -------------------------------------------
>
> Key: WFLY-3632
> URL: https://issues.jboss.org/browse/WFLY-3632
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Environment: Wildfly 8.1.0Final (tested on MacOS X 10.9.3)
> Reporter: Alexander Langer
> Assignee: Jozef Hartinger
> Attachments: CDIMultiModuleTest.zip, CDIMultiModuleTest.zip, server.log
>
>
> @Inject is broken on Wildfly 8.1.0 Final when the interface to be injected is parameterized with a type that extends another type. Example code:
> {code}
> public interface Foo<T extends Serializable> { } // will fail
> public class FooBean implements Foo { }
> public interface Bar<T> { } // will work
> public class BarBean implements Bar { }
> @Singleton
> @Startup
> public class TestSingleton {
> @Inject
> private Instance<Foo> foo;
> @Inject
> private Instance<Bar> bar;
> @PostConstruct
> public void init() {
> System.out.println("##### foo is unsatisfied = " + foo.isUnsatisfied());
> for (Foo f : foo)
> System.out.println("foo is: " + f.getClass().getCanonicalName());
> System.out.println("##### bar is unsatisfied = " + bar.isUnsatisfied());
> for (Bar b : bar)
> System.out.println("bar is: " + b.getClass().getCanonicalName());
> }
> }
> {code}
> output:
> {code}
> 22:30:25,904 INFO [stdout] (ServerService Thread Pool -- 50) ##### foo is unsatisfied = true
> 22:30:25,905 INFO [stdout] (ServerService Thread Pool -- 50) ##### bar is unsatisfied = false
> {code}
> The same code works on JBoss AS 7.1.1, so something must have changed for Wildfly.
> The attached small example project can be used to reproduce the error.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3632) @Inject broken for parameterized interfaces
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3632?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3632:
------------------------------
Component/s: CDI / Weld
> @Inject broken for parameterized interfaces
> -------------------------------------------
>
> Key: WFLY-3632
> URL: https://issues.jboss.org/browse/WFLY-3632
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Environment: Wildfly 8.1.0Final (tested on MacOS X 10.9.3)
> Reporter: Alexander Langer
> Assignee: Jason Greene
> Attachments: CDIMultiModuleTest.zip, CDIMultiModuleTest.zip, server.log
>
>
> @Inject is broken on Wildfly 8.1.0 Final when the interface to be injected is parameterized with a type that extends another type. Example code:
> {code}
> public interface Foo<T extends Serializable> { } // will fail
> public class FooBean implements Foo { }
> public interface Bar<T> { } // will work
> public class BarBean implements Bar { }
> @Singleton
> @Startup
> public class TestSingleton {
> @Inject
> private Instance<Foo> foo;
> @Inject
> private Instance<Bar> bar;
> @PostConstruct
> public void init() {
> System.out.println("##### foo is unsatisfied = " + foo.isUnsatisfied());
> for (Foo f : foo)
> System.out.println("foo is: " + f.getClass().getCanonicalName());
> System.out.println("##### bar is unsatisfied = " + bar.isUnsatisfied());
> for (Bar b : bar)
> System.out.println("bar is: " + b.getClass().getCanonicalName());
> }
> }
> {code}
> output:
> {code}
> 22:30:25,904 INFO [stdout] (ServerService Thread Pool -- 50) ##### foo is unsatisfied = true
> 22:30:25,905 INFO [stdout] (ServerService Thread Pool -- 50) ##### bar is unsatisfied = false
> {code}
> The same code works on JBoss AS 7.1.1, so something must have changed for Wildfly.
> The attached small example project can be used to reproduce the error.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3785) java.lang.ClassCircularityError if default-binding is xa-datasource
by Karl Pietrzak (JIRA)
[ https://issues.jboss.org/browse/WFLY-3785?page=com.atlassian.jira.plugin.... ]
Karl Pietrzak closed WFLY-3785.
-------------------------------
Resolution: Rejected
Never mind, this is something else. My bad!
> java.lang.ClassCircularityError if default-binding is xa-datasource
> -------------------------------------------------------------------
>
> Key: WFLY-3785
> URL: https://issues.jboss.org/browse/WFLY-3785
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Karl Pietrzak
> Assignee: Jason Greene
> Priority: Minor
>
> I updated my {{<default-bindings>}} section to use my own custom datasource:
> {code:xml}
> <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/custom-ds" ....>
> {code}
> The config for that datasource is:
> {code:xml}
> <xa-datasource jndi-name="java:jboss/datasources/custom-ds" pool-name="custom-ds" enabled="true">
> <xa-datasource-property name="URL">
> jdbc:mysql://localhost:3306/custom?transformedBitIsBoolean=true
> </xa-datasource-property>
> <driver>com.mysql</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>10</min-pool-size>
> <max-pool-size>30</max-pool-size>
> <prefill>true</prefill>
> </xa-pool>
> <security>
> <user-name>root</user-name>
> </security>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
> <validate-on-match>true</validate-on-match>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
> </validation>
> <statement>
> <prepared-statement-cache-size>32</prepared-statement-cache-size>
> <share-prepared-statements>true</share-prepared-statements>
> </statement>
> </xa-datasource>
> {code}
> This, however, results is a very ugly exception loop:
> {noformat}
> 15:18:40,927 WARN [org.jboss.modules] (ServerService Thread Pool -- 25) Failed to define class org.jboss.jca.adapters.jdbc.xa.XAManagedConnection in Module "deployment.Mine-ear.ear:main" from Service Module Loader: java.lang.ClassCircularityError: org/jboss/jca/adapters/jdbc/xa/XAManagedConnection
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_67]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_67]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_67]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.guessClass(Formatters.java:751) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.renderExtended(Formatters.java:644) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.access$300(Formatters.java:597) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:608) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.renderRaw(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:225) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:79) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:296) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.log(Logger.java:367) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:492) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_67]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.guessClass(Formatters.java:751) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.renderExtended(Formatters.java:644) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.access$300(Formatters.java:597) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:608) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.renderRaw(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:225) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:79) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:296) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.log(Logger.java:367) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:492) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_67]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.guessClass(Formatters.java:751) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.renderExtended(Formatters.java:644) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.access$300(Formatters.java:597) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:608) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.renderRaw(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:225) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:79) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:296) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.log(Logger.java:367) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:492) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_67]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.guessClass(Formatters.java:751) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.renderExtended(Formatters.java:644) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.access$300(Formatters.java:597) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:608) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.renderRaw(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:225) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:79) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:296) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.log(Logger.java:367) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:492) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_67]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.guessClass(Formatters.java:751) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.renderExtended(Formatters.java:644) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11.access$300(Formatters.java:597) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:608) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$11$1.run(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_67]
> at org.jboss.logmanager.formatters.Formatters$11.renderRaw(Formatters.java:599) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:225) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:79) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:296) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.logmanager.Logger.log(Logger.java:367) [jboss-logmanager-1.5.2.Final.jar:1.5.2.Final]
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:492) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_67]
> {noformat}
> Any ideas?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months