Petals CDK

Better organisation of the JBI Schemas and their handling in Java

Details

  • Type: Task Task
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 5.4.2
  • Fix Version/s: 5.9.0
  • Component/s: Utils
  • Security Level: Public
  • Description:
    Hide

    Currently we got the following situation with respect to the JBI xml schema:

    • There is a schema definition in petals-jbi-descriptor that follows the official JBI specification
    • associated to it are JAXB generated classes and a JAXB parser to get a Java view of a jbi xml file.
    • There is an extension in the same project
    • the schema describe only the supplementary elements in a different namespace without saying where they are (it does not actually extends the jbi schema)
    • there is a JAXB parser that is applied in an ad-hoc way to the anyOrAny element of the service element.
    • There is the CDK jbidescriptor that completely redefines the JBI schema with its added elements
    • there are associated JAXB Java classes and the parser
    • For some components, there is extension to the CDK schema defined with xsd
    • but they are not actually used as real schema extension of the CDK jbi (not used for validation, not used for parsing with the CDK parser)
    • sometimes there are ad-hoc jaxb parser for them (for example in the SE BPMN2)

    There is thus the following problem:

    • some classes are duplicated and potentially different between the original JBI and the CDK jbi
    • there is ad-hoc handling of the original extension but manipulable using Java classes
    • there is ad-hoc low-level handling of the component-specific schema elements without any generalised mechanism to validate and parse them.

    Currently, things work because there is multiple "any" elements everywhere (in services, consumes and provides I think... maybe in other places) we have the need to add component-specific things in an ad-hoc way...

    In the same way as with the issue EASYWSDL-13, we should try to find a way to:

    • reuse generated classes, but in this case the problem is mainly that we want to extend schemas.
    • provide, from a component development point of view, a JAXB parser that takes the extension as an xsd and as generated classes, and that parse the extended xml files seamlessly.

    The first one is going to be hard, the second one should be easier.

    Show
    Currently we got the following situation with respect to the JBI xml schema:
    • There is a schema definition in petals-jbi-descriptor that follows the official JBI specification
    • associated to it are JAXB generated classes and a JAXB parser to get a Java view of a jbi xml file.
    • There is an extension in the same project
    • the schema describe only the supplementary elements in a different namespace without saying where they are (it does not actually extends the jbi schema)
    • there is a JAXB parser that is applied in an ad-hoc way to the anyOrAny element of the service element.
    • There is the CDK jbidescriptor that completely redefines the JBI schema with its added elements
    • there are associated JAXB Java classes and the parser
    • For some components, there is extension to the CDK schema defined with xsd
    • but they are not actually used as real schema extension of the CDK jbi (not used for validation, not used for parsing with the CDK parser)
    • sometimes there are ad-hoc jaxb parser for them (for example in the SE BPMN2)
    There is thus the following problem:
    • some classes are duplicated and potentially different between the original JBI and the CDK jbi
    • there is ad-hoc handling of the original extension but manipulable using Java classes
    • there is ad-hoc low-level handling of the component-specific schema elements without any generalised mechanism to validate and parse them.
    Currently, things work because there is multiple "any" elements everywhere (in services, consumes and provides I think... maybe in other places) we have the need to add component-specific things in an ad-hoc way... In the same way as with the issue EASYWSDL-13, we should try to find a way to:
    • reuse generated classes, but in this case the problem is mainly that we want to extend schemas.
    • provide, from a component development point of view, a JAXB parser that takes the extension as an xsd and as generated classes, and that parse the extended xml files seamlessly.
    The first one is going to be hard, the second one should be easier.
  • Environment:
    -

Issue Links

Activity

Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
7d 18h 32m
1
Christophe DENEUX
Thu, 12 Mar 2015 - 09:38:23 +0100

People

Dates

  • Created:
    Wed, 4 Mar 2015 - 15:05:53 +0100
    Updated:
    Tue, 11 Apr 2023 - 11:54:53 +0200