New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WFLY-3830] Use external-context for TIBCO EMS #6878

Merged
merged 1 commit into from Nov 4, 2014

Conversation

Projects
None yet
5 participants
@jmesnil
Member

jmesnil commented Oct 29, 2014

Tibco EMS's JNDI provider is non-standard and accepts only CompoundName
in its lookup(Name) method while WildFly passes a CompositeName.

For such JNDI providers that accept only specific subtypes of Name, the
StringOnlyInitialContext will wrap a normal InitialContext and make sure
that any Name-based method is using the corresponding String-based
method (that is more likely to work as expected).

JIRA: https://issues.jboss.org/browse/WFLY-3830

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Linux with security manager Build 343 is now running using a merge of 89591ff

wildfly-ci commented Oct 29, 2014

Linux with security manager Build 343 is now running using a merge of 89591ff

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Linux Build 5351 is now running using a merge of 89591ff

wildfly-ci commented Oct 29, 2014

Linux Build 5351 is now running using a merge of 89591ff

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Windows Build 458 is now running using a merge of 89591ff

wildfly-ci commented Oct 29, 2014

Windows Build 458 is now running using a merge of 89591ff

@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Oct 29, 2014

Member

Using the configuration:

<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:/<server>:<port>"/>
    <property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
  </environment>
</external-context>

results in an error in TibjmsContext.lookup:

 11:31:49,047 ERROR [org.jboss.resource.adapter.jms.inflow.JmsActivation] (default-threads - 1) Unable to reconnect org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@44e0be11(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@d2f5afb3 destination=java:global/tibco/Q1 destinationType=javax.jms.Queue acknowledgeMode=Auto-acknowledge subscriptionDurability=false reconnectInterval=10 reconnectAttempts=-1 user=null maxMessages=1 minSession=1 maxSession=15 connectionFactory=java:global/tibco/XACF): javax.naming.InvalidNameException: Only support CompoundName names
    at com.tibco.tibjms.naming.TibjmsContext.lookup(TibjmsContext.java:504) [tibjms.jar:6.3.0]
    at javax.naming.InitialContext.lookup(InitialContext.java:421) [rt.jar:1.8.0_05]
    at javax.naming.InitialContext.lookup(InitialContext.java:421) [rt.jar:1.8.0_05]
    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:231)

If I use instead this StringOnlyInitialContext in the external-context configuration:

<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>

the lookup succeeds and I can interact with TIBCO EMS resource.

Member

jmesnil commented Oct 29, 2014

Using the configuration:

<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:/<server>:<port>"/>
    <property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
  </environment>
</external-context>

results in an error in TibjmsContext.lookup:

 11:31:49,047 ERROR [org.jboss.resource.adapter.jms.inflow.JmsActivation] (default-threads - 1) Unable to reconnect org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@44e0be11(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@d2f5afb3 destination=java:global/tibco/Q1 destinationType=javax.jms.Queue acknowledgeMode=Auto-acknowledge subscriptionDurability=false reconnectInterval=10 reconnectAttempts=-1 user=null maxMessages=1 minSession=1 maxSession=15 connectionFactory=java:global/tibco/XACF): javax.naming.InvalidNameException: Only support CompoundName names
    at com.tibco.tibjms.naming.TibjmsContext.lookup(TibjmsContext.java:504) [tibjms.jar:6.3.0]
    at javax.naming.InitialContext.lookup(InitialContext.java:421) [rt.jar:1.8.0_05]
    at javax.naming.InitialContext.lookup(InitialContext.java:421) [rt.jar:1.8.0_05]
    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:231)

If I use instead this StringOnlyInitialContext in the external-context configuration:

<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>

the lookup succeeds and I can interact with TIBCO EMS resource.

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Linux with security manager Build 343 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:19

wildfly-ci commented Oct 29, 2014

Linux with security manager Build 343 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:19

@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Oct 29, 2014

Member

this PR supersedes #6687.

Please do not merge until @emmartins & @n1hility have approved.

Member

jmesnil commented Oct 29, 2014

