Re: Dynamic registration of databindings, was: 0.91 Memory Footprint

[Jean-Sebastien Delfino]

Raymond Feng wrote:
Hi,
Your latest proposal sounds good.

Thanks,
Raymond

----- Original Message ----- From: "Jean-Sebastien Delfino" 
<[EMAIL PROTECTED]>
To: <tuscany-dev@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" 
<[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



I just commited some changes to load the databindings dynamically. This 
should help with the footprint.

--
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]