Re: [JBoss-dev] Integration issues

[Tom E. <to...@jb...>]

The example in particular that I remember was in 
org.jboss.util.propertyeditor.PropertyEditors (rev 1.8 to 1.9).  I was 
using the following method:

   /**
     * This method takes the properties found in the given beanProps
     * to the bean using the property editor registered for the property.
     * Any properties for which an editor cannot be found are ignored.
     *
     * @param bean the java bean instance to apply the properties to
     * @param beanProps
     */
    public static void mapJavaBeanProperties(Object bean, Properties 
beanProps)
       throws IntrospectionException

so knew there may be some properties in my configuration that would not 
map to bean properties (but as the javadoc states, it would be ignored).

In version 1.9, the behavior changed, as noted in the change in javadoc:

    /**
     * This method takes the properties found in the given beanProps
     * to the bean using the property editor registered for the property.
     * Any property in beanProps that does not have an associated java bean
     * property will result in an IntrospectionException. The string 
property
     * values are converted to the true java bean property type using the
     * java bean PropertyEditor framework. If a property in beanProps 
does not
     * have a PropertyEditor registered it will be ignored.
     *
     * @param bean - the java bean instance to apply the properties to
     * @param beanProps - map of java bean property name to property value.
     * @throws IntrospectionException thrown on introspection of bean and if
     *    a property in beanProps does not map to a property of bean.
     */
    public static void mapJavaBeanProperties(Object bean, Properties 
beanProps)
       throws IntrospectionException

This is all fine, but I certainly didn't have a test case for this 
within remoting, so only discovered it when I updated the commons jar I 
was using and saw the error in my code (where the IntrospectionException 
was thrown).  Again, this is fine (at least to me), but important that I 
discovered this early.

I guess what you and Adrian are saying is that I should have written a 
test case within jbossas that verified that is worked they way I 
expected (and it was javadoc'd)?



Scott M Stark wrote:
> Be specific as to the common examples as all I get from this argument is
> that a proper test could not be formulated and so existing
> implementations should be used as a proxy. I have said we should
> introduce such lazy testing as a failsafe mechanism for screwing up on
> the proper integration testing, but this is not going to work as a
> general development methodology.
> 
> -----Original Message-----
> From: jbo...@li...
> [mailto:jbo...@li...] On Behalf Of Tom
> Elrod
> Sent: Tuesday, November 01, 2005 10:46 AM
> To: jbo...@li...
> Subject: Re: [JBoss-dev] Integration issues
> 
> We agree (I think).  Yes, there needs to be a contract of API.  Yes, the
> 
> project should have tests to verify that API works correctly.
> 
> However, just because the API remains the same, behavior can change that
> 
> impacts the user of that API (without the person who changed that 
> behavior knowing it would impact the user).  I can site a few concrete 
> examples of this in the commons package.
> 
> Without the proper testing at a higher level on regular basis, these 
> incompatible changes in behavior will go unnoticed until is too late 
> (after the dependent component is released).
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> JBoss-Development mailing list
> JBo...@li...
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
>