this PR supersedes #6687.

Please do not merge until @emmartins & @n1hility have approved.

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Windows Build 458 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:54:21

wildfly-ci commented Oct 29, 2014

Windows Build 458 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:54:21

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Linux Build 5351 outcome was FAILURE using a merge of 89591ff
Summary: Tests failed: 4 (4 new), passed: 3022, ignored: 238, muted: 1 Build time: 0:57:24

Build problems:

Failed tests detected

Failed tests

org.jboss.as.test.manualmode.ws.ReloadRequiringChangesTestCase.testWSDLHostChangeRequiresReloadAndDoesNotAffectRuntime: java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
    at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:216)
    at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146)

org.jboss.as.test.manualmode.ws.ReloadRequiringChangesTestCase.testWSDLHostChangeRequiresReloadAndDoesNotAffectRuntime: org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not stop container
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:735)

org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload: org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: jaxws-manual-pojo.war
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)

org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase.testWsdlUriSchemeChanges: java.net.UnknownHostException: foo-host
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:178)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

wildfly-ci commented Oct 29, 2014

Linux Build 5351 outcome was FAILURE using a merge of 89591ff
Summary: Tests failed: 4 (4 new), passed: 3022, ignored: 238, muted: 1 Build time: 0:57:24

Build problems:

Failed tests detected

Failed tests

org.jboss.as.test.manualmode.ws.ReloadRequiringChangesTestCase.testWSDLHostChangeRequiresReloadAndDoesNotAffectRuntime: java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
    at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:216)
    at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146)

org.jboss.as.test.manualmode.ws.ReloadRequiringChangesTestCase.testWSDLHostChangeRequiresReloadAndDoesNotAffectRuntime: org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not stop container
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:735)

org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload: org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: jaxws-manual-pojo.war
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)

org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase.testWsdlUriSchemeChanges: java.net.UnknownHostException: foo-host
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:178)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Oct 29, 2014

Member

retest this please

Member

jmesnil commented Oct 29, 2014

retest this please

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Windows Build 459 is now running using a merge of 89591ff

wildfly-ci commented Oct 29, 2014

Windows Build 459 is now running using a merge of 89591ff

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Linux Build 5352 is now running using a merge of 89591ff

wildfly-ci commented Oct 29, 2014

Linux Build 5352 is now running using a merge of 89591ff

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Linux with security manager Build 344 is now running using a merge of 89591ff

wildfly-ci commented Oct 29, 2014

Linux with security manager Build 344 is now running using a merge of 89591ff

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Linux with security manager Build 344 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:20

wildfly-ci commented Oct 29, 2014

Linux with security manager Build 344 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:20

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Windows Build 459 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:54:42

wildfly-ci commented Oct 29, 2014

Windows Build 459 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:54:42

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 29, 2014

Linux Build 5352 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:56:56

wildfly-ci commented Oct 29, 2014

Linux Build 5352 outcome was SUCCESS using a merge of 89591ff
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:56:56

@stuartwdouglas

This comment has been minimized.

Show comment
Hide comment
@stuartwdouglas

stuartwdouglas Oct 30, 2014

Contributor

This issue I have with this is that in general we are not supposed to expose internal class names via our management API, and something like this should be exposed as an attribute on the management model, although as this case is fairly borderline I'm not 100% sure if we should enforce this here.

Contributor

stuartwdouglas commented Oct 30, 2014

This issue I have with this is that in general we are not supposed to expose internal class names via our management API, and something like this should be exposed as an attribute on the management model, although as this case is fairly borderline I'm not 100% sure if we should enforce this here.

@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Oct 30, 2014

Member

I understand your concern and agree with it but I'd like to make an exception for that case.
This PR is really a workaround because Tibco JNDI provider is not behaving correctly. I don't want to add a management attribute and having to support and maintain it just for this single case. If the next version of Tibco fixes that behaviour, we'd still have to support this management attribute.

I'm not happy with this hack but I don't want to commit to a change in our management model until we see that other JNDI providers have the same non-standard behaviour. So far, only TIBCO has exhibited it.

