[JBoss JIRA] (AS7-6432) Incorrect evaluation of system property for expression substitution
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/AS7-6432?page=com.atlassian.jira.plugin.s... ]
Ondřej Chaloupka closed AS7-6432.
---------------------------------
Resolution: Rejected
Yes, you're perfectly correct. Sorry for this jira.
The problem was in misconfiguration of test caused by the forgotten management action outcome check.
The evaluation of system properties works nice.
Thanks.
> Incorrect evaluation of system property for expression substitution
> -------------------------------------------------------------------
>
> Key: AS7-6432
> URL: https://issues.jboss.org/browse/AS7-6432
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.2.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Brian Stansberry
>
> Finally I think that I've got a way how to resolve expressions on VM where container resides.
> My test case:
> https://github.com/ochaloup/jboss-as/blob/expression-substitution-run-in-...
> From this I've found issues for system property evaluation. I mean the case when System.getProperty(someName) is called.
> The application should get the evaluated value from expression but instead of it it gets the default value from expression.
> The problematic test cases are
> testSystemPropertyEvaluation - there is defined system property by calling System.setProperty and it's expected that the expression which uses this defined property will evaluate itself to the value of the System.setProperty. For the way of :resolve-expression it works fine but for getting value with System.getProperty the old default value is returned.
> setInnerExpression - it defines two levels of evaluation of expression and it seems that then the System.getProperty on the second level of evaluation does not get the evaluated/substituted value
> I hope that the test code will be more comprehensible than my explanation.
--
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, 11 months
[JBoss JIRA] (AS7-6435) XA datasources not automatically bound with enable=true
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6435?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated AS7-6435:
-----------------------------
Fix Version/s: 7.2.0.CR1
> XA datasources not automatically bound with enable=true
> -------------------------------------------------------
>
> Key: AS7-6435
> URL: https://issues.jboss.org/browse/AS7-6435
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.2.0.Alpha1
> Environment: Fedora 18 (x86_64)
> JDK 7u11
> jboss-as-7.2.0.Alpha1-SNAPSHOT (built today)
> Reporter: Frederico Francisco
> Assignee: Stefano Maestri
> Fix For: 7.2.0.CR1
>
> Attachments: domain.xml
>
>
> It seems that my xa-datasource is not started automatically and this causes my applications to fail with:
> [Server:master-server-one] JBAS014775: New missing/unsatisfied dependencies:
> [Server:master-server-one] service jboss.data-source.java:jboss/datasources/XADS (unavailable) dependents: [service jboss.deployment.subunit."myapp.ear"."myapp-ejb.jar".component.UserClass.jdbc.store-manager.INIT]
> The webconsole shows that the datasource is enabled but when I try to disable it I get:
>
> Internal Server Error
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"cedsif-server-group" => {"host" => {"master" => {"master-server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS010455: Data-source service [XADS] is not enabled",
> "rolled-back" => true
> }}}}}}
> }
> The only way I got it to work was to use jboss-cli to start the datasource and then redeploying my applications.
> Also, it works if I use a non-xa datasource.
--
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, 11 months
[JBoss JIRA] (AS7-6435) XA datasources not automatically bound with enable=true
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6435?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated AS7-6435:
-----------------------------
Component/s: Domain Management
> XA datasources not automatically bound with enable=true
> -------------------------------------------------------
>
> Key: AS7-6435
> URL: https://issues.jboss.org/browse/AS7-6435
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 7.2.0.Alpha1
> Environment: Fedora 18 (x86_64)
> JDK 7u11
> jboss-as-7.2.0.Alpha1-SNAPSHOT (built today)
> Reporter: Frederico Francisco
> Assignee: Stefano Maestri
> Fix For: 7.2.0.CR1
>
> Attachments: domain.xml
>
>
> It seems that my xa-datasource is not started automatically and this causes my applications to fail with:
> [Server:master-server-one] JBAS014775: New missing/unsatisfied dependencies:
> [Server:master-server-one] service jboss.data-source.java:jboss/datasources/XADS (unavailable) dependents: [service jboss.deployment.subunit."myapp.ear"."myapp-ejb.jar".component.UserClass.jdbc.store-manager.INIT]
> The webconsole shows that the datasource is enabled but when I try to disable it I get:
>
> Internal Server Error
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"cedsif-server-group" => {"host" => {"master" => {"master-server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS010455: Data-source service [XADS] is not enabled",
> "rolled-back" => true
> }}}}}}
> }
> The only way I got it to work was to use jboss-cli to start the datasource and then redeploying my applications.
> Also, it works if I use a non-xa datasource.
--
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, 11 months
[JBoss JIRA] (HIBERNATE-132) The license information for hibernate-jpa-2.0-api has no name, only an URL: "license.txt"
by Alix Warnke (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-132?page=com.atlassian.jira.plu... ]
Alix Warnke updated HIBERNATE-132:
----------------------------------
Issue Type: Enhancement (was: Feature Request)
> The license information for hibernate-jpa-2.0-api has no name, only an URL: "license.txt"
> -----------------------------------------------------------------------------------------
>
> Key: HIBERNATE-132
> URL: https://issues.jboss.org/browse/HIBERNATE-132
> Project: Hibernate Integration
> Issue Type: Enhancement
> Environment: Maven 3
> Reporter: Alix Warnke
> Assignee: Steve Ebersole
> Priority: Minor
> Labels: license
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Today in the pom-file of hibernate-jpa-2.0-api:
> <licenses> -<license> <url>license.txt</url> </license> </licenses>
> I would like it to say:
> <licenses> -<license> <name>Eclipse Public License, V 1.0</name> <url>license.txt</url> </license> </licenses>
> as this would help when using a license plugin to automatically validate against a whitelist of licenses. It is impossible for the maven plugin to know what "license.txt" is.
--
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, 11 months
[JBoss JIRA] (AS7-6435) XA datasources not automatically bound with enable=true
by Frederico Francisco (JIRA)
[ https://issues.jboss.org/browse/AS7-6435?page=com.atlassian.jira.plugin.s... ]
Frederico Francisco updated AS7-6435:
-------------------------------------
Attachment: domain.xml
> XA datasources not automatically bound with enable=true
> -------------------------------------------------------
>
> Key: AS7-6435
> URL: https://issues.jboss.org/browse/AS7-6435
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.2.0.Alpha1
> Environment: Fedora 18 (x86_64)
> JDK 7u11
> jboss-as-7.2.0.Alpha1-SNAPSHOT (built today)
> Reporter: Frederico Francisco
> Assignee: Jesper Pedersen
> Attachments: domain.xml
>
>
> It seems that my xa-datasource is not started automatically and this causes my applications to fail with:
> [Server:master-server-one] JBAS014775: New missing/unsatisfied dependencies:
> [Server:master-server-one] service jboss.data-source.java:jboss/datasources/XADS (unavailable) dependents: [service jboss.deployment.subunit."myapp.ear"."myapp-ejb.jar".component.UserClass.jdbc.store-manager.INIT]
> The webconsole shows that the datasource is enabled but when I try to disable it I get:
>
> Internal Server Error
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"cedsif-server-group" => {"host" => {"master" => {"master-server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS010455: Data-source service [XADS] is not enabled",
> "rolled-back" => true
> }}}}}}
> }
> The only way I got it to work was to use jboss-cli to start the datasource and then redeploying my applications.
> Also, it works if I use a non-xa datasource.
--
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, 11 months
[JBoss JIRA] (AS7-6435) XA datasources not automatically bound with enable=true
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6435?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar reassigned AS7-6435:
--------------------------------
Assignee: Stefano Maestri (was: Jesper Pedersen)
> XA datasources not automatically bound with enable=true
> -------------------------------------------------------
>
> Key: AS7-6435
> URL: https://issues.jboss.org/browse/AS7-6435
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.2.0.Alpha1
> Environment: Fedora 18 (x86_64)
> JDK 7u11
> jboss-as-7.2.0.Alpha1-SNAPSHOT (built today)
> Reporter: Frederico Francisco
> Assignee: Stefano Maestri
> Attachments: domain.xml
>
>
> It seems that my xa-datasource is not started automatically and this causes my applications to fail with:
> [Server:master-server-one] JBAS014775: New missing/unsatisfied dependencies:
> [Server:master-server-one] service jboss.data-source.java:jboss/datasources/XADS (unavailable) dependents: [service jboss.deployment.subunit."myapp.ear"."myapp-ejb.jar".component.UserClass.jdbc.store-manager.INIT]
> The webconsole shows that the datasource is enabled but when I try to disable it I get:
>
> Internal Server Error
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"cedsif-server-group" => {"host" => {"master" => {"master-server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS010455: Data-source service [XADS] is not enabled",
> "rolled-back" => true
> }}}}}}
> }
> The only way I got it to work was to use jboss-cli to start the datasource and then redeploying my applications.
> Also, it works if I use a non-xa datasource.
--
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, 11 months
[JBoss JIRA] (AS7-6435) XA datasources not automatically bound with enable=true
by Frederico Francisco (JIRA)
Frederico Francisco created AS7-6435:
----------------------------------------
Summary: XA datasources not automatically bound with enable=true
Key: AS7-6435
URL: https://issues.jboss.org/browse/AS7-6435
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.2.0.Alpha1
Environment: Fedora 18 (x86_64)
JDK 7u11
jboss-as-7.2.0.Alpha1-SNAPSHOT (built today)
Reporter: Frederico Francisco
Assignee: Jesper Pedersen
It seems that my xa-datasource is not started automatically and this causes my applications to fail with:
[Server:master-server-one] JBAS014775: New missing/unsatisfied dependencies:
[Server:master-server-one] service jboss.data-source.java:jboss/datasources/XADS (unavailable) dependents: [service jboss.deployment.subunit."myapp.ear"."myapp-ejb.jar".component.UserClass.jdbc.store-manager.INIT]
The webconsole shows that the datasource is enabled but when I try to disable it I get:
Internal Server Error
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
"rolled-back" => true,
"server-groups" => {"cedsif-server-group" => {"host" => {"master" => {"master-server-one" => {"response" => {
"outcome" => "failed",
"failure-description" => "JBAS010455: Data-source service [XADS] is not enabled",
"rolled-back" => true
}}}}}}
}
The only way I got it to work was to use jboss-cli to start the datasource and then redeploying my applications.
Also, it works if I use a non-xa datasource.
--
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, 11 months
[JBoss JIRA] (AS7-4042) On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-4042?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-4042:
-----------------------------------
P R, this JIRA is just about a cosmetic change to the logging. If you are running into specific issue then please create a forum discussion here https://community.jboss.org/community/jbossas7?view=discussions with the relevant details.
> On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4042
> URL: https://issues.jboss.org/browse/AS7-4042
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Final, 7.1.2.Final (EAP)
> Reporter: Ondřej Chaloupka
> Assignee: jaikiran pai
> Priority: Minor
>
> When EJB invocations from a remote server instance is used and remoting connector of the remote server is secured and the attempt to connection fails an incorrect exception is thrown.
> In case of version 7.1.0.Final when authentication si not correctly defined then during deployment following exception is thrown:
> {code}
> ERROR [org.jboss.remoting.remote.connection] (Remoting "clientnode" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": org.jboss.msc.service.StartException in service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
> Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
> at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.createRemotingConnections(DescriptorBasedEJBClientContextService.java:124)
> at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.start(DescriptorBasedEJBClientContextService.java:86)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> ... 3 more
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:315) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.as.remoting.RemoteOutboundConnectionService.connect(RemoteOutboundConnectionService.java:130) [jboss-as-remoting-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> {code}
> which is correct. But in case that the remote server is shut down, configuration is changed to use security connection then incorrect and confusing exception is thrown:
> {code}
> ERROR [org.jboss.ejb3.invocation] (EJB default - 2) JBAS014134: EJB Invocation failed on component CallingBean for method public abstract java.lang.String serverclient.CallingBeanRemote.call(): javax.ejb.EJBException: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:80) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:300) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:194) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_23]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_23]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_23]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
> at serverclient.CallingBean.call(CallingBean.java:39) [serverclient-ejb.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> ... 27 more
> Caused by: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
> at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:516) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at $Proxy15.sayHello(Unknown Source) at serverclient.CallingBean.call(CallingBean.java:34) [serverclient-ejb.jar:]
> ... 46 more
> {code}
> The exception seems that everything was connected correctly only module does not exist in remote context.
> In case of the AS7 Final version is not so problematic but when you take source codes from git then after deploying of application to client server which would like to connect to a secured remote server then no exception is thrown during deployment. Everything looks fine but after execution of remote call the confusing exception is thrown and it's hard to understand that the problem is in not connected context because of security.
--
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, 11 months
[JBoss JIRA] (AS7-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated AS7-6334:
-----------------------------
Description:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups [OK]
clustering/infinispan - PR https://github.com/jbossas/jboss-as/pull/3971
cmp [OK]
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
ee - [OK]
ejb3 [OK]
jacorb - PR https://github.com/jbossas/jboss-as/pull/3974
jaxr [OK]
jaxrs [OK] empty subsystem
jdr - [OK] empty subsystem
jmx [OK]
jpa [OK]
jsf [OK]
jsr77 [OK] empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail PR sent https://github.com/jbossas/jboss-as/pull/3979
messaging [OK]
modcluster [OK]
naming [OK]
osgi [OK]
pojo [OK] empty subsystem
remoting - [OK]
sar [OK] empty subsystem
security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
threads [OK]
transactions [OK]
web [OK]
webservices - PR sent https://github.com/jbossas/jboss-as/pull/3979
weld [OK] empty subsystem
xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
was:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups [OK]
clustering/infinispan - PR https://github.com/jbossas/jboss-as/pull/3971
cmp [OK]
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
ee - [OK]
ejb3 [OK]
jacorb - PR https://github.com/jbossas/jboss-as/pull/3974
jaxr [OK]
jaxrs [OK] empty subsystem
jdr - [OK] empty subsystem
jmx [OK]
jpa [OK]
jsf [OK]
jsr77 [OK] empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail done - will send PR together with WS
messaging [OK]
modcluster [OK]
naming [OK]
osgi [OK]
pojo [OK] empty subsystem
remoting - [OK]
sar [OK] empty subsystem
security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
threads [OK]
transactions [OK]
web [OK]
webservices - almost done, problem with recursive discard transformation [tomaz]
weld [OK] empty subsystem
xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
> Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6334
> URL: https://issues.jboss.org/browse/AS7-6334
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.2.0.Alpha1
>
>
> Task to track the work we've all been doing on expressions/transformers.
> See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
> 1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
> 2) Basic transformation testing against 7.1.2 and 7.1.3
> 3) Reject-expression testing against 7.1.2 and 7.1.3
> Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
> Please edit this description and put an OK after the subsystem name to indicate it's good to go.
> clustering/jgroups [OK]
> clustering/infinispan - PR https://github.com/jbossas/jboss-as/pull/3971
> cmp [OK]
> configadmin [OK]
> connector/datasource
> connector/jca [OK]
> connector/resource-adapter
> deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
> ee - [OK]
> ejb3 [OK]
> jacorb - PR https://github.com/jbossas/jboss-as/pull/3974
> jaxr [OK]
> jaxrs [OK] empty subsystem
> jdr - [OK] empty subsystem
> jmx [OK]
> jpa [OK]
> jsf [OK]
> jsr77 [OK] empty subsystem
> logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
> mail PR sent https://github.com/jbossas/jboss-as/pull/3979
> messaging [OK]
> modcluster [OK]
> naming [OK]
> osgi [OK]
> pojo [OK] empty subsystem
> remoting - [OK]
> sar [OK] empty subsystem
> security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
> threads [OK]
> transactions [OK]
> web [OK]
> webservices - PR sent https://github.com/jbossas/jboss-as/pull/3979
> weld [OK] empty subsystem
> xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
--
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, 11 months
[JBoss JIRA] (JGRP-1578) UNICAST: lost ACK leads to endless retransmissions
by Bela Ban (JIRA)
Bela Ban created JGRP-1578:
------------------------------
Summary: UNICAST: lost ACK leads to endless retransmissions
Key: JGRP-1578
URL: https://issues.jboss.org/browse/JGRP-1578
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.2.7, 3.3
- B sends a unicast message M to A
- A drops the ACK(M) to B
- B sends no further messages to A
--> B will keep retransmitting M to A until it gets an ACK from A, or A leaves the cluster
--> However, A will not send an ACK(M) to B, as the logic for acking only sends an ack if we did receive a message from B and it was successfully added to the retransmit table
--> However, the retransmitted M will not get added to A's table, as M has already been received
SOLUTION:
- Always ack a message frpm B with the highest delivered seqno for B's table
--
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, 11 months