You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/08/05 19:57:25 UTC
Dynamic registration of databindings, was: 0.91 Memory Footprint
Jean-Sebastien Delfino wrote:
> scyip12@rogers.com wrote:
>> We recently migrated our version of Tuscany from M2 to 0.91, and we
>> noticed that the memory consumption seems to have increased by quite
>> a bit. When doing memory profiling, the culprit appeared to be
>> classes related to Xerces DOM (DeferredElementNSImpl, several other
>> schema element related classes). When profiling the samples
>> (helloworld-ws-sdo-webapp) and our application in M2, those classes
>> don't seem to get called. We are going through the jars to determine
>> which module is triggering the Xerces parser, but any suggestions
>> would be greatly appreciated.
>>
>
> I'm not sure which Tuscany extension triggers the loading of Xerces
> yet, but the SDO-Axiom and JSON databindings and the EJB and Script
> bindings seem to pull Xerces in their pom.xml.
>
> I noticed that in 0.91 most Tuscany extensions on the classpath (and
> most of them are going to be on the classpath if you're using
> tuscany-sca-all.jar) are aggressively loaded and initialized when the
> runtime starts. I'm going to make some changes to a number of binding
> and implementation extensions to allow them to be loaded only when
> they are actually required by an SCA assembly.
>
> I hope this will help.
>
I looked into most of the bindings and implementations, they are now
loaded dynamically, this should help with the footprint. I think we need
to do the same with data bindings as they are dragging a lot of
dependencies and in most cases people will stick to a single databinding
in their environment.
Registering databindings should be easy:
file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
<databinding class name>,id=<databinding id>
<databinding class name>,id=<databinding id>
etc.
I'm not sure about transformers, but was thinking about something like this:
file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
<transformer class name>,source=<databinding id>,target=<databinding
id>,weight=<weight>
<transformer class name>,source=<databinding id>,target=<databinding
id>,weight=<weight>
etc.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> Your latest proposal sounds good.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Sunday, August 05, 2007 7:20 PM
> Subject: Re: Dynamic registration of databindings, was: 0.91 Memory
> Footprint
>
>
>> Jean-Sebastien Delfino wrote:
>>> Raymond Feng wrote:
>>>> Hi,
>>>>
>>>> Your proposal looks good. I think it is consistent with the pattern
>>>> that we use to deal with unresolved models. IMO, the proxy/delegate
>>>> objects for databindings could be:
>>>>
>>>> DataBindingDelegate:
>>>> className = "my.MyDataBinding" (or ClassReference?)
>>>> DataBinding databinding; // transient instance lazily
>>>> instantiated from the class name
>>>> id = "db1"
>>>>
>>>> TransformerDelegate:
>>>> className = "my.DB12DB2Transformer"
>>>> Transformer instance; // transient instance lazily instantiated
>>>> from the class name
>>>> source = "DB1"
>>>> target = "DB2"
>>>> weight = 100
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>> <js...@apache.org>
>>>> To: <tu...@ws.apache.org>
>>>> Sent: Sunday, August 05, 2007 10:57 AM
>>>> Subject: Dynamic registration of databindings, was: 0.91 Memory
>>>> Footprint
>>>>
>>>>
>>>>> Jean-Sebastien Delfino wrote:
>>>>>> scyip12@rogers.com wrote:
>>>>>>> We recently migrated our version of Tuscany from M2 to 0.91, and
>>>>>>> we noticed that the memory consumption seems to have increased
>>>>>>> by quite a bit. When doing memory profiling, the culprit
>>>>>>> appeared to be classes related to Xerces DOM
>>>>>>> (DeferredElementNSImpl, several other schema element related
>>>>>>> classes). When profiling the samples (helloworld-ws-sdo-webapp)
>>>>>>> and our application in M2, those classes don't seem to get
>>>>>>> called. We are going through the jars to determine which module
>>>>>>> is triggering the Xerces parser, but any suggestions would be
>>>>>>> greatly appreciated.
>>>>>>>
>>>>>>
>>>>>> I'm not sure which Tuscany extension triggers the loading of
>>>>>> Xerces yet, but the SDO-Axiom and JSON databindings and the EJB
>>>>>> and Script bindings seem to pull Xerces in their pom.xml.
>>>>>>
>>>>>> I noticed that in 0.91 most Tuscany extensions on the classpath
>>>>>> (and most of them are going to be on the classpath if you're
>>>>>> using tuscany-sca-all.jar) are aggressively loaded and
>>>>>> initialized when the runtime starts. I'm going to make some
>>>>>> changes to a number of binding and implementation extensions to
>>>>>> allow them to be loaded only when they are actually required by
>>>>>> an SCA assembly.
>>>>>>
>>>>>> I hope this will help.
>>>>>>
>>>>>
>>>>> I looked into most of the bindings and implementations, they are
>>>>> now loaded dynamically, this should help with the footprint. I
>>>>> think we need to do the same with data bindings as they are
>>>>> dragging a lot of dependencies and in most cases people will stick
>>>>> to a single databinding in their environment.
>>>>>
>>>>> Registering databindings should be easy:
>>>>>
>>>>> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
>>>>> <databinding class name>,id=<databinding id>
>>>>> <databinding class name>,id=<databinding id>
>>>>> etc.
>>>>>
>>>>> I'm not sure about transformers, but was thinking about something
>>>>> like this:
>>>>>
>>>>> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
>>>>> <transformer class name>,source=<databinding
>>>>> id>,target=<databinding id>,weight=<weight>
>>>>> <transformer class name>,source=<databinding
>>>>> id>,target=<databinding id>,weight=<weight>
>>>>> etc.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> --
>>>>> Jean-Sebastien
>>>>>
>>>>>
>>>
>>> Most of the data binding initialization code seems to assume that
>>> data bindings extend BaseDataBinding by calling
>>> BaseDataBinding.setRegistry(...).
>>>
>>> I'm trying to understand why data bindings need to keep a pointer to
>>> the registry (actually the DataBindingExtensionPoint) and the only
>>> occurrence where it's used is in XMLStringDataBinding in:
>>>
>>> @Override
>>> public boolean introspect(DataType type, Annotation[] annotations) {
>>> if (registry.getDataBinding(type.getDataBinding()) == this) {
>>> type.setDataBinding(getName());
>>> type.setLogical(XMLType.UNKNOWN);
>>> return true;
>>> } else {
>>> return false;
>>> }
>>> }
>>>
>>> I don't understand what this code is for :) What does it do?
>>>
>>> Would the following alternative work?
>>>
>>> @Override
>>> public boolean introspect(DataType type, Annotation[] annotations) {
>>> if (getName().equals(type.getDataBinding())) {
>>> type.setLogical(XMLType.UNKNOWN);
>>> return true;
>>> } else {
>>> return false;
>>> }
>>> }
>>>
>>> Thanks
>>>
>>
>> or better (as it looks like data bindings can be identified by name
>> or by alias)?
>>
>> @Override
>> public boolean introspect(DataType type, Annotation[] annotations) {
>> String dataBinding = type.getDataBinding();
>> if (NAME.equals(dataBinding) || ALIASES[0].equals(dataBinding)) {
>> type.setLogical(XMLType.UNKNOWN);
>> return true;
>> } else {
>> return false;
>> }
>> }
>>
>> --
>> Jean-Sebastien
>>
>>
>>
I just commited some changes to load the databindings dynamically. This
should help with the footprint.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Your latest proposal sounds good.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Sunday, August 05, 2007 7:20 PM
Subject: Re: Dynamic registration of databindings, was: 0.91 Memory
Footprint
> Jean-Sebastien Delfino wrote:
>> Raymond Feng wrote:
>>> Hi,
>>>
>>> Your proposal looks good. I think it is consistent with the pattern that
>>> we use to deal with unresolved models. IMO, the proxy/delegate objects
>>> for databindings could be:
>>>
>>> DataBindingDelegate:
>>> className = "my.MyDataBinding" (or ClassReference?)
>>> DataBinding databinding; // transient instance lazily instantiated
>>> from the class name
>>> id = "db1"
>>>
>>> TransformerDelegate:
>>> className = "my.DB12DB2Transformer"
>>> Transformer instance; // transient instance lazily instantiated from
>>> the class name
>>> source = "DB1"
>>> target = "DB2"
>>> weight = 100
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>> <js...@apache.org>
>>> To: <tu...@ws.apache.org>
>>> Sent: Sunday, August 05, 2007 10:57 AM
>>> Subject: Dynamic registration of databindings, was: 0.91 Memory
>>> Footprint
>>>
>>>
>>>> Jean-Sebastien Delfino wrote:
>>>>> scyip12@rogers.com wrote:
>>>>>> We recently migrated our version of Tuscany from M2 to 0.91, and we
>>>>>> noticed that the memory consumption seems to have increased by quite
>>>>>> a bit. When doing memory profiling, the culprit appeared to be
>>>>>> classes related to Xerces DOM (DeferredElementNSImpl, several other
>>>>>> schema element related classes). When profiling the samples
>>>>>> (helloworld-ws-sdo-webapp) and our application in M2, those classes
>>>>>> don't seem to get called. We are going through the jars to determine
>>>>>> which module is triggering the Xerces parser, but any suggestions
>>>>>> would be greatly appreciated.
>>>>>>
>>>>>
>>>>> I'm not sure which Tuscany extension triggers the loading of Xerces
>>>>> yet, but the SDO-Axiom and JSON databindings and the EJB and Script
>>>>> bindings seem to pull Xerces in their pom.xml.
>>>>>
>>>>> I noticed that in 0.91 most Tuscany extensions on the classpath (and
>>>>> most of them are going to be on the classpath if you're using
>>>>> tuscany-sca-all.jar) are aggressively loaded and initialized when the
>>>>> runtime starts. I'm going to make some changes to a number of binding
>>>>> and implementation extensions to allow them to be loaded only when
>>>>> they are actually required by an SCA assembly.
>>>>>
>>>>> I hope this will help.
>>>>>
>>>>
>>>> I looked into most of the bindings and implementations, they are now
>>>> loaded dynamically, this should help with the footprint. I think we
>>>> need to do the same with data bindings as they are dragging a lot of
>>>> dependencies and in most cases people will stick to a single
>>>> databinding in their environment.
>>>>
>>>> Registering databindings should be easy:
>>>>
>>>> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
>>>> <databinding class name>,id=<databinding id>
>>>> <databinding class name>,id=<databinding id>
>>>> etc.
>>>>
>>>> I'm not sure about transformers, but was thinking about something like
>>>> this:
>>>>
>>>> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
>>>> <transformer class name>,source=<databinding id>,target=<databinding
>>>> id>,weight=<weight>
>>>> <transformer class name>,source=<databinding id>,target=<databinding
>>>> id>,weight=<weight>
>>>> etc.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Jean-Sebastien
>>>>
>>>>
>>
>> Most of the data binding initialization code seems to assume that data
>> bindings extend BaseDataBinding by calling
>> BaseDataBinding.setRegistry(...).
>>
>> I'm trying to understand why data bindings need to keep a pointer to the
>> registry (actually the DataBindingExtensionPoint) and the only occurrence
>> where it's used is in XMLStringDataBinding in:
>>
>> @Override
>> public boolean introspect(DataType type, Annotation[] annotations) {
>> if (registry.getDataBinding(type.getDataBinding()) == this) {
>> type.setDataBinding(getName());
>> type.setLogical(XMLType.UNKNOWN);
>> return true;
>> } else {
>> return false;
>> }
>> }
>>
>> I don't understand what this code is for :) What does it do?
>>
>> Would the following alternative work?
>>
>> @Override
>> public boolean introspect(DataType type, Annotation[] annotations) {
>> if (getName().equals(type.getDataBinding())) {
>> type.setLogical(XMLType.UNKNOWN);
>> return true;
>> } else {
>> return false;
>> }
>> }
>>
>> Thanks
>>
>
> or better (as it looks like data bindings can be identified by name or by
> alias)?
>
> @Override
> public boolean introspect(DataType type, Annotation[] annotations) {
> String dataBinding = type.getDataBinding();
> if (NAME.equals(dataBinding) || ALIASES[0].equals(dataBinding)) {
> type.setLogical(XMLType.UNKNOWN);
> return true;
> } else {
> return false;
> }
> }
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Raymond Feng wrote:
>> Hi,
>>
>> Your proposal looks good. I think it is consistent with the pattern
>> that we use to deal with unresolved models. IMO, the proxy/delegate
>> objects for databindings could be:
>>
>> DataBindingDelegate:
>> className = "my.MyDataBinding" (or ClassReference?)
>> DataBinding databinding; // transient instance lazily instantiated
>> from the class name
>> id = "db1"
>>
>> TransformerDelegate:
>> className = "my.DB12DB2Transformer"
>> Transformer instance; // transient instance lazily instantiated
>> from the class name
>> source = "DB1"
>> target = "DB2"
>> weight = 100
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Sunday, August 05, 2007 10:57 AM
>> Subject: Dynamic registration of databindings, was: 0.91 Memory
>> Footprint
>>
>>
>>> Jean-Sebastien Delfino wrote:
>>>> scyip12@rogers.com wrote:
>>>>> We recently migrated our version of Tuscany from M2 to 0.91, and
>>>>> we noticed that the memory consumption seems to have increased by
>>>>> quite a bit. When doing memory profiling, the culprit appeared to
>>>>> be classes related to Xerces DOM (DeferredElementNSImpl, several
>>>>> other schema element related classes). When profiling the samples
>>>>> (helloworld-ws-sdo-webapp) and our application in M2, those
>>>>> classes don't seem to get called. We are going through the jars to
>>>>> determine which module is triggering the Xerces parser, but any
>>>>> suggestions would be greatly appreciated.
>>>>>
>>>>
>>>> I'm not sure which Tuscany extension triggers the loading of Xerces
>>>> yet, but the SDO-Axiom and JSON databindings and the EJB and Script
>>>> bindings seem to pull Xerces in their pom.xml.
>>>>
>>>> I noticed that in 0.91 most Tuscany extensions on the classpath
>>>> (and most of them are going to be on the classpath if you're using
>>>> tuscany-sca-all.jar) are aggressively loaded and initialized when
>>>> the runtime starts. I'm going to make some changes to a number of
>>>> binding and implementation extensions to allow them to be loaded
>>>> only when they are actually required by an SCA assembly.
>>>>
>>>> I hope this will help.
>>>>
>>>
>>> I looked into most of the bindings and implementations, they are now
>>> loaded dynamically, this should help with the footprint. I think we
>>> need to do the same with data bindings as they are dragging a lot of
>>> dependencies and in most cases people will stick to a single
>>> databinding in their environment.
>>>
>>> Registering databindings should be easy:
>>>
>>> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
>>> <databinding class name>,id=<databinding id>
>>> <databinding class name>,id=<databinding id>
>>> etc.
>>>
>>> I'm not sure about transformers, but was thinking about something
>>> like this:
>>>
>>> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
>>> <transformer class name>,source=<databinding id>,target=<databinding
>>> id>,weight=<weight>
>>> <transformer class name>,source=<databinding id>,target=<databinding
>>> id>,weight=<weight>
>>> etc.
>>>
>>> Thoughts?
>>>
>>> --
>>> Jean-Sebastien
>>>
>>>
>
> Most of the data binding initialization code seems to assume that data
> bindings extend BaseDataBinding by calling
> BaseDataBinding.setRegistry(...).
>
> I'm trying to understand why data bindings need to keep a pointer to
> the registry (actually the DataBindingExtensionPoint) and the only
> occurrence where it's used is in XMLStringDataBinding in:
>
> @Override
> public boolean introspect(DataType type, Annotation[] annotations) {
> if (registry.getDataBinding(type.getDataBinding()) == this) {
> type.setDataBinding(getName());
> type.setLogical(XMLType.UNKNOWN);
> return true;
> } else {
> return false;
> }
> }
>
> I don't understand what this code is for :) What does it do?
>
> Would the following alternative work?
>
> @Override
> public boolean introspect(DataType type, Annotation[] annotations) {
> if (getName().equals(type.getDataBinding())) {
> type.setLogical(XMLType.UNKNOWN);
> return true;
> } else {
> return false;
> }
> }
>
> Thanks
>
or better (as it looks like data bindings can be identified by name or
by alias)?
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
String dataBinding = type.getDataBinding();
if (NAME.equals(dataBinding) || ALIASES[0].equals(dataBinding)) {
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> Your proposal looks good. I think it is consistent with the pattern
> that we use to deal with unresolved models. IMO, the proxy/delegate
> objects for databindings could be:
>
> DataBindingDelegate:
> className = "my.MyDataBinding" (or ClassReference?)
> DataBinding databinding; // transient instance lazily instantiated
> from the class name
> id = "db1"
>
> TransformerDelegate:
> className = "my.DB12DB2Transformer"
> Transformer instance; // transient instance lazily instantiated
> from the class name
> source = "DB1"
> target = "DB2"
> weight = 100
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Sunday, August 05, 2007 10:57 AM
> Subject: Dynamic registration of databindings, was: 0.91 Memory Footprint
>
>
>> Jean-Sebastien Delfino wrote:
>>> scyip12@rogers.com wrote:
>>>> We recently migrated our version of Tuscany from M2 to 0.91, and we
>>>> noticed that the memory consumption seems to have increased by
>>>> quite a bit. When doing memory profiling, the culprit appeared to
>>>> be classes related to Xerces DOM (DeferredElementNSImpl, several
>>>> other schema element related classes). When profiling the samples
>>>> (helloworld-ws-sdo-webapp) and our application in M2, those classes
>>>> don't seem to get called. We are going through the jars to
>>>> determine which module is triggering the Xerces parser, but any
>>>> suggestions would be greatly appreciated.
>>>>
>>>
>>> I'm not sure which Tuscany extension triggers the loading of Xerces
>>> yet, but the SDO-Axiom and JSON databindings and the EJB and Script
>>> bindings seem to pull Xerces in their pom.xml.
>>>
>>> I noticed that in 0.91 most Tuscany extensions on the classpath (and
>>> most of them are going to be on the classpath if you're using
>>> tuscany-sca-all.jar) are aggressively loaded and initialized when
>>> the runtime starts. I'm going to make some changes to a number of
>>> binding and implementation extensions to allow them to be loaded
>>> only when they are actually required by an SCA assembly.
>>>
>>> I hope this will help.
>>>
>>
>> I looked into most of the bindings and implementations, they are now
>> loaded dynamically, this should help with the footprint. I think we
>> need to do the same with data bindings as they are dragging a lot of
>> dependencies and in most cases people will stick to a single
>> databinding in their environment.
>>
>> Registering databindings should be easy:
>>
>> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
>> <databinding class name>,id=<databinding id>
>> <databinding class name>,id=<databinding id>
>> etc.
>>
>> I'm not sure about transformers, but was thinking about something
>> like this:
>>
>> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
>> <transformer class name>,source=<databinding id>,target=<databinding
>> id>,weight=<weight>
>> <transformer class name>,source=<databinding id>,target=<databinding
>> id>,weight=<weight>
>> etc.
>>
>> Thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
Most of the data binding initialization code seems to assume that data
bindings extend BaseDataBinding by calling BaseDataBinding.setRegistry(...).
I'm trying to understand why data bindings need to keep a pointer to the
registry (actually the DataBindingExtensionPoint) and the only
occurrence where it's used is in XMLStringDataBinding in:
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
if (registry.getDataBinding(type.getDataBinding()) == this) {
type.setDataBinding(getName());
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
I don't understand what this code is for :) What does it do?
Would the following alternative work?
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
if (getName().equals(type.getDataBinding())) {
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Your proposal looks good. I think it is consistent with the pattern that we
use to deal with unresolved models. IMO, the proxy/delegate objects for
databindings could be:
DataBindingDelegate:
className = "my.MyDataBinding" (or ClassReference?)
DataBinding databinding; // transient instance lazily instantiated from
the class name
id = "db1"
TransformerDelegate:
className = "my.DB12DB2Transformer"
Transformer instance; // transient instance lazily instantiated from the
class name
source = "DB1"
target = "DB2"
weight = 100
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Sunday, August 05, 2007 10:57 AM
Subject: Dynamic registration of databindings, was: 0.91 Memory Footprint
> Jean-Sebastien Delfino wrote:
>> scyip12@rogers.com wrote:
>>> We recently migrated our version of Tuscany from M2 to 0.91, and we
>>> noticed that the memory consumption seems to have increased by quite a
>>> bit. When doing memory profiling, the culprit appeared to be classes
>>> related to Xerces DOM (DeferredElementNSImpl, several other schema
>>> element related classes). When profiling the samples
>>> (helloworld-ws-sdo-webapp) and our application in M2, those classes
>>> don't seem to get called. We are going through the jars to determine
>>> which module is triggering the Xerces parser, but any suggestions would
>>> be greatly appreciated.
>>>
>>
>> I'm not sure which Tuscany extension triggers the loading of Xerces yet,
>> but the SDO-Axiom and JSON databindings and the EJB and Script bindings
>> seem to pull Xerces in their pom.xml.
>>
>> I noticed that in 0.91 most Tuscany extensions on the classpath (and most
>> of them are going to be on the classpath if you're using
>> tuscany-sca-all.jar) are aggressively loaded and initialized when the
>> runtime starts. I'm going to make some changes to a number of binding and
>> implementation extensions to allow them to be loaded only when they are
>> actually required by an SCA assembly.
>>
>> I hope this will help.
>>
>
> I looked into most of the bindings and implementations, they are now
> loaded dynamically, this should help with the footprint. I think we need
> to do the same with data bindings as they are dragging a lot of
> dependencies and in most cases people will stick to a single databinding
> in their environment.
>
> Registering databindings should be easy:
>
> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
> <databinding class name>,id=<databinding id>
> <databinding class name>,id=<databinding id>
> etc.
>
> I'm not sure about transformers, but was thinking about something like
> this:
>
> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
> <transformer class name>,source=<databinding id>,target=<databinding
> id>,weight=<weight>
> <transformer class name>,source=<databinding id>,target=<databinding
> id>,weight=<weight>
> etc.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org