The current alternative is to let clients that use TIBCO write their own ObjectFactory (and put them in a module). Using the external-context instead solves 99% of their issue. This dumb wrapper is the remaining 1% to provide a more user-friendly solution.

Member

jmesnil commented Oct 30, 2014

I understand your concern and agree with it but I'd like to make an exception for that case.
This PR is really a workaround because Tibco JNDI provider is not behaving correctly. I don't want to add a management attribute and having to support and maintain it just for this single case. If the next version of Tibco fixes that behaviour, we'd still have to support this management attribute.

I'm not happy with this hack but I don't want to commit to a change in our management model until we see that other JNDI providers have the same non-standard behaviour. So far, only TIBCO has exhibited it.

The current alternative is to let clients that use TIBCO write their own ObjectFactory (and put them in a module). Using the external-context instead solves 99% of their issue. This dumb wrapper is the remaining 1% to provide a more user-friendly solution.

@n1hility

This comment has been minimized.

Show comment
Hide comment
@n1hility

n1hility Oct 30, 2014

Contributor

Yeah it effectively means this is an API/SPI.

Contributor

n1hility commented Oct 30, 2014

Yeah it effectively means this is an API/SPI.

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux with security manager Build 364 is now running using a merge of 692ed7c

wildfly-ci commented Oct 31, 2014

Linux with security manager Build 364 is now running using a merge of 692ed7c

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux Build 5373 is now running using a merge of 692ed7c

wildfly-ci commented Oct 31, 2014

Linux Build 5373 is now running using a merge of 692ed7c

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Windows Build 479 is now running using a merge of 692ed7c

wildfly-ci commented Oct 31, 2014

Windows Build 479 is now running using a merge of 692ed7c

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux with security manager Build 364 outcome was SUCCESS using a merge of 692ed7c
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:26

wildfly-ci commented Oct 31, 2014

Linux with security manager Build 364 outcome was SUCCESS using a merge of 692ed7c
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:26

@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Oct 31, 2014

Member

One more try... :)

Yesterday, we talked about this PR and @dmlloyd and @n1hility suggested to used a decision table (based on the Context class metadata) to decide whether a JNDI provider would use the lookup(String) instead of the lookup(Name).

This has the advantage to avoid adding any API.
However we would have to maintain and update this decision table (when a new version of a guilty JNDI provider is released, when another provider exhibits the same behaviours). I don't want to have to cut a new release of WildFly because an user requires such a JNDI provider that's not taken into account by the decision table.

So, would it be acceptable if the decision of using the lookup(String) was based on the presence of a org.jboss.as.naming.lookup.by.string property set to true in the external-context's environment?

With such a property, the additional API surface is minimal (only this property, no class, no module dependency).

To sum up, if the user is using TIBCO without success with this configuration:

<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:/<server>:<port>"/>
    <property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
  </environment>
</external-context>

because it results in an error in TibjmsContext.lookup:

 11:31:49,047 ERROR [org.jboss.resource.adapter.jms.inflow.JmsActivation] (default-threads - 1) Unable to reconnect org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@44e0be11(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@d2f5afb3 destination=java:global/tibco/Q1 destinationType=javax.jms.Queue acknowledgeMode=Auto-acknowledge subscriptionDurability=false reconnectInterval=10 reconnectAttempts=-1 user=null maxMessages=1 minSession=1 maxSession=15 connectionFactory=java:global/tibco/XACF): javax.naming.InvalidNameException: Only support CompoundName names
    at com.tibco.tibjms.naming.TibjmsContext.lookup(TibjmsContext.java:504) [tibjms.jar:6.3.0]
    at javax.naming.InitialContext.lookup(InitialContext.java:421) [rt.jar:1.8.0_05]
    at javax.naming.InitialContext.lookup(InitialContext.java:421) [rt.jar:1.8.0_05]
    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:231)

He just would have to update the external-context's environment with the org.jboss.as.naming.lookup.by.string property:

