[JBoss JIRA] (WFLY-490) Domain Management Role Based Access Control
by Gopi Chand Uppala (JIRA)
[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ]
Gopi Chand Uppala commented on WFLY-490:
----------------------------------------
Brian, do you know which version of EAP would include this Feature and when we can expect that release?
> Domain Management Role Based Access Control
> -------------------------------------------
>
> Key: WFLY-490
> URL: https://issues.jboss.org/browse/WFLY-490
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: Authorization
> Fix For: 8.0.0.CR1
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
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-1613) FORK: cactus stacks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1613 at 8/1/13 7:16 AM:
--------------------------------------------------------
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope.
One of the main reasons not to implement a cactus stack like architecture like in the picture above was that - as grafts could be dynamically created (as a matter of fact, Sanne would need a graft to be created *per deployed application*) and deleted - not all nodes would have all grafts. This means that GMS would have to maintain something like the dreaded service views (google for Multiplexer service views, e.g. [1]). This means that if we have view \{A,B,C,D\}, but only nodes B and C have a certain graft created, then the *service view* for that graft would be \{B,C\}.
Another reason was that a number of protocols (discovery, failure detection, merge) would have to be rewritten to become singletons. It turned out that it's unlikely this could be genericized, e.g. FD_ALL maintains mappings between logical addresses (which are per channel) and physical addresses. It is therefore tied to a channel and would have to be rewritten to only deal with physical addresses. I'll keep this task for a later day...
So the new, limited, functionality should be:
* FORK can only be the top protocol in a stack (or towards the top of the stack)
* An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel
* The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets
* The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel
* In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty
* That string is used to mux/demux messages to the app
* A header is added to each message including that max-id so we know how to mux/demux
* There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel
* When the main channel is closed, sending of messages on the fork-channel throws an exception
* The view and address of the fork-channels is the same as that of the main channel
[1] https://community.jboss.org/wiki/MigrationFromMultiplexerToSharedTransport
was (Author: belaban):
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope.
One of the main reasons not to implement a cactus stack like architecture like in the picture above was that - as grafts could be dynamically created (as a matter of fact, Sanne would need a graft to be created *per deployed application*) and deleted - not all nodes would have all grafts. This means that GMS would have to maintain something like the dreaded service views (google for Multiplexer service views, e.g. [1]). This means that if we have view \{A,B,C,D\}, but only nodes B and C have a certain graft created, then the *service view* for that graft would be \{B,C\}.
The new functionality should be:
* FORK can only be the top protocol in a stack (or towards the top of the stack)
* An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel
* The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets
* The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel
* In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty
* That string is used to mux/demux messages to the app
* A header is added to each message including that max-id so we know how to mux/demux
* There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel
* When the main channel is closed, sending of messages on the fork-channel throws an exception
* The view and address of the fork-channels is the same as that of the main channel
[1] https://community.jboss.org/wiki/MigrationFromMultiplexerToSharedTransport
> FORK: cactus stacks
> -------------------
>
> Key: JGRP-1613
> URL: https://issues.jboss.org/browse/JGRP-1613
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack.
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.
--
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-1613) FORK: cactus stacks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1613 at 8/1/13 7:09 AM:
--------------------------------------------------------
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope.
One of the main reasons not to implement a cactus stack like architecture like in the picture above was that - as grafts could be dynamically created (as a matter of fact, Sanne would need a graft to be created *per deployed application*) and deleted - not all nodes would have all grafts. This means that GMS would have to maintain something like the dreaded service views (google for Multiplexer service views, e.g. [1]). This means that if we have view \{A,B,C,D\}, but only nodes B and C have a certain graft created, then the *service view* for that graft would be \{B,C\}.
The new functionality should be:
* FORK can only be the top protocol in a stack (or towards the top of the stack)
* An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel
* The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets
* The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel
* In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty
* That string is used to mux/demux messages to the app
* A header is added to each message including that max-id so we know how to mux/demux
* There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel
* When the main channel is closed, sending of messages on the fork-channel throws an exception
* The view and address of the fork-channels is the same as that of the main channel
[1] https://community.jboss.org/wiki/MigrationFromMultiplexerToSharedTransport
was (Author: belaban):
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope. One of the main reasons was that - as grafts could be dynamically created (as a matter of fact, Sanne would need a graft to be created *per deployed application*) and deleted - not all nodes would have all grafts. This means that GMS would have to maintain something like the dreaded service views (google for Multiplexer service views, e.g. [1]). This means that if we have view \{A,B,C,D\}, but only nodes B and C have a certain graft created, then the *service view* for that graft would be \{B,C\}.
The new functionality should be:
* FORK can only be the top protocol in a stack (or towards the top of the stack)
* An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel
* The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets
* The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel
* In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty
* That string is used to mux/demux messages to the app
* A header is added to each message including that max-id so we know how to mux/demux
* There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel
* When the main channel is closed, sending of messages on the fork-channel throws an exception
* The view and address of the fork-channels is the same as that of the main channel
[1] https://community.jboss.org/wiki/MigrationFromMultiplexerToSharedTransport
> FORK: cactus stacks
> -------------------
>
> Key: JGRP-1613
> URL: https://issues.jboss.org/browse/JGRP-1613
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack.
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.
--
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-1613) FORK: cactus stacks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1613 at 8/1/13 7:08 AM:
--------------------------------------------------------
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope. One of the main reasons was that - as grafts could be dynamically created (as a matter of fact, Sanne would need a graft to be created *per deployed application*) and deleted - not all nodes would have all grafts. This means that GMS would have to maintain something like the dreaded service views (google for Multiplexer service views, e.g. [1]). This means that if we have view \{A,B,C,D\}, but only nodes B and C have a certain graft created, then the *service view* for that graft would be \{B,C\}.
The new functionality should be:
* FORK can only be the top protocol in a stack (or towards the top of the stack)
* An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel
* The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets
* The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel
* In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty
* That string is used to mux/demux messages to the app
* A header is added to each message including that max-id so we know how to mux/demux
* There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel
* When the main channel is closed, sending of messages on the fork-channel throws an exception
* The view and address of the fork-channels is the same as that of the main channel
[1] https://community.jboss.org/wiki/MigrationFromMultiplexerToSharedTransport
was (Author: belaban):
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope:
* FORK can only be the top protocol in a stack (or towards the top of the stack)
* An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel
* The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets
* The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel
* In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty
* That string is used to mux/demux messages to the app
* A header is added to each message including that max-id so we know how to mux/demux
* There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel
* When the main channel is closed, sending of messages on the fork-channel throws an exception
* The view and address of the fork-channels is the same as that of the main channel
> FORK: cactus stacks
> -------------------
>
> Key: JGRP-1613
> URL: https://issues.jboss.org/browse/JGRP-1613
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack.
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.
--
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] (WFLY-1783) IIOPNamingTestCase is failing when run on IBM JDK
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka resolved WFLY-1783.
------------------------------------
Resolution: Done
The pom.xml change for basic module of testsuite was merged.
> IIOPNamingTestCase is failing when run on IBM JDK
> -------------------------------------------------
>
> Key: WFLY-1783
> URL: https://issues.jboss.org/browse/WFLY-1783
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha3
> Environment: ibm jdk
> Reporter: Ondřej Chaloupka
> Assignee: Ondřej Chaloupka
>
> Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
> Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> The stack trace:
> {code}
> java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
> at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
> at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}
> The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.
--
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] (WFLY-1800) Upgrade to Remoting JMX 2.0.0 (Beta 2)
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-1800:
--------------------------------------
Summary: Upgrade to Remoting JMX 2.0.0 (Beta 2)
Key: WFLY-1800
URL: https://issues.jboss.org/browse/WFLY-1800
Project: WildFly
Issue Type: Task
Components: JMX, Remoting
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.Alpha4
So that association of the Subject with the AccessControlContext is in place Remoting JMX 2.0.0.Beta 2 is 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
12 years, 11 months
[JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing when run on IBM JDK
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-1783:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/4856
> IIOPNamingTestCase is failing when run on IBM JDK
> -------------------------------------------------
>
> Key: WFLY-1783
> URL: https://issues.jboss.org/browse/WFLY-1783
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha3
> Environment: ibm jdk
> Reporter: Ondřej Chaloupka
> Assignee: Ondřej Chaloupka
>
> Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
> Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> The stack trace:
> {code}
> java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
> at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
> at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}
> The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.
--
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