[JBoss JIRA] (WFCORE-1348) Specify filesystem rights for deployment content
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1348?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-1348:
-------------------------------------------
Using the old File.createTempFile seems the way to go as it doesn't apply the same rights and this was working nicely before.
> Specify filesystem rights for deployment content
> ------------------------------------------------
>
> Key: WFCORE-1348
> URL: https://issues.jboss.org/browse/WFCORE-1348
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> Currently when we add a content to the ContentRepository we are using Files.createTempFile whitout specifying the file attributes. On GNU/Linux this may create a file with only read write rights for the user (and not the group or other). We should change that as this could lead to some strange errors.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6120) SFSB PassivationTestCase fails to resolve XPC following passivation
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6120?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-6120:
-------------------------------
Priority: Blocker (was: Major)
> SFSB PassivationTestCase fails to resolve XPC following passivation
> -------------------------------------------------------------------
>
> Key: WFLY-6120
> URL: https://issues.jboss.org/browse/WFLY-6120
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> javax.ejb.EJBException: WFLYJPA0030: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it. This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context. See JPA spec 2.0 section 7.6.3.1. Scoped persistence unit name=passivation-test.jar#main, persistence context already in transaction =ExtendedEntityManager [passivation-test.jar#main], extended persistence context =ExtendedEntityManager [passivation-test.jar#main].
> at org.jboss.as.jpa.container.ExtendedEntityManager.internalAssociateWithJtaTx(ExtendedEntityManager.java:149)
> at org.jboss.as.jpa.container.ExtendedEntityManager.getEntityManager(ExtendedEntityManager.java:129)
> at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:444)
> at org.jboss.as.test.integration.ejb.stateful.passivation.TestPassivationBean.isPersistenceContextSame(TestPassivationBean.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.delegateInterception(Jsr299BindingsInterceptor.java:70)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 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)
> 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.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 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:64)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 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.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 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)
> 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:636)
> 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.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy72.isPersistenceContextSame(Unknown Source)
> at org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize(PassivationTestCase.java:103)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5549) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5549?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-5549:
------------------------------------
[~koen.aers] please see previous comment about how JBoss Developer tools users might run into WFLY-5549.
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ---------------------------------------------------------------------
>
> Key: WFLY-5549
> URL: https://issues.jboss.org/browse/WFLY-5549
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: carlos feria
> Assignee: Scott Marlow
>
> 10:06:35,545 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.persistenceunit."********": org.jboss.msc.service.StartException in service jboss.persistenceunit."*******": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> at org.dom4j.DocumentFactory.getInstance(DocumentFactory.java:97)
> at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:33)
> at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:27)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.workWithClassLoader(ClassLoaderServiceImpl.java:342)
> at org.hibernate.internal.util.xml.XMLHelper.<init>(XMLHelper.java:26)
> at org.hibernate.envers.boot.internal.EnversServiceImpl.initialize(EnversServiceImpl.java:115)
> at org.hibernate.envers.boot.internal.AdditionalJaxbMappingProducerImpl.produceAdditionalMappings(AdditionalJaxbMappingProducerImpl.java:99)
> at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:288)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:770)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:797)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> 10:06:35,552 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "cooperativa-1.0.0.Final.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.persistenceunit.\"cooperativa-1.0.0.Final.war#CooperativaPU\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"cooperativa-1.0.0.Final.war#CooperativaPU\": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory"}}
> 10:06:35,732 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "cooperativa-1.0.0.Final.war" (runtime-name : "cooperativa-1.0.0.Final.war")
> 10:06:35,733 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.persistenceunit."cooperativa-1.0.0.Final.war#CooperativaPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."cooperativa-1.0.0.Final.war#CooperativaPU": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6142) [Migration] StuckThreadDetectionValve is not automatically migrated
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6142?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-3284 to WFLY-6142:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6142 (was: JBEAP-3284)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (JBoss Web)
Web (Undertow)
(was: Documentation)
(was: Web (Undertow))
(was: Migration)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
> [Migration] StuckThreadDetectionValve is not automatically migrated
> -------------------------------------------------------------------
>
> Key: WFLY-6142
> URL: https://issues.jboss.org/browse/WFLY-6142
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web), Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> {{org.apache.catalina.valves.StuckThreadDetectionValve}} is not automatically migrated even though there exists equivalent handler in EAP7 ({{io.undertow.server.handlers.StuckThreadDetectionHandler}}).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6141) [Migration][WebToUndertow] Migrating access log valve results always in migration warning
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6141?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-3283 to WFLY-6141:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6141 (was: JBEAP-3283)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (JBoss Web)
Web (Undertow)
(was: Web (JBoss Web))
(was: Web (Undertow))
(was: Migration)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
> [Migration][WebToUndertow] Migrating access log valve results always in migration warning
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6141
> URL: https://issues.jboss.org/browse/WFLY-6141
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web), Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> When migrating AccessLogValve it results in printing migration warning for attributes which are not even defined with the valve.
> The attributes are: "resolveHosts", "fileDateFormat", "renameOnRotate", "encoding", "locale", "requestAttributesEnabled", "buffered".
> Such warning should only be printed for attributes which were actually used with the valve and not when they are actually not used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-4939) WFLYEJB0467: The request was rejected as the container is suspended during server shutdown
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4939?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-4939:
--------------------------------------
I've fixed the PR and test are passing now.
> WFLYEJB0467: The request was rejected as the container is suspended during server shutdown
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-4939
> URL: https://issues.jboss.org/browse/WFLY-4939
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Romain Pelisse
>
> Seen in our failover tests (scenario shutdown) for remote stateful EJBs
> Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application.
> When server is shutting down (via cli command ":shutdown"), it logs the following error message for each client invocation during suspend phase:
> {code}
> [JBossINF] [0m[0m12:36:39,319 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0211: Suspending server
> [JBossINF] [0m[0m12:36:39,323 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> [JBossINF] [0m[31m12:36:39,346 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 7) WFLYEJB0034: EJB Invocation failed on component RemoteStatefulSBImpl for method public abstract int org.jboss.test.clusterbench.common.ejb.CommonStatefulSB.getSerialAndIncrement(): org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0467: The request was rejected as the container is suspended
> [JBossINF] at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:50)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> [JBossINF] at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:635)
> [JBossINF] at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> [JBossINF] at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> [JBossINF] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1356) javax.sql.api should declare a dependency on javax.transaction.api
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1356?page=com.atlassian.jira.plugi... ]
Tom Jenkinson updated WFCORE-1356:
----------------------------------
Labels: (was: oracle-ucp)
> javax.sql.api should declare a dependency on javax.transaction.api
> ------------------------------------------------------------------
>
> Key: WFCORE-1356
> URL: https://issues.jboss.org/browse/WFCORE-1356
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Priority: Blocker
> Fix For: 2.1.0.CR2
>
>
> javax.sql.XAConnection (https://docs.oracle.com/javase/7/docs/api/javax/sql/XAConnection.html) depends on javax.transaction.xa.XAResource
> Including a partial stack trace that shows the failure:
> {quote}
> Caused by: java.lang.ClassNotFoundException: javax.transaction.xa.XAResource from [Module "javax.sql.api:main" from local module loader <SNIP/>
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6136) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6136?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-6136:
------------------------------
Component/s: Web (Undertow)
> Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6136
> URL: https://issues.jboss.org/browse/WFLY-6136
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: Ubuntu Linux 14.04 amd64
> Reporter: Juanm Manuel Enrique Muñido
> Assignee: Stuart Douglas
>
> I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
> <jsp-config>
> <jsp-property-group>
> <description>header and footer settings</description>
> <url-pattern>/WEB-INF/view/*</url-pattern>
> <url-pattern>/WEB-INF/error/*</url-pattern>
> <include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
> <include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
> </jsp-property-group>
> </jsp-config>
> This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
> But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
> If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
> Any suggestion about this issue?
> Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6136) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6136?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-6136:
-----------------------------------
do you have simple reproducer for this?
> Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6136
> URL: https://issues.jboss.org/browse/WFLY-6136
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: Ubuntu Linux 14.04 amd64
> Reporter: Juanm Manuel Enrique Muñido
> Assignee: Stuart Douglas
>
> I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
> <jsp-config>
> <jsp-property-group>
> <description>header and footer settings</description>
> <url-pattern>/WEB-INF/view/*</url-pattern>
> <url-pattern>/WEB-INF/error/*</url-pattern>
> <include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
> <include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
> </jsp-property-group>
> </jsp-config>
> This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
> But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
> If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
> Any suggestion about this issue?
> Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months