Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Current
    • Component/s: Vysper
    • Labels:
      None
    • Environment:
      java version "1.6.0_12"
      Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
      Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)

      Description

      The testAllowBareFromEntityOnlyOnSingleBoundResource Unit test failed with an exception. The API seems to have changed.

        Activity

        Hide
        Michael Jakl added a comment -

        Patch to resolve the issue.

        The patch assumes that an exception has to be thrown to make the test pass.

        Show
        Michael Jakl added a comment - Patch to resolve the issue. The patch assumes that an exception has to be thrown to make the test pass.
        Hide
        Michael Jakl added a comment -

        Alternative patch.

        Judging from the variables present within the testcase this might be the right fix for the failing test.

        Show
        Michael Jakl added a comment - Alternative patch. Judging from the variables present within the testcase this might be the right fix for the failing test.
        Hide
        Bernd Fondermann added a comment -

        This bug is specific to unit testing with a session, where stanzas are being sent.

        When a handler gets tested, the handler sends out stanzas and the test keeps track of them, by looking them up and inspecting them. Handlers can send stanzas via the StanzaRelayBroker (to any receiver), by returning them as a handler's result to the calling session's client or by directly putting them on the wire of some active session using LocalDeliveryUtils.relayToResourceDirectly(). The test env is not currently set up to deal with more than one stanza send in the latter way. When the second stanza gets sent, the ISE is raised.

        A proper solution would be to refactor TestSessionContext.write() to be able to receive (and inspect) more than one stanza.

        Show
        Bernd Fondermann added a comment - This bug is specific to unit testing with a session, where stanzas are being sent. When a handler gets tested, the handler sends out stanzas and the test keeps track of them, by looking them up and inspecting them. Handlers can send stanzas via the StanzaRelayBroker (to any receiver), by returning them as a handler's result to the calling session's client or by directly putting them on the wire of some active session using LocalDeliveryUtils.relayToResourceDirectly(). The test env is not currently set up to deal with more than one stanza send in the latter way. When the second stanza gets sent, the ISE is raised. A proper solution would be to refactor TestSessionContext.write() to be able to receive (and inspect) more than one stanza.
        Hide
        Michael Jakl added a comment -

        This patch adapts the TestSessionContext used to record and replay more than one stanza.

        Most of the code was already there, but the "reset" operations were harmful.

        Either we should introduce a "reset" method rather than writing a "null" to re-initialize the TestSessionContext. For the time being I have removed the write(null) calls from this specific test. All other (working) tests are still working.

        Show
        Michael Jakl added a comment - This patch adapts the TestSessionContext used to record and replay more than one stanza. Most of the code was already there, but the "reset" operations were harmful. Either we should introduce a "reset" method rather than writing a "null" to re-initialize the TestSessionContext. For the time being I have removed the write(null) calls from this specific test. All other (working) tests are still working.
        Hide
        Bernd Fondermann added a comment -

        With the latest patch the tests still keep failing for me. As I said before, the routing of messages changed, so the tests need to be semantically altered to reflect the changed behavior. The patches do not go to the root of the problem (which is not so easy to understand, I guess - otherwise I would have had this already sorted long before ).

        Also, I don't know if my description of the underlying problem is helpful. Please try to ask questions.
        Nevertheless, I plan to take a look at this today or tomorrow.

        Show
        Bernd Fondermann added a comment - With the latest patch the tests still keep failing for me. As I said before, the routing of messages changed, so the tests need to be semantically altered to reflect the changed behavior. The patches do not go to the root of the problem (which is not so easy to understand, I guess - otherwise I would have had this already sorted long before ). Also, I don't know if my description of the underlying problem is helpful. Please try to ask questions. Nevertheless, I plan to take a look at this today or tomorrow.
        Hide
        Michael Jakl added a comment -

        I reverted all changes and have 2 Failing tests and 1 Error. After applying the patch I only have 2 Failing tests and no more errors. You mentioned failing tests in you last comment?

        I was only patching the test of this sub-task (testAllowBareEntityOnlyOnSingleBoundResource).

        Are your descriptions for this particular test or for the other two?

        Show
        Michael Jakl added a comment - I reverted all changes and have 2 Failing tests and 1 Error. After applying the patch I only have 2 Failing tests and no more errors. You mentioned failing tests in you last comment? I was only patching the test of this sub-task (testAllowBareEntityOnlyOnSingleBoundResource). Are your descriptions for this particular test or for the other two?

          People

          • Assignee:
            Unassigned
            Reporter:
            Michael Jakl
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development