8 Replies Latest reply on Oct 30, 2005 12:12 PM by Martin Dirichs

    extending jpdl

    Martin Dirichs Newbie

      In an attempt to add application specific information to a process definition, I stumbled upon the following fact: It is not possible in jBPM 3.01 to extend the processdefinition XML schema by an additional schema. XML namespaces, which are also used within in typical jpdl file, were designed to allow for the extension of a fixed schema. It should be a matter of just declaring a new namespace and linking the namespace to a schema location.

      To illustrate this, take the default way of starting a jpdl process definition:

       xsi:schemaLocation="http://jbpm.org/3/jpdl http://jbpm.org/xsd/jpdl-3.0.xsd"

      Here, jpdl namespace and corresponding schema location are neatly defined.

      It should be possible, in my opinion, to do something like this:
       xsi:schemaLocation="http://my.extension.com file:///path/to/my/extension.xsd
       http://jbpm.org/3/jpdl http://jbpm.org/xsd/jpdl-3.0.xsd"

      While digging in the source code to discover why this was not working, I saw that class SchemaValidationHandler uses a special EntityResolver, effectively preventing any extensions of the basic jpdl schema.

      The only way I found to get around this limitation (while leaving the jBPM code as it is) is to use no namespaces at all in the process definition and thus disabling XML validation completely.

      Concluding question: Is there a reason for preventing extensions to the jpdl schema? Or, if there's no reason, wouldn't it be a good move to allow extensions in future releases?

      With regards,

      Martin Dirichs.

        • 1. Re: extending jpdl
          Ronald van Kuijk Master

          What would your extensions to JDPL look like?

          • 2. Re: extending jpdl
            Julian Klein Newbie

            I would like to add to this thought by suggesting extensibility that would allow one to map extra attributes to a Task node. This would then map to a custom TaskInstance.


            • 3. Re: extending jpdl
              Ronald van Kuijk Master

              what kind of extra attributes? The reason I ask this is that to much generic functionality make the core engine way to difficult.

              • 4. Re: extending jpdl
                Julian Klein Newbie

                I cannot speak for Martin's request, but could it be possible for the Jpdl Deployer to use reflection on the custom TaskInstance class to determine what the xml attributes/tags defined in a task node would mean? This would likely only be for translating Strings.

                As far as other extensions (per the original question), it would be more difficult. I do believe however that one can add xml snippets within certain node types (e.g. action nodes?)

                Finally, I am not familiar with the BPEL specs so these customizations might not map to that spec.


                • 5. Re: extending jpdl
                  Martin Dirichs Newbie

                  Right now, there are already several elements that can or must be provided with a custom implementation:

                  - action
                  - assignment
                  - handler
                  - controller

                  and, using a different method of looking up the specific implementation class,

                  - task

                  For these elements, a mechanism is provided to supply additional configuration data. Citing an example from the user guide:

                  <action class="org.test.MyAction">

                  To state my question more clearly, I want to break it into two separate ones:

                  1. How do you tell the jpdl parser what kind of elements "city" and "rounds" are, so that the parser can check the contents according to a schema? Right now, I only get it to run by completely disabling schema validation.

                  2. Why not making jpdl process definitions more flexible by allowing that all jpdl elements may be extended by application specific implementations? In particular, I would like to put a user readable description into each transition. Technically, this would mean to just add a string attribute via a custom subclass of transition.

                  The first question is plainly about the usage of currently available features. The second question is a feature request which seems quite logical from my view. I just see it as applying object orientation to the elements of a process definition. I like jpdl the way it is - with not too many features only necessary for specific contexts. Instead, it confines to including only a reasonable subset of what should be meaningful in all applications. The only thing that is missing is a way to add those few bits that are special about a certain application context.


                  • 6. Re: extending jpdl
                    Koen Aers Master


                    It looks to me these are very valid points. The xsd/validation stuff is not yet as it should be. Why not file a JIRA issue?


                    • 7. Re: extending jpdl
                      bob munger Newbie

                      it's entirely natural to need to inject custom metadata into node.action definitions. writing custom java classes to implement node semantics is krazy. the modern way is to write a single class, driven by metadata.

                      as for instance, our architecture uses application services to implement user actions. we currently inject our metadata into the XPDL Activity model using the Activity.ExtendedAttribute element. we define how variables in context are mapped to IN/OUT/INOUT parameters to java services. this enables our mvc2 implementation. an Activity can support multiple user actions.

                      my point is that one of the main benefits of a 'Process Definition Language' is the ability to design a process using meta-data rather than writing java classes. a mechanism that parses custom metadata into some model (hashmaps, document, etc.) would be beneficial.