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"
<[EMAIL PROTECTED]>
To: <tuscany-dev@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:
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]