[JBoss JIRA] (AS7-6434) ResourceTransformationDescriptionBuilder needs a rejectChildResource(PathElement pathElement) method
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6434:
-------------------------------------
Summary: ResourceTransformationDescriptionBuilder needs a rejectChildResource(PathElement pathElement) method
Key: AS7-6434
URL: https://issues.jboss.org/browse/AS7-6434
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Kabir Khan
Priority: Critical
Fix For: 7.2.0.Alpha1
It has discardChildResource(PathElement pathElement) but in many, perhaps all cases using that is not correct.
Discarding is only valid if the legacy slave can produce a server without the discarded data and that server's running configuration will be consistent with newer version servers that see the data.
If that can't be done, or some conversion can't be made, a reject should happen to produce a more useful error message than what the slave will issue when it gets ops it can't understand.
--
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
11 years, 2 months
[JBoss JIRA] (JBASM-23) multiple servers with different credentials
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/JBASM-23?page=com.atlassian.jira.plugin.s... ]
Aleksandar Kostadinov closed JBASM-23.
--------------------------------------
Resolution: Out of Date
Closing as I don't think anybody would be touching that code anymore. Please correct me if I'm wrong.
> multiple servers with different credentials
> -------------------------------------------
>
> Key: JBASM-23
> URL: https://issues.jboss.org/browse/JBASM-23
> Project: JBoss AS Server Manager
> Issue Type: Task
> Affects Versions: 1.0.0.GA
> Reporter: Aleksandar Kostadinov
> Assignee: Aleksandar Kostadinov
> Priority: Minor
>
> Currently server manager sets credentials like
> SecurityAssociation.setPrincipal(new SimplePrincipal(username));
> SecurityAssociation.setCredential(password);
> I think that in this case every managed server should use the same credentials. Probably using the JndiLoginInitialContextFactory can fix that but not for the http invoker.
> Alternative way with JAAS needed.
--
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
11 years, 2 months
[JBoss JIRA] (AS7-4042) On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
by P R (JIRA)
[ https://issues.jboss.org/browse/AS7-4042?page=com.atlassian.jira.plugin.s... ]
P R commented on AS7-4042:
--------------------------
This bug, along with the aggressive EJB caching, also seems to prevent a consuming server from failing over to another server since the consuming server sees the down server as not having the EJB and never checks it again; even if the other server is started up later.
> 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
11 years, 2 months
[JBoss JIRA] (AS7-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry 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 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
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 - WIP Brian
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 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
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ]
Kabir Khan 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 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 - WIP Brian
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
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 - Just a note: the 'security' attribute transformation is not tested
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 - WIP Brian
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 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 - WIP Brian
> 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
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6397) Cluster Environment Web Session Locks
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-6397?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated AS7-6397:
--------------------------------
Forum Reference: https://community.jboss.org/message/794189#794189
@[~mrspinto] always link the prior discussion we had https://community.jboss.org/message/794189#794189 (@[~rachmato] these are the things we went through already :-) )
> Cluster Environment Web Session Locks
> -------------------------------------
>
> Key: AS7-6397
> URL: https://issues.jboss.org/browse/AS7-6397
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 64bits, 8 GB RAM
> Reporter: Manuel Pinto
> Assignee: Paul Ferraro
>
> Hi,
> I found a problem with web session locks in a cluster environment. We have two Liferay 6.1.1 nodes (over JBoss 7.1.1 Final) in standalone-ha.xml configuration with infinispan "web" cache-container, replicated-cache and file store. The load balancer is configured in non sticky session mode.
> Problem: when a node processes requests in some cases locks the session and never unlock it, preventing other node from processing requests for that session. The affected node never regain the locked session and keep throwing the following exception for all subsequent requests and only recover a session when other node shutdown:
> Note: we also tried invalidation-cache and distributed-cache and all locking modes but without success.
> 17:39:00,174 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http--172.16.250.105-8080-4) An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Cvn-K+r-cBGesIBoDrakJhrO
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:496) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2625) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:81) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//Cvn-K+r-cBGesIBoDrakJhrO from cluster
> at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372)
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> ... 12 more
> The standalone-ha.xml "web" cache-container config is the following:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="SYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> Thanks,
> Manuel Pinto
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6432) Incorrect evaluation of system property for expression substitution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6432?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6432:
---------------------------------------
I haven't fully analyzed this, but I suspect this is a similar issue to AS7-6431.
When you invoke /system-property=foo:add(value=bar), as part of executing that operation "bar" is evaluated and if it is an expression, the expression is resolved. The resolved value is then passed to System.setProperty(). There's no mechanism to monitor any subsequent changes to the system property map / environment variables / security vault and then re-resolve and re-invoke System.getProperty() whenever new data comes in. The same applies to all other uses of expressions -- when the value of the configuration attribute needs to be provided to a runtime service (e.g. a port # to a web connector) the expression is resolved at that point, the resolved value is provided to the runtime service and that's it. The AS and EAP have never supported anything beyond this and trying to do so is not part of this feature.
When you use the resolve-expression operation, what you are doing is providing a string to the operation handler, which resolves any expressions in it at that moment in time. So you shouldn't expect to get the same result that a resolution in at an earlier point in time would have gotten.
> 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
11 years, 2 months
[JBoss JIRA] (AS7-6397) Cluster Environment Web Session Locks
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-6397?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-6397:
------------------------------------------
This issue seems to be a duplicate of AS7-4260 which was resolved in AS 7.1.3, as were a number of other issues.
If you are willing, you may check out the tag of AS 7.1.3 from GitHub (https://github.com/jbossas/jboss-as/tree/7.1.3.Final) and
rebuild from source in order to pick up those fixes.
Is this acceptable?
> Cluster Environment Web Session Locks
> -------------------------------------
>
> Key: AS7-6397
> URL: https://issues.jboss.org/browse/AS7-6397
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 64bits, 8 GB RAM
> Reporter: Manuel Pinto
> Assignee: Paul Ferraro
>
> Hi,
> I found a problem with web session locks in a cluster environment. We have two Liferay 6.1.1 nodes (over JBoss 7.1.1 Final) in standalone-ha.xml configuration with infinispan "web" cache-container, replicated-cache and file store. The load balancer is configured in non sticky session mode.
> Problem: when a node processes requests in some cases locks the session and never unlock it, preventing other node from processing requests for that session. The affected node never regain the locked session and keep throwing the following exception for all subsequent requests and only recover a session when other node shutdown:
> Note: we also tried invalidation-cache and distributed-cache and all locking modes but without success.
> 17:39:00,174 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http--172.16.250.105-8080-4) An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Cvn-K+r-cBGesIBoDrakJhrO
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:496) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2625) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:81) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//Cvn-K+r-cBGesIBoDrakJhrO from cluster
> at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372)
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> ... 12 more
> The standalone-ha.xml "web" cache-container config is the following:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="SYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> Thanks,
> Manuel Pinto
--
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
11 years, 2 months
[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 updated AS7-6432:
----------------------------------
Summary: Incorrect evaluation of system property for expression substitution (was: Incorrect evaluation of sytem property for expression substitution)
> 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
11 years, 2 months