[JBoss JIRA] (WFLY-3005) cannot override logging.configuration in jboss-cli.sh and jboss-cli.bat
by Gabriele Garuglieri (JIRA)
[ https://issues.jboss.org/browse/WFLY-3005?page=com.atlassian.jira.plugin.... ]
Gabriele Garuglieri updated WFLY-3005:
--------------------------------------
Issue Type: Bug (was: Enhancement)
> cannot override logging.configuration in jboss-cli.sh and jboss-cli.bat
> -----------------------------------------------------------------------
>
> Key: WFLY-3005
> URL: https://issues.jboss.org/browse/WFLY-3005
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Final
> Environment: windows and linux
> Reporter: Gabriele Garuglieri
> Assignee: Brian Stansberry
>
> when using cli scripts jboss-cli.sh and jboss-cli.bat and you cannot write in $JBOSS_HOME because it is serving many server instances, you can override default jboss-cli.xml setting -Djboss.cli.config in $JAVA_OPTS but you cannot override logging.configuration because in both scripts is set with default after expanding $JAVA_OPTS
> last lines of bat script could be modified as follows:
> echo "%JAVA_OPTS%" | findstr /I "logging.configuration" > nul
> if errorlevel == 1 (
> set "JAVA_OPTS=%JAVA_OPTS% -Dlogging.configuration=file:%JBOSS_HOME%\bin\jboss-cli-logging.properties"
> ) else (
> echo logging.configuration already set in JAVA_OPTS
> )
> "%JAVA%" %JAVA_OPTS% ^
> -jar "%JBOSS_RUNJAR%" ^
> -mp "%JBOSS_MODULEPATH%" ^
> org.jboss.as.cli ^
> %*
> Last lines of sh script could be modified as follows:
> LOG_CONF=`echo $JAVA_OPTS | $GREP "logging.configuration"`
> if [ "x$LOG_CONF" = "x" ]; then
> JAVA_OPTS="$JAVA_OPTS -Dlogging.configuration=file:$JBOSS_HOME/bin/jboss-cli-logging.properties"
> else
> echo "logging.configuration already set in JAVA_OPTS"
> fi
> # Sample JPDA settings for remote socket debugging
> #JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n"
> eval \"$JAVA\" $JAVA_OPTS -jar \"$JBOSS_HOME/jboss-modules.jar\" -mp \"${JBOSS_MODULEPATH}\" org.jboss.as.cli '"$@"'
--
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-3005) cannot override logging.configuration in jboss-cli.sh and jboss-cli.bat
by Gabriele Garuglieri (JIRA)
Gabriele Garuglieri created WFLY-3005:
-----------------------------------------
Summary: cannot override logging.configuration in jboss-cli.sh and jboss-cli.bat
Key: WFLY-3005
URL: https://issues.jboss.org/browse/WFLY-3005
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Scripts
Affects Versions: 8.0.0.Final
Environment: windows and linux
Reporter: Gabriele Garuglieri
Assignee: Brian Stansberry
when using cli scripts jboss-cli.sh and jboss-cli.bat and you cannot write in $JBOSS_HOME because it is serving many server instances, you can override default jboss-cli.xml setting -Djboss.cli.config in $JAVA_OPTS but you cannot override logging.configuration because in both scripts is set with default after expanding $JAVA_OPTS
last lines of bat script could be modified as follows:
echo "%JAVA_OPTS%" | findstr /I "logging.configuration" > nul
if errorlevel == 1 (
set "JAVA_OPTS=%JAVA_OPTS% -Dlogging.configuration=file:%JBOSS_HOME%\bin\jboss-cli-logging.properties"
) else (
echo logging.configuration already set in JAVA_OPTS
)
"%JAVA%" %JAVA_OPTS% ^
-jar "%JBOSS_RUNJAR%" ^
-mp "%JBOSS_MODULEPATH%" ^
org.jboss.as.cli ^
%*
Last lines of sh script could be modified as follows:
LOG_CONF=`echo $JAVA_OPTS | $GREP "logging.configuration"`
if [ "x$LOG_CONF" = "x" ]; then
JAVA_OPTS="$JAVA_OPTS -Dlogging.configuration=file:$JBOSS_HOME/bin/jboss-cli-logging.properties"
else
echo "logging.configuration already set in JAVA_OPTS"
fi
# Sample JPDA settings for remote socket debugging
#JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n"
eval \"$JAVA\" $JAVA_OPTS -jar \"$JBOSS_HOME/jboss-modules.jar\" -mp \"${JBOSS_MODULEPATH}\" org.jboss.as.cli '"$@"'
--
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] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1795:
-------------------------------------------
It may take a while as: (i) Jenkins is currently kaput and (ii) because we have to run the jobs sequentially now, and because there are so many in each matrix, its taking *forever* to do one run. I'll have to talk to QE and get them to stop the automated jobs and do one offs for the time being.
> OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
> -----------------------------------------------------------------------
>
> Key: JGRP-1795
> URL: https://issues.jboss.org/browse/JGRP-1795
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> This test does the following with two channels a and b:
> - adds a DISCARD layer to a to disccard 50% of down messages
> - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB
> - wait 10 seconds for 20 messages to be received by each of a and b
> - print out the messages received
> - remove the DISCARD layer from a
> - wait 2.5 seconds for further messages to arrive
> - assert that 20 messages have arrived for each channel a and b
> The test fails on the assertion, with results such as:
> {noformat}
> expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11]
> {noformat}
--
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] (JGRP-1799) RpcDispatcher test fails when working with large values
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1799:
-------------------------------------------
The memory settings in the testsuite are set to: -Xms600M -Xmx800M
Two points to note:
- in the case of testLargeReturnValue, shouldn't an exception be returned if the value cannot be transported back to the caller, as opposed to null?
- in the case of testLargeReturnValueUnicastCall, could this be the result of longer than usual processing in de-fragmentation or bundling (due to slower machine) which causes the timeout on the send?
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
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] (JGRP-1799) RpcDispatcher test fails when working with large values
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1799:
-----------------------------------------
Summary: RpcDispatcher test fails when working with large values
Key: JGRP-1799
URL: https://issues.jboss.org/browse/JGRP-1799
Project: JGroups
Issue Type: Bug
Affects Versions: 3.2.13
Environment: RHEL, Win, Solaris
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Fix For: 3.2.13
The two tests:
* testLargeReturnValue
* testLargeReturnValueUnicastCall
make RPC calls with values which are increasingly large.
The values used are in this range:
{noformat}
SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
{noformat}
The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
--
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-1904) Usage of vault for system-properties throws java.lang.SecurityException
by Navin Surtani (JIRA)
[ https://issues.jboss.org/browse/WFLY-1904?page=com.atlassian.jira.plugin.... ]
Navin Surtani updated WFLY-1904:
--------------------------------
Assignee: Brian Stansberry (was: Navin Surtani)
> Usage of vault for system-properties throws java.lang.SecurityException
> -----------------------------------------------------------------------
>
> Key: WFLY-1904
> URL: https://issues.jboss.org/browse/WFLY-1904
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Beta1
> Reporter: Navin Surtani
> Assignee: Brian Stansberry
>
> Steps to Reproduce: 1. add the lines in standalone.xml:-
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/dir/truststore.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="${VAULT::blk::attr::MTBlYWUzNDEtMjI2MC00NWYzLWFiZmUtM2EyYjZkNDgyZWM4TElORV9CUkVBS215YWxpYXM=}" />
> </system-properties>
> <vault>
> <vault-option name="KEYSTORE_URL" value="/opt/jboss-eap-6.0/standalone/configuration/vault.jks"/>
> <vault-option name="KEYSTORE_PASSWORD" value="MASK-2gTQPnrWJaqrh0pURMKAOw"/>
> <vault-option name="KEYSTORE_ALIAS" value="myalias"/>
> <vault-option name="SALT" value="12345678"/>
> <vault-option name="ITERATION_COUNT" value="44"/>
> <vault-option name="ENC_FILE_DIR" value="/opt/jboss-eap-6.0/standalone/configuration/"/>
> </vault>
> {code}
> 2. start EAP6 in standalone mode
> project_key: JBPAPP6
> Usage of vault for system-properties throws java.lang.SecurityException.
> boot.log:-
> {code}
> 20:35:30,267 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([("system-property" => "javax.net.ssl.trustStorePassword")]): java.lang.SecurityException: JBAS013322: Vault is not initialized
> at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:98) [jboss-as-security-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:58) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:40) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:455) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:689) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.operations.common.SystemPropertyAddHandler.execute(SystemPropertyAddHandler.java:112) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:175) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:191) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:295) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:270) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
--
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 Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2960?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2960:
------------------------------------
I'm not 100% sure from the exception call stack that you originally posted but when your using CMT, it looks like Spring is trying to start a new JTA transaction.
Are you specifying org.springframework.transaction.jta.JtaTransactionManager? The [Spring documentation|http://docs.spring.io/spring/docs/3.0.x/reference/transaction.html] mentions that JtaTransactionManager could be used.
> 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-2633) Cannot use deployments with same runtime-name in a domain
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2633?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2633:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1040621|https://bugzilla.redhat.com/show_bug.cgi?id=1040621] from ON_QA to VERIFIED
> Cannot use deployments with same runtime-name in a domain
> ---------------------------------------------------------
>
> Key: WFLY-2633
> URL: https://issues.jboss.org/browse/WFLY-2633
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.CR1
>
>
> The check for duplicate runtime-name in a server group on startup is too aggressive. It is incorrectly throwing an error on startup if there are any duplicate runtime-names in the whole domain, instead of just in a single server group.
> Steps to Reproduce:
> 1. Start a single HC/DC
> 2. deploy --name=foo1 --runtime-name=bar --disabled testfile
> 3. deploy --name=foo2 --runtime-name=bar --disabled testfile
> 4. restart the DC/HC
> Actual results:
> JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> ...
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1348,9]
> ...
> Message: JBAS014664: An element of this type named 'bar' has already been declared
> Expected results:
> No errors
--
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