1 2 Previous Next 15 Replies Latest reply: Apr 14, 2011 11:52 AM by David Ward RSS

Utility classes

Keith Babo Master

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
    Magesh Bojan Master

    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
    Keith Babo Master

    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
    Magesh Bojan Master

    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
    Keith Babo Master

    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
    Magesh Bojan Master

    Exactly 100%

  • 6. Utility classes
    David Ward Master

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

  • 7. Utility classes
    Keith Babo Master

    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
    Tom Fennelly Master

    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
    Keith Babo Master

    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
    Magesh Bojan Master

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

  • 12. Utility classes
    Magesh Bojan Master

    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
    David Ward Master

    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?

1 2 Previous Next