[JBoss JIRA] (WFLY-3776) ClassNotFound exception when running Arquillian test
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-3776?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos reassigned WFLY-3776:
---------------------------------------------
Assignee: Panagiotis Sotiropoulos (was: Jason Greene)
> ClassNotFound exception when running Arquillian test
> ----------------------------------------------------
>
> Key: WFLY-3776
> URL: https://issues.jboss.org/browse/WFLY-3776
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.1.0.Final
> Environment: Mac
> Reporter: xiaodong xie
> Assignee: Panagiotis Sotiropoulos
>
> org.jboss.as.embedded.EmbeddedStandAloneServerFactory uses org.jboss.as.protocol.StreamUtils, which belongs to "org.jboss.as.protocol" module. This module is not imported in "org.jboss.as.embedded" module.
> Adding the import fix the issue.
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-3799) Wrong WildFly version when WildFly standalone is started
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-3799?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos commented on WFLY-3799:
-----------------------------------------------
INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha9) started in 1687ms - Started 199 of 361 services (192 services are lazy, passive or on-demand)
Tested and version is ok.
> Wrong WildFly version when WildFly standalone is started
> --------------------------------------------------------
>
> Key: WFLY-3799
> URL: https://issues.jboss.org/browse/WFLY-3799
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Server
> Affects Versions: 9.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Panagiotis Sotiropoulos
> Fix For: 9.0.0.Beta1
>
>
> I compiled the WildFly snapshot from GitHub. When I start WildFly standalone, then I see this final log message with the version number from WildFly Core:
> {code}
> INFO [org.jboss.as] WFLYSRV0025: WildFly 1.0.0.Alpha5 "Kenny" started in 2454ms - Started 216 of 319 services (143 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-3830) Use external-context for remote TIBCO ems lookup
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3830?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-3830:
-----------------------------------
As explained in the PR, the TIBCO JNDI provider accepts only CompoundName in its lookup(Name) method.
With the PR, it is possible to use the external-context with TIBCO EMS by using the StringOnlyInitialContext wrapper that convert the lookup(Name) call to the corresponding lookup(String) call.
{noformat}
<external-context name="java:global/tibco" module="com.tibco" class="org.jboss.as.naming.StringOnlyInitialContext">
<environment>
<property name="java.naming.factory.initial" value="com.tibco.tibjms.naming.TibjmsInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp:/<server>:<port>"/>
<property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
</environment>
</external-context>
{noformat}
Note that the com.tibco module *must* have a dependency on the org.jboss.as.naming module to access this wrapper.
> Use external-context for remote TIBCO ems lookup
> ------------------------------------------------
>
> Key: WFLY-3830
> URL: https://issues.jboss.org/browse/WFLY-3830
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.1.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> If an users uses the generic JMS RA with the TIBCO EMS messaging server, he has to duplicate all the JNDI parameters in the MDB annotations.
> Instead, he should be able to use a naming's external-context to connect to the Remote TIBCO server with the following configuration:
> {noformat}
> <bindings>
> <external-context name="java:global/tibco" module="com.tibco" class="javax.naming.InitialContext">
> <environment>
> <property name="java.naming.factory.initial" value="com.tibco.tibjms.naming.TibjmsInitialContextFactory"/>
> <property name="java.naming.provider.url" value="tcp://<tibco_server>:<tibco_port>"/>
> <property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
> </environment>
> </external-context>
> </bindings>
> {noformat}
> With these settings, the user only needs to pass the expected connection factory and destination lookup in the MDB:
> {noformat}
> @ActivationConfigProperty(propertyName = "connectionFactory", propertyValue = "java:global/tibco/XACF"),
> @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:global/tibco/Q1"),
> {noformat}
> The local JNDI lookup "java:global/tibco/Q1" will then use the external context (bound to "java:global/tibco") to lookup the "Q1" name on the TIBCO EMS.
> There are a few bugs in the ExternalObjectFactory that prevents to use this configuration with a regular javax.naming.InitialContext to build the external context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-3830) Use external-context for remote TIBCO ems lookup
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3830?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-3830:
------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/6878 (was: https://github.com/wildfly/wildfly/pull/6687)
> Use external-context for remote TIBCO ems lookup
> ------------------------------------------------
>
> Key: WFLY-3830
> URL: https://issues.jboss.org/browse/WFLY-3830
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.1.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> If an users uses the generic JMS RA with the TIBCO EMS messaging server, he has to duplicate all the JNDI parameters in the MDB annotations.
> Instead, he should be able to use a naming's external-context to connect to the Remote TIBCO server with the following configuration:
> {noformat}
> <bindings>
> <external-context name="java:global/tibco" module="com.tibco" class="javax.naming.InitialContext">
> <environment>
> <property name="java.naming.factory.initial" value="com.tibco.tibjms.naming.TibjmsInitialContextFactory"/>
> <property name="java.naming.provider.url" value="tcp://<tibco_server>:<tibco_port>"/>
> <property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
> </environment>
> </external-context>
> </bindings>
> {noformat}
> With these settings, the user only needs to pass the expected connection factory and destination lookup in the MDB:
> {noformat}
> @ActivationConfigProperty(propertyName = "connectionFactory", propertyValue = "java:global/tibco/XACF"),
> @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:global/tibco/Q1"),
> {noformat}
> The local JNDI lookup "java:global/tibco/Q1" will then use the external context (bound to "java:global/tibco") to lookup the "Q1" name on the TIBCO EMS.
> There are a few bugs in the ExternalObjectFactory that prevents to use this configuration with a regular javax.naming.InitialContext to build the external context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-4028) Can't register cache-container with more than one local-cache entries
by Dmitry Lisovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-4028?page=com.atlassian.jira.plugin.... ]
Dmitry Lisovsky updated WFLY-4028:
----------------------------------
Description:
When I try to add my cache-container with more then one local-cache entries in standalone-full.xml I got error:
{noformat}
ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "infinispan"),
("cache-container" => "my-container-name"),
("local-cache" => "my-2nd-local-cache-name")
]): org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java.jboss.true is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1866) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.installJndiService(CacheAddHandler.java:318)
at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.installRuntimeServices(CacheAddHandler.java:225)
at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.performRuntime(CacheAddHandler.java:180)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:131) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:695) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:530) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:298) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:355) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{noformat}
The XML I'm trying to add:
{noformat}
<cache-container name="my-container-name" jndi-name="java:jboss/infinispan/container/my-container-name">
<local-cache name="my-1st-local-cache-name" batching="true">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="my-2nd-local-cache-name" batching="true">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="my-3rd-local-cache-name" batching="true">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
</cache-container>
{noformat}
In the Wildfly 8.1.0 it worked OK.
was:
When I try to add my cache-container with more then one local-cache entries in standalone-full.xml I got error:
{noformat}
ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "infinispan"),
("cache-container" => "my-container-name"),
("local-cache" => "my-2nd-local-cache-name")
]): org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java.jboss.true is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1866) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.installJndiService(CacheAddHandler.java:318)
at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.installRuntimeServices(CacheAddHandler.java:225)
at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.performRuntime(CacheAddHandler.java:180)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:131) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:695) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:530) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:298) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:355) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{noformat}
The XML I'm trying to add:
{noformat}
<cache-container name="my-container-name" jndi-name="java:jboss/infinispan/container/my-container-name">
<local-cache name="my-1st-local-cache-name" batching="true">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="my-2nd-local-cache-name" batching="true">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="my-3rd-local-cache-name" batching="true">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
</cache-container>
{noformat}
> Can't register cache-container with more than one local-cache entries
> ---------------------------------------------------------------------
>
> Key: WFLY-4028
> URL: https://issues.jboss.org/browse/WFLY-4028
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Alpha1
> Reporter: Dmitry Lisovsky
> Assignee: Jason Greene
>
> When I try to add my cache-container with more then one local-cache entries in standalone-full.xml I got error:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "infinispan"),
> ("cache-container" => "my-container-name"),
> ("local-cache" => "my-2nd-local-cache-name")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java.jboss.true is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1866) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.installJndiService(CacheAddHandler.java:318)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.installRuntimeServices(CacheAddHandler.java:225)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.performRuntime(CacheAddHandler.java:180)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:131) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:695) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:530) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:298) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:355) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {noformat}
> The XML I'm trying to add:
> {noformat}
> <cache-container name="my-container-name" jndi-name="java:jboss/infinispan/container/my-container-name">
> <local-cache name="my-1st-local-cache-name" batching="true">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <local-cache name="my-2nd-local-cache-name" batching="true">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <local-cache name="my-3rd-local-cache-name" batching="true">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> </cache-container>
> {noformat}
> In the Wildfly 8.1.0 it worked OK.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-3799) Wrong WildFly version when WildFly standalone is started
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-3799?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann resolved WFLY-3799.
--------------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
The issue is gone in the latest WildFly snapshot.
> Wrong WildFly version when WildFly standalone is started
> --------------------------------------------------------
>
> Key: WFLY-3799
> URL: https://issues.jboss.org/browse/WFLY-3799
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Server
> Affects Versions: 9.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Panagiotis Sotiropoulos
> Fix For: 9.0.0.Beta1
>
>
> I compiled the WildFly snapshot from GitHub. When I start WildFly standalone, then I see this final log message with the version number from WildFly Core:
> {code}
> INFO [org.jboss.as] WFLYSRV0025: WildFly 1.0.0.Alpha5 "Kenny" started in 2454ms - Started 216 of 319 services (143 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-3799) Wrong WildFly version when WildFly standalone is started
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-3799?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos reassigned WFLY-3799:
---------------------------------------------
Assignee: Panagiotis Sotiropoulos
> Wrong WildFly version when WildFly standalone is started
> --------------------------------------------------------
>
> Key: WFLY-3799
> URL: https://issues.jboss.org/browse/WFLY-3799
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Server
> Affects Versions: 9.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Panagiotis Sotiropoulos
>
> I compiled the WildFly snapshot from GitHub. When I start WildFly standalone, then I see this final log message with the version number from WildFly Core:
> {code}
> INFO [org.jboss.as] WFLYSRV0025: WildFly 1.0.0.Alpha5 "Kenny" started in 2454ms - Started 216 of 319 services (143 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-140) switching users between ejb calls does not work when the call originates from a remote client
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-140?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-140:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=921217
> switching users between ejb calls does not work when the call originates from a remote client
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-140
> URL: https://issues.jboss.org/browse/WFLY-140
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Alpha1
>
>
> Description of problem:
> Switching users between ejb calls does not work when the call originates
> from a remote client. In this case, both ejbs are on the same JBoss instance.
> The use case looks like the following:
> remote standalone client ---> unsecured ejb3 (switch user here) -> secured ejb3
> I tried to use both approaches outlined in Q10/A10 of the JBoss
> Security FAQ [1] in order to establish a security context in
> the unsecured ejb that should be used to invoke the secured ejb.
> Neither approach worked in my testing.
> When the same unsecured ejb is called from a web application (secured
> or unsecured), then the user switching works correctly.
> The ejb security code appears to work differently based on the client
> type (standalone remote ejb client vs a web application).
> I believe this is happening because the
> org.jboss.as.security.service.SimpleSecurityManager.push method (called
> by the SecurityContextInterceptor) is checking for an existing
> RemotingContext and grabbing the security context from there even
> though the security context that should be used appears to be getting
> propagated correctly.
> The following area of the code appears to be causing the issue. This
> section of code is executed which causes the newly established security
> context to be ignored:
> if (RemotingContext.isSet()) {
> // In this case the principal and credential will not have been set to set some random values.
> SecurityContextUtil util = current.getUtil();
> Steps to Reproduce:
> Create a test application that looks like the following:
> remote client ---> unsecured ejb3 (switch user here) -> secured ejb3
> Actual results:
> If the unsecured ejb is invoked from a remote client, the user switching that takes place in the first ejb is ignored. Replace the remote standalone client with a web application and the user switching works.
> Expected results:
> User switching should work if the client is a standalone remote client or a web application.
> Additional info:
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (DROOLS-644) no-loop attribute and named consequences
by Pedro Martins (JIRA)
Pedro Martins created DROOLS-644:
------------------------------------
Summary: no-loop attribute and named consequences
Key: DROOLS-644
URL: https://issues.jboss.org/browse/DROOLS-644
Project: Drools
Issue Type: Bug
Affects Versions: 6.1.0.Final
Reporter: Pedro Martins
Assignee: Mark Proctor
I wrote a rule that modifies a fact from within a named consequence. The no-loop attribute failed to prevent the rule from reactivating.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months