[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by Tobi Tobias (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
Tobi Tobias commented on WFCORE-1330:
-------------------------------------
I have the feeling that this problem is related to a wrong user right setup on my ubuntu machine.
It seems that widfly had problems writing the standalone.xml and the war files properly.
I may have deployed the applications as a different user than the user with which I have started the server. Can you confirm this behaviour?
At the end it would mean that I have to start, manage and deploy applications via the same user. Am I right?
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (SECURITY-934) RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/SECURITY-934?page=com.atlassian.jira.plug... ]
Hynek Švábek updated SECURITY-934:
----------------------------------
Description:
There will be needless LDAP calls if we use AdvancedLdap login module.
If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
It can be performance problem.
Same problem was in LdapExt login module.
You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
https://issues.jboss.org/browse/SECURITY-891
Example from Wireshark for 2 groups:
{code}
* searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
* searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
* searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
* searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
* searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
* searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
{code}|
was:
There will be needless LDAP calls if we use AdvancedLdap login module.
If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
It can be performance problem.
Same problem was in LdapExt login module.
You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
Example from Wireshark for 2 groups:
{code}
* searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
* searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
* searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
* searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
* searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
* searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
{code}|
> RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
> ---------------------------------------------------------------------------------------------
>
> Key: SECURITY-934
> URL: https://issues.jboss.org/browse/SECURITY-934
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
>
> There will be needless LDAP calls if we use AdvancedLdap login module.
> If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
> It can be performance problem.
> Same problem was in LdapExt login module.
> You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
> https://issues.jboss.org/browse/SECURITY-891
> Example from Wireshark for 2 groups:
> {code}
> * searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
> * searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
> * searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
> * searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
> {code}|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5082) WebSphere MQ 8 RA - [TCK] ClassCastException when calling toString() on JMSContext
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5082?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5082:
-----------------------------------
It seems that Glassfish's Generic JMS RA has the same cast in place to cast a regular CF in a XA CF (https://java.net/projects/genericjmsra/sources/svn/content/trunk/src/java...)
> WebSphere MQ 8 RA - [TCK] ClassCastException when calling toString() on JMSContext
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5082
> URL: https://issues.jboss.org/browse/WFLY-5082
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Alpha6
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
>
> TCK 7 tests are calling toString() on JMSContext to print trace information about jms context like:
> {code}
> ...
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void method1a() {
> TestUtil.logMsg("CMBean1.method1a(): JMSContext context="+context); <-- this is the line
> ...
> {code}
> This call is handled by ActiveMQ Artemis integration because it provides JMSContextProducer for CDI by which JMSContext was injected to EJB in TCK test. Problem occurs in call of JMSContextProducer#JMSContextWrapper.create():
> {code}
> ...
> ConnectionFactory cf = (ConnectionFactory) lookup(info.connectionFactoryLookup);
> if (inTransaction) {
> XAJMSContext xaContext = ((XAConnectionFactory) cf).createXAContext(info.userName, info.password);
> return xaContext.getContext();
> ...
> {code}
> Looked up connection factory is instance of class com.ibm.mq.connector.outbound.ManagedQueueConnectionFactoryImpl which does not implement javax.jms.XAConnectionFactory interface.
> Tests fails with:
> {code}
> 15:06:28,130 INFO [stdout] (EJB default - 4) cfactory=com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl@4bb55738
> 15:06:28,203 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 5) WFLYEJB0034: EJB Invocation failed on component CDIUseCasesCMBEAN1 for method public abstract void com.sun.ts.tests.jms.ee20.cditests.usecases.CMBean1IF.method1a(): javax.ejb.EJBException: java.lang.ClassCastException: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be cast to javax.jms.XAConnectionFactory
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:635)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.ClassCastException: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be cast to javax.jms.XAConnectionFactory
> at org.wildfly.extension.messaging.activemq.deployment.JMSContextProducer$JMSContextWrapper.create(JMSContextProducer.java:192) [wildfly-messaging-activemq-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.wildfly.extension.messaging.activemq.deployment.JMSContextProducer$JMSContextWrapper.getDelegate(JMSContextProducer.java:217) [wildfly-messaging-activemq-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.wildfly.extension.messaging.activemq.deployment.JMSContextProducer$JMSContextWrapper.toString(JMSContextProducer.java:477) [wildfly-messaging-activemq-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at java.lang.String.valueOf(String.java:2982) [rt.jar:1.8.0_51]
> at java.lang.StringBuilder.append(StringBuilder.java:131) [rt.jar:1.8.0_51]
> at com.sun.ts.tests.jms.ee20.cditests.usecases.CMBean1.method1a(CMBean1.java:105) [cditestsusecases_ejb.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_51]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_51]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) [weld-core-impl-2.3.0.Beta2.jar:2015-07-01 06:18]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-10.0.0.Alpha5-redhat-1.jar:10.0.0.Alpha5-redhat-1]
> ... 39 more
> {code}
> Affected tests:
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#bea...
> Customer impact:
> If JMSContext is injected using CDI like:
> {code}//JMSContext CDI injection specifying ConnectionFactory
> @Inject
> @JMSConnectionFactory("jms/ConnectionFactory")
> JMSContext context;{code}
> then call of toString() method on this JMSContext will lead to java.lang.ClassCastException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by Tobi Tobias (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
Tobi Tobias commented on WFCORE-1330:
-------------------------------------
The driver is added via jboss-cli using the 'deploy' command.
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months