<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.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
    <property name="java.naming.provider.url" value="tcp:/<server>:<port>"/>
    <property name="org.jboss.as.naming.lookup.by.string" value="true"/>
  </environment>
</external-context>

to be able to lookup Tibco resources.

Member

jmesnil commented Oct 31, 2014

One more try... :)

Yesterday, we talked about this PR and @dmlloyd and @n1hility suggested to used a decision table (based on the Context class metadata) to decide whether a JNDI provider would use the lookup(String) instead of the lookup(Name).

This has the advantage to avoid adding any API.
However we would have to maintain and update this decision table (when a new version of a guilty JNDI provider is released, when another provider exhibits the same behaviours). I don't want to have to cut a new release of WildFly because an user requires such a JNDI provider that's not taken into account by the decision table.

So, would it be acceptable if the decision of using the lookup(String) was based on the presence of a org.jboss.as.naming.lookup.by.string property set to true in the external-context's environment?

With such a property, the additional API surface is minimal (only this property, no class, no module dependency).

To sum up, if the user is using TIBCO without success with this configuration:

<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:/<server>:<port>"/>
    <property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
  </environment>
</external-context>

because it results in an error in TibjmsContext.lookup:

 11:31:49,047 ERROR [org.jboss.resource.adapter.jms.inflow.JmsActivation] (default-threads - 1) Unable to reconnect org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@44e0be11(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@d2f5afb3 destination=java:global/tibco/Q1 destinationType=javax.jms.Queue acknowledgeMode=Auto-acknowledge subscriptionDurability=false reconnectInterval=10 reconnectAttempts=-1 user=null maxMessages=1 minSession=1 maxSession=15 connectionFactory=java:global/tibco/XACF): javax.naming.InvalidNameException: Only support CompoundName names
    at com.tibco.tibjms.naming.TibjmsContext.lookup(TibjmsContext.java:504) [tibjms.jar:6.3.0]
    at javax.naming.InitialContext.lookup(InitialContext.java:421) [rt.jar:1.8.0_05]
    at javax.naming.InitialContext.lookup(InitialContext.java:421) [rt.jar:1.8.0_05]
    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:231)

He just would have to update the external-context's environment with the org.jboss.as.naming.lookup.by.string property:

<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.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
    <property name="java.naming.provider.url" value="tcp:/<server>:<port>"/>
    <property name="org.jboss.as.naming.lookup.by.string" value="true"/>
  </environment>
</external-context>

to be able to lookup Tibco resources.

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Windows Build 479 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:54:48

wildfly-ci commented Oct 31, 2014

Windows Build 479 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:54:48

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux Build 5373 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 3026, ignored: 238 Build time: 0:56:38

wildfly-ci commented Oct 31, 2014

Linux Build 5373 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 3026, ignored: 238 Build time: 0:56:38

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux with security manager Build 365 is now running using a merge of 7a5f745

wildfly-ci commented Oct 31, 2014

Linux with security manager Build 365 is now running using a merge of 7a5f745

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux Build 5375 is now running using a merge of 7a5f745

wildfly-ci commented Oct 31, 2014

Linux Build 5375 is now running using a merge of 7a5f745

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Windows Build 480 is now running using a merge of 7a5f745

wildfly-ci commented Oct 31, 2014

Windows Build 480 is now running using a merge of 7a5f745

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux with security manager Build 365 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 796, ignored: 244 Build time: 0:07:04

wildfly-ci commented Oct 31, 2014

Linux with security manager Build 365 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 796, ignored: 244 Build time: 0:07:04

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux Build 5375 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:57:36

wildfly-ci commented Oct 31, 2014

Linux Build 5375 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 3025, ignored: 238, muted: 1 Build time: 0:57:36

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Windows Build 480 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 3026, ignored: 238 Build time: 1:17:01

wildfly-ci commented Oct 31, 2014

Windows Build 480 outcome was SUCCESS using a merge of 7a5f745
Summary: Tests passed: 3026, ignored: 238 Build time: 1:17:01

