[JBoss JIRA] (JGRP-1798) loopback=false is not working in 3.3.5 version
by Sreenivasa Reddy Boreddy (JIRA)
Sreenivasa Reddy Boreddy created JGRP-1798:
----------------------------------------------
Summary: loopback=false is not working in 3.3.5 version
Key: JGRP-1798
URL: https://issues.jboss.org/browse/JGRP-1798
Project: JGroups
Issue Type: Bug
Environment: Fedora 17
Reporter: Sreenivasa Reddy Boreddy
Assignee: Bela Ban
Recently I upgraded by JGroups version from 2.12.1 to 3.3.5 and observed that JGroups messages are received to self node even though I configured loopback=false in my jgroupsmanager.xml.
I am using TCP/IP as protocol stack.
24.02.2014 12.00.13:191 109357 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
24.02.2014 12.00.13:593 109365 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REPLICATE_COUNTER_V2][elements: 2] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
24.02.2014 12.00.14:327 109366 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
24.02.2014 12.00.14:476 109370 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REPLICATE_COUNTER_V2][elements: 2] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
24.02.2014 12.00.14:635 109379 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 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:
--------------------------------------
[~jharting] what do you think about modifying the Resteasy CDI integration to not make beans request scoped any more, and instead just create an instance directly and destroy it at the end of the request using a listener (or using some other hook in Resteasy)?
As it is this also causes some performance problems, Resteasy with CDI is noticeably slower.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2961) NPE after redeploy in HttpConversationContextImpl
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2961?page=com.atlassian.jira.plugin.... ]
Stuart Douglas closed WFLY-2961.
--------------------------------
Resolution: Out of Date
Issue with persistent session and weld. Persistent sessions have been disabled for now till we have a fix.
> NPE after redeploy in HttpConversationContextImpl
> -------------------------------------------------
>
> Key: WFLY-2961
> URL: https://issues.jboss.org/browse/WFLY-2961
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: windows. firefox
> Reporter: Leos Literak
> Assignee: Stuart Douglas
> Priority: Minor
>
> It occurs to me quite regularly:
> I have servlet, construct some GET URL and find bug. So I fix it, redeploy my war application and press reload in firefox. But WildFly fails with NPE. If I reload the page again, then it works.
> 22:21:59,888 ERROR [io.undertow.request] (default I/O-3) Blocking request failed HttpServerExchange{ GET /OAuthLogin/callback/google}: java.lang.NullPointerException
> at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:47)
> at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:13)
> at org.jboss.weld.context.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:177)
> at org.jboss.weld.context.AbstractConversationContext.sessionCreated(AbstractConversationContext.java:185)
> at org.jboss.weld.servlet.ConversationContextActivator.sessionCreated(ConversationContextActivator.java:187)
> at org.jboss.weld.servlet.HttpContextLifecycle.sessionCreated(HttpContextLifecycle.java:122)
> at org.jboss.weld.servlet.WeldInitialListener.sessionCreated(WeldInitialListener.java:107)
> at io.undertow.servlet.core.ApplicationListeners.sessionCreated(ApplicationListeners.java:256)
> at io.undertow.servlet.core.SessionListenerBridge.sessionCreated(SessionListenerBridge.java:36)
> at io.undertow.server.session.SessionListeners.sessionCreated(SessionListeners.java:32)
> at io.undertow.server.session.InMemorySessionManager.createSession(InMemorySessionManager.java:121)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:691)
> at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:110)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:56)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:53)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:142)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:69)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:38)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2989) Replacing JSP files through deployment overlays doesn't work for exploded deployments
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2989?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2989.
----------------------------------
Resolution: Won't Fix
This was actually a deliberate decision. Basically the only way to properly support this is to directly replace the JSP file in the exploded deployment, which I don't really want to do as it involves modifying the user deployment. I think we should just document that this is not supported, it should not be a big deal as overlays are not particularly useful with exploded deployments anyway (as the user can just copy the file directly).
> Replacing JSP files through deployment overlays doesn't work for exploded deployments
> -------------------------------------------------------------------------------------
>
> Key: WFLY-2989
> URL: https://issues.jboss.org/browse/WFLY-2989
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.Final
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
> Attachments: DeploymentOverlayCLITestCase.java
>
>
> I am enhancing DeploymentOverlayCLITestCase with tests for exploded deployments. It seems that with exploded deployments, replacing JSP files doesn't work. Replacing/adding libraries works correctly.
> Attaching my enhanced version of DeploymentOverlayCLITestCase. It just reuses the old stuff, only deploys deployment0.war and deployment1.war as exploded directories. To reproduce, simply replace the original test with the new source file and run testSimpleOverrideExploded method. It will fail on line 298.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-3002) ServletContext.getResourcePaths() does'nt meet Spec
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3002?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-190 to WFLY-3002:
-----------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-3002 (was: UNDERTOW-190)
Affects Version/s: 8.0.0.Final
(was: 1.0.0.Final)
Component/s: Web (Undertow)
(was: Servlet)
Security: Public
> ServletContext.getResourcePaths() does'nt meet Spec
> ---------------------------------------------------
>
> Key: WFLY-3002
> URL: https://issues.jboss.org/browse/WFLY-3002
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Ercan Oezkan
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: resource-test.zip
>
>
> Undertow ServletContext.getResourcePaths() does'nt meet the Spec Servlet 2.3. Please see attched Test Web Project resource-test.zip, Undertow does'nt resolve the resources in Child Dependencies located under WEB-INF/lib Folder
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2960) Hibernate 4.3.1 can't find [java:jboss/UserTransaction] - JTA
by ofbiz brazil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2960?page=com.atlassian.jira.plugin.... ]
ofbiz brazil edited comment on WFLY-2960 at 2/23/14 8:44 PM:
-------------------------------------------------------------
Hi guys, I'd like to discuss a little bit more about this topic.
I really changed my EJB's as said previously, but now I am facing constantly issues saying that result in transaction was not closed. Why?
My point of view is if I have @Transaction in my spring services shouldn't I use CMT in EJB?
Please take a look at this code example, they're using @TransactionManagement(TransactionManagementType.CONTAINER) + @Transaction
http://blog.inflinx.com/2010/04/08/spring-jta-jpa-jms/
@Transaction in Spring means I want the container to take of my transaction, so if I use an EJB as BMT it will never find a commit by java code. Isn't it?
Another point there's a forum sayin to use @TransactionAttribute(TransactionAttributeType.REQUIRED) in EJB´s, so what´s the difference for Wildfly it?
http://forum.spring.io/forum/spring-projects/data/84667-jtatransctionmana...
Let me know your thoughts.
Cheers,
was (Author: ofbizbrazil):
Hi guys, I'd like to discuss a little bit more about this topic.
I really changed my EJB's as said previously, but now I am facing constantly issues saying that result in transaction was not closed. Why?
My point of view is if I have @Transaction wouldn't I using CMT in EJB?
Please take a look at this code example, they're using @TransactionManagement(TransactionManagementType.CONTAINER) + @Transaction
http://blog.inflinx.com/2010/04/08/spring-jta-jpa-jms/
@Transaction in Spring means I want the container to take of my transaction, so if I use an EJB as BMT it will never find a commit by java code. Isn't it?
Another point there's a forum sayin to use @TransactionAttribute(TransactionAttributeType.REQUIRED) in EJB´s, so what´s the difference for Wildfly it?
http://forum.spring.io/forum/spring-projects/data/84667-jtatransctionmana...
Let me know your thoughts.
Cheers,
> Hibernate 4.3.1 can't find [java:jboss/UserTransaction] - JTA
> -------------------------------------------------------------
>
> Key: WFLY-2960
> URL: https://issues.jboss.org/browse/WFLY-2960
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Final
> Environment: Spring 4.0.1, Hibernate 4.3.1, Hibernate Validator 5.0.3.Final, EJB 3.1
> Reporter: ofbiz brazil
> Assignee: Scott Marlow
> Priority: Critical
>
> 1) There's no UserTransaction implemented by WildFly.
> JNDI tree view shows:
> === WildFly 8.0.0Final ===
> "java:jboss" => {
> "UserTransaction" => {
> "class-name" => "javax.transaction.UserTransaction",
> "value" => "UserTransaction"
> },
> === JBoss 7.1.1 ===
> "java:jboss" => {
> "UserTransaction" => {
> "class-name" => "org.jboss.tm.usertx.client.ServerVMClientUserTransaction",
> "value" => "org.jboss.tm.usertx.client.ServerVMClientUserTransaction@9e85f"
> },
> 2) Method locateUserTransaction in JBossAppServerJtaPlatform can't get transaction objet from JNDI tree.
> 3) Hibernate Configuration
> hibernate.default_schema=dbo
> hibernate.default_catalog=XX
> hibernate.database=SQL_SERVER
> hibernate.dialect=org.hibernate.dialect.SQLServer2008Dialect
> hibernate.show_sql=false
> hibernate.generate_ddl=false
> hibernate.hbm2ddl.auto=validate
> hibernate.transaction.factory_class=org.hibernate.transaction.JTATransactionFactory
> hibernate.transaction.jta.platform=org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform
> hibernate.current_session_context_class=org.springframework.orm.hibernate4.SpringJtaSessionContext
> hibernate.connection.release_mode=auto
> 4) Runtime Exception in console
> Caused by: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is javax.persistence.PersistenceException: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:430) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:420) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:257) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) [spring-aop-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) [spring-aop-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at com.sun.proxy.$Proxy102.findByUserProfile(Unknown Source)
> at com.sbb.useraccess.ejb.AccessibleItemBean.findByUserProfile(AccessibleItemBean.java:74) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> ... 99 more
> Caused by: javax.persistence.PersistenceException: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1771) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:64) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.springframework.orm.jpa.DefaultJpaDialect.beginTransaction(DefaultJpaDialect.java:67) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:110) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:380) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> ... 141 more
> Caused by: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform.locateUserTransaction(JBossAppServerJtaPlatform.java:77) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.jta.platform.internal.AbstractJtaPlatform.retrieveUserTransaction(AbstractJtaPlatform.java:124) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.internal.jta.JtaTransaction.locateUserTransaction(JtaTransaction.java:84) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.internal.jta.JtaTransaction.doBegin(JtaTransaction.java:69) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1431) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> ... 144 more
> Caused by: org.hibernate.engine.jndi.JndiException: Unable to lookup JNDI name [java:jboss/UserTransaction]
> at org.hibernate.engine.jndi.internal.JndiServiceImpl.locate(JndiServiceImpl.java:117) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform.locateUserTransaction(JBossAppServerJtaPlatform.java:70) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> ... 150 more
> Caused by: javax.naming.NamingException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction [Root exception is java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
> at javax.naming.InitialContext.lookup(InitialContext.java:415) [rt.jar:1.7.0_51]
> at javax.naming.InitialContext.lookup(InitialContext.java:415) [rt.jar:1.7.0_51]
> at org.hibernate.engine.jndi.internal.JndiServiceImpl.locate(JndiServiceImpl.java:114) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> ... 151 more
> Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction
> at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.realCheckPermission(AllowedMethodsInformation.java:138) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.checkAllowed(AllowedMethodsInformation.java:112) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.subsystem.EJB3UserTransactionAccessControlService$1.authorizeAccess(EJB3UserTransactionAccessControlService.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.txn.service.UserTransactionAccessControlService.authorizeAccess(UserTransactionAccessControlService.java:83)
> at org.jboss.as.txn.service.UserTransactionBindingService$1.getReference(UserTransactionBindingService.java:71)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> ... 159 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2960) Hibernate 4.3.1 can't find [java:jboss/UserTransaction] - JTA
by ofbiz brazil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2960?page=com.atlassian.jira.plugin.... ]
ofbiz brazil edited comment on WFLY-2960 at 2/23/14 8:42 PM:
-------------------------------------------------------------
Hi guys, I'd like to discuss a little bit more about this topic.
I really changed my EJB's as said previously, but now I am facing constantly issues saying that result in transaction was not closed. Why?
My point of view is if I have @Transaction wouldn't I using CMT in EJB?
Please take a look at this code example, they're using @TransactionManagement(TransactionManagementType.CONTAINER) + @Transaction
http://blog.inflinx.com/2010/04/08/spring-jta-jpa-jms/
@Transaction in Spring means I want the container to take of my transaction, so if I use an EJB as BMT it will never find a commit by java code. Isn't it?
Another point there´re forum sayin to use @TransactionAttribute(TransactionAttributeType.REQUIRED) in EJB´s, what´s the difference for Wildfly it?
http://forum.spring.io/forum/spring-projects/data/84667-jtatransctionmana...
Let me know your thoughts.
Cheers,
was (Author: ofbizbrazil):
Hi guys, I'd like to discuss a little bit more about this topic.
I really changed my EJB's as said previously, but now I am facing constantly issues saying that result in transaction was not closed. Why?
My point of view is if I have @Transaction wouldn't I using CMT in EJB?
Please take a look at this code example, they're using @TransactionManagement(TransactionManagementType.CONTAINER) + @Transaction
http://blog.inflinx.com/2010/04/08/spring-jta-jpa-jms/
@Transaction in Spring means I want the container to take of my transaction, so if I use an EJB as BMT it will never find a commit by java code. Isn't it?
Let me know your thoughts.
Cheers,
> Hibernate 4.3.1 can't find [java:jboss/UserTransaction] - JTA
> -------------------------------------------------------------
>
> Key: WFLY-2960
> URL: https://issues.jboss.org/browse/WFLY-2960
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Final
> Environment: Spring 4.0.1, Hibernate 4.3.1, Hibernate Validator 5.0.3.Final, EJB 3.1
> Reporter: ofbiz brazil
> Assignee: Scott Marlow
> Priority: Critical
>
> 1) There's no UserTransaction implemented by WildFly.
> JNDI tree view shows:
> === WildFly 8.0.0Final ===
> "java:jboss" => {
> "UserTransaction" => {
> "class-name" => "javax.transaction.UserTransaction",
> "value" => "UserTransaction"
> },
> === JBoss 7.1.1 ===
> "java:jboss" => {
> "UserTransaction" => {
> "class-name" => "org.jboss.tm.usertx.client.ServerVMClientUserTransaction",
> "value" => "org.jboss.tm.usertx.client.ServerVMClientUserTransaction@9e85f"
> },
> 2) Method locateUserTransaction in JBossAppServerJtaPlatform can't get transaction objet from JNDI tree.
> 3) Hibernate Configuration
> hibernate.default_schema=dbo
> hibernate.default_catalog=XX
> hibernate.database=SQL_SERVER
> hibernate.dialect=org.hibernate.dialect.SQLServer2008Dialect
> hibernate.show_sql=false
> hibernate.generate_ddl=false
> hibernate.hbm2ddl.auto=validate
> hibernate.transaction.factory_class=org.hibernate.transaction.JTATransactionFactory
> hibernate.transaction.jta.platform=org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform
> hibernate.current_session_context_class=org.springframework.orm.hibernate4.SpringJtaSessionContext
> hibernate.connection.release_mode=auto
> 4) Runtime Exception in console
> Caused by: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is javax.persistence.PersistenceException: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:430) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:420) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:257) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) [spring-aop-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) [spring-aop-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at com.sun.proxy.$Proxy102.findByUserProfile(Unknown Source)
> at com.sbb.useraccess.ejb.AccessibleItemBean.findByUserProfile(AccessibleItemBean.java:74) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> ... 99 more
> Caused by: javax.persistence.PersistenceException: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1771) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:64) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.springframework.orm.jpa.DefaultJpaDialect.beginTransaction(DefaultJpaDialect.java:67) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:110) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:380) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> ... 141 more
> Caused by: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform.locateUserTransaction(JBossAppServerJtaPlatform.java:77) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.jta.platform.internal.AbstractJtaPlatform.retrieveUserTransaction(AbstractJtaPlatform.java:124) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.internal.jta.JtaTransaction.locateUserTransaction(JtaTransaction.java:84) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.internal.jta.JtaTransaction.doBegin(JtaTransaction.java:69) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1431) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> ... 144 more
> Caused by: org.hibernate.engine.jndi.JndiException: Unable to lookup JNDI name [java:jboss/UserTransaction]
> at org.hibernate.engine.jndi.internal.JndiServiceImpl.locate(JndiServiceImpl.java:117) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform.locateUserTransaction(JBossAppServerJtaPlatform.java:70) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> ... 150 more
> Caused by: javax.naming.NamingException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction [Root exception is java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
> at javax.naming.InitialContext.lookup(InitialContext.java:415) [rt.jar:1.7.0_51]
> at javax.naming.InitialContext.lookup(InitialContext.java:415) [rt.jar:1.7.0_51]
> at org.hibernate.engine.jndi.internal.JndiServiceImpl.locate(JndiServiceImpl.java:114) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> ... 151 more
> Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction
> at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.realCheckPermission(AllowedMethodsInformation.java:138) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.checkAllowed(AllowedMethodsInformation.java:112) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.subsystem.EJB3UserTransactionAccessControlService$1.authorizeAccess(EJB3UserTransactionAccessControlService.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.txn.service.UserTransactionAccessControlService.authorizeAccess(UserTransactionAccessControlService.java:83)
> at org.jboss.as.txn.service.UserTransactionBindingService$1.getReference(UserTransactionBindingService.java:71)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> ... 159 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2960) Hibernate 4.3.1 can't find [java:jboss/UserTransaction] - JTA
by ofbiz brazil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2960?page=com.atlassian.jira.plugin.... ]
ofbiz brazil edited comment on WFLY-2960 at 2/23/14 8:42 PM:
-------------------------------------------------------------
Hi guys, I'd like to discuss a little bit more about this topic.
I really changed my EJB's as said previously, but now I am facing constantly issues saying that result in transaction was not closed. Why?
My point of view is if I have @Transaction wouldn't I using CMT in EJB?
Please take a look at this code example, they're using @TransactionManagement(TransactionManagementType.CONTAINER) + @Transaction
http://blog.inflinx.com/2010/04/08/spring-jta-jpa-jms/
@Transaction in Spring means I want the container to take of my transaction, so if I use an EJB as BMT it will never find a commit by java code. Isn't it?
Another point there's a forum sayin to use @TransactionAttribute(TransactionAttributeType.REQUIRED) in EJB´s, so what´s the difference for Wildfly it?
http://forum.spring.io/forum/spring-projects/data/84667-jtatransctionmana...
Let me know your thoughts.
Cheers,
was (Author: ofbizbrazil):
Hi guys, I'd like to discuss a little bit more about this topic.
I really changed my EJB's as said previously, but now I am facing constantly issues saying that result in transaction was not closed. Why?
My point of view is if I have @Transaction wouldn't I using CMT in EJB?
Please take a look at this code example, they're using @TransactionManagement(TransactionManagementType.CONTAINER) + @Transaction
http://blog.inflinx.com/2010/04/08/spring-jta-jpa-jms/
@Transaction in Spring means I want the container to take of my transaction, so if I use an EJB as BMT it will never find a commit by java code. Isn't it?
Another point there´re forum sayin to use @TransactionAttribute(TransactionAttributeType.REQUIRED) in EJB´s, what´s the difference for Wildfly it?
http://forum.spring.io/forum/spring-projects/data/84667-jtatransctionmana...
Let me know your thoughts.
Cheers,
> Hibernate 4.3.1 can't find [java:jboss/UserTransaction] - JTA
> -------------------------------------------------------------
>
> Key: WFLY-2960
> URL: https://issues.jboss.org/browse/WFLY-2960
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Final
> Environment: Spring 4.0.1, Hibernate 4.3.1, Hibernate Validator 5.0.3.Final, EJB 3.1
> Reporter: ofbiz brazil
> Assignee: Scott Marlow
> Priority: Critical
>
> 1) There's no UserTransaction implemented by WildFly.
> JNDI tree view shows:
> === WildFly 8.0.0Final ===
> "java:jboss" => {
> "UserTransaction" => {
> "class-name" => "javax.transaction.UserTransaction",
> "value" => "UserTransaction"
> },
> === JBoss 7.1.1 ===
> "java:jboss" => {
> "UserTransaction" => {
> "class-name" => "org.jboss.tm.usertx.client.ServerVMClientUserTransaction",
> "value" => "org.jboss.tm.usertx.client.ServerVMClientUserTransaction@9e85f"
> },
> 2) Method locateUserTransaction in JBossAppServerJtaPlatform can't get transaction objet from JNDI tree.
> 3) Hibernate Configuration
> hibernate.default_schema=dbo
> hibernate.default_catalog=XX
> hibernate.database=SQL_SERVER
> hibernate.dialect=org.hibernate.dialect.SQLServer2008Dialect
> hibernate.show_sql=false
> hibernate.generate_ddl=false
> hibernate.hbm2ddl.auto=validate
> hibernate.transaction.factory_class=org.hibernate.transaction.JTATransactionFactory
> hibernate.transaction.jta.platform=org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform
> hibernate.current_session_context_class=org.springframework.orm.hibernate4.SpringJtaSessionContext
> hibernate.connection.release_mode=auto
> 4) Runtime Exception in console
> Caused by: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is javax.persistence.PersistenceException: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:430) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:420) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:257) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) [spring-tx-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) [spring-aop-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) [spring-aop-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at com.sun.proxy.$Proxy102.findByUserProfile(Unknown Source)
> at com.sbb.useraccess.ejb.AccessibleItemBean.findByUserProfile(AccessibleItemBean.java:74) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> ... 99 more
> Caused by: javax.persistence.PersistenceException: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1771) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:64) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> at org.springframework.orm.jpa.DefaultJpaDialect.beginTransaction(DefaultJpaDialect.java:67) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:110) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:380) [spring-orm-4.0.1.RELEASE.jar:4.0.1.RELEASE]
> ... 141 more
> Caused by: org.hibernate.engine.jndi.JndiException: unable to find UserTransaction
> at org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform.locateUserTransaction(JBossAppServerJtaPlatform.java:77) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.jta.platform.internal.AbstractJtaPlatform.retrieveUserTransaction(AbstractJtaPlatform.java:124) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.internal.jta.JtaTransaction.locateUserTransaction(JtaTransaction.java:84) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.internal.jta.JtaTransaction.doBegin(JtaTransaction.java:69) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1431) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61) [hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
> ... 144 more
> Caused by: org.hibernate.engine.jndi.JndiException: Unable to lookup JNDI name [java:jboss/UserTransaction]
> at org.hibernate.engine.jndi.internal.JndiServiceImpl.locate(JndiServiceImpl.java:117) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> at org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform.locateUserTransaction(JBossAppServerJtaPlatform.java:70) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> ... 150 more
> Caused by: javax.naming.NamingException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction [Root exception is java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
> at javax.naming.InitialContext.lookup(InitialContext.java:415) [rt.jar:1.7.0_51]
> at javax.naming.InitialContext.lookup(InitialContext.java:415) [rt.jar:1.7.0_51]
> at org.hibernate.engine.jndi.internal.JndiServiceImpl.locate(JndiServiceImpl.java:114) [hibernate-core-4.3.1.Final.jar:4.3.1.Final]
> ... 151 more
> Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction
> at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.realCheckPermission(AllowedMethodsInformation.java:138) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.checkAllowed(AllowedMethodsInformation.java:112) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.subsystem.EJB3UserTransactionAccessControlService$1.authorizeAccess(EJB3UserTransactionAccessControlService.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.txn.service.UserTransactionAccessControlService.authorizeAccess(UserTransactionAccessControlService.java:83)
> at org.jboss.as.txn.service.UserTransactionBindingService$1.getReference(UserTransactionBindingService.java:71)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> ... 159 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-3000) Incorrect 'Content-Type' response set after executing an erroneous command
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3000?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3000:
-----------------------------------
Fix Version/s: 8.0.1.Final
> Incorrect 'Content-Type' response set after executing an erroneous command
> --------------------------------------------------------------------------
>
> Key: WFLY-3000
> URL: https://issues.jboss.org/browse/WFLY-3000
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Christos Vasilakis
> Assignee: Brian Stansberry
> Fix For: 8.0.1.Final
>
>
> The http management interface, upon error, returns an incorrect 'Content-Type' of
> {noformat}
> 'Content-Type: text/plain; charset=utf-8'
> {noformat}
> although JSON response is returned.
> To reproduce, issue from the command line a simple 'read' operation
> {noformat}
> curl --digest -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "name":"foo"}' -u <username>:<password>
> ..
> Content-Type: text/plain; charset=utf-8
> Content-Length: 119
> Date: Sun, 23 Feb 2014 17:27:10 GMT
> {
> "outcome" : "failed",
> "failure-description" : "JBAS014792: Unknown attribute foo",
> "rolled-back" : true
> }
> {noformat}
> The 'Content-Type' should have been set to *'application/json'* instead of *'text/plain'*
> Note: On JBoss AS 7.1.1.Final, the correct type of *'application/json'* is returned for the same operation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months