Return-Path: 
 <commons-dev-return-79899-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 39048 invoked from network); 16 Nov 2005 23:55:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 16 Nov 2005 23:55:51 -0000
Received: (qmail 13454 invoked by uid 500); 16 Nov 2005 23:55:48 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 13386 invoked by uid 500); 16 Nov 2005 23:55:48 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 13375 invoked by uid 99); 16 Nov 2005 23:55:48 -0000
X-ASF-Spam-Status: No, hits=0.6 required=10.0
	tests=NO_REAL_NAME
X-Spam-Check-By: apache.org
Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Nov 2005 15:55:47 -0800
Received: by ajax.apache.org (Postfix, from userid 99)
	id 55FF2126; Thu, 17 Nov 2005 00:55:26 +0100 (CET)
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 37542]  New:  -
    Options: Parent vs Target Integration
X-Bugzilla-Reason: AssignedTo
Message-Id: <20051116235526.55FF2126@ajax.apache.org>
Date: Thu, 17 Nov 2005 00:55:26 +0100 (CET)
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37542>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37542

           Summary: Options: Parent vs Target Integration
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Betwixt
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: bdferris@u.washington.edu


[This is taken partially from my email to commons-users@jakarta]:

I was recently working with a custom IdStoringStrategy which used an Option
value to determine if an instance of an object would be encoded with an id-ref
or not.  Something like:

  <element name="node" property="node">
    <option>
      <name>use-idref</name>
      <value>true</value>
    </option>
  </element>

I quickly discovered that things didn't work quite as I planned, since the
Conext object passed into method calls in IdStoringStrategy didn't have any
Options.  The relevant code in AbstractBeanWriter indicated that options weren't
pushed onto the context stack prior to calls concerning the id-storage strategy.
 I patched AbstractBeanWriter to push options onto the stack at the appropriate
point, at which point I discovered another issue.  It roughly concerns the idea
of "options inheritance", for lack of a better words.

Consider the following two classes:

public class A {
    public B getB();
}

public class B {
   public String getValue();
}

They could have an associated class mapping file that looks like:

<?xml version='1.0'?>
<betwixt-config>

  <class name="A" >
    <element property="b">
      <option>
        <name>use-idref</name>
        <value>true</value>
      </option>
    </element>
  </class>

  <class name="B" >
    <option>
      <name>use-idref</name>
      <value>false</value>
    </option>
  </class>

</betwixt-config>

When the IdStorageStrategy is queried for the B object (returned by A.getB()),
what options will it see in the supplied Context object?  What object should it see?

It should clearly see a value for the option "use-idref".  However, the value
could come from two places:

1) The parent element descriptor defined for the "b" property in the A-class
mapping.
2) The target element descriptor defined by the B-class mapping.

In the current implementation, it would see neither value.  Thus, I am proposing
this enhancement with the following behavior:

When mapping a particular bean, two element descriptors may apply: the element
descriptor for the bean's class itself (the target), and the element descriptor
of a parent bean's property (the parent).  I believe that Option values defined
in the parent should overwrite Option values defined in the target.

Why this particular behavior?  The idea is that the target class' options could
be used to define general-behavior for mapping a particular class, while the
parent classes can override the general behavior with specific options for that
context.  Different parents could specify different flavors as different mapping
needs necessitated.

The desired behavior will require modifications to AbstractBeanWriter and
Options.  A patch with test cases follows.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org