7 Replies Latest reply on Dec 19, 2013 11:38 AM by oehme

    My first impressions of the Eclipse tooling

    oehme

      First of all I want to say that I really like the idea behind Switchyard. I'm all for more typesafety, less configuration and better tooling. So while the feedback below is mostly negative, I'm just trying to help you improve this great framework.

       

      I tried the Eclipse tooling a few weeks ago and only built a very small "Hello World" example. But even while doing that I stumbled upon many usability/maintenance issues that I would like to point out. Some of those may be due to my lack of knowledge, so please feel free to point me in the right direction if you think that any of the below points is not justified.

       

      No refactoring support

       

      When I use JDT's rename refactoring to rename a class or method, those changes are not reflected in the Switchyard configuration. I have to fix the XML file by hand.

      Also, there is no way to "autogenerate a WSDL" from an Interface, meaning that any new methods are automatically added to the WSDL. I think this would be pretty convenient.

       

      String constants all over the place

       

      The autogenerated classes (e.g. Transformers) have String constants smeared all over the place. If I am to change a class or method name, there are still lots of silently broken Strings pointing at the old name.

       

      Questionable use of annotations

       

      This one really puzzled me. If I annotate a method with @Transformer, I have to use a special build plugin that then adds this method to the XML file which is then evaluated at runtime. Why is this annotation not evaluated at runtime directly? This seems like unnecessary indirection and code duplication to me.

       

      Internal interfaces take too much effort

       

      Often times, I just want to define some internal services (e.g. for splitting, routing or filtering messages with camel). To do so, I define "ESB" interfaces, because adding Java interfaces for such trivial things seems wasteful. But I need to define that interface two times. Once when defining the service and another time when referencing the service. Why can't the interface be inferred in the second case?

       

      Some features are well hidden

       

      It took me some time to discover that I can add Validators via the properties menu. The visual editor should at least contain a small hint to that.

       

      Frequent crashes

       

      The visual editor crahses quite frequently. All the edit panes are gone and the only way to get it back is to restart Eclipse

       

      Silent failure

       

      I accidentally defined two endpoints with the same name. This did not lead to a clear error message. Instead, the first endpoint was used for all requests, resulting in puzzling error messages when confronted with messages that where intended for the second endpoint.

       

      Tightly bound to Maven

       

      The whole tooling seems to be tightly bound to Maven. While this is nice if I'm actually using Maven, it will probably put off users of Gradle and other build systems. But even for Maven users, modifying the pom.xml is not such a great idea. You usually have dependencies managed in a parent POM, but the tooling always modifies the POM of the current project, probably overriding any parent configuration.

        • 1. Re: My first impressions of the Eclipse tooling
          kcbabo

          We appreciate the feedback.  Constructive criticism is always welcome here, so no worries about negative feedback vs. positive feedback.  Starting a discussion thread in the forum is a great first step.  As it becomes clearer whether something is a bug, feature request, or working as designed, it's great if you can file JIRAs against the project.  Of course, code contributions are always welcome as well.  Here's the JIRA URL:

          SwitchYard - JBoss Issue Tracker

           

          Let's take the feedback one piece at a time:

           

          No Refactoring Support

          There actually is some refactoring support available, but it's definitely not comprehensive.  Unfortunately, this is more of a find and fix scenario than simply implementing a feature in one place and having it work for everything.  This is one of the areas where filing a JIRA and documenting the use cases that did not work with refactoring really helps.  It's an iterative process, but we will tackle these as we find them.

           

          String Constants All Over the Place

          The WWW also has string constants all over the place, they're called URIs.  :-)  Seriously though, we use strings to serve as identifiers for lots of things : operation names, message type names, service names, etc., etc.  This is just a fact of life for these types of applications.  That said, we can certainly try to help users so that this is not a major pain point through things like refactoring and validation.

           

          Questionable Use of Annotations

          There is a TL;DR answer here which I won't bother boring everyone with now.  Short answer is that we want a single source of truth for the configuration of an application and that is the switchyard.xml.  This means any client/tool/code that wants to introspect an application only needs to understand switchyard.xml and doesn't have to parse/scan annotations and the like.  Annotations are a developer tool only - they generate config which in some cases (notably, folks that don't use our Eclipse tooling) helps with dev productivity.

           

          Internal Interfaces Take Too Much Effort

          By "too much effort" do you mean entering the string literal for the message type name twice?  It's true that this is necessary for wiring a reference and service together, since all references and services must have a contract.  It is not true for promoting a service or reference, since the interface type can be inherited.  I definitely get where you're coming from here in terms of internal service interactions, though.

           

          Hidden Features

          Please file a JIRA for any instances of this type of thing.  We aren't capable of finding these issues on our own since we already know where everything is at.  It's very valuable to get the perspective of new users.

           

          Frequent Crashes

          I'm in the editor a lot and crashes are very rare for me.  Generally only when I'm building and testing editor pull requests and I've horked my update site.  If you can post details on the version of the tooling you're using and the base platform you're installing into, that would be helpful.

           

          Silent Failure

          Validation should pick this up.  In certain releases of the tooling, validation would only work if you ran it manually.  Current version of the tooling for 1.1.1 performs validation as part of the build lifecycle.

           

          Maven Integration

          We're always open to ideas of how to make the tooling more flexible.  I honestly can't remember if the tooling will detect capabilities defined in a parent pom or not, but I know Rob and I have discussed the possibility in the past.

           

          Thanks for taking the time to put the tooling through its paces and sharing your impressions.

          • 2. Re: My first impressions of the Eclipse tooling
            rcernich

            Hey Stefan,

             

            Thanks for the feedback.  I'd like to reiterate a few of Keith's comments:

             

            Hidden Features

            I am in the process of updating the documentation for the tools and will take this into consideration.

             

            Frequent Crashes

            If you experience a crash or any weird editor behavior, please file a JIRA and attach the .log file for your workspace, if possible (.../workspace/.metadata/.log).

             

            Silent Failure

            Validation is an underdeveloped feature in the tooling and is something that will improve over time.  Up to this point, we've been focusing our effort ensuring the tools are capable of supporting all the features in the runtime, not necessarily that the configurations users create will deploy (i.e. we've been trying to keep the user out of XML).

             

            Maven Integration

            I agree that changing the pom.xml file can be bad.  However, we decided to do this so users would not have to go searching for the specific dependencies that are required to use specific features.  To make things even easier, we decided to just add those dependencies as users make use of features in their application.  That said, this should probably be configurable (e.g. automatically add component dependencies).  Also, as Keith mentioned, the tooling should already take into account whether or not the user is using dependency management or whether or not dependencies are declared in a parent pom.  There may be cases where new dependencies get added to the project pom and there may be bugs.  For the time being, you will have to manually organize your dependencies.  That said, you'll never have to ask, which dependencies do I need for feature X.

             

            Thanks again for all the feedback,

            Rob

            • 3. Re: My first impressions of the Eclipse tooling
              magick93
              No refactoring support

               

              When I use JDT's rename refactoring to rename a class or method, those changes are not reflected in the Switchyard configuration. I have to fix the XML file by hand.

              Also, there is no way to "autogenerate a WSDL" from an Interface, meaning that any new methods are automatically added to the WSDL. I think this would be pretty convenient.

               

              String constants all over the place

               

              The autogenerated classes (e.g. Transformers) have String constants smeared all over the place. If I am to change a class or method name, there are still lots of silently broken Strings pointing at the old name.

              +1 for these points.

               

              I have recently found out how painful it is to refactor in SY, which is directly related to the many uses of strings.

              • 4. Re: My first impressions of the Eclipse tooling
                benny.yih

                This might be an "hidden feature" but does the Eclipse tooling support generated source code ?  My maven pom.xml is successfully generating a jar target with JAXB classes from a WSDL, and the eclipse project includes the generated sources.  But the "run on server" deploys a project jar to my JBoss AS 7 & Switchyard 0.8 runtime missing the generated classes.   Should I try the newer 1.1.1 Eclipse tooling ?  8-) 

                • 5. Re: My first impressions of the Eclipse tooling
                  rcernich

                  Hey Anton,

                   

                  When refactoring Java types, you can check the "Update fully qualified names in non-Java text files (forces preview)" button and make sure that the specified file name patterns would include switchyard.xml. The attached screenshot demonstrates this. It might be beneficial to specify *.xml instead, as this would also update other files (e.g. log4j.xml, bean.xml, etc.).

                  refactor-dialog.gif

                  It's not the ideal solution, but it will help for simple renames.

                   

                  Rob

                  • 6. Re: My first impressions of the Eclipse tooling
                    rcernich

                    Hey Benny,

                     

                    There is no hidden feature here.  I suspect the project is simply not configured correctly.  Some things to check:

                    • Make sure the generated source folder is identified properly by Eclipse (i.e. it's listed as a source folder in Properrties->Java Build Path)
                    • Make sure the generated source folder is listed in the packaging structure for the project (Properties->Deployment Assembly)

                     

                    You will probably be able to correct the problem by simply invoking Maven->Update Project... on the project.

                     

                    FYI, the SwitchYard tooling does not provide any specialized deployment support.  It relies on functionality provided by JBoss Tools AS tools, so you might find better support in the JBoss Tools forums.  That said, if you continue to have problems, I would be interested to know what they are.  If you could post a project that reproduces the problem, that would be great.

                     

                    Hope that helps,

                    Rob

                    • 7. Re: My first impressions of the Eclipse tooling
                      oehme

                      Thank you all for the nice feedback. I didn't have time to work with Switchyard lately, but I'd like to respond to some of the points =)

                       

                      As I see, the rename refactoring support already has a ticket, that's nice. The silent failure and hidden features will also be adressed, so that's three important points less. If I stumble upon something like this again, I will file an issue.

                       

                      Maven support

                      So the feature checkboxes are really just there to add the right dependencies? So if I manage dependencies myself (with whatever tool), I can just ignore them? Then that's fine by me as long as there is an online list of all the features and their Maven coordinates.

                       

                      String constants

                      For instance the "target namespace" is used pretty much everywhere. This could be a static String constant in some generated class. This way, if I make up my mind and change it, I don't have to hunt for references. Of course I wouldn't do that when my service is already in use. But for prototyping this is probably a valid use case.

                       

                      I guess many of my suggestions are not that critical for services which are already in use and have fixed APIs. You wouldn't just regenerate the WSDL for your service when you have already published it. But for some iterative development it would be nice if the WSDL would just be regenerated every time I change the corresponding Java interface (if I'm doing Java-first-development). I must admint, I don't have much EIP background, maybe iterative development is not as common for such applications?

                       

                      Annotations

                      I understand the "single source of truth" argument. Maybe you could add a Quick Fix that says "Add this to switchyard.xml"? That way, people don't need to run the Maven plugin, but can stay in their Eclipse workflow.

                       

                      Crashes

                      The crashes might also be due to the fact that I have a lot of other plugins installed. Some of those may be interfering with the Switchyard editor. I will file an issue with the error log output when that happens again.