[WFLY-3830] Use external-context for TIBCO EMS
Tibco EMS's JNDI provider is non-standard and accepts only CompoundName
in its lookup(Name) method while WildFly passes a CompositeName.

For such JNDI providers that accept only specific subtypes of Name, we
must instead use their lookup(String) method (that is more likely to
work as expectedi but comes with performance degradation as the whole
name would have to be parsed again).

If such a JNDI provider is configured in an external-context resource,
the presence of the org.jboss.as.naming.lookup.by.string property in the
external-context's environments with a value set to true will ensure
that the lookup(String) method is used. In any other case, the
lookup(Name) will be used.

JIRA: https://issues.jboss.org/browse/WFLY-3830
@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Oct 31, 2014

Member

I've updated the PR based on @emmartins suggestion. The check on the org.jboss.as.naming.lookup.by.string env property is done only once when the Context is created in ExternalObjectFactory.
This way there is 0 impact for well-behaving JNDI providers in NamingContext.

Member

jmesnil commented Oct 31, 2014

I've updated the PR based on @emmartins suggestion. The check on the org.jboss.as.naming.lookup.by.string env property is done only once when the Context is created in ExternalObjectFactory.
This way there is 0 impact for well-behaving JNDI providers in NamingContext.

@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Oct 31, 2014

Member

retest this please

Member

jmesnil commented Oct 31, 2014

retest this please

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux Build 5380 is now running using a merge of b712d52

wildfly-ci commented Oct 31, 2014

Linux Build 5380 is now running using a merge of b712d52

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Windows Build 483 is now running using a merge of b712d52

wildfly-ci commented Oct 31, 2014

Windows Build 483 is now running using a merge of b712d52

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux with security manager Build 368 is now running using a merge of b712d52

wildfly-ci commented Oct 31, 2014

Linux with security manager Build 368 is now running using a merge of b712d52

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux with security manager Build 368 outcome was SUCCESS using a merge of b712d52
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:20

wildfly-ci commented Oct 31, 2014

Linux with security manager Build 368 outcome was SUCCESS using a merge of b712d52
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:20

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Windows Build 483 outcome was SUCCESS using a merge of b712d52
Summary: Tests passed: 3027, ignored: 238, muted: 1 Build time: 0:54:08

wildfly-ci commented Oct 31, 2014

Windows Build 483 outcome was SUCCESS using a merge of b712d52
Summary: Tests passed: 3027, ignored: 238, muted: 1 Build time: 0:54:08

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Oct 31, 2014

Linux Build 5380 outcome was FAILURE using a merge of b712d52
Summary: Tests failed: 1 (1 new), passed: 3027, ignored: 238 Build time: 0:57:09

Build problems:

Failed tests detected

Failed tests

org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testConcurrentFailover: java.util.concurrent.ExecutionException: javax.ejb.EJBException: java.io.IOException: Channel Channel ID 88f96c1d (outbound) of Remoting connection 00bdab3d to /0:0:0:0:0:0:0:1:8180 has been closed
    at java.util.concurrent.FutureTask.report(FutureTask.java:122)
    at java.util.concurrent.FutureTask.get(FutureTask.java:188)

wildfly-ci commented Oct 31, 2014

Linux Build 5380 outcome was FAILURE using a merge of b712d52
Summary: Tests failed: 1 (1 new), passed: 3027, ignored: 238 Build time: 0:57:09

Build problems:

Failed tests detected

Failed tests

org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testConcurrentFailover: java.util.concurrent.ExecutionException: javax.ejb.EJBException: java.io.IOException: Channel Channel ID 88f96c1d (outbound) of Remoting connection 00bdab3d to /0:0:0:0:0:0:0:1:8180 has been closed
    at java.util.concurrent.FutureTask.report(FutureTask.java:122)
    at java.util.concurrent.FutureTask.get(FutureTask.java:188)

@dmlloyd

This comment has been minimized.

Show comment
Hide comment
@dmlloyd

dmlloyd Oct 31, 2014

