Home » Modeling » EMF » [emf-sdo] Chosing dynamically relations to serialize
| | | |
| Re: [emf-sdo] Chosing dynamically relations to serialize [message #429628 is a reply to message #427304] |
Tue, 28 April 2009 08:19   |
 Thomas
Messages: 37
Registered: July 2009 |
Member |
|
|
Ed, all,
So, I have rewrite shouldSaveFeature and it has seem working well.
But now I have a problem of serialization for certain of our objects.
I want to serialize an object Ecore named Activity that it be contained
into a Process which is contained into Root
The linkage into Root before serialization work well, but the
overwriting of the XMLSaveImpl isn't call as the specialisation was
lost. Could it be as the Object is not contained into the Root element ?
Because of I have no problem to serialize for example Process and not
taken its Activities.
To specialize the XMLSaveImpl,
I overwrite the methods createRoot of ModelFactoryImpl like this:
public Root createRoot()
{
RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
EDataGraph dataGraph = new DreamsEDataGraphImpl();
dataGraph.setERootObject(root);
return root;
}
and all the classes above:
public class DreamsEDataGraphImpl extends EDataGraphImpl
{
@Override
protected ResourceSet createResourceSet()
{
ResourceSet createResourceSet = super.createResourceSet();
createResourceSet.getResourceFactoryRegistry().
getExtensionToFactoryMap().put("datagraph", new
DreamsDataGraphResourceFactoryImpl());
return createResourceSet;
}
@Override
protected EDataGraphExternalizable createEDataGraphExternalizable()
{
return new DreamsEDataGraphExternalizable(this);
}
}
public class DreamsDataGraphResourceFactoryImpl extends
DataGraphResourceFactoryImpl
{
@Override
public Resource createResource(URI uri)
{
XMLResourceImpl result = new
DreamsDataGraphResourceImpl(uri);
result.setEncoding("UTF-8");
result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
Boolean.TRUE);
result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
Boolean.TRUE);
result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
Boolean.TRUE);
result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
Boolean.TRUE);
result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH, new
Integer(80));
result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
SDOPackage.eINSTANCE.getEDataObjectAnyType());
result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
SDOPackage.eINSTANCE.getEDataObjectAnyType());
result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
Boolean.FALSE);
return result;
}
}
public class DreamsDataGraphResourceImpl extends DataGraphResourceImpl
{
public DreamsDataGraphResourceImpl(URI uri)
{
super(uri);
}
@Override
protected XMLSave createXMLSave()
{
return new DreamsSaveImpl(createXMLHelper());
}
}
public class DreamsSaveImpl extends SaveImpl
{
public DreamsSaveImpl(XMLHelper arg0)
{
super(arg0);
}
@Override
protected boolean shouldSaveFeature(EObject o, EStructuralFeature f)
{
return DelegateSaveImpl.shouldFetchFeature(o, f) &&
super.shouldSaveFeature(o, f);
}
}
Have I miss something for contained object ???
Ed Merks a écrit :
> Thomas,
>
> Comments below.
>
> Thomas wrote:
>> It is interesting.
>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>> The problem I have is that there are always reference.
>>
>> Here is a sample of serialization
>> Without filtering instances of Capability
>> <sdo:datagraph xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>> xmlns:sdo="commonj.sdo">
>> <com.oslo.dreams:Root>
>> <resources id="123" name="titi" capabilities="#1 #2"
>> beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>> <capabilities id="2" name="c2" skill="#1111" resourceOwner="#123"/>
>> <skills id="1111" name="s1" description="theSkill"/>
>> </com.oslo.dreams:Root>
>> </sdo:datagraph>
>>
>> With filtering instances of Capability (return false on
>> shouldSaveFeature when the Eobject is an instance of Capability)
> It sounds like you are making it not serialize any of the features of a
> Capability instance but what you ought to be doing is not serializing
> the "capabilities" feature of a "Root".
>> <sdo:datagraph xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>> xmlns:sdo="commonj.sdo">
>> <com.oslo.dreams:Root>
>> <resources id="123" name="titi" capabilities="#1 #2"
>> beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>> <capabilities/>
>> <capabilities/>
>> <skills id="1111" name="s1" description="theSkill"/>
>> </com.oslo.dreams:Root>
>> </sdo:datagraph>
>>
>> I always have reference en capabilities and then on deserialization,
>> it crash an exception as it unknow the reference.
> I see you also have capabilities="#1 #2" which I guess are the reference
> of which you speak. So you'll also want to not serialize the
> "capabilities" feature of a "Resource".
>
> So find these two features in your model,
> XyzPackage.Literals.ROOT__CAPABILITIES and
> XyzPackage.Literals.RESOURCE__CAPABILITIES and return false when the
> feature is either of those two...
>>
>>
>> Ed Merks a écrit :
>>> Thomas,
>>>
>>> Comments below.
>>>
>>> Thomas wrote:
>>>> Hello,
>>>>
>>>> Am i able with sdo to serialize a part of a datagraph chosen
>>>> dynamically, in function of the request.
>>>> My difficulties is to know how/where I can filter data I want to
>>>> serialize.
>>> There's no built-in support for filtering.
>>>> I cannot remove relation from my object as they can be loaded with
>>>> teneo and while the transaction is not closed, I must not do that or
>>>> modification will be stored into database (that I don't want)
>>> I suppose you could make a copy and serialize that.
>>>> Thank's for you light.
>>> I suppose you could specialize XMLSaveImpl.shouldSaveFeature if you
>>> are filter per-feature...
>>>> Regards
>>>>
>>>> Thomas
|
|
|
| Re: [emf-sdo] Chosing dynamically relations to serialize [message #429630 is a reply to message #429628] |
Tue, 28 April 2009 10:38 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Thomas,
Comments below.
Thomas wrote:
> Ed, all,
>
> So, I have rewrite shouldSaveFeature and it has seem working well.
> But now I have a problem of serialization for certain of our objects.
Hmmm.
>
> I want to serialize an object Ecore named Activity that it be
> contained into a Process which is contained into Root
> The linkage into Root before serialization work well, but the
> overwriting of the XMLSaveImpl isn't call as the specialisation was lost.
Not sure what isn't called?
> Could it be as the Object is not contained into the Root element ?
You said it is contained by Root indirectly via Process...
> Because of I have no problem to serialize for example Process and not
> taken its Activities.
I'm not sure I follow the problem though...
>
> To specialize the XMLSaveImpl,
> I overwrite the methods createRoot of ModelFactoryImpl like this:
> public Root createRoot()
> {
> RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
> EDataGraph dataGraph = new DreamsEDataGraphImpl();
> dataGraph.setERootObject(root);
> return root;
> }
I don't think I fully understand what Root is. Creating a datagraph at
the same time that you create a root object can't be a good thing in
general (i.e., is likely to cause problems during deserialization.
>
> and all the classes above:
>
> public class DreamsEDataGraphImpl extends EDataGraphImpl
> {
> @Override
> protected ResourceSet createResourceSet()
> {
> ResourceSet createResourceSet = super.createResourceSet();
>
> createResourceSet.getResourceFactoryRegistry().
> getExtensionToFactoryMap().put("datagraph", new
> DreamsDataGraphResourceFactoryImpl());
> return createResourceSet;
> }
>
> @Override
> protected EDataGraphExternalizable createEDataGraphExternalizable()
> {
> return new DreamsEDataGraphExternalizable(this);
> }
> }
>
> public class DreamsDataGraphResourceFactoryImpl extends
> DataGraphResourceFactoryImpl
> {
>
> @Override
> public Resource createResource(URI uri)
> {
> XMLResourceImpl result = new
> DreamsDataGraphResourceImpl(uri);
>
> result.setEncoding("UTF-8");
>
>
> result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
> Boolean.TRUE);
>
>
> result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
> Boolean.TRUE);
>
> result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
> Boolean.TRUE);
>
>
> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
> Boolean.TRUE);
>
> result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH, new
> Integer(80));
>
>
> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>
> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>
>
> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>
> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>
>
> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
> Boolean.FALSE);
>
> return result;
> }
> }
>
> public class DreamsDataGraphResourceImpl extends DataGraphResourceImpl
> {
> public DreamsDataGraphResourceImpl(URI uri)
> {
> super(uri);
> }
>
> @Override
> protected XMLSave createXMLSave()
> {
> return new DreamsSaveImpl(createXMLHelper());
> }
> }
>
> public class DreamsSaveImpl extends SaveImpl
> {
> public DreamsSaveImpl(XMLHelper arg0)
> {
> super(arg0);
> }
>
> @Override
> protected boolean shouldSaveFeature(EObject o, EStructuralFeature f)
> {
> return DelegateSaveImpl.shouldFetchFeature(o, f) &&
> super.shouldSaveFeature(o, f);
> }
> }
>
> Have I miss something for contained object ???
Can you elaborate on how it actually saves, i.e., the actual result you
see, as opposed to the expected result you want to see?
>
> Ed Merks a écrit :
>> Thomas,
>>
>> Comments below.
>>
>> Thomas wrote:
>>> It is interesting.
>>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>>> The problem I have is that there are always reference.
>>>
>>> Here is a sample of serialization
>>> Without filtering instances of Capability
>>> <sdo:datagraph
>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>> xmlns:sdo="commonj.sdo">
>>> <com.oslo.dreams:Root>
>>> <resources id="123" name="titi" capabilities="#1 #2"
>>> beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>>> <capabilities id="2" name="c2" skill="#1111"
>>> resourceOwner="#123"/>
>>> <skills id="1111" name="s1" description="theSkill"/>
>>> </com.oslo.dreams:Root>
>>> </sdo:datagraph>
>>>
>>> With filtering instances of Capability (return false on
>>> shouldSaveFeature when the Eobject is an instance of
>>> Capability)
>> It sounds like you are making it not serialize any of
>> the features of a Capability instance but what you ought
>> to be doing is not serializing the "capabilities" feature
>> of a "Root".
>>> <sdo:datagraph
>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>> xmlns:sdo="commonj.sdo">
>>> <com.oslo.dreams:Root>
>>> <resources id="123" name="titi" capabilities="#1 #2"
>>> beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>>> <capabilities/>
>>> <capabilities/>
>>> <skills id="1111" name="s1" description="theSkill"/>
>>> </com.oslo.dreams:Root>
>>> </sdo:datagraph>
>>>
>>> I always have reference en capabilities and then on
>>> deserialization, it crash an exception as it unknow the
>>> reference.
>> I see you also have capabilities="#1 #2" which I guess
>> are the reference of which you speak. So you'll also
>> want to not serialize the "capabilities" feature of a
>> "Resource".
>>
>> So find these two features in your model,
>> XyzPackage.Literals.ROOT__CAPABILITIES and
>> XyzPackage.Literals.RESOURCE__CAPABILITIES and return false
>> when the feature is either of those two...
>>>
>>>
>>> Ed Merks a écrit :
>>>> Thomas,
>>>>
>>>> Comments below.
>>>>
>>>> Thomas wrote:
>>>>> Hello,
>>>>>
>>>>> Am i able with sdo to serialize a part of a datagraph
>>>>> chosen dynamically, in function of the request.
>>>>> My difficulties is to know how/where I can filter data
>>>>> I want to serialize.
>>>> There's no built-in support for filtering.
>>>>> I cannot remove relation from my object as they can be
>>>>> loaded with teneo and while the transaction is not
>>>>> closed, I must not do that or modification will be
>>>>> stored into database (that I don't want)
>>>> I suppose you could make a copy and serialize that.
>>>>> Thank's for you light.
>>>> I suppose you could specialize XMLSaveImpl.shouldSaveFeature
>>>> if you are filter per-feature...
>>>>> Regards
>>>>>
>>>>> Thomas
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [emf-sdo] Chosing dynamically relations to serialize [message #429634 is a reply to message #429630] |
Tue, 28 April 2009 11:50 |
Thomas
Messages: 37
Registered: July 2009 |
Member |
|
|
We have define an Object named Root use for serialization, for that all
objects to serialize will be contained.
Before serialization, we create the Root object, and be care that all
object will be contained. It is this Root object, that we associate with
our overwrited DataGraph.
The result is that I have a LazyInitializationException during
serialization on a relation that I doesn't want as I didn't initialize
(call) it and that the serialization is out of transaction. (I use
teneo/hibernate for persistance)
Am I more clear now ?
Ed Merks a écrit :
> Thomas,
>
> Comments below.
>
> Thomas wrote:
>> Ed, all,
>>
>> So, I have rewrite shouldSaveFeature and it has seem working well.
>> But now I have a problem of serialization for certain of our objects.
> Hmmm.
>>
>> I want to serialize an object Ecore named Activity that it be
>> contained into a Process which is contained into Root
>> The linkage into Root before serialization work well, but the
>> overwriting of the XMLSaveImpl isn't call as the specialisation was lost.
> Not sure what isn't called?
>> Could it be as the Object is not contained into the Root element ?
> You said it is contained by Root indirectly via Process...
>> Because of I have no problem to serialize for example Process and not
>> taken its Activities.
> I'm not sure I follow the problem though...
>>
>> To specialize the XMLSaveImpl,
>> I overwrite the methods createRoot of ModelFactoryImpl like this:
>> public Root createRoot()
>> {
>> RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
>> EDataGraph dataGraph = new DreamsEDataGraphImpl();
>> dataGraph.setERootObject(root);
>> return root;
>> }
> I don't think I fully understand what Root is. Creating a datagraph at
> the same time that you create a root object can't be a good thing in
> general (i.e., is likely to cause problems during deserialization.
>>
>> and all the classes above:
>>
>> public class DreamsEDataGraphImpl extends EDataGraphImpl
>> {
>> @Override
>> protected ResourceSet createResourceSet()
>> {
>> ResourceSet createResourceSet = super.createResourceSet();
>>
>> createResourceSet.getResourceFactoryRegistry().
>> getExtensionToFactoryMap().put("datagraph", new
>> DreamsDataGraphResourceFactoryImpl());
>> return createResourceSet;
>> }
>>
>> @Override
>> protected EDataGraphExternalizable createEDataGraphExternalizable()
>> {
>> return new DreamsEDataGraphExternalizable(this);
>> }
>> }
>
>>
>> public class DreamsDataGraphResourceFactoryImpl extends
>> DataGraphResourceFactoryImpl
>> {
>>
>> @Override
>> public Resource createResource(URI uri)
>> {
>> XMLResourceImpl result = new
>> DreamsDataGraphResourceImpl(uri);
>>
>> result.setEncoding("UTF-8");
>>
>>
>> result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
>> Boolean.TRUE);
>>
>>
>> result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>> Boolean.TRUE);
>>
>> result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>> Boolean.TRUE);
>>
>>
>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
>> Boolean.TRUE);
>>
>> result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH, new
>> Integer(80));
>>
>>
>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>
>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>
>>
>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>
>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>
>>
>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
>> Boolean.FALSE);
>>
>> return result;
>> }
>> }
>>
>> public class DreamsDataGraphResourceImpl extends DataGraphResourceImpl
>> {
>> public DreamsDataGraphResourceImpl(URI uri)
>> {
>> super(uri);
>> }
>>
>> @Override
>> protected XMLSave createXMLSave()
>> {
>> return new DreamsSaveImpl(createXMLHelper());
>> }
>> }
>>
>> public class DreamsSaveImpl extends SaveImpl
>> {
>> public DreamsSaveImpl(XMLHelper arg0)
>> {
>> super(arg0);
>> }
>>
>> @Override
>> protected boolean shouldSaveFeature(EObject o, EStructuralFeature f)
>> {
>> return DelegateSaveImpl.shouldFetchFeature(o, f) &&
>> super.shouldSaveFeature(o, f);
>> }
>> }
>>
>> Have I miss something for contained object ???
> Can you elaborate on how it actually saves, i.e., the actual result you
> see, as opposed to the expected result you want to see?
>>
>> Ed Merks a écrit :
>>> Thomas,
>>>
>>> Comments below.
>>>
>>> Thomas wrote:
>>>> It is interesting.
>>>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>>>> The problem I have is that there are always reference.
>>>>
>>>> Here is a sample of serialization
>>>> Without filtering instances of Capability
>>>> <sdo:datagraph
>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>> xmlns:sdo="commonj.sdo">
>>>> <com.oslo.dreams:Root>
>>>> <resources id="123" name="titi" capabilities="#1 #2"
>>>> beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>>>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>>>> <capabilities id="2" name="c2" skill="#1111"
>>>> resourceOwner="#123"/>
>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>> </com.oslo.dreams:Root>
>>>> </sdo:datagraph>
>>>>
>>>> With filtering instances of Capability (return false on
>>>> shouldSaveFeature when the Eobject is an instance of
>>>> Capability)
>>> It sounds like you are making it not serialize any of
>>> the features of a Capability instance but what you ought
>>> to be doing is not serializing the "capabilities" feature
>>> of a "Root".
>>>> <sdo:datagraph
>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>> xmlns:sdo="commonj.sdo">
>>>> <com.oslo.dreams:Root>
>>>> <resources id="123" name="titi" capabilities="#1 #2"
>>>> beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>>>> <capabilities/>
>>>> <capabilities/>
>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>> </com.oslo.dreams:Root>
>>>> </sdo:datagraph>
>>>>
>>>> I always have reference en capabilities and then on
>>>> deserialization, it crash an exception as it unknow the
>>>> reference.
>>> I see you also have capabilities="#1 #2" which I guess
>>> are the reference of which you speak. So you'll also
>>> want to not serialize the "capabilities" feature of a
>>> "Resource".
>>>
>>> So find these two features in your model,
>>> XyzPackage.Literals.ROOT__CAPABILITIES and
>>> XyzPackage.Literals.RESOURCE__CAPABILITIES and return false
>>> when the feature is either of those two...
>>>>
>>>>
>>>> Ed Merks a écrit :
>>>>> Thomas,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Thomas wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Am i able with sdo to serialize a part of a datagraph
>>>>>> chosen dynamically, in function of the request.
>>>>>> My difficulties is to know how/where I can filter data
>>>>>> I want to serialize.
>>>>> There's no built-in support for filtering.
>>>>>> I cannot remove relation from my object as they can be
>>>>>> loaded with teneo and while the transaction is not
>>>>>> closed, I must not do that or modification will be
>>>>>> stored into database (that I don't want)
>>>>> I suppose you could make a copy and serialize that.
>>>>>> Thank's for you light.
>>>>> I suppose you could specialize XMLSaveImpl.shouldSaveFeature
>>>>> if you are filter per-feature...
>>>>>> Regards
>>>>>>
>>>>>> Thomas
|
|
|
| Re: [emf-sdo] Chosing dynamically relations to serialize [message #429635 is a reply to message #429634] |
Tue, 28 April 2009 13:19 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Thomas,
Comments below.
Thomas wrote:
> We have define an Object named Root use for serialization, for that
> all objects to serialize will be contained.
I don't know much about Root's implementation to be able to comment in a
meaningful way about what might be going wrong with its containment support.
> Before serialization, we create the Root object, and be care that all
> object will be contained. It is this Root object, that we associate
> with our overwrited DataGraph.
From a general EMF perspective, all that's needed is for the objects to
be contained by a resource...
>
> The result is that I have a LazyInitializationException during
> serialization on a relation that I doesn't want as I didn't initialize
> (call) it and that the serialization is out of transaction. (I use
> teneo/hibernate for persistance)
So you've looked at the stack trace to see what's causing the relation
to be accessed?
>
> Am I more clear now ?
There appears to be more going on than you've spelled out in detail.
Note that you've not answered my question about actual verses expected
results...
>
> Ed Merks a écrit :
>> Thomas,
>>
>> Comments below.
>>
>> Thomas wrote:
>>> Ed, all,
>>>
>>> So, I have rewrite shouldSaveFeature and it has seem working well.
>>> But now I have a problem of serialization for certain of our objects.
>> Hmmm.
>>>
>>> I want to serialize an object Ecore named Activity that it be
>>> contained into a Process which is contained into Root
>>> The linkage into Root before serialization work well, but the
>>> overwriting of the XMLSaveImpl isn't call as the specialisation was
>>> lost.
>> Not sure what isn't called?
>>> Could it be as the Object is not contained into the Root element ?
>> You said it is contained by Root indirectly via Process...
>>> Because of I have no problem to serialize for example Process and
>>> not taken its Activities.
>> I'm not sure I follow the problem though...
>>>
>>> To specialize the XMLSaveImpl,
>>> I overwrite the methods createRoot of ModelFactoryImpl like this:
>>> public Root createRoot()
>>> {
>>> RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
>>> EDataGraph dataGraph = new DreamsEDataGraphImpl();
>>> dataGraph.setERootObject(root);
>>> return root;
>>> }
>> I don't think I fully understand what Root is. Creating a datagraph
>> at the same time that you create a root object can't be a good thing
>> in general (i.e., is likely to cause problems during deserialization.
>>>
>>> and all the classes above:
>>>
>>> public class DreamsEDataGraphImpl extends EDataGraphImpl
>>> {
>>> @Override
>>> protected ResourceSet createResourceSet()
>>> {
>>> ResourceSet createResourceSet = super.createResourceSet();
>>>
>>> createResourceSet.getResourceFactoryRegistry().
>>> getExtensionToFactoryMap().put("datagraph", new
>>> DreamsDataGraphResourceFactoryImpl());
>>> return createResourceSet;
>>> }
>>>
>>> @Override
>>> protected EDataGraphExternalizable createEDataGraphExternalizable()
>>> {
>>> return new DreamsEDataGraphExternalizable(this);
>>> }
>>> }
>>
>>>
>>> public class DreamsDataGraphResourceFactoryImpl extends
>>> DataGraphResourceFactoryImpl
>>> {
>>>
>>> @Override
>>> public Resource createResource(URI uri)
>>> {
>>> XMLResourceImpl result = new
>>> DreamsDataGraphResourceImpl(uri);
>>>
>>> result.setEncoding("UTF-8");
>>>
>>>
>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
>>> Boolean.TRUE);
>>>
>>>
>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>> Boolean.TRUE);
>>>
>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>> Boolean.TRUE);
>>>
>>>
>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
>>> Boolean.TRUE);
>>>
>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH,
>>> new Integer(80));
>>>
>>>
>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>
>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>
>>>
>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>
>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>
>>>
>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
>>> Boolean.FALSE);
>>>
>>> return result;
>>> }
>>> }
>>>
>>> public class DreamsDataGraphResourceImpl extends DataGraphResourceImpl
>>> {
>>> public DreamsDataGraphResourceImpl(URI uri)
>>> {
>>> super(uri);
>>> }
>>>
>>> @Override
>>> protected XMLSave createXMLSave()
>>> {
>>> return new DreamsSaveImpl(createXMLHelper());
>>> }
>>> }
>>>
>>> public class DreamsSaveImpl extends SaveImpl
>>> {
>>> public DreamsSaveImpl(XMLHelper arg0)
>>> {
>>> super(arg0);
>>> }
>>>
>>> @Override
>>> protected boolean shouldSaveFeature(EObject o, EStructuralFeature f)
>>> {
>>> return DelegateSaveImpl.shouldFetchFeature(o, f) &&
>>> super.shouldSaveFeature(o, f);
>>> }
>>> }
>>>
>>> Have I miss something for contained object ???
>> Can you elaborate on how it actually saves, i.e., the actual result
>> you see, as opposed to the expected result you want to see?
>>>
>>> Ed Merks a écrit :
>>>> Thomas,
>>>>
>>>> Comments below.
>>>>
>>>> Thomas wrote:
>>>>> It is interesting.
>>>>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>>>>> The problem I have is that there are always reference.
>>>>>
>>>>> Here is a sample of serialization
>>>>> Without filtering instances of Capability
>>>>> <sdo:datagraph
>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>> xmlns:sdo="commonj.sdo">
>>>>> <com.oslo.dreams:Root>
>>>>> <resources id="123" name="titi" capabilities="#1 #2"
>>>>> beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>>>>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>>>>> <capabilities id="2" name="c2" skill="#1111"
>>>>> resourceOwner="#123"/>
>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>> </com.oslo.dreams:Root>
>>>>> </sdo:datagraph>
>>>>>
>>>>> With filtering instances of Capability (return false on
>>>>> shouldSaveFeature when the Eobject is an instance of
>>>>> Capability)
>>>> It sounds like you are making it not serialize any of
>>>> the features of a Capability instance but what you ought
>>>> to be doing is not serializing the "capabilities" feature
>>>> of a "Root".
>>>>> <sdo:datagraph
>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>> xmlns:sdo="commonj.sdo">
>>>>> <com.oslo.dreams:Root>
>>>>> <resources id="123" name="titi" capabilities="#1 #2"
>>>>> beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>>>>> <capabilities/>
>>>>> <capabilities/>
>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>> </com.oslo.dreams:Root>
>>>>> </sdo:datagraph>
>>>>>
>>>>> I always have reference en capabilities and then on
>>>>> deserialization, it crash an exception as it unknow the
>>>>> reference.
>>>> I see you also have capabilities="#1 #2" which I guess
>>>> are the reference of which you speak. So you'll also
>>>> want to not serialize the "capabilities" feature of a
>>>> "Resource".
>>>>
>>>> So find these two features in your model,
>>>> XyzPackage.Literals.ROOT__CAPABILITIES and
>>>> XyzPackage.Literals.RESOURCE__CAPABILITIES and return false
>>>> when the feature is either of those two...
>>>>>
>>>>>
>>>>> Ed Merks a écrit :
>>>>>> Thomas,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Thomas wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Am i able with sdo to serialize a part of a
>>>>>>> datagraph chosen dynamically, in function of the request.
>>>>>>> My difficulties is to know how/where I can filter
>>>>>>> data I want to serialize.
>>>>>> There's no built-in support for filtering.
>>>>>>> I cannot remove relation from my object as they can
>>>>>>> be loaded with teneo and while the transaction is not
>>>>>>> closed, I must not do that or modification will be
>>>>>>> stored into database (that I don't want)
>>>>>> I suppose you could make a copy and serialize that.
>>>>>>> Thank's for you light.
>>>>>> I suppose you could specialize
>>>>>> XMLSaveImpl.shouldSaveFeature if you are filter per-feature...
>>>>>>> Regards
>>>>>>>
>>>>>>> Thomas
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [emf-sdo] Chosing dynamically relations to serialize [message #429641 is a reply to message #429635] |
Tue, 28 April 2009 15:47 |
Thomas
Messages: 37
Registered: July 2009 |
Member |
|
|
I am debbuging the serialization, and it appears that getter of
contained EObject are called before the method shouldSaveFeature is called.
Here is the stacktrace of the call.
What is the tracking modification ?
org.hibernate.LazyInitializationException: failed to lazily initialize a
collection of role: Activity.possibilities, no session or session was closed
at
org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationException(AbstractPersistentCollection.java :358)
at
org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationExceptionIfNotConnected(AbstractPersistentC ollection.java:350)
at
org.hibernate.collection.AbstractPersistentCollection.initia lize(AbstractPersistentCollection.java:343)
at
org.hibernate.collection.AbstractPersistentCollection.read(A bstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentBag.toArray(PersistentBag .java:257)
at
org.eclipse.emf.teneo.hibernate.mapping.elist.HibernatePersi stableEList.doLoad(HibernatePersistableEList.java:139)
at
org.eclipse.emf.teneo.mapping.elist.PersistableEList.load(Pe rsistableEList.java:253)
at
org.eclipse.emf.teneo.mapping.elist.PersistableEList.delegat eIsEmpty(PersistableEList.java:430)
at
org.eclipse.emf.common.util.DelegatingEList.isEmpty(Delegati ngEList.java:243)
at
com.oslo.dreams.model.dreams.model.impl.ActivityImpl.eIsSet( ActivityImpl.java:528)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1235)
at
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:407)
at
org.eclipse.emf.ecore.util.EcoreUtil$ProperContentIterator.h asNext(EcoreUtil.java:1212)
at
org.eclipse.emf.common.util.AbstractTreeIterator.next(Abstra ctTreeIterator.java:145)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.setTracking Modification(ResourceImpl.java:1665)
at
org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:676)
at
org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:703)
at org.eclipse.emf.ecore.sdo.util.SDOUtil.writeReplace(SDOUtil. java:599)
at
org.eclipse.emf.ecore.sdo.impl.DynamicEDataObjectImpl.writeR eplace(DynamicEDataObjectImpl.java:1264)
at
com.oslo.dreams.model.util.DreamsDynamicDataObject.writeRepl ace(DreamsDynamicDataObject.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamCla ss.java:1004)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.j ava:1036)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.ja va:302)
at
com.oslo.dreams.model.impl.BasicSerializationTest.serialize( BasicSerializationTest.java:272)
at
com.oslo.dreams.dao.DAOActivityTest.testActivitySerializatio nFiltered(DAOActivityTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java :59)
at
org.junit.internal.runners.MethodRoadie.runTestMethod(Method Roadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.j ava:79)
at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestTh enAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie .java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.jav a:42)
at
org.junit.internal.runners.JUnit4ClassRunner.invokeTestMetho d(JUnit4ClassRunner.java:88)
at
org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUni t4ClassRunner.java:51)
at
org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4Cla ssRunner.java:44)
at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassR oadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoa die.java:37)
at
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4Class Runner.java:42)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.r un(JUnit4TestReference.java:45)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
Ed Merks a écrit :
> Thomas,
>
> Comments below.
>
> Thomas wrote:
>> We have define an Object named Root use for serialization, for that
>> all objects to serialize will be contained.
> I don't know much about Root's implementation to be able to comment in a
> meaningful way about what might be going wrong with its containment
> support.
>> Before serialization, we create the Root object, and be care that all
>> object will be contained. It is this Root object, that we associate
>> with our overwrited DataGraph.
> From a general EMF perspective, all that's needed is for the objects to
> be contained by a resource...
>>
>> The result is that I have a LazyInitializationException during
>> serialization on a relation that I doesn't want as I didn't initialize
>> (call) it and that the serialization is out of transaction. (I use
>> teneo/hibernate for persistance)
> So you've looked at the stack trace to see what's causing the relation
> to be accessed?
>>
>> Am I more clear now ?
> There appears to be more going on than you've spelled out in detail.
> Note that you've not answered my question about actual verses expected
> results...
>>
>> Ed Merks a écrit :
>>> Thomas,
>>>
>>> Comments below.
>>>
>>> Thomas wrote:
>>>> Ed, all,
>>>>
>>>> So, I have rewrite shouldSaveFeature and it has seem working well.
>>>> But now I have a problem of serialization for certain of our objects.
>>> Hmmm.
>>>>
>>>> I want to serialize an object Ecore named Activity that it be
>>>> contained into a Process which is contained into Root
>>>> The linkage into Root before serialization work well, but the
>>>> overwriting of the XMLSaveImpl isn't call as the specialisation was
>>>> lost.
>>> Not sure what isn't called?
>>>> Could it be as the Object is not contained into the Root element ?
>>> You said it is contained by Root indirectly via Process...
>>>> Because of I have no problem to serialize for example Process and
>>>> not taken its Activities.
>>> I'm not sure I follow the problem though...
>>>>
>>>> To specialize the XMLSaveImpl,
>>>> I overwrite the methods createRoot of ModelFactoryImpl like this:
>>>> public Root createRoot()
>>>> {
>>>> RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
>>>> EDataGraph dataGraph = new DreamsEDataGraphImpl();
>>>> dataGraph.setERootObject(root);
>>>> return root;
>>>> }
>>> I don't think I fully understand what Root is. Creating a datagraph
>>> at the same time that you create a root object can't be a good thing
>>> in general (i.e., is likely to cause problems during deserialization.
>>>>
>>>> and all the classes above:
>>>>
>>>> public class DreamsEDataGraphImpl extends EDataGraphImpl
>>>> {
>>>> @Override
>>>> protected ResourceSet createResourceSet()
>>>> {
>>>> ResourceSet createResourceSet = super.createResourceSet();
>>>>
>>>> createResourceSet.getResourceFactoryRegistry().
>>>> getExtensionToFactoryMap().put("datagraph", new
>>>> DreamsDataGraphResourceFactoryImpl());
>>>> return createResourceSet;
>>>> }
>>>>
>>>> @Override
>>>> protected EDataGraphExternalizable createEDataGraphExternalizable()
>>>> {
>>>> return new DreamsEDataGraphExternalizable(this);
>>>> }
>>>> }
>>>
>>>>
>>>> public class DreamsDataGraphResourceFactoryImpl extends
>>>> DataGraphResourceFactoryImpl
>>>> {
>>>>
>>>> @Override
>>>> public Resource createResource(URI uri)
>>>> {
>>>> XMLResourceImpl result = new
>>>> DreamsDataGraphResourceImpl(uri);
>>>>
>>>> result.setEncoding("UTF-8");
>>>>
>>>>
>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
>>>> Boolean.TRUE);
>>>>
>>>>
>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>> Boolean.TRUE);
>>>>
>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>> Boolean.TRUE);
>>>>
>>>>
>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
>>>> Boolean.TRUE);
>>>>
>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH,
>>>> new Integer(80));
>>>>
>>>>
>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>
>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>
>>>>
>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>
>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>
>>>>
>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
>>>> Boolean.FALSE);
>>>>
>>>> return result;
>>>> }
>>>> }
>>>>
>>>> public class DreamsDataGraphResourceImpl extends DataGraphResourceImpl
>>>> {
>>>> public DreamsDataGraphResourceImpl(URI uri)
>>>> {
>>>> super(uri);
>>>> }
>>>>
>>>> @Override
>>>> protected XMLSave createXMLSave()
>>>> {
>>>> return new DreamsSaveImpl(createXMLHelper());
>>>> }
>>>> }
>>>>
>>>> public class DreamsSaveImpl extends SaveImpl
>>>> {
>>>> public DreamsSaveImpl(XMLHelper arg0)
>>>> {
>>>> super(arg0);
>>>> }
>>>>
>>>> @Override
>>>> protected boolean shouldSaveFeature(EObject o, EStructuralFeature f)
>>>> {
>>>> return DelegateSaveImpl.shouldFetchFeature(o, f) &&
>>>> super.shouldSaveFeature(o, f);
>>>> }
>>>> }
>>>>
>>>> Have I miss something for contained object ???
>>> Can you elaborate on how it actually saves, i.e., the actual result
>>> you see, as opposed to the expected result you want to see?
>>>>
>>>> Ed Merks a écrit :
>>>>> Thomas,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Thomas wrote:
>>>>>> It is interesting.
>>>>>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>>>>>> The problem I have is that there are always reference.
>>>>>>
>>>>>> Here is a sample of serialization
>>>>>> Without filtering instances of Capability
>>>>>> <sdo:datagraph
>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>> xmlns:sdo="commonj.sdo">
>>>>>> <com.oslo.dreams:Root>
>>>>>> <resources id="123" name="titi" capabilities="#1 #2"
>>>>>> beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>>>>>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>>>>>> <capabilities id="2" name="c2" skill="#1111"
>>>>>> resourceOwner="#123"/>
>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>> </com.oslo.dreams:Root>
>>>>>> </sdo:datagraph>
>>>>>>
>>>>>> With filtering instances of Capability (return false on
>>>>>> shouldSaveFeature when the Eobject is an instance of
>>>>>> Capability)
>>>>> It sounds like you are making it not serialize any of
>>>>> the features of a Capability instance but what you ought
>>>>> to be doing is not serializing the "capabilities" feature
>>>>> of a "Root".
>>>>>> <sdo:datagraph
>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>> xmlns:sdo="commonj.sdo">
>>>>>> <com.oslo.dreams:Root>
>>>>>> <resources id="123" name="titi" capabilities="#1 #2"
>>>>>> beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>>>>>> <capabilities/>
>>>>>> <capabilities/>
>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>> </com.oslo.dreams:Root>
>>>>>> </sdo:datagraph>
>>>>>>
>>>>>> I always have reference en capabilities and then on
>>>>>> deserialization, it crash an exception as it unknow the
>>>>>> reference.
>>>>> I see you also have capabilities="#1 #2" which I guess
>>>>> are the reference of which you speak. So you'll also
>>>>> want to not serialize the "capabilities" feature of a
>>>>> "Resource".
>>>>>
>>>>> So find these two features in your model,
>>>>> XyzPackage.Literals.ROOT__CAPABILITIES and
>>>>> XyzPackage.Literals.RESOURCE__CAPABILITIES and return false
>>>>> when the feature is either of those two...
>>>>>>
>>>>>>
>>>>>> Ed Merks a écrit :
>>>>>>> Thomas,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Thomas wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Am i able with sdo to serialize a part of a
>>>>>>>> datagraph chosen dynamically, in function of the request.
>>>>>>>> My difficulties is to know how/where I can filter
>>>>>>>> data I want to serialize.
>>>>>>> There's no built-in support for filtering.
>>>>>>>> I cannot remove relation from my object as they can
>>>>>>>> be loaded with teneo and while the transaction is not
>>>>>>>> closed, I must not do that or modification will be
>>>>>>>> stored into database (that I don't want)
>>>>>>> I suppose you could make a copy and serialize that.
>>>>>>>> Thank's for you light.
>>>>>>> I suppose you could specialize
>>>>>>> XMLSaveImpl.shouldSaveFeature if you are filter per-feature...
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Thomas
|
|
|
| Re: [emf-sdo] Chosing dynamically relations to serialize [message #429643 is a reply to message #429641] |
Tue, 28 April 2009 16:00 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Thomas,
Comments below.
Thomas wrote:
> I am debbuging the serialization, and it appears that getter of
> contained EObject are called before the method shouldSaveFeature is
> called.
>
> Here is the stacktrace of the call.
> What is the tracking modification ?
>
> org.hibernate.LazyInitializationException: failed to lazily initialize
> a collection of role: Activity.possibilities, no session or session
> was closed
> at
> org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationException(AbstractPersistentCollection.java :358)
>
> at
> org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationExceptionIfNotConnected(AbstractPersistentC ollection.java:350)
>
> at
> org.hibernate.collection.AbstractPersistentCollection.initia lize(AbstractPersistentCollection.java:343)
>
> at
> org.hibernate.collection.AbstractPersistentCollection.read(A bstractPersistentCollection.java:86)
>
> at
> org.hibernate.collection.PersistentBag.toArray(PersistentBag .java:257)
> at
> org.eclipse.emf.teneo.hibernate.mapping.elist.HibernatePersi stableEList.doLoad(HibernatePersistableEList.java:139)
>
> at
> org.eclipse.emf.teneo.mapping.elist.PersistableEList.load(Pe rsistableEList.java:253)
>
> at
> org.eclipse.emf.teneo.mapping.elist.PersistableEList.delegat eIsEmpty(PersistableEList.java:430)
>
> at
> org.eclipse.emf.common.util.DelegatingEList.isEmpty(Delegati ngEList.java:243)
>
> at
> com.oslo.dreams.model.dreams.model.impl.ActivityImpl.eIsSet( ActivityImpl.java:528)
>
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1235)
>
> at
> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:407)
>
> at
> org.eclipse.emf.ecore.util.EcoreUtil$ProperContentIterator.h asNext(EcoreUtil.java:1212)
>
> at
> org.eclipse.emf.common.util.AbstractTreeIterator.next(Abstra ctTreeIterator.java:145)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.setTracking Modification(ResourceImpl.java:1665)
>
Unfortunately this walks the whole tree. A hack would be to specialize
your resource impl to ignore this call.
> at
> org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:676)
>
> at
> org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:703)
>
> at
> org.eclipse.emf.ecore.sdo.util.SDOUtil.writeReplace(SDOUtil. java:599)
> at
> org.eclipse.emf.ecore.sdo.impl.DynamicEDataObjectImpl.writeR eplace(DynamicEDataObjectImpl.java:1264)
>
> at
> com.oslo.dreams.model.util.DreamsDynamicDataObject.writeRepl ace(DreamsDynamicDataObject.java:51)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamCla ss.java:1004)
> at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.j ava:1036)
> at
> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.ja va:302)
> at
> com.oslo.dreams.model.impl.BasicSerializationTest.serialize( BasicSerializationTest.java:272)
>
> at
> com.oslo.dreams.dao.DAOActivityTest.testActivitySerializatio nFiltered(DAOActivityTest.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java :59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(Method Roadie.java:98)
>
> at
> org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.j ava:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestTh enAfters(MethodRoadie.java:87)
>
> at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie .java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.jav a:42)
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMetho d(JUnit4ClassRunner.java:88)
>
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUni t4ClassRunner.java:51)
>
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4Cla ssRunner.java:44)
>
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassR oadie.java:27)
>
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoa die.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4Class Runner.java:42)
>
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.r un(JUnit4TestReference.java:45)
>
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>
>
>
>
> Ed Merks a écrit :
>> Thomas,
>>
>> Comments below.
>>
>> Thomas wrote:
>>> We have define an Object named Root use for serialization, for that
>>> all objects to serialize will be contained.
>> I don't know much about Root's implementation to be able to comment
>> in a meaningful way about what might be going wrong with its
>> containment support.
>>> Before serialization, we create the Root object, and be care that
>>> all object will be contained. It is this Root object, that we
>>> associate with our overwrited DataGraph.
>> From a general EMF perspective, all that's needed is for the objects
>> to be contained by a resource...
>>>
>>> The result is that I have a LazyInitializationException during
>>> serialization on a relation that I doesn't want as I didn't
>>> initialize (call) it and that the serialization is out of
>>> transaction. (I use teneo/hibernate for persistance)
>> So you've looked at the stack trace to see what's causing the
>> relation to be accessed?
>>>
>>> Am I more clear now ?
>> There appears to be more going on than you've spelled out in detail.
>> Note that you've not answered my question about actual verses
>> expected results...
>>>
>>> Ed Merks a écrit :
>>>> Thomas,
>>>>
>>>> Comments below.
>>>>
>>>> Thomas wrote:
>>>>> Ed, all,
>>>>>
>>>>> So, I have rewrite shouldSaveFeature and it has seem working well.
>>>>> But now I have a problem of serialization for certain of our objects.
>>>> Hmmm.
>>>>>
>>>>> I want to serialize an object Ecore named Activity that it be
>>>>> contained into a Process which is contained into Root
>>>>> The linkage into Root before serialization work well, but the
>>>>> overwriting of the XMLSaveImpl isn't call as the specialisation
>>>>> was lost.
>>>> Not sure what isn't called?
>>>>> Could it be as the Object is not contained into the Root element ?
>>>> You said it is contained by Root indirectly via Process...
>>>>> Because of I have no problem to serialize for example Process and
>>>>> not taken its Activities.
>>>> I'm not sure I follow the problem though...
>>>>>
>>>>> To specialize the XMLSaveImpl,
>>>>> I overwrite the methods createRoot of ModelFactoryImpl like this:
>>>>> public Root createRoot()
>>>>> {
>>>>> RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
>>>>> EDataGraph dataGraph = new DreamsEDataGraphImpl();
>>>>> dataGraph.setERootObject(root);
>>>>> return root;
>>>>> }
>>>> I don't think I fully understand what Root is. Creating a
>>>> datagraph at the same time that you create a root object can't be a
>>>> good thing in general (i.e., is likely to cause problems during
>>>> deserialization.
>>>>>
>>>>> and all the classes above:
>>>>>
>>>>> public class DreamsEDataGraphImpl extends EDataGraphImpl
>>>>> {
>>>>> @Override
>>>>> protected ResourceSet createResourceSet()
>>>>> {
>>>>> ResourceSet createResourceSet = super.createResourceSet();
>>>>>
>>>>> createResourceSet.getResourceFactoryRegistry().
>>>>> getExtensionToFactoryMap().put("datagraph", new
>>>>> DreamsDataGraphResourceFactoryImpl());
>>>>> return createResourceSet;
>>>>> }
>>>>>
>>>>> @Override
>>>>> protected EDataGraphExternalizable createEDataGraphExternalizable()
>>>>> {
>>>>> return new DreamsEDataGraphExternalizable(this);
>>>>> }
>>>>> }
>>>>
>>>>>
>>>>> public class DreamsDataGraphResourceFactoryImpl extends
>>>>> DataGraphResourceFactoryImpl
>>>>> {
>>>>>
>>>>> @Override
>>>>> public Resource createResource(URI uri)
>>>>> {
>>>>> XMLResourceImpl result = new
>>>>> DreamsDataGraphResourceImpl(uri);
>>>>>
>>>>> result.setEncoding("UTF-8");
>>>>>
>>>>>
>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
>>>>> Boolean.TRUE);
>>>>>
>>>>>
>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>>> Boolean.TRUE);
>>>>>
>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>>> Boolean.TRUE);
>>>>>
>>>>>
>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
>>>>> Boolean.TRUE);
>>>>>
>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH,
>>>>> new Integer(80));
>>>>>
>>>>>
>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>>
>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>>
>>>>>
>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>>
>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>>
>>>>>
>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
>>>>> Boolean.FALSE);
>>>>>
>>>>> return result;
>>>>> }
>>>>> }
>>>>>
>>>>> public class DreamsDataGraphResourceImpl extends
>>>>> DataGraphResourceImpl
>>>>> {
>>>>> public DreamsDataGraphResourceImpl(URI uri)
>>>>> {
>>>>> super(uri);
>>>>> }
>>>>>
>>>>> @Override
>>>>> protected XMLSave createXMLSave()
>>>>> {
>>>>> return new DreamsSaveImpl(createXMLHelper());
>>>>> }
>>>>> }
>>>>>
>>>>> public class DreamsSaveImpl extends SaveImpl
>>>>> {
>>>>> public DreamsSaveImpl(XMLHelper arg0)
>>>>> {
>>>>> super(arg0);
>>>>> }
>>>>>
>>>>> @Override
>>>>> protected boolean shouldSaveFeature(EObject o,
>>>>> EStructuralFeature f)
>>>>> {
>>>>> return DelegateSaveImpl.shouldFetchFeature(o, f) &&
>>>>> super.shouldSaveFeature(o, f);
>>>>> }
>>>>> }
>>>>>
>>>>> Have I miss something for contained object ???
>>>> Can you elaborate on how it actually saves, i.e., the actual result
>>>> you see, as opposed to the expected result you want to see?
>>>>>
>>>>> Ed Merks a écrit :
>>>>>> Thomas,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Thomas wrote:
>>>>>>> It is interesting.
>>>>>>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>>>>>>> The problem I have is that there are always reference.
>>>>>>>
>>>>>>> Here is a sample of serialization
>>>>>>> Without filtering instances of Capability
>>>>>>> <sdo:datagraph
>>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>>> xmlns:sdo="commonj.sdo">
>>>>>>> <com.oslo.dreams:Root>
>>>>>>> <resources id="123" name="titi" capabilities="#1
>>>>>>> #2" beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>>>>>>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>>>>>>> <capabilities id="2" name="c2" skill="#1111"
>>>>>>> resourceOwner="#123"/>
>>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>>> </com.oslo.dreams:Root>
>>>>>>> </sdo:datagraph>
>>>>>>>
>>>>>>> With filtering instances of Capability (return false on
>>>>>>> shouldSaveFeature when the Eobject is an instance of
>>>>>>> Capability)
>>>>>> It sounds like you are making it not serialize any of
>>>>>> the features of a Capability instance but what you
>>>>>> ought to be doing is not serializing the "capabilities"
>>>>>> feature of a "Root".
>>>>>>> <sdo:datagraph
>>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>>> xmlns:sdo="commonj.sdo">
>>>>>>> <com.oslo.dreams:Root>
>>>>>>> <resources id="123" name="titi" capabilities="#1
>>>>>>> #2" beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>>>>>>> <capabilities/>
>>>>>>> <capabilities/>
>>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>>> </com.oslo.dreams:Root>
>>>>>>> </sdo:datagraph>
>>>>>>>
>>>>>>> I always have reference en capabilities and then on
>>>>>>> deserialization, it crash an exception as it unknow
>>>>>>> the reference.
>>>>>> I see you also have capabilities="#1 #2" which I guess
>>>>>> are the reference of which you speak. So you'll also
>>>>>> want to not serialize the "capabilities" feature of a
>>>>>> "Resource".
>>>>>>
>>>>>> So find these two features in your model,
>>>>>> XyzPackage.Literals.ROOT__CAPABILITIES and
>>>>>> XyzPackage.Literals.RESOURCE__CAPABILITIES and return false
>>>>>> when the feature is either of those two...
>>>>>>>
>>>>>>>
>>>>>>> Ed Merks a écrit :
>>>>>>>> Thomas,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>> Thomas wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Am i able with sdo to serialize a part of a
>>>>>>>>> datagraph chosen dynamically, in function of the request.
>>>>>>>>> My difficulties is to know how/where I can filter
>>>>>>>>> data I want to serialize.
>>>>>>>> There's no built-in support for filtering.
>>>>>>>>> I cannot remove relation from my object as they can
>>>>>>>>> be loaded with teneo and while the transaction is
>>>>>>>>> not closed, I must not do that or modification will
>>>>>>>>> be stored into database (that I don't want)
>>>>>>>> I suppose you could make a copy and serialize that.
>>>>>>>>> Thank's for you light.
>>>>>>>> I suppose you could specialize
>>>>>>>> XMLSaveImpl.shouldSaveFeature if you are filter
>>>>>>>> per-feature...
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Thomas
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [emf-sdo] Chosing dynamically relations to serialize [message #429644 is a reply to message #429643] |
Tue, 28 April 2009 16:10 |
Thomas
Messages: 37
Registered: July 2009 |
Member |
|
|
Sorry Ed to have written you directly. A problem of click ;)
I have said that:
"I would like not getter called before the method shouldSaveFeature is
called.
If I doesn't need a relation I doesn't want that one to be loaded.
If not, with a hudge model, we will saturate."
We are in EMF 2.4
I have seen a bug with the ResourceImpl.ModificationTrackingAdapter
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252981
Can it be linked ?
What ModificationTracking does ?
Ed Merks a écrit :
> Thomas,
>
> Comments below.
>
> Thomas wrote:
>> I am debbuging the serialization, and it appears that getter of
>> contained EObject are called before the method shouldSaveFeature is
>> called.
>>
>> Here is the stacktrace of the call.
>> What is the tracking modification ?
>>
>> org.hibernate.LazyInitializationException: failed to lazily initialize
>> a collection of role: Activity.possibilities, no session or session
>> was closed
>> at
>> org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationException(AbstractPersistentCollection.java :358)
>>
>> at
>> org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationExceptionIfNotConnected(AbstractPersistentC ollection.java:350)
>>
>> at
>> org.hibernate.collection.AbstractPersistentCollection.initia lize(AbstractPersistentCollection.java:343)
>>
>> at
>> org.hibernate.collection.AbstractPersistentCollection.read(A bstractPersistentCollection.java:86)
>>
>> at
>> org.hibernate.collection.PersistentBag.toArray(PersistentBag .java:257)
>> at
>> org.eclipse.emf.teneo.hibernate.mapping.elist.HibernatePersi stableEList.doLoad(HibernatePersistableEList.java:139)
>>
>> at
>> org.eclipse.emf.teneo.mapping.elist.PersistableEList.load(Pe rsistableEList.java:253)
>>
>> at
>> org.eclipse.emf.teneo.mapping.elist.PersistableEList.delegat eIsEmpty(PersistableEList.java:430)
>>
>> at
>> org.eclipse.emf.common.util.DelegatingEList.isEmpty(Delegati ngEList.java:243)
>>
>> at
>> com.oslo.dreams.model.dreams.model.impl.ActivityImpl.eIsSet( ActivityImpl.java:528)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1235)
>>
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:407)
>>
>> at
>> org.eclipse.emf.ecore.util.EcoreUtil$ProperContentIterator.h asNext(EcoreUtil.java:1212)
>>
>> at
>> org.eclipse.emf.common.util.AbstractTreeIterator.next(Abstra ctTreeIterator.java:145)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.setTracking Modification(ResourceImpl.java:1665)
>>
> Unfortunately this walks the whole tree. A hack would be to specialize
> your resource impl to ignore this call.
>> at
>> org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:676)
>>
>> at
>> org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:703)
>>
>> at
>> org.eclipse.emf.ecore.sdo.util.SDOUtil.writeReplace(SDOUtil. java:599)
>> at
>> org.eclipse.emf.ecore.sdo.impl.DynamicEDataObjectImpl.writeR eplace(DynamicEDataObjectImpl.java:1264)
>>
>> at
>> com.oslo.dreams.model.util.DreamsDynamicDataObject.writeRepl ace(DreamsDynamicDataObject.java:51)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at
>> java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamCla ss.java:1004)
>> at
>> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.j ava:1036)
>> at
>> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.ja va:302)
>> at
>> com.oslo.dreams.model.impl.BasicSerializationTest.serialize( BasicSerializationTest.java:272)
>>
>> at
>> com.oslo.dreams.dao.DAOActivityTest.testActivitySerializatio nFiltered(DAOActivityTest.java:130)
>>
>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java :59)
>> at
>> org.junit.internal.runners.MethodRoadie.runTestMethod(Method Roadie.java:98)
>>
>> at
>> org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.j ava:79)
>> at
>> org.junit.internal.runners.MethodRoadie.runBeforesThenTestTh enAfters(MethodRoadie.java:87)
>>
>> at
>> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie .java:77)
>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.jav a:42)
>> at
>> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMetho d(JUnit4ClassRunner.java:88)
>>
>> at
>> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUni t4ClassRunner.java:51)
>>
>> at
>> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4Cla ssRunner.java:44)
>>
>> at
>> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassR oadie.java:27)
>>
>> at
>> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoa die.java:37)
>> at
>> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4Class Runner.java:42)
>>
>> at
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.r un(JUnit4TestReference.java:45)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>
>>
>>
>>
>> Ed Merks a écrit :
>>> Thomas,
>>>
>>> Comments below.
>>>
>>> Thomas wrote:
>>>> We have define an Object named Root use for serialization, for that
>>>> all objects to serialize will be contained.
>>> I don't know much about Root's implementation to be able to comment
>>> in a meaningful way about what might be going wrong with its
>>> containment support.
>>>> Before serialization, we create the Root object, and be care that
>>>> all object will be contained. It is this Root object, that we
>>>> associate with our overwrited DataGraph.
>>> From a general EMF perspective, all that's needed is for the objects
>>> to be contained by a resource...
>>>>
>>>> The result is that I have a LazyInitializationException during
>>>> serialization on a relation that I doesn't want as I didn't
>>>> initialize (call) it and that the serialization is out of
>>>> transaction. (I use teneo/hibernate for persistance)
>>> So you've looked at the stack trace to see what's causing the
>>> relation to be accessed?
>>>>
>>>> Am I more clear now ?
>>> There appears to be more going on than you've spelled out in detail.
>>> Note that you've not answered my question about actual verses
>>> expected results...
>>>>
>>>> Ed Merks a écrit :
>>>>> Thomas,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Thomas wrote:
>>>>>> Ed, all,
>>>>>>
>>>>>> So, I have rewrite shouldSaveFeature and it has seem working well.
>>>>>> But now I have a problem of serialization for certain of our objects.
>>>>> Hmmm.
>>>>>>
>>>>>> I want to serialize an object Ecore named Activity that it be
>>>>>> contained into a Process which is contained into Root
>>>>>> The linkage into Root before serialization work well, but the
>>>>>> overwriting of the XMLSaveImpl isn't call as the specialisation
>>>>>> was lost.
>>>>> Not sure what isn't called?
>>>>>> Could it be as the Object is not contained into the Root element ?
>>>>> You said it is contained by Root indirectly via Process...
>>>>>> Because of I have no problem to serialize for example Process and
>>>>>> not taken its Activities.
>>>>> I'm not sure I follow the problem though...
>>>>>>
>>>>>> To specialize the XMLSaveImpl,
>>>>>> I overwrite the methods createRoot of ModelFactoryImpl like this:
>>>>>> public Root createRoot()
>>>>>> {
>>>>>> RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
>>>>>> EDataGraph dataGraph = new DreamsEDataGraphImpl();
>>>>>> dataGraph.setERootObject(root);
>>>>>> return root;
>>>>>> }
>>>>> I don't think I fully understand what Root is. Creating a
>>>>> datagraph at the same time that you create a root object can't be a
>>>>> good thing in general (i.e., is likely to cause problems during
>>>>> deserialization.
>>>>>>
>>>>>> and all the classes above:
>>>>>>
>>>>>> public class DreamsEDataGraphImpl extends EDataGraphImpl
>>>>>> {
>>>>>> @Override
>>>>>> protected ResourceSet createResourceSet()
>>>>>> {
>>>>>> ResourceSet createResourceSet = super.createResourceSet();
>>>>>>
>>>>>> createResourceSet.getResourceFactoryRegistry().
>>>>>> getExtensionToFactoryMap().put("datagraph", new
>>>>>> DreamsDataGraphResourceFactoryImpl());
>>>>>> return createResourceSet;
>>>>>> }
>>>>>>
>>>>>> @Override
>>>>>> protected EDataGraphExternalizable createEDataGraphExternalizable()
>>>>>> {
>>>>>> return new DreamsEDataGraphExternalizable(this);
>>>>>> }
>>>>>> }
>>>>>
>>>>>>
>>>>>> public class DreamsDataGraphResourceFactoryImpl extends
>>>>>> DataGraphResourceFactoryImpl
>>>>>> {
>>>>>>
>>>>>> @Override
>>>>>> public Resource createResource(URI uri)
>>>>>> {
>>>>>> XMLResourceImpl result = new
>>>>>> DreamsDataGraphResourceImpl(uri);
>>>>>>
>>>>>> result.setEncoding("UTF-8");
>>>>>>
>>>>>>
>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
>>>>>> Boolean.TRUE);
>>>>>>
>>>>>>
>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>>>> Boolean.TRUE);
>>>>>>
>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>>>> Boolean.TRUE);
>>>>>>
>>>>>>
>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
>>>>>> Boolean.TRUE);
>>>>>>
>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH,
>>>>>> new Integer(80));
>>>>>>
>>>>>>
>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>>>
>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>>>
>>>>>>
>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>>>
>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>>>
>>>>>>
>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
>>>>>> Boolean.FALSE);
>>>>>>
>>>>>> return result;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> public class DreamsDataGraphResourceImpl extends
>>>>>> DataGraphResourceImpl
>>>>>> {
>>>>>> public DreamsDataGraphResourceImpl(URI uri)
>>>>>> {
>>>>>> super(uri);
>>>>>> }
>>>>>>
>>>>>> @Override
>>>>>> protected XMLSave createXMLSave()
>>>>>> {
>>>>>> return new DreamsSaveImpl(createXMLHelper());
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> public class DreamsSaveImpl extends SaveImpl
>>>>>> {
>>>>>> public DreamsSaveImpl(XMLHelper arg0)
>>>>>> {
>>>>>> super(arg0);
>>>>>> }
>>>>>>
>>>>>> @Override
>>>>>> protected boolean shouldSaveFeature(EObject o,
>>>>>> EStructuralFeature f)
>>>>>> {
>>>>>> return DelegateSaveImpl.shouldFetchFeature(o, f) &&
>>>>>> super.shouldSaveFeature(o, f);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Have I miss something for contained object ???
>>>>> Can you elaborate on how it actually saves, i.e., the actual result
>>>>> you see, as opposed to the expected result you want to see?
>>>>>>
>>>>>> Ed Merks a écrit :
>>>>>>> Thomas,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Thomas wrote:
>>>>>>>> It is interesting.
>>>>>>>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>>>>>>>> The problem I have is that there are always reference.
>>>>>>>>
>>>>>>>> Here is a sample of serialization
>>>>>>>> Without filtering instances of Capability
>>>>>>>> <sdo:datagraph
>>>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>>>> xmlns:sdo="commonj.sdo">
>>>>>>>> <com.oslo.dreams:Root>
>>>>>>>> <resources id="123" name="titi" capabilities="#1
>>>>>>>> #2" beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>>>>>>>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>>>>>>>> <capabilities id="2" name="c2" skill="#1111"
>>>>>>>> resourceOwner="#123"/>
>>>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>>>> </com.oslo.dreams:Root>
>>>>>>>> </sdo:datagraph>
>>>>>>>>
>>>>>>>> With filtering instances of Capability (return false on
>>>>>>>> shouldSaveFeature when the Eobject is an instance of
>>>>>>>> Capability)
>>>>>>> It sounds like you are making it not serialize any of
>>>>>>> the features of a Capability instance but what you
>>>>>>> ought to be doing is not serializing the "capabilities"
>>>>>>> feature of a "Root".
>>>>>>>> <sdo:datagraph
>>>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>>>> xmlns:sdo="commonj.sdo">
>>>>>>>> <com.oslo.dreams:Root>
>>>>>>>> <resources id="123" name="titi" capabilities="#1
>>>>>>>> #2" beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>>>>>>>> <capabilities/>
>>>>>>>> <capabilities/>
>>>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>>>> </com.oslo.dreams:Root>
>>>>>>>> </sdo:datagraph>
>>>>>>>>
>>>>>>>> I always have reference en capabilities and then on
>>>>>>>> deserialization, it crash an exception as it unknow
>>>>>>>> the reference.
>>>>>>> I see you also have capabilities="#1 #2" which I guess
>>>>>>> are the reference of which you speak. So you'll also
>>>>>>> want to not serialize the "capabilities" feature of a
>>>>>>> "Resource".
>>>>>>>
>>>>>>> So find these two features in your model,
>>>>>>> XyzPackage.Literals.ROOT__CAPABILITIES and
>>>>>>> XyzPackage.Literals.RESOURCE__CAPABILITIES and return false
>>>>>>> when the feature is either of those two...
>>>>>>>>
>>>>>>>>
>>>>>>>> Ed Merks a écrit :
>>>>>>>>> Thomas,
>>>>>>>>>
>>>>>>>>> Comments below.
>>>>>>>>>
>>>>>>>>> Thomas wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Am i able with sdo to serialize a part of a
>>>>>>>>>> datagraph chosen dynamically, in function of the request.
>>>>>>>>>> My difficulties is to know how/where I can filter
>>>>>>>>>> data I want to serialize.
>>>>>>>>> There's no built-in support for filtering.
>>>>>>>>>> I cannot remove relation from my object as they can
>>>>>>>>>> be loaded with teneo and while the transaction is
>>>>>>>>>> not closed, I must not do that or modification will
>>>>>>>>>> be stored into database (that I don't want)
>>>>>>>>> I suppose you could make a copy and serialize that.
>>>>>>>>>> Thank's for you light.
>>>>>>>>> I suppose you could specialize
>>>>>>>>> XMLSaveImpl.shouldSaveFeature if you are filter
>>>>>>>>> per-feature...
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> Thomas
|
|
|
| Re: [emf-sdo] Chosing dynamically relations to serialize [message #429645 is a reply to message #429644] |
Tue, 28 April 2009 16:22 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Thomas,
Comments below.
Thomas wrote:
> Sorry Ed to have written you directly. A problem of click ;)
:-P
> I have said that:
> "I would like not getter called before the method shouldSaveFeature is
> called.
Of course, but from the stack trace you can see that the call to the
getter has nothing to do with the process of XML serialization but
rather is part of SDO's Serializeable support.
> If I doesn't need a relation I doesn't want that one to be loaded.
Unfortunately if the framework wants to walk your whole containment
tree, it will visit everything...
> If not, with a hudge model, we will saturate."
>
> We are in EMF 2.4
> I have seen a bug with the ResourceImpl.ModificationTrackingAdapter
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252981
> Can it be linked ?
There is no bug here. It's working as designed.
>
> What ModificationTracking does ?
The idea is that if the model is changed again in some way (the
modification tracking adapter checks for that) the write replacements
can thrown away because they are stale.
Note that SDO is no longer supported and you'd be best to avoid using it.
>
>
> Ed Merks a écrit :
>> Thomas,
>>
>> Comments below.
>>
>> Thomas wrote:
>>> I am debbuging the serialization, and it appears that getter of
>>> contained EObject are called before the method shouldSaveFeature is
>>> called.
>>>
>>> Here is the stacktrace of the call.
>>> What is the tracking modification ?
>>>
>>> org.hibernate.LazyInitializationException: failed to lazily
>>> initialize a collection of role: Activity.possibilities, no session
>>> or session was closed
>>> at
>>> org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationException(AbstractPersistentCollection.java :358)
>>>
>>> at
>>> org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationExceptionIfNotConnected(AbstractPersistentC ollection.java:350)
>>>
>>> at
>>> org.hibernate.collection.AbstractPersistentCollection.initia lize(AbstractPersistentCollection.java:343)
>>>
>>> at
>>> org.hibernate.collection.AbstractPersistentCollection.read(A bstractPersistentCollection.java:86)
>>>
>>> at
>>> org.hibernate.collection.PersistentBag.toArray(PersistentBag .java:257)
>>> at
>>> org.eclipse.emf.teneo.hibernate.mapping.elist.HibernatePersi stableEList.doLoad(HibernatePersistableEList.java:139)
>>>
>>> at
>>> org.eclipse.emf.teneo.mapping.elist.PersistableEList.load(Pe rsistableEList.java:253)
>>>
>>> at
>>> org.eclipse.emf.teneo.mapping.elist.PersistableEList.delegat eIsEmpty(PersistableEList.java:430)
>>>
>>> at
>>> org.eclipse.emf.common.util.DelegatingEList.isEmpty(Delegati ngEList.java:243)
>>>
>>> at
>>> com.oslo.dreams.model.dreams.model.impl.ActivityImpl.eIsSet( ActivityImpl.java:528)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1235)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:407)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.EcoreUtil$ProperContentIterator.h asNext(EcoreUtil.java:1212)
>>>
>>> at
>>> org.eclipse.emf.common.util.AbstractTreeIterator.next(Abstra ctTreeIterator.java:145)
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.setTracking Modification(ResourceImpl.java:1665)
>>>
>> Unfortunately this walks the whole tree. A hack would be to
>> specialize your resource impl to ignore this call.
>>> at
>>> org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:676)
>>>
>>> at
>>> org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:703)
>>>
>>> at
>>> org.eclipse.emf.ecore.sdo.util.SDOUtil.writeReplace(SDOUtil. java:599)
>>> at
>>> org.eclipse.emf.ecore.sdo.impl.DynamicEDataObjectImpl.writeR eplace(DynamicEDataObjectImpl.java:1264)
>>>
>>> at
>>> com.oslo.dreams.model.util.DreamsDynamicDataObject.writeRepl ace(DreamsDynamicDataObject.java:51)
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at
>>> java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamCla ss.java:1004)
>>>
>>> at
>>> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.j ava:1036)
>>> at
>>> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.ja va:302)
>>> at
>>> com.oslo.dreams.model.impl.BasicSerializationTest.serialize( BasicSerializationTest.java:272)
>>>
>>> at
>>> com.oslo.dreams.dao.DAOActivityTest.testActivitySerializatio nFiltered(DAOActivityTest.java:130)
>>>
>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java :59)
>>> at
>>> org.junit.internal.runners.MethodRoadie.runTestMethod(Method Roadie.java:98)
>>>
>>> at
>>> org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.j ava:79)
>>> at
>>> org.junit.internal.runners.MethodRoadie.runBeforesThenTestTh enAfters(MethodRoadie.java:87)
>>>
>>> at
>>> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie .java:77)
>>> at
>>> org.junit.internal.runners.MethodRoadie.run(MethodRoadie.jav a:42)
>>> at
>>> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMetho d(JUnit4ClassRunner.java:88)
>>>
>>> at
>>> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUni t4ClassRunner.java:51)
>>>
>>> at
>>> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4Cla ssRunner.java:44)
>>>
>>> at
>>> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassR oadie.java:27)
>>>
>>> at
>>> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoa die.java:37)
>>>
>>> at
>>> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4Class Runner.java:42)
>>>
>>> at
>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.r un(JUnit4TestReference.java:45)
>>>
>>> at
>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>>
>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>>
>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>>
>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>>
>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>>
>>>
>>>
>>>
>>> Ed Merks a écrit :
>>>> Thomas,
>>>>
>>>> Comments below.
>>>>
>>>> Thomas wrote:
>>>>> We have define an Object named Root use for serialization, for
>>>>> that all objects to serialize will be contained.
>>>> I don't know much about Root's implementation to be able to comment
>>>> in a meaningful way about what might be going wrong with its
>>>> containment support.
>>>>> Before serialization, we create the Root object, and be care that
>>>>> all object will be contained. It is this Root object, that we
>>>>> associate with our overwrited DataGraph.
>>>> From a general EMF perspective, all that's needed is for the
>>>> objects to be contained by a resource...
>>>>>
>>>>> The result is that I have a LazyInitializationException during
>>>>> serialization on a relation that I doesn't want as I didn't
>>>>> initialize (call) it and that the serialization is out of
>>>>> transaction. (I use teneo/hibernate for persistance)
>>>> So you've looked at the stack trace to see what's causing the
>>>> relation to be accessed?
>>>>>
>>>>> Am I more clear now ?
>>>> There appears to be more going on than you've spelled out in
>>>> detail. Note that you've not answered my question about actual
>>>> verses expected results...
>>>>>
>>>>> Ed Merks a écrit :
>>>>>> Thomas,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Thomas wrote:
>>>>>>> Ed, all,
>>>>>>>
>>>>>>> So, I have rewrite shouldSaveFeature and it has seem working well.
>>>>>>> But now I have a problem of serialization for certain of our
>>>>>>> objects.
>>>>>> Hmmm.
>>>>>>>
>>>>>>> I want to serialize an object Ecore named Activity that it be
>>>>>>> contained into a Process which is contained into Root
>>>>>>> The linkage into Root before serialization work well, but the
>>>>>>> overwriting of the XMLSaveImpl isn't call as the specialisation
>>>>>>> was lost.
>>>>>> Not sure what isn't called?
>>>>>>> Could it be as the Object is not contained into the Root element ?
>>>>>> You said it is contained by Root indirectly via Process...
>>>>>>> Because of I have no problem to serialize for example Process
>>>>>>> and not taken its Activities.
>>>>>> I'm not sure I follow the problem though...
>>>>>>>
>>>>>>> To specialize the XMLSaveImpl,
>>>>>>> I overwrite the methods createRoot of ModelFactoryImpl like this:
>>>>>>> public Root createRoot()
>>>>>>> {
>>>>>>> RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
>>>>>>> EDataGraph dataGraph = new DreamsEDataGraphImpl();
>>>>>>> dataGraph.setERootObject(root);
>>>>>>> return root;
>>>>>>> }
>>>>>> I don't think I fully understand what Root is. Creating a
>>>>>> datagraph at the same time that you create a root object can't be
>>>>>> a good thing in general (i.e., is likely to cause problems during
>>>>>> deserialization.
>>>>>>>
>>>>>>> and all the classes above:
>>>>>>>
>>>>>>> public class DreamsEDataGraphImpl extends EDataGraphImpl
>>>>>>> {
>>>>>>> @Override
>>>>>>> protected ResourceSet createResourceSet()
>>>>>>> {
>>>>>>> ResourceSet createResourceSet = super.createResourceSet();
>>>>>>>
>>>>>>> createResourceSet.getResourceFactoryRegistry().
>>>>>>> getExtensionToFactoryMap().put("datagraph", new
>>>>>>> DreamsDataGraphResourceFactoryImpl());
>>>>>>> return createResourceSet;
>>>>>>> }
>>>>>>>
>>>>>>> @Override
>>>>>>> protected EDataGraphExternalizable
>>>>>>> createEDataGraphExternalizable()
>>>>>>> {
>>>>>>> return new DreamsEDataGraphExternalizable(this);
>>>>>>> }
>>>>>>> }
>>>>>>
>>>>>>>
>>>>>>> public class DreamsDataGraphResourceFactoryImpl extends
>>>>>>> DataGraphResourceFactoryImpl
>>>>>>> {
>>>>>>>
>>>>>>> @Override
>>>>>>> public Resource createResource(URI uri)
>>>>>>> {
>>>>>>> XMLResourceImpl result = new
>>>>>>> DreamsDataGraphResourceImpl(uri);
>>>>>>>
>>>>>>> result.setEncoding("UTF-8");
>>>>>>>
>>>>>>>
>>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
>>>>>>> Boolean.TRUE);
>>>>>>>
>>>>>>>
>>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>>>>> Boolean.TRUE);
>>>>>>>
>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>>>>> Boolean.TRUE);
>>>>>>>
>>>>>>>
>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
>>>>>>> Boolean.TRUE);
>>>>>>>
>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH,
>>>>>>> new Integer(80));
>>>>>>>
>>>>>>>
>>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>>>>
>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>>>>
>>>>>>>
>>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>>>>
>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>>>>
>>>>>>>
>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
>>>>>>> Boolean.FALSE);
>>>>>>>
>>>>>>> return result;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> public class DreamsDataGraphResourceImpl extends
>>>>>>> DataGraphResourceImpl
>>>>>>> {
>>>>>>> public DreamsDataGraphResourceImpl(URI uri)
>>>>>>> {
>>>>>>> super(uri);
>>>>>>> }
>>>>>>>
>>>>>>> @Override
>>>>>>> protected XMLSave createXMLSave()
>>>>>>> {
>>>>>>> return new DreamsSaveImpl(createXMLHelper());
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> public class DreamsSaveImpl extends SaveImpl
>>>>>>> {
>>>>>>> public DreamsSaveImpl(XMLHelper arg0)
>>>>>>> {
>>>>>>> super(arg0);
>>>>>>> }
>>>>>>>
>>>>>>> @Override
>>>>>>> protected boolean shouldSaveFeature(EObject o,
>>>>>>> EStructuralFeature f)
>>>>>>> {
>>>>>>> return DelegateSaveImpl.shouldFetchFeature(o, f) &&
>>>>>>> super.shouldSaveFeature(o, f);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> Have I miss something for contained object ???
>>>>>> Can you elaborate on how it actually saves, i.e., the actual
>>>>>> result you see, as opposed to the expected result you want to see?
>>>>>>>
>>>>>>> Ed Merks a écrit :
>>>>>>>> Thomas,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>> Thomas wrote:
>>>>>>>>> It is interesting.
>>>>>>>>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>>>>>>>>> The problem I have is that there are always reference.
>>>>>>>>>
>>>>>>>>> Here is a sample of serialization
>>>>>>>>> Without filtering instances of Capability
>>>>>>>>> <sdo:datagraph
>>>>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>>>>> xmlns:sdo="commonj.sdo">
>>>>>>>>> <com.oslo.dreams:Root>
>>>>>>>>> <resources id="123" name="titi" capabilities="#1
>>>>>>>>> #2" beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>>>>>>>>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>>>>>>>>> <capabilities id="2" name="c2" skill="#1111"
>>>>>>>>> resourceOwner="#123"/>
>>>>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>>>>> </com.oslo.dreams:Root>
>>>>>>>>> </sdo:datagraph>
>>>>>>>>>
>>>>>>>>> With filtering instances of Capability (return false
>>>>>>>>> on shouldSaveFeature when the Eobject is an instance
>>>>>>>>> of Capability)
>>>>>>>> It sounds like you are making it not serialize any
>>>>>>>> of the features of a Capability instance but what
>>>>>>>> you ought to be doing is not serializing the
>>>>>>>> "capabilities" feature of a "Root".
>>>>>>>>> <sdo:datagraph
>>>>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>>>>> xmlns:sdo="commonj.sdo">
>>>>>>>>> <com.oslo.dreams:Root>
>>>>>>>>> <resources id="123" name="titi" capabilities="#1
>>>>>>>>> #2" beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>>>>>>>>> <capabilities/>
>>>>>>>>> <capabilities/>
>>>>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>>>>> </com.oslo.dreams:Root>
>>>>>>>>> </sdo:datagraph>
>>>>>>>>>
>>>>>>>>> I always have reference en capabilities and then on
>>>>>>>>> deserialization, it crash an exception as it unknow
>>>>>>>>> the reference.
>>>>>>>> I see you also have capabilities="#1 #2" which I
>>>>>>>> guess are the reference of which you speak. So
>>>>>>>> you'll also want to not serialize the "capabilities"
>>>>>>>> feature of a "Resource".
>>>>>>>>
>>>>>>>> So find these two features in your model,
>>>>>>>> XyzPackage.Literals.ROOT__CAPABILITIES and
>>>>>>>> XyzPackage.Literals.RESOURCE__CAPABILITIES and return
>>>>>>>> false when the feature is either of those two...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ed Merks a écrit :
>>>>>>>>>> Thomas,
>>>>>>>>>>
>>>>>>>>>> Comments below.
>>>>>>>>>>
>>>>>>>>>> Thomas wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Am i able with sdo to serialize a part of a
>>>>>>>>>>> datagraph chosen dynamically, in function of the
>>>>>>>>>>> request.
>>>>>>>>>>> My difficulties is to know how/where I can filter
>>>>>>>>>>> data I want to serialize.
>>>>>>>>>> There's no built-in support for filtering.
>>>>>>>>>>> I cannot remove relation from my object as they
>>>>>>>>>>> can be loaded with teneo and while the transaction
>>>>>>>>>>> is not closed, I must not do that or modification
>>>>>>>>>>> will be stored into database (that I don't want)
>>>>>>>>>> I suppose you could make a copy and serialize that.
>>>>>>>>>>> Thank's for you light.
>>>>>>>>>> I suppose you could specialize
>>>>>>>>>> XMLSaveImpl.shouldSaveFeature if you are filter
>>>>>>>>>> per-feature...
>>>>>>>>>>> Regards
>>>>>>>>>>>
>>>>>>>>>>> Thomas
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| SDO is no longer supported ??? [message #429674 is a reply to message #429645] |
Wed, 29 April 2009 07:56 |
Thomas
Messages: 37
Registered: July 2009 |
Member |
|
|
Ed, what do you mean by SDO is no longer supported ?
I don't understand. It is always referenced into EMF homepage
http://www.eclipse.org/modeling/emf/?project=sdo
Ed Merks a écrit :
> Thomas,
>
> Comments below.
>
> Thomas wrote:
>> Sorry Ed to have written you directly. A problem of click ;)
> :-P
>> I have said that:
>> "I would like not getter called before the method shouldSaveFeature is
>> called.
> Of course, but from the stack trace you can see that the call to the
> getter has nothing to do with the process of XML serialization but
> rather is part of SDO's Serializeable support.
>> If I doesn't need a relation I doesn't want that one to be loaded.
> Unfortunately if the framework wants to walk your whole containment
> tree, it will visit everything...
>> If not, with a hudge model, we will saturate."
>>
>> We are in EMF 2.4
>> I have seen a bug with the ResourceImpl.ModificationTrackingAdapter
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252981
>> Can it be linked ?
> There is no bug here. It's working as designed.
>>
>> What ModificationTracking does ?
> The idea is that if the model is changed again in some way (the
> modification tracking adapter checks for that) the write replacements
> can thrown away because they are stale.
>
> Note that SDO is no longer supported and you'd be best to avoid using it.
>>
>>
>> Ed Merks a écrit :
>>> Thomas,
>>>
>>> Comments below.
>>>
>>> Thomas wrote:
>>>> I am debbuging the serialization, and it appears that getter of
>>>> contained EObject are called before the method shouldSaveFeature is
>>>> called.
>>>>
>>>> Here is the stacktrace of the call.
>>>> What is the tracking modification ?
>>>>
>>>> org.hibernate.LazyInitializationException: failed to lazily
>>>> initialize a collection of role: Activity.possibilities, no session
>>>> or session was closed
>>>> at
>>>> org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationException(AbstractPersistentCollection.java :358)
>>>>
>>>> at
>>>> org.hibernate.collection.AbstractPersistentCollection.throwL azyInitializationExceptionIfNotConnected(AbstractPersistentC ollection.java:350)
>>>>
>>>> at
>>>> org.hibernate.collection.AbstractPersistentCollection.initia lize(AbstractPersistentCollection.java:343)
>>>>
>>>> at
>>>> org.hibernate.collection.AbstractPersistentCollection.read(A bstractPersistentCollection.java:86)
>>>>
>>>> at
>>>> org.hibernate.collection.PersistentBag.toArray(PersistentBag .java:257)
>>>> at
>>>> org.eclipse.emf.teneo.hibernate.mapping.elist.HibernatePersi stableEList.doLoad(HibernatePersistableEList.java:139)
>>>>
>>>> at
>>>> org.eclipse.emf.teneo.mapping.elist.PersistableEList.load(Pe rsistableEList.java:253)
>>>>
>>>> at
>>>> org.eclipse.emf.teneo.mapping.elist.PersistableEList.delegat eIsEmpty(PersistableEList.java:430)
>>>>
>>>> at
>>>> org.eclipse.emf.common.util.DelegatingEList.isEmpty(Delegati ngEList.java:243)
>>>>
>>>> at
>>>> com.oslo.dreams.model.dreams.model.impl.ActivityImpl.eIsSet( ActivityImpl.java:528)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1235)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:407)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.util.EcoreUtil$ProperContentIterator.h asNext(EcoreUtil.java:1212)
>>>>
>>>> at
>>>> org.eclipse.emf.common.util.AbstractTreeIterator.next(Abstra ctTreeIterator.java:145)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.setTracking Modification(ResourceImpl.java:1665)
>>>>
>>> Unfortunately this walks the whole tree. A hack would be to
>>> specialize your resource impl to ignore this call.
>>>> at
>>>> org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:676)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.sdo.impl.EDataGraphImpl.getWriteReplac ement(EDataGraphImpl.java:703)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.sdo.util.SDOUtil.writeReplace(SDOUtil. java:599)
>>>> at
>>>> org.eclipse.emf.ecore.sdo.impl.DynamicEDataObjectImpl.writeR eplace(DynamicEDataObjectImpl.java:1264)
>>>>
>>>> at
>>>> com.oslo.dreams.model.util.DreamsDynamicDataObject.writeRepl ace(DreamsDynamicDataObject.java:51)
>>>>
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>>
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>>
>>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>>> at
>>>> java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamCla ss.java:1004)
>>>>
>>>> at
>>>> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.j ava:1036)
>>>> at
>>>> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.ja va:302)
>>>> at
>>>> com.oslo.dreams.model.impl.BasicSerializationTest.serialize( BasicSerializationTest.java:272)
>>>>
>>>> at
>>>> com.oslo.dreams.dao.DAOActivityTest.testActivitySerializatio nFiltered(DAOActivityTest.java:130)
>>>>
>>>
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>>
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>>
>>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>>> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java :59)
>>>> at
>>>> org.junit.internal.runners.MethodRoadie.runTestMethod(Method Roadie.java:98)
>>>>
>>>> at
>>>> org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.j ava:79)
>>>> at
>>>> org.junit.internal.runners.MethodRoadie.runBeforesThenTestTh enAfters(MethodRoadie.java:87)
>>>>
>>>> at
>>>> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie .java:77)
>>>> at
>>>> org.junit.internal.runners.MethodRoadie.run(MethodRoadie.jav a:42)
>>>> at
>>>> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMetho d(JUnit4ClassRunner.java:88)
>>>>
>>>> at
>>>> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUni t4ClassRunner.java:51)
>>>>
>>>> at
>>>> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4Cla ssRunner.java:44)
>>>>
>>>> at
>>>> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassR oadie.java:27)
>>>>
>>>> at
>>>> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoa die.java:37)
>>>>
>>>> at
>>>> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4Class Runner.java:42)
>>>>
>>>> at
>>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.r un(JUnit4TestReference.java:45)
>>>>
>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>>>
>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>>>
>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>>>
>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>>>
>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>>>
>>>>
>>>>
>>>>
>>>> Ed Merks a écrit :
>>>>> Thomas,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Thomas wrote:
>>>>>> We have define an Object named Root use for serialization, for
>>>>>> that all objects to serialize will be contained.
>>>>> I don't know much about Root's implementation to be able to comment
>>>>> in a meaningful way about what might be going wrong with its
>>>>> containment support.
>>>>>> Before serialization, we create the Root object, and be care that
>>>>>> all object will be contained. It is this Root object, that we
>>>>>> associate with our overwrited DataGraph.
>>>>> From a general EMF perspective, all that's needed is for the
>>>>> objects to be contained by a resource...
>>>>>>
>>>>>> The result is that I have a LazyInitializationException during
>>>>>> serialization on a relation that I doesn't want as I didn't
>>>>>> initialize (call) it and that the serialization is out of
>>>>>> transaction. (I use teneo/hibernate for persistance)
>>>>> So you've looked at the stack trace to see what's causing the
>>>>> relation to be accessed?
>>>>>>
>>>>>> Am I more clear now ?
>>>>> There appears to be more going on than you've spelled out in
>>>>> detail. Note that you've not answered my question about actual
>>>>> verses expected results...
>>>>>>
>>>>>> Ed Merks a écrit :
>>>>>>> Thomas,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Thomas wrote:
>>>>>>>> Ed, all,
>>>>>>>>
>>>>>>>> So, I have rewrite shouldSaveFeature and it has seem working well.
>>>>>>>> But now I have a problem of serialization for certain of our
>>>>>>>> objects.
>>>>>>> Hmmm.
>>>>>>>>
>>>>>>>> I want to serialize an object Ecore named Activity that it be
>>>>>>>> contained into a Process which is contained into Root
>>>>>>>> The linkage into Root before serialization work well, but the
>>>>>>>> overwriting of the XMLSaveImpl isn't call as the specialisation
>>>>>>>> was lost.
>>>>>>> Not sure what isn't called?
>>>>>>>> Could it be as the Object is not contained into the Root element ?
>>>>>>> You said it is contained by Root indirectly via Process...
>>>>>>>> Because of I have no problem to serialize for example Process
>>>>>>>> and not taken its Activities.
>>>>>>> I'm not sure I follow the problem though...
>>>>>>>>
>>>>>>>> To specialize the XMLSaveImpl,
>>>>>>>> I overwrite the methods createRoot of ModelFactoryImpl like this:
>>>>>>>> public Root createRoot()
>>>>>>>> {
>>>>>>>> RootImpl root = new RootImpl(ModelPackage.eINSTANCE.getRoot());
>>>>>>>> EDataGraph dataGraph = new DreamsEDataGraphImpl();
>>>>>>>> dataGraph.setERootObject(root);
>>>>>>>> return root;
>>>>>>>> }
>>>>>>> I don't think I fully understand what Root is. Creating a
>>>>>>> datagraph at the same time that you create a root object can't be
>>>>>>> a good thing in general (i.e., is likely to cause problems during
>>>>>>> deserialization.
>>>>>>>>
>>>>>>>> and all the classes above:
>>>>>>>>
>>>>>>>> public class DreamsEDataGraphImpl extends EDataGraphImpl
>>>>>>>> {
>>>>>>>> @Override
>>>>>>>> protected ResourceSet createResourceSet()
>>>>>>>> {
>>>>>>>> ResourceSet createResourceSet = super.createResourceSet();
>>>>>>>>
>>>>>>>> createResourceSet.getResourceFactoryRegistry().
>>>>>>>> getExtensionToFactoryMap().put("datagraph", new
>>>>>>>> DreamsDataGraphResourceFactoryImpl());
>>>>>>>> return createResourceSet;
>>>>>>>> }
>>>>>>>>
>>>>>>>> @Override
>>>>>>>> protected EDataGraphExternalizable
>>>>>>>> createEDataGraphExternalizable()
>>>>>>>> {
>>>>>>>> return new DreamsEDataGraphExternalizable(this);
>>>>>>>> }
>>>>>>>> }
>>>>>>>
>>>>>>>>
>>>>>>>> public class DreamsDataGraphResourceFactoryImpl extends
>>>>>>>> DataGraphResourceFactoryImpl
>>>>>>>> {
>>>>>>>>
>>>>>>>> @Override
>>>>>>>> public Resource createResource(URI uri)
>>>>>>>> {
>>>>>>>> XMLResourceImpl result = new
>>>>>>>> DreamsDataGraphResourceImpl(uri);
>>>>>>>>
>>>>>>>> result.setEncoding("UTF-8");
>>>>>>>>
>>>>>>>>
>>>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LE XICAL_HANDLER,
>>>>>>>> Boolean.TRUE);
>>>>>>>>
>>>>>>>>
>>>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>>>>>> Boolean.TRUE);
>>>>>>>>
>>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_EXTEND ED_META_DATA,
>>>>>>>> Boolean.TRUE);
>>>>>>>>
>>>>>>>>
>>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_EN CODED_ATTRIBUTE_STYLE,
>>>>>>>> Boolean.TRUE);
>>>>>>>>
>>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_W IDTH,
>>>>>>>> new Integer(80));
>>>>>>>>
>>>>>>>>
>>>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>>>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>>>>>
>>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_TY PE,
>>>>>>>> SDOPackage.eINSTANCE.getEDataObjectAnyType());
>>>>>>>>
>>>>>>>>
>>>>>>>> result.getDefaultLoadOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>>>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>>>>>
>>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_ANY_SI MPLE_TYPE,
>>>>>>>> SDOPackage.eINSTANCE.getEDataObjectSimpleAnyType());
>>>>>>>>
>>>>>>>>
>>>>>>>> result.getDefaultSaveOptions().put(XMLResource.OPTION_USE_XM L_NAME_TO_FEATURE_MAP,
>>>>>>>> Boolean.FALSE);
>>>>>>>>
>>>>>>>> return result;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> public class DreamsDataGraphResourceImpl extends
>>>>>>>> DataGraphResourceImpl
>>>>>>>> {
>>>>>>>> public DreamsDataGraphResourceImpl(URI uri)
>>>>>>>> {
>>>>>>>> super(uri);
>>>>>>>> }
>>>>>>>>
>>>>>>>> @Override
>>>>>>>> protected XMLSave createXMLSave()
>>>>>>>> {
>>>>>>>> return new DreamsSaveImpl(createXMLHelper());
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> public class DreamsSaveImpl extends SaveImpl
>>>>>>>> {
>>>>>>>> public DreamsSaveImpl(XMLHelper arg0)
>>>>>>>> {
>>>>>>>> super(arg0);
>>>>>>>> }
>>>>>>>>
>>>>>>>> @Override
>>>>>>>> protected boolean shouldSaveFeature(EObject o,
>>>>>>>> EStructuralFeature f)
>>>>>>>> {
>>>>>>>> return DelegateSaveImpl.shouldFetchFeature(o, f) &&
>>>>>>>> super.shouldSaveFeature(o, f);
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> Have I miss something for contained object ???
>>>>>>> Can you elaborate on how it actually saves, i.e., the actual
>>>>>>> result you see, as opposed to the expected result you want to see?
>>>>>>>>
>>>>>>>> Ed Merks a écrit :
>>>>>>>>> Thomas,
>>>>>>>>>
>>>>>>>>> Comments below.
>>>>>>>>>
>>>>>>>>> Thomas wrote:
>>>>>>>>>> It is interesting.
>>>>>>>>>> I try to specialize XMLSaveImpl.shouldSaveFeature,
>>>>>>>>>> The problem I have is that there are always reference.
>>>>>>>>>>
>>>>>>>>>> Here is a sample of serialization
>>>>>>>>>> Without filtering instances of Capability
>>>>>>>>>> <sdo:datagraph
>>>>>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>>>>>> xmlns:sdo="commonj.sdo">
>>>>>>>>>> <com.oslo.dreams:Root>
>>>>>>>>>> <resources id="123" name="titi" capabilities="#1
>>>>>>>>>> #2" beginDateValidity="2009-02-11T17:10:50.413+0100"/>
>>>>>>>>>> <capabilities id="1" name="c1" resourceOwner="#123"/>
>>>>>>>>>> <capabilities id="2" name="c2" skill="#1111"
>>>>>>>>>> resourceOwner="#123"/>
>>>>>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>>>>>> </com.oslo.dreams:Root>
>>>>>>>>>> </sdo:datagraph>
>>>>>>>>>>
>>>>>>>>>> With filtering instances of Capability (return false
>>>>>>>>>> on shouldSaveFeature when the Eobject is an instance
>>>>>>>>>> of Capability)
>>>>>>>>> It sounds like you are making it not serialize any
>>>>>>>>> of the features of a Capability instance but what
>>>>>>>>> you ought to be doing is not serializing the
>>>>>>>>> "capabilities" feature of a "Root".
>>>>>>>>>> <sdo:datagraph
>>>>>>>>>> xmlns:com.oslo.dreams="http:///com.oslo.dreams.model"
>>>>>>>>>> xmlns:sdo="commonj.sdo">
>>>>>>>>>> <com.oslo.dreams:Root>
>>>>>>>>>> <resources id="123" name="titi" capabilities="#1
>>>>>>>>>> #2" beginDateValidity="2009-02-11T17:33:15.293+0100"/>
>>>>>>>>>> <capabilities/>
>>>>>>>>>> <capabilities/>
>>>>>>>>>> <skills id="1111" name="s1" description="theSkill"/>
>>>>>>>>>> </com.oslo.dreams:Root>
>>>>>>>>>> </sdo:datagraph>
>>>>>>>>>>
>>>>>>>>>> I always have reference en capabilities and then on
>>>>>>>>>> deserialization, it crash an exception as it unknow
>>>>>>>>>> the reference.
>>>>>>>>> I see you also have capabilities="#1 #2" which I
>>>>>>>>> guess are the reference of which you speak. So
>>>>>>>>> you'll also want to not serialize the "capabilities"
>>>>>>>>> feature of a "Resource".
>>>>>>>>>
>>>>>>>>> So find these two features in your model,
>>>>>>>>> XyzPackage.Literals.ROOT__CAPABILITIES and
>>>>>>>>> XyzPackage.Literals.RESOURCE__CAPABILITIES and return
>>>>>>>>> false when the feature is either of those two...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ed Merks a écrit :
>>>>>>>>>>> Thomas,
>>>>>>>>>>>
>>>>>>>>>>> Comments below.
>>>>>>>>>>>
>>>>>>>>>>> Thomas wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Am i able with sdo to serialize a part of a
>>>>>>>>>>>> datagraph chosen dynamically, in function of the
>>>>>>>>>>>> request.
>>>>>>>>>>>> My difficulties is to know how/where I can filter
>>>>>>>>>>>> data I want to serialize.
>>>>>>>>>>> There's no built-in support for filtering.
>>>>>>>>>>>> I cannot remove relation from my object as they
>>>>>>>>>>>> can be loaded with teneo and while the transaction
>>>>>>>>>>>> is not closed, I must not do that or modification
>>>>>>>>>>>> will be stored into database (that I don't want)
>>>>>>>>>>> I suppose you could make a copy and serialize that.
>>>>>>>>>>>> Thank's for you light.
>>>>>>>>>>> I suppose you could specialize
>>>>>>>>>>> XMLSaveImpl.shouldSaveFeature if you are filter
>>>>>>>>>>> per-feature...
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> Thomas
|
|
| |
| Re: SDO is no longer supported ??? [message #429688 is a reply to message #429679] |
Wed, 29 April 2009 13:18 |
Thomas
Messages: 37
Registered: July 2009 |
Member |
|
|
You've right. We are using SDO only for the EObject serialization.
Actually, I will rewrite the method setTrackingModification of the
EResource. When serialization will be good on emf, we should increase
the version of emf/teneo framework used.
Thanks a lot for your help
Thomas
Ed Merks a écrit :
> Thomas,
>
> We no longer provide builds in the 2.5 stream for SDO, it's not part of
> Galileo, nor will we commit any further changes to CVS for it.
>
> When the current release cycle is completed, we plan to sweep through
> the web pages to update out-of-date information and to improve the
> overall marketing message. If you followed the download link, you'd
> notice there's no SDO download for 2.5...
>
> In my opinion SDO provides almost no additional value over top of
> Ecore. In fact, it performs worse than using EMF directly. One of the
> few valuable things in SDO is support for java.io.Serializable but we
> can do that directly in EMF as well:
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=245014>
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=245014
>
> There's beens surprisingly little interest in this feature though (even
> though it's pretty much completely prototyped already). Probably his is
> the only reason you're using SDO as well, right?
>
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 18:48:08 GMT 2024
Powered by FUDForum. Page generated in 0.06118 seconds |
] 
Search
Help
Register
Login
Home
