1 2 Previous Next 15 Replies Latest reply on Apr 14, 2011 11:52 AM by dward

    Utility classes

    kcbabo

      Where should we put common utility code which spans multiple modules in SwitchYard?  We discussed this at the F2F and I said I would start a forum thread on the subject so we could add in examples of common utility code and decide where it should live.  Finally getting around to that task item. ;-)

       

      Since our utility module will be used from many modules, we should try and keep external dependencies at a minimum.  Ideally, the utility module would have no external dependencies.

       

      If you can think of current utility classes that belong in this module, please reply to the thread.  Moving forward, if you come across an example of general purpose code, come back to this thread and add it to the list.

        • 1. Utility classes
          mageshbk

          I have a very generic one org.switchyard.component.soap.util.XMLHelper at the moment. I feel, any util that is used starting from API can live at api/src/main/java/org/switchyard/common/util and the ones that are needed starting from runtime alone can live at runtime/src/main/java/org/switchyard/runtime/common/util. I know we have a task t ochange the package of runtime .

          • 2. Utility classes
            kcbabo

            I was actually thinking that the utility classes would be a separate module.

             

            Re: the package change for runtime, my recollection is that we excluded core API and core runtime from that naming requirement.  Of course, modules have moved around since then (core/core was removed), so maybe we need to revisit that decision.

            • 3. Utility classes
              mageshbk

              I was actually thinking that the utility classes would be a separate module.

              Yeah, I thought about that too. Having a module "common" and then the core "api" module adding that as a dependecy seemed odd to me.

              • 4. Utility classes
                kcbabo

                Core API should not depend on any other module.  Reading between the lines, I can see how this is significant to you because you want to put XML helper classes in there which would be used from metadata.wsdl.  Did I get that right?

                • 5. Utility classes
                  mageshbk

                  Exactly 100%

                  • 6. Utility classes
                    dward

                    Everything in core/config/src/main/java/org/switchyard/config/util/**/* are potential candidates.

                    • 7. Utility classes
                      kcbabo

                      OK, I've been giving this a bit more thought and I wonder if what we really want here is an extensions parent module (i.e. core/extensions) which can contain individual extension modules.  One extension would be the XML helper classes referred to above (e.g. switchyard-extensions-xml).  This helps avoid a situation where we add a bunch of different utility classes to a single util/common module and also allows individual extensions to use external dependencies where appropriate without risking a situation where a single module has a bazillion dependencies (as an aggregated common/util might).

                       

                      I would also like to see the org.switchyard.metadata.wsdl stuff go in the switchyard-extensions-xml (or whatever we decide to call it) module.  I don't want the API module to depend on anything external and it should be easy enough for clients to pull in the additional module if WSDL interfaces are used.

                      • 8. Utility classes
                        tfennelly

                        My 2c.... I'd prefer a single commons/utils module that has all our commons code.  I'm sure I'll be on my own on this, but I don't like the idea of fragmenting this into a slew of commons/utils modules.  I think we should at least just start with one and see how we go.  I think the trick to managing external depdendencies is firstly to try not having them, but where we can't avoid having them (e.g. perhaps the wsdl stuff)... scope them as "provided", which would mean that a module using that commons code would need to provide that dependency itself.

                        • 9. Utility classes
                          kcbabo

                          Marking them as provided takes care of the maven dependency, but you will still need them at runtime which is my real concern.  It would be nice if the user could pick up specific extensions/utils based on the needs of their environment.  Maybe we move forward here by starting in the middle.  Let's create a common module and stick and xml module in that.  We can put Magesh's XML helpers in there and then evaluate other cases as they come up (e.g. David's config util).  If we see a proliferation of small modules in common, then it's a sign that we may need to bring it back to common/util alone.  On the other hand, if we just have a few modules and it turns out to be a useful separation, then we are good to go.

                          • 10. Utility classes
                            mageshbk

                            Agree with both of you. So there is no extension module as of now, I guess.

                            • 11. Utility classes
                              mageshbk
                              • 12. Utility classes
                                mageshbk

                                So there is no extension module as of now, I guess.

                                Strike that. The interface.wsdl will live in extensions/wsdl and will depend on core/api and common/xml.

                                • 13. Re: Utility classes
                                  dward

                                  Okay, so I know I'm late to the ballgame here, but I wholeheartedly agree with Tom Fennelly.  I don't want to see a bazillion switchard-common-* modules.  Yuck. I undertand the concern of dependencies, but how about this?:

                                   

                                       If you put something in common, it cannot have ANY dependencies outside of common itself.

                                   

                                  Then we don't have any dependency concerns, and we also won't end up with too many "common" modules (which doesn't even sound right when you say it out-loud).

                                   

                                  So instead of what we have now:

                                   

                                  switchyard-common-xml:

                                      org.switchyard.common.xml.Element

                                      org.switchyard.common.xml.IdentitySAXHandler

                                      org.switchyard.common.xml.Node

                                      org.switchyard.common.xml.Text

                                      org.switchyard.common.xml.XMLHelper

                                   

                                  switchyard-config

                                      org.switchyard.config.util.Classes

                                      org.switchyard.config.util.ElementResource

                                      org.switchyard.config.util.Nodes

                                      org.switchyard.config.util.PropertiesResource

                                      org.switchyard.config.util.QNames

                                      org.switchyard.config.util.Resource

                                      org.switchyard.config.util.StringResource

                                      org.switchyard.config.util.classpath.AbstractTypeFilter

                                      org.switchyard.config.util.classpath.ClasspathScanner

                                      org.switchyard.config.util.classpath.Filter

                                      org.switchyard.config.util.classpath.InstanceOfFilter

                                      org.switchyard.config.util.classpath.IsAnnotationPresentFilter

                                      org.switchyard.config.util.classpath.ResourceExistsFilter

                                   

                                  switchyard-runtime:

                                      org.switchyard.internal.io.CountingOutputStream

                                      org.switchyard.internal.io.Reflection

                                   

                                  I would prefer to see this (1 common module):

                                   

                                  switchyard-common:

                                      org.switchyard.common.io.CountingOutputStream

                                      org.switchyard.common.io.resource.ElementResource

                                      org.switchyard.common.io.resource.PropertiesResource

                                      org.switchyard.common.io.resource.Resource

                                      org.switchyard.common.io.resource.StringResource

                                      org.switchyard.common.type.Classes

                                      org.switchyard.common.type.classpath.AbstractTypeFilter

                                      org.switchyard.common.type.classpath.ClasspathScanner

                                      org.switchyard.common.type.classpath.Filter

                                      org.switchyard.common.type.classpath.InstanceOfFilter

                                      org.switchyard.common.type.classpath.IsAnnotationPresentFilter

                                      org.switchyard.common.type.classpath.ResourceExistsFilter

                                      org.switchyard.common.type.reflect.Access

                                      org.switchyard.common.type.reflect.BeanAccess

                                      org.switchyard.common.type.reflect.Construction

                                      org.switchyard.common.type.reflect.FieldAccess

                                      org.switchyard.common.type.reflect.MethodAccess

                                      org.switchyard.common.xml.Element

                                      org.switchyard.common.xml.IdentitySAXHandler

                                      org.switchyard.common.xml.Node

                                      org.switchyard.common.xml.Text

                                      org.switchyard.common.xml.XMLHelper

                                   

                                  Please, pretty-please, pretty-please with a cherry on top?

                                  • 14. Re: Utility classes
                                    dward
                                    1 2 Previous Next