Member

This iteration is fine IMO

Member

dmlloyd commented Oct 31, 2014

This iteration is fine IMO

@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Nov 4, 2014

Member

retest this please

Member

jmesnil commented Nov 4, 2014

retest this please

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Nov 4, 2014

Windows Build 506 is now running using a merge of b712d52

wildfly-ci commented Nov 4, 2014

Windows Build 506 is now running using a merge of b712d52

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Nov 4, 2014

Linux with security manager Build 392 is now running using a merge of b712d52

wildfly-ci commented Nov 4, 2014

Linux with security manager Build 392 is now running using a merge of b712d52

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Nov 4, 2014

Linux Build 5403 is now running using a merge of b712d52

wildfly-ci commented Nov 4, 2014

Linux Build 5403 is now running using a merge of b712d52

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Nov 4, 2014

Linux with security manager Build 392 outcome was SUCCESS using a merge of b712d52
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:24

wildfly-ci commented Nov 4, 2014

Linux with security manager Build 392 outcome was SUCCESS using a merge of b712d52
Summary: Tests passed: 796, ignored: 244 Build time: 0:06:24

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Nov 4, 2014

Linux Build 5403 outcome was SUCCESS using a merge of b712d52
Summary: Tests passed: 2997, ignored: 239 Build time: 0:53:44

wildfly-ci commented Nov 4, 2014

Linux Build 5403 outcome was SUCCESS using a merge of b712d52
Summary: Tests passed: 2997, ignored: 239 Build time: 0:53:44

@wildfly-ci

This comment has been minimized.

Show comment
Hide comment
@wildfly-ci

wildfly-ci Nov 4, 2014

Windows Build 506 outcome was FAILURE using a merge of b712d52
Summary: Tests failed: 1 (1 new), passed: 2995, ignored: 239, muted: 1 Build time: 0:55:45

Build problems:

Failed tests detected

Failed tests

org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize: javax.ejb.EJBException: java.lang.IllegalStateException: WFLYCLEJBINF0008: Stateful session bean {[12, -2, -77, 95, 63, -2, 73, -73, -99, 11, -104, -13, -83, -62, -69, 32]} refers to an invalid bean group 4b3f51e3-e984-49f4-943f-2282a28bd927
    at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.createBean(InfinispanBeanFactory.java:75)
    at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:270)

wildfly-ci commented Nov 4, 2014

Windows Build 506 outcome was FAILURE using a merge of b712d52
Summary: Tests failed: 1 (1 new), passed: 2995, ignored: 239, muted: 1 Build time: 0:55:45

Build problems:

Failed tests detected

Failed tests

org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize: javax.ejb.EJBException: java.lang.IllegalStateException: WFLYCLEJBINF0008: Stateful session bean {[12, -2, -77, 95, 63, -2, 73, -73, -99, 11, -104, -13, -83, -62, -69, 32]} refers to an invalid bean group 4b3f51e3-e984-49f4-943f-2282a28bd927
    at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.createBean(InfinispanBeanFactory.java:75)
    at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:270)

@jmesnil

This comment has been minimized.

Show comment
Hide comment
@jmesnil

jmesnil Nov 4, 2014

Member

The passivation failure is not related to the PR.

Member

jmesnil commented Nov 4, 2014

The passivation failure is not related to the PR.

@n1hility

This comment has been minimized.

Show comment
Hide comment
@n1hility

n1hility Nov 4, 2014

Contributor

works for me let me check the code

Contributor

n1hility commented Nov 4, 2014

works for me let me check the code

n1hility added a commit that referenced this pull request Nov 4, 2014

Merge pull request #6878 from jmesnil/WFLY-3830_external-context_fixes
[WFLY-3830] Use external-context for TIBCO EMS

@n1hility n1hility merged commit c103ab3 into wildfly:master Nov 4, 2014

1 check failed

default TeamCity Build WildFly :: Pull Request :: Windows finished: Tests failed: 1 (1 new), passed: 2995, ignored: 239, muted: 1
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment