Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320079

Summary: XML serialization is not using the right tags
Product: [Modeling] MDT.BPMN2 Reporter: Antoine Toulmé <antoine>
Component: CoreAssignee: Project Inbox <mdt-bpmn2-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: hheitkoetter, reiner.hille-doering
Version: 0.7.0   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Attachments:
Description Flags
Proposed change none

Description Antoine Toulmé CLA 2010-07-16 03:41:01 EDT
Here is some sample code:
ResourceSet rSet = new ResourceSetImpl();
Resource bpmn2 = new Bpmn2ResourceImpl(URI.createURI("virtual.bpmn2"));
rSet.getResources().add(bpmn2);
Definitions def = Bpmn2Factory.eINSTANCE.createDefinitions();
bpmn2.getContents().add(def);
def.getRootElements().add(Bpmn2Factory.eINSTANCE.createGlobalTask());
def.eResource().save(System.out, Collections.emptyMap());

The console shows this output:
<?xml version="1.0" encoding="ASCII"?>
<bpmn2:Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL-XMI" id="_WO-ykJCtEd-jucrpkUIwXw">
  <rootElements xsi:type="bpmn2:GlobalTask" id="_WPAAsJCtEd-jucrpkUIwXw"/>
</bpmn2:Definitions>

Instead of <rootElements xsi:type="bpmn2:GlobalTask", shouldn't we have <bpmn2:GlobalTask directly ?
Comment 1 Reiner Hille CLA 2010-07-16 03:47:41 EDT
I know this behaviour and it is caused by the fact the the Activator of the org.eclipse.bpmn2 bundle is not loaded if you create a Java program. The activator registers the "non-XMI" XML namespace in the package registry. As this does not happen in your case, the XML serializer does not do the correct inheritence/substiution group magic.
As a solution I will add a convenience method to Bpmn2ResourceFactory, that create and initializes a new resource and also registers the packages accordingly.

Reiner.
Comment 2 Reiner Hille CLA 2010-07-16 04:16:38 EDT
> As a solution I will add a convenience method to Bpmn2ResourceFactory, that
> create and initializes a new resource and also registers the packages
> accordingly.

I submitted this improvement. Here is a sample how to use
    public static void main(String[] args) throws IOException {    
        Bpmn2Factory factory = Bpmn2Factory.eINSTANCE;
      
        Definitions definitions = new Bpmn2ResourceFactoryImpl().createAndInitResource(URI.createFileURI("c:/temp/sample.bpmn2"));
        Process simpleProcess = factory.createProcess();
        definitions.getRootElements().add(simpleProcess);
        simpleProcess.getFlowElements().add(factory.createStartEvent());
        simpleProcess.getFlowElements().add(factory.createEndEvent());
  
        
        ResourceSet resourceSet = new ResourceSetImpl();
        Resource resource = definitions.eResource();
        resourceSet.getResources().add(resource);
        resource.save(null);
    }

It create the correct BPMN:
<?xml version="1.0" encoding="UTF-8"?>
<bpmn2:definitions xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL" id="_DvjigZCwEd-cRvLbK_de3w">
  <bpmn2:process id="_DvjigpCwEd-cRvLbK_de3w">
    <bpmn2:startEvent id="_DvtTgJCwEd-cRvLbK_de3w"/>
    <bpmn2:endEvent id="_DvtTgZCwEd-cRvLbK_de3w"/>
  </bpmn2:process>
</bpmn2:definitions>
Comment 3 Henning Heitkoetter CLA 2010-07-16 11:11:02 EDT
Created attachment 174505 [details]
Proposed change

It would be easier if we register the XSD namespace during initialization of the package (along with the XMI namespace). This would obsolete the plugin activator. Additionally, it would not require special handling in standalone usage (as compared to typical EMF usage).

The attached patch shows the changes for the core BPMN2 package. If you're ok with this, I would do the same for the other packages (BPMNDI, DC, DI) and commit everything.

Note that ExtendedMetaData.INSTANCE.putPackage() is identical to EPackage.Registry.INSTANCE.putPackage().
Comment 4 Reiner Hille CLA 2010-07-16 11:50:03 EDT
> The attached patch shows the changes for the core BPMN2 package. If you're ok
> with this, I would do the same for the other packages (BPMNDI, DC, DI) and
> commit everything.

Thanks Henning. If this works and the static init is not called to early, then it is fine for me. 
Please commit.
Comment 5 Antoine Toulmé CLA 2010-07-16 14:01:10 EDT
My fault for not registering the packages in non OSGi mode. Making the init register them is nice.

Thanks guys!
Comment 6 Henning Heitkoetter CLA 2010-07-17 08:31:17 EDT
Done in 5ee0967c82e36c8ee93197ed852113bdeb0eae3a.

I have some (very basic) tests to safeguard serialization and could add them as a new test project?
Comment 7 Reiner Hille CLA 2010-07-19 05:00:10 EDT
> Done in 5ee0967c82e36c8ee93197ed852113bdeb0eae3a.
> 
> I have some (very basic) tests to safeguard serialization and could add them as
> a new test project?
Excellent. 
Please also commit the tests.
Comment 8 Henning Heitkoetter CLA 2010-07-19 09:19:38 EDT
(In reply to comment #7)
> Please also commit the tests.

Done in 30bfb6acd90e3a81e691179c0f3fc11af73e44d8.
Comment 9 Antoine Toulmé CLA 2010-07-21 19:26:16 EDT
It looks like it's still not working for me. I'll look at the tests.

It looks like this line is needed to register the resourceSet in case we are not in OSGi mode:
if (!EMFPlugin.IS_ECLIPSE_RUNNING)
            rs.getResourceFactoryRegistry().getExtensionToFactoryMap().put("bpmn2",
                    new Bpmn2ResourceFactoryImpl());
Comment 10 Henning Heitkoetter CLA 2010-08-10 04:41:08 EDT
From the forum (http://www.eclipse.org/forums/index.php?t=rview&th=173368):
Within Eclipse, loading a XML resource did not in all cases work, as the package registry contained only the XMI uri as long as the package was not initialized.

> new ResourceSetImpl().getResource("example.bpmn2", true)
would have failed (assuming the filename references a XML BPMN model), if BPMNPackage had not been accessed before.

We have to register the packages in plugin.xml under their XML namespace (in addition to XMI). Then they are available within Eclipse regardless of package access.

Fixed in 226c36b3e07644916bd0701bb9295bb62a521c71.

This does not concern standalone usage, as packages have to be registered/accessed manually anyway in that case. So, registration upon initialization of the package as implemented above (5ee0967c) is fine and relieves the user from manually registering the packages under XML namespace.
Within Eclipse, the init() method now just replaces the existing package descriptor with the actual package.
Comment 11 Reiner Hille CLA 2010-08-10 05:11:36 EDT
Thanks Henning. I have also seen the problem if you don't touch Bpmn2Package.eINSTANCE before loading (or saving), you don't have the non-XMI namespaces registered. Do you think that the changes in plugin.xml are sufficient?
Or should we bring back the Activator and call Bpmn2Package.eINSTANCE there, to ensure that the code is touched?
Comment 12 Henning Heitkoetter CLA 2010-08-10 05:47:07 EDT
(In reply to comment #11)
> Thanks Henning. I have also seen the problem if you don't touch
> Bpmn2Package.eINSTANCE before loading (or saving), you don't have the non-XMI
> namespaces registered. Do you think that the changes in plugin.xml are
> sufficient?
At the moment, I can't imagine a use case (within Eclipse) that's not covered - but I've thought that before :)
When running as a plugin in Eclipse, in the registry both namespaces point to the package as they are registered via the extension point generated_package.

> Or should we bring back the Activator and call Bpmn2Package.eINSTANCE there, to
> ensure that the code is touched?
I don't think that's necessary, because with the changes to plugin.xml the registration that is performed in the init method is only of real relevance in standalone usage. When running within Eclipse, it does no harm, but should not be strictly necessary, so that the Activator would have no visible effect.
Comment 13 Henning Heitkoetter CLA 2011-05-04 03:53:06 EDT
(In reply to comment #10)
> Fixed in 226c36b3e07644916bd0701bb9295bb62a521c71.
... some time ago.