Announcement Announcement Module
Collapse
No announcement yet.
Using multiples channels Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using multiples channels

    I'm testing some features of spring integrating with blazeds but I'm with doubt of how can I use multiples channels.

    In my "flex/service-config.xml" I have.
    Code:
          <default-channels>
               <channel ref="my-polling-amf"/>
               <channel ref="my-amf"/>
          </default-channels>
    I have these defaults channels configured, observe that my-polling-amf is in first possition.

    In my applicationContext.xml I have.

    Code:
    	<flex:message-broker>
    		<flex:remoting-service default-channels="my-amf"/>
    		<flex:message-service default-channels="my-polling-amf"/>
    	</flex:message-broker>	
    
    	<flex:message-destination id="chat"/>
    
    	<bean id="hello" class="eliezer.com.Hello">
    		<flex:remoting-destination channels="my-amf"/>
    	</bean>
    For me, when I set default channel for each service (remoting and message), if my flex client call "chat" destination then It's should use my-polling-amf and if I call "hello" destination then It's should use my-amf channel but It's not happens. If I try call "hello" destination using my-amf channel the follow message is thrown:

    Code:
    Destination 'hello' not accessible over channel 'my-polling-amf'.
    It's strange because my applicationContext is implicitly configured. I observe too that if I change order in my defaults-channel over service-config,xml when I try use "chat" destination its thrown exception saying that this channel not acessible over my-amf channel.

    In summary, defaults-config over applicationContext is complete unnecessary? If I need use multiples channels that is only possible with mxml or actionscipt?

    Regards, Eliezer

    Sorry for my bad english.

  • #2
    Anyone know something about it?

    Comment


    • #3
      What you are seeing is due to the way the fallback behavior for a ChannelSet works in the Flex client. The only way the client will try to fall back to the standard AMF channel in your example is if there is actually a failure in network communication over the polling channel. It does not fall back to another channel if it simply can't find the destination over the first channel, as is the case here.

      Setting the default-channels for a service (be it remoting or messaging) basically just tells BlazeDS to expose the destinations created for that service over that channel by default. So, for example, you could remove the channels="my-amf" from your "hello" destination in the example, and it would still be exposed over the "my-amf" channel because you've configured that as the default channel for the remoting service. Setting these defaults unfortunately has no effect on what channel a client-side Flex component defaults to using.

      In summary, if you want to use multiple channels in this way, then you will indeed need to define two separate ChannelSets on the client and assign them to your RemoteObject, Producer, Consumer, etc.

      Comment


      • #4
        authenticating multiple channel sets

        Jeremy, do you have any insight into how to go about properly authenticating each of the multiple channel sets?

        We are building an application which creates two channel sets, one for remoting and one for messaging. I am having an absolute nightmare getting each channel set to properly connect and authenticate (allowing access to the same principal through the Authentication in the security context).

        Even when making sure to make the authentication requests seqeuntially, ensuring one channel set is connected and authenticated before attempting to connect the other, and being lucky enough to have both connect and authenticate without faults (requiring ALOT of luck, as most often this results in duplicate session faults or the cryptic server.processing null pointer on the auth destination reqs) we are still getting null Authentication objects in the security context on our first remoting invocations.

        I'm sorry for the rambling, and wish I could be more clear and concise in the explanation, however I am getting such erratic behavior that I am not quite sure how to explain the circumstances. I am still using RC1, along with BlazeDS 3.2.0.3978 and Flex SDK 3.2.0.3958.

        Comment


        • #5
          First off, I would definitely recommend upgrading to the final 1.0.0.RELEASE as there were some subtle bugs with the security integration that were fixed after RC1, and these could very well be at least partially causing the problems you are seeing.

          My thought is that you should really only ever have to call login() on one of the ChannelSets. After that first login, the Authentication will be in the session and subsequent calls to secured destinations should just use that existing Authentication. I will do some tests to verify the way this works to be sure. We're going to be releasing 1.0.1 either at the end of this week or early next week, and I will see about even working a more complex security example like this into the testdrive.

          Comment


          • #6
            Did this ever get resolved one way or the other? I'm in a similar situation to the OP.

            Comment


            • #7
              There wasn't really anything to resolve, unless I'm missing something. Can explain exactly the problem you are having?

              Comment

              Working...
              X