4 Replies Latest reply on Feb 14, 2014 10:20 AM by synclpz

    sca binding in switchyard: expected usage

    bbuterbrott

      Hello!

      I try to use sca binding for in vm communication between composites on one JBoss server, but I get following exception when I try to call sca:

       

      Cannot convert from 'sca.ScaRequest' to 'sca.ScaRequest''.  No registered Transformer available for transforming from 'java:sca.ScaRequest' to 'java:sca.ScaRequest'.  A Transformer must be registered.: org.switchyard.SwitchYardException: Cannot convert from 'sca.ScaRequest' to 'sca.ScaRequest'.  No registered Transformer available for transforming from 'java:sca.ScaRequest' to 'java:sca.ScaRequest'.  A Transformer must be registered.

       

      As I understand the problem occurs because class sca.ScaRequest is being loaded with different classloaders, thus they are being considered different by java.

      Do I understand the problem right? Or the problem is in something else?

       

      As a workaround for transmitting beans I can imaging serializing them to JSON and then transferring String instead of ScaRequest, because transferring Strings works alright. But I think maybe there is other way that I just don't see.

       

      I seek advise of the expected way of using sca bindings when the transfer is done inside one VM and is not clustered.

       

      Thanks in advance!

        • 1. Re: sca binding in switchyard: expected usage
          kcbabo

          If you are sharing classes between applications, then you'll want to isolate those into a separate module and introduce a dependency on that module within each app that uses the shared classes.  There are two examples of this in our quickstart repository:

           

          Packaging as an EAR:

          https://github.com/jboss-switchyard/quickstarts/tree/master/ear-deployment

           

          Packaging as independent applications:

          quickstarts/demos/multiApp at master · jboss-switchyard/quickstarts · GitHub

           

          hth,

          keith

          • 2. Re: sca binding in switchyard: expected usage
            synclpz

            Hi, Keith!

             

            Keith Babo wrote:

             

            If you are sharing classes between applications, then you'll want to isolate those into a separate module and introduce a dependency on that module within each app that uses the shared classes.

            We are using independent applications in our system, so the only option to use SCA invocation between deployments is making an "interface + DTO" module (did you mean a "JBoss modules" module?) and installing it into jboss + attaching proper jboss-deployment-structure.xml to every deployment that needs to use the interface?

             

            The point against it is that we need to restart jboss in case of interface updates.

             

            Is it possible to use shared classes as a deployment?

            • 3. Re: sca binding in switchyard: expected usage
              kcbabo

              Yes, you should definitely isolate classes shared between deployments in a separate JBoss Modules module.  You can declare a dependency on this module via jboss-deployment-structure.xml or an entry in your manifest.

               

              Updates to the shared interfaces module should be carefully considered in terms of lifecycle and compatibility with applications that depend on the shared module.  You might want to experiment with using slots which would provide you a form of versioning and also isolate changes to a specific slot (applications change their dependency to the new slot when they can).  Just brainstorming here.

               

              All deployments are modules, so yes, you can use a deployed jar as a dependency.  I'm pretty sure that changes (via redeploy) to the shared classes module will trigger a redeploy of dependent applications, so keep that in mind.

              • 4. Re: sca binding in switchyard: expected usage
                synclpz

                Yep, that's right, everything's right. I got the same things in mind after some brainstorming also. Especially the "slot" one is good.