Hi Pina,

please, could elaborate about the contributor's identity?

Thanks,

  Bernd

ppoddar@apache.org wrote:
> Author: ppoddar
> Date: Thu Dec  3 07:41:56 2009
> New Revision: 886691
> 
> URL: http://svn.apache.org/viewvc?rev=886691&view=rev
> Log:
> Major update from Sergio's contribution. 
> 
> Added:
>     labs/fluid/example/
>     labs/fluid/example/domain/
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/BiDiMapID.java   (with props)
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDODynamicClassResolver.java   (with
props)
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOEndTransactionListener.java  
(with props)
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/ContainedIdenticalTypeMapping.java
  (with props)
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/ContainerRelationMapping.java
  (with props)
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/EmbeddableIdenticalTypeMapping.java
  (with props)
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/EmbeddedRelationListMapping.java
  (with props)
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/EmbeddedRelationMapping.java
  (with props)
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/SDOMappingStrategyInstaller.java
>       - copied, changed from r778535, labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/SDOMappingStrategy.java
>     labs/fluid/src/main/java/serp/
>     labs/fluid/src/main/java/serp/bytecode/
>     labs/fluid/src/main/java/serp/bytecode/Annotation.java   (with props)
>     labs/fluid/src/test/java/example/basic/TestConfiguration.java   (with props)
> Removed:
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOMappingRepository.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOTypeRepository.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/TypeNotFoundException.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/SDOMappingStrategy.java
> Modified:
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/BiDiMap.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/ImplHelper.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDO2POJOGenerator.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDODelegatingResultList.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOEntityManager.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOEntityManagerFactory.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOInstanceMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOMetaDataFactory.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOProductDerivation.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOQuery.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SDOTypeParser.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/SourceCode.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/AbstractPropertyMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/IdenticalTypeMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/IdentityMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/PrimitiveListMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/PrimitiveMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/PropertyMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/RelationListMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/RelationMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/TypeMapping.java
>     labs/fluid/src/main/java/org/apache/openjpa/sdo/mapping/VersionMapping.java
>     labs/fluid/src/main/resources/org/apache/openjpa/sdo/localizer.properties
>     labs/fluid/src/test/java/example/basic/TestCRUD.java
>     labs/fluid/src/test/java/example/basic/TestRelation.java
>     labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSDO.java
>     labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSourceCode.java
>     labs/fluid/src/test/java/test/common/AbstractSDOTest.java
>     labs/fluid/src/test/resources/META-INF/persistence.xml
<snip/>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Hi Pina,

please could you clarify the origins of the code below?

Thanks,

  Bernd

ppoddar@apache.org wrote:
> Added: labs/fluid/src/main/java/serp/bytecode/Annotation.java
> URL: http://svn.apache.org/viewvc/labs/fluid/src/main/java/serp/bytecode/Annotation.java?rev=886691&view=auto
> ==============================================================================
> --- labs/fluid/src/main/java/serp/bytecode/Annotation.java (added)
> +++ labs/fluid/src/main/java/serp/bytecode/Annotation.java Thu Dec  3 07:41:56 2009
> @@ -0,0 +1,1010 @@
> +package serp.bytecode;
> +
> +import java.io.*;
> +import java.lang.reflect.*;
> +import java.util.*;
> +
> +import serp.bytecode.lowlevel.*;
> +import serp.bytecode.visitor.*;
> +import serp.util.*;
> +
> +/**
> + * A declared annotation.
> + *
> + * @author Abe White
> + */
> +public class Annotation implements BCEntity, VisitAcceptor {
> +    private static Method ENUM_VALUEOF = null;
> +    private static Method ENUM_NAME = null;
> +    static {
> +        try {
> +            Class c = Class.forName("java.lang.Enum");
> +            ENUM_VALUEOF = c.getMethod("valueOf", new Class[] {
> +                Class.class, String.class });
> +            ENUM_NAME = c.getMethod("name", (Class[]) null);
> +        } catch (Throwable t) {
> +            // pre-1.5 JDK
> +        }
> +    }
> + 
> +    private BCEntity _owner = null;
> +    private int _typeIndex = 0;
> +    private List _properties = null;
> +
> +    Annotation(BCEntity owner) {
> +        _owner = owner;
> +    }
> +
> +    /**
> +     * Annotations are stored in an {@link Annotations} table or as
> +     * part of an {@link Annotation} property value.
> +     */
> +    public BCEntity getOwner() {
> +        return _owner;
> +    }
> +
> +    void invalidate() {
> +        _owner = null;
> +    }
> +
> +    /**
> +     * The index in the class {@link ConstantPool} of the
> +     * {@link UTF8Entry} holding the type of this annotation.
> +     */
> +    public int getTypeIndex() {
> +        return _typeIndex;
> +    }
> +
> +    /**
> +     * The index in the class {@link ConstantPool} of the
> +     * {@link UTF8Entry} holding the type of this annotation.
> +     */
> +    public void setTypeIndex(int index) {
> +        _typeIndex = index;
> +    }
> +
> +    /**
> +     * The name of this annotation's type.
> +     */
> +    public String getTypeName() {
> +        String desc = ((UTF8Entry) getPool().getEntry(_typeIndex)).getValue();
> +        return getProject().getNameCache().getExternalForm(desc, false);
> +    }
> +
> +    /**
> +     * The {@link Class} object for this annotation's type.
> +     */
> +    public Class getType() {
> +        return Strings.toClass(getTypeName(), getClassLoader());
> +    }
> +
> +    /**
> +     * The bytecode for the type of this annotation.
> +     */
> +    public BCClass getTypeBC() {
> +        return getProject().loadClass(getTypeName(), getClassLoader());
> +    }
> +
> +    /**
> +     * This annotation's type.
> +     */
> +    public void setType(String type) {
> +        type = getProject().getNameCache().getInternalForm(type, true);
> +        _typeIndex = getPool().findUTF8Entry(type, true);
> +    }
> +
> +    /**
> +     * This annotation's type.
> +     */
> +    public void setType(Class type) {
> +        setType(type.getName());
> +    }
> +
> +    /**
> +     * This annotation's type.
> +     */
> +    public void setType(BCClass type) {
> +        setType(type.getName());
> +    }
> +
> +    /**
> +     * All declared properties.
> +     */
> +    public Property[] getProperties() {
> +        if (_properties == null)
> +            return new Property[0];
> +        return (Property[]) _properties.toArray
> +            (new Property[_properties.size()]);
> +    }
> +
> +    /**
> +     * Set the annotation properties.  This method is useful when
> +     * importing properties from another instance.
> +     */
> +    public void setProperties(Property[] props) {
> +        clearProperties();
> +        if (props != null)
> +            for (int i = 0; i < props.length; i++)
> +                addProperty(props[i]);
> +    }
> +
> +    /**
> +     * Return the property with the given name, or null if none.
> +     */
> +    public Property getProperty(String name) {
> +        if (_properties == null)
> +            return null;
> +        Property prop;
> +        for (int i = 0; i < _properties.size(); i++) {
> +            prop = (Property) _properties.get(i);
> +            if (prop.getName().equals(name))
> +                return prop;
> +        }
> +        return null;
> +    }
> +
> +    /**
> +     * Import a property from another instance.
> +     *
> +     * @return the newly added property
> +     */
> +    public Property addProperty(Property p) {
> +        Property prop = addProperty(p.getName());
> +        prop.setValue(p.getValue());
> +        return prop;
> +    }
> +
> +    /**
> +     * Add a new property.
> +     */
> +    public Property addProperty(String name) {
> +        Property prop = new Property(this);
> +        prop.setName(name);
> +        if (_properties == null)
> +            _properties = new ArrayList();
> +        _properties.add(prop);
> +        return prop;
> +    }
> +
> +    /**
> +     * Clear all annotation properties.
> +     */
> +    public void clearProperties() {
> +        if (_properties == null)
> +            return;
> +        for (int i = 0; i < _properties.size(); i++)
> +            ((Property) _properties.get(i)).invalidate();
> +        _properties.clear();
> +    }
> +
> +    /**
> +     * Remove the given property.
> +     *
> +     * @return true if an property was removed, false otherwise
> +     */
> +    public boolean removeProperty(Property prop) {
> +        return prop != null && removeProperty(prop.getName());
> +    }
> +
> +    /**
> +     * Remove the property with the given name.
> +     *
> +     * @return true if a property was removed, false otherwise
> +     */
> +    public boolean removeProperty(String name) {
> +        if (name == null || _properties == null)
> +            return false;
> +        Property prop;
> +        for (int i = 0; i < _properties.size(); i++) {
> +            prop = (Property) _properties.get(i);
> +            if (prop.getName().equals(name)) {
> +                prop.invalidate();
> +                _properties.remove(i);
> +                return true;
> +            }
> +        }
> +        return false;
> +    }
> +
> +    public Project getProject() {
> +        return _owner.getProject();
> +    }
> +
> +    public ConstantPool getPool() {
> +        return _owner.getPool();
> +    }
> +
> +    public ClassLoader getClassLoader() {
> +        return _owner.getClassLoader();
> +    }
> +
> +    public boolean isValid() {
> +        return _owner != null;
> +    }
> +
> +    public void acceptVisit(BCVisitor visit) {
> +        visit.enterAnnotation(this);
> +        if (_properties != null)
> +            for (int i = 0; i < _properties.size(); i++)
> +                ((Property) _properties.get(i)).acceptVisit(visit);
> +        visit.exitAnnotation(this);
> +    }
> +
> +    int getLength() {
> +        int len = 4;
> +        if (_properties != null)
> +            for (int i = 0; i < _properties.size(); i++)
> +                len += ((Property) _properties.get(i)).getLength();
> +        return len;
> +    }
> +
> +    void read(DataInput in) throws IOException {
> +        _typeIndex = in.readUnsignedShort();
> +        clearProperties();
> +        int props = in.readUnsignedShort();
> +        if (props > 0) {
> +            if (_properties == null)
> +                _properties = new ArrayList(props);
> +            Property prop;
> +            for (int i = 0; i < props; i++) {
> +                prop = new Property(this);
> +                prop.read(in);
> +                _properties.add(prop); 
> +            }
> +        }
> +    }
> +
> +    void write(DataOutput out) throws IOException {
> +        out.writeShort(_typeIndex); 
> +        out.writeShort((_properties == null) ? 0 : _properties.size());
> +        if (_properties != null) {
> +            for (int i = 0; i < _properties.size(); i++)
> +                ((Property) _properties.get(i)).write(out);
> +        }
> +    }
> +
> +    /**
> +     * An annotation property.
> +     */
> +    public static class Property implements BCEntity, VisitAcceptor {
> +        private Annotation _owner = null;
> +        private int _nameIndex = 0;
> +        private final Value _value = new Value();
> +        private Value[] _values = null;
> +
> +        Property(Annotation owner) {
> +            _owner = owner;
> +        }
> +
> +        /**
> +         * The owning annotation.
> +         */
> +        public Annotation getAnnotation() {
> +            return _owner;
> +        }
> +
> +        void invalidate() {
> +            _owner = null;
> +        }
> +
> +        /**
> +         * Return the index in the class {@link ConstantPool} of the
> +         * {@link UTF8Entry} holding the name of this property.
> +         */
> +        public int getNameIndex() {
> +            return _nameIndex;
> +        }
> +
> +        /**
> +         * Set the index in the class {@link ConstantPool} of the
> +         * {@link UTF8Entry} holding the name of this property.
> +         */
> +        public void setNameIndex(int index) {
> +            _nameIndex = index;
> +        }
> +
> +        /**
> +         * Return the name of this property.
> +         */
> +        public String getName() {
> +            return ((UTF8Entry) getPool().getEntry(_nameIndex)).getValue();
> +        }
> +
> +        /**
> +         * Set the name of this property.
> +         */
> +        public void setName(String name) {
> +            _nameIndex = getPool().findUTF8Entry(name, true);
> +        }
> +
> +        /**
> +         * Return the value of the property as its wrapper type.
> +         * Returns class values as the class name.
> +         */
> +        public Object getValue() {
> +            if (_values == null)
> +                return getValue(_value);
> +            Object[] vals = new Object[_values.length];
> +            for (int i = 0; i < vals.length; i++)
> +                vals[i] = getValue(_values[i]);
> +            return vals;
> +        }
> +
> +        /**
> +         * Extract the Java value.
> +         */
> +        private Object getValue(Value val) {
> +            if (val.index == -1)
> +                return val.value;
> +
> +            Object o = ((ConstantEntry) getPool().getEntry(val.index)).
> +                getConstant();
> +            if (val.index2 != -1) {
> +                // enum value
> +                String e = getProject().getNameCache().
> +                    getExternalForm((String) o, false);
> +                String name = ((UTF8Entry) getPool().getEntry(val.index2)).
> +                    getValue();
> +                try {
> +                    Class cls = Class.forName(e, true, getClassLoader());  
> +                    return ENUM_VALUEOF.invoke(null, new Object[] {cls, name});
> +                } catch (Throwable t) {
> +                    return e + "." + name;
> +                } 
> +            }
> +            if (val.type == null)
> +                return o;
> +
> +            switch (val.type.getName().charAt(0)) {
> +            case 'b': 
> +                if (val.type == boolean.class)
> +                    return (((Number) o).intValue() != 0) ? Boolean.TRUE
> +                        : Boolean.FALSE;
> +                return new Byte(((Number) o).byteValue());
> +            case 'c':
> +                return new Character((char) ((Number) o).intValue());
> +            case 'j': // java.lang.Class
> +                return getProject().getNameCache().getExternalForm((String) o, 
> +                    false);
> +            case 's':
> +                return new Short(((Number) o).shortValue());
> +            default:
> +                return o;
> +            }
> +        }
> +
> +        /**
> +         * Set value of this property. The value should be an instance of any
> +         * primitive wrapper type, String, Class, BCClass, an enum constant,
> +         * an annotation, or an array of any of these types.
> +         */
> +        public void setValue(Object value) {
> +            if (!value.getClass().isArray()) {
> +                _values = null;
> +                setValue(_value, value);
> +            } else {
> +                _value.value = null;
> +                _values = new Value[Array.getLength(value)];
> +                for (int i = 0; i < _values.length; i++) {
> +                    _values[i] = new Value();
> +                    setValue(_values[i], Array.get(value, i));
> +                } 
> +            }
> +        }
> +
> +        /**
> +         * Set the given value.
> +         */
> +        private void setValue(Value val, Object o) {
> +            if (o instanceof String) 
> +                setValue(val, (String) o);
> +            else if (o instanceof Boolean)
> +                setValue(val, ((Boolean) o).booleanValue());
> +            else if (o instanceof Byte)
> +                setValue(val, ((Byte) o).byteValue());
> +            else if (o instanceof Character)
> +                setValue(val, ((Character) o).charValue());
> +            else if (o instanceof Double)
> +                setValue(val, ((Double) o).doubleValue());
> +            else if (o instanceof Float)
> +                setValue(val, ((Float) o).floatValue());
> +            else if (o instanceof Integer)
> +                setValue(val, ((Integer) o).intValue());
> +            else if (o instanceof Long)
> +                setValue(val, ((Long) o).longValue());
> +            else if (o instanceof Short)
> +                setValue(val, ((Short) o).shortValue());
> +            else if (o instanceof Class)
> +                setClassNameValue(val, ((Class) o).getName());
> +            else if (o instanceof BCClass)
> +                setClassNameValue(val, ((BCClass) o).getName());
> +            else if (o instanceof Annotation)
> +                setValue(val, (Annotation) o);
> +            else {
> +                String name = getEnumName(o);
> +                if (name != null) {
> +                    String type = getProject().getNameCache().
> +                        getInternalForm(o.getClass().getName(), true);
> +                    val.index = getPool().findUTF8Entry(type, true);
> +                    val.index2 = getPool().findUTF8Entry(name, true);
> +                    val.value = null;
> +                    val.type = null;
> +                } else {
> +                    val.index = -1;
> +                    val.index2 = -1;
> +                    val.value = o;
> +                    val.type = o.getClass();
> +                }
> +            }
> +        }
> +
> +        /**
> +         * Return the name of this enum value, or null if not an enum.
> +         */
> +        private static String getEnumName(Object o) {
> +            for (Class c = o.getClass(); true; c = c.getSuperclass()) {
> +                if (c == Object.class || c == null)
> +                    return null;
> +                if ("java.lang.Enum".equals(c.getName()))
> +                    break;
> +            }
> +            try {
> +                return (String) ENUM_NAME.invoke(o, (Object[]) null);
> +            } catch (Throwable t) {
> +                return o.toString();
> +            }
> +        }
> +
> +        /**
> +         * Return the string value of this property, or null if not set.
> +         */
> +        public String getStringValue() {
> +            return (String) getValue();
> +        }
> +
> +        /**
> +         * Return the boolean value of this property, or false if not set.
> +         */
> +        public boolean getBooleanValue() {
> +            Object value = getValue();
> +            return (value == null) ? false : ((Boolean) value).booleanValue();
> +        }
> +
> +        /**
> +         * Return the byte value of this property, or false if not set.
> +         */
> +        public byte getByteValue() {
> +            Object value = getValue();
> +            return (value == null) ? (byte) 0 : ((Number) value).byteValue();
> +        }
> +
> +        /**
> +         * Return the int value of this property, or 0 if not set.
> +         */
> +        public int getIntValue() {
> +            Object value = getValue();
> +            return (value == null) ? 0 : ((Number) value).intValue();
> +        }
> +
> +        /**
> +         * Return the long value of this property, or 0 if not set.
> +         */
> +        public long getLongValue() {
> +            Object value = getValue();
> +            return (value == null) ? 0L : ((Number) value).longValue();
> +        }
> +
> +        /**
> +         * Return the float value of this property, or 0 if not set.
> +         */
> +        public float getFloatValue() {
> +            Object value = getValue();
> +            return (value == null) ? 0F : ((Number) value).floatValue();
> +        }
> +
> +        /**
> +         * Return the double value of this property, or 0 if not set.
> +         */
> +        public double getDoubleValue() {
> +            Object value = getValue();
> +            return (value == null) ? 0D : ((Number) value).doubleValue();
> +        }
> +
> +        /**
> +         * Return the short value of this property, or 0 if not set.
> +         */
> +        public short getShortValue() {
> +            Object value = getValue();
> +            return (value == null) ? (short) 0 : ((Number) value).shortValue();
> +        }
> +
> +        /**
> +         * Return the class value of this property, or null if not set.
> +         */
> +        public String getClassNameValue() {
> +            return (String) getValue();
> +        }
> +
> +        /**
> +         * Return the annotation value of this property, or null if not set.
> +         */
> +        public Annotation getAnnotationValue() {
> +            return (Annotation) getValue();
> +        }
> +
> +        /**
> +         * Set the string value of this property.
> +         */
> +        public void setValue(String value) {
> +            _values = null;
> +            setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the string value of this property.
> +         */
> +        private void setValue(Value val, String o) {
> +            val.index = getPool().findUTF8Entry(o, true);
> +            val.index2 = -1;
> +            val.value = null;
> +            val.type = null;
> +        }
> +
> +        /**
> +         * Set the boolean value of this property.
> +         */
> +        public void setValue(boolean value) {
> +            _values = null;
> +            setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the boolean value of this property.
> +         */
> +        private void setValue(Value val, boolean o) {
> +            setValue(val, (o) ? 1 : 0);
> +            val.type = boolean.class;
> +        }
> +
> +        /**
> +         * Set the byte value of this property.
> +         */
> +        public void setValue(byte value) {
> +            _values = null;
> +            setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the byte value of this property.
> +         */
> +        private void setValue(Value val, byte o) {
> +            setValue(val, (int) o);
> +            val.type = byte.class;
> +        }
> +
> +        /**
> +         * Set the int value of this property.
> +         */
> +        public void setValue(int value) {
> +            _values = null;
> +            setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the int value of this property.
> +         */
> +        private void setValue(Value val, int o) {
> +            val.index = getPool().findIntEntry(o, true);
> +            val.index2 = -1;
> +            val.value = null;
> +            val.type = null;
> +        }
> +
> +        /**
> +         * Set the long value of this property.
> +         */
> +        public void setValue(long value) {
> +            _values = null;
> +            setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the long value of this property.
> +         */
> +        private void setValue(Value val, long o) {
> +            val.index = getPool().findLongEntry(o, true);
> +            val.index2 = -1;
> +            val.value = null;
> +            val.type = null;
> +        }
> +
> +        /**
> +         * Set the float value of this property.
> +         */
> +        public void setValue(float value) {
> +            _values = null;
> +            setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the float value of this property.
> +         */
> +        private void setValue(Value val, float o) {
> +            val.index = getPool().findFloatEntry(o, true);
> +            val.index2 = -1;
> +            val.value = null;
> +            val.type = null;
> +        }
> +
> +        /**
> +         * Set the double value of this property.
> +         */
> +        public void setValue(double value) {
> +            _values = null;
> +            setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the double value of this property.
> +         */
> +        private void setValue(Value val, double o) {
> +            val.index = getPool().findDoubleEntry(o, true);
> +            val.index2 = -1;
> +            val.value = null;
> +            val.type = null;
> +        }
> +
> +        /**
> +         * Set the short value of this property.
> +         */
> +        public void setValue(short value) {
> +            _values = null;
> +            setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the short value of this property.
> +         */
> +        private void setValue(Value val, short o) {
> +            setValue(val, (int) o);
> +            val.type = short.class;
> +        }
> +
> +        /**
> +         * Set the class value of this property.
> +         */
> +        public void setValue(Class value) {
> +            setClassNameValue(value.getName());
> +        }
> +
> +        /**
> +         * Set the class value of this property.
> +         */
> +        public void setValue(BCClass value) {
> +            setClassNameValue(value.getName());
> +        }
> +
> +        /**
> +         * Set the class value of this property.
> +         */
> +        public void setClassNameValue(String value) {
> +            _values = null;
> +            setClassNameValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the class value of this property.
> +         */
> +        private void setClassNameValue(Value val, String o) {
> +            o = getProject().getNameCache().getInternalForm(o, true);
> +            val.index = getPool().findUTF8Entry(o, true);
> +            val.index2 = -1;
> +            val.value = null;
> +            val.type = Class.class;
> +        }
> +
> +        /**
> +         * Set the annotation value of this property by importing the given
> +         * annotation from another instance.
> +         */
> +        public Annotation setValue(Annotation value) {
> +            _values = null;
> +            return setValue(_value, value);
> +        }
> +
> +        /**
> +         * Set the annotation value of this property by importing the given
> +         * annotation from another instance.
> +         */
> +        private Annotation setValue(Value val, Annotation o) {
> +            Annotation anno = new Annotation(this);
> +            anno.setType(o.getTypeName());
> +            anno.setProperties(o.getProperties());
> +            val.index = -1;
> +            val.index2 = -1;
> +            val.value = anno;
> +            val.type = null;
> +            return anno;
> +        }
> +
> +        /**
> +         * Set the annotation value of this property by importing the given
> +         * annotation from another instance.
> +         */
> +        public Annotation[] setValue(Annotation[] value) {
> +            _value.value = null;
> +            _values = new Value[value.length];
> +            Annotation[] ret = new Annotation[value.length];
> +            for (int i = 0; i < _values.length; i++) {
> +                _values[i] = new Value();
> +                ret[i] = setValue(_values[i], value[i]);
> +            }
> +            return ret;
> +        }
> +
> +        /**
> +         * Set this property value to a new annotation of the given type, 
> +         * returning the annotation for manipulation.
> +         */
> +        public Annotation newAnnotationValue(Class type) {
> +            return newAnnotationValue(type.getName());
> +        }
> +
> +        /**
> +         * Set this property value to a new annotation of the given type, 
> +         * returning the annotation for manipulation.
> +         */
> +        public Annotation newAnnotationValue(BCClass type) {
> +            return newAnnotationValue(type.getName());
> +        }
> +
> +        /**
> +         * Set this property value to a new annotation of the given type, 
> +         * returning the annotation for manipulation.
> +         */
> +        public Annotation newAnnotationValue(String type) {
> +            Annotation anno = new Annotation(this);
> +            anno.setType(type);
> +            _values = null;
> +            _value.index = -1;
> +            _value.index2 = -1;
> +            _value.value = anno;
> +            _value.type = null;
> +            return anno;
> +        }
> +
> +        /**
> +         * Set this property value to a new annotation array of the given type
> +         * and length, returning the annotations for manipulation.
> +         */
> +        public Annotation[] newAnnotationArrayValue(Class type, int length) {
> +            return newAnnotationArrayValue(type.getName(), length);
> +        }
> +
> +        /**
> +         * Set this property value to a new annotation array of the given type
> +         * and length, returning the annotations for manipulation.
> +         */
> +        public Annotation[] newAnnotationArrayValue(BCClass type, int length) {
> +            return newAnnotationArrayValue(type.getName(), length);
> +        }
> +
> +        /**
> +         * Set this property value to a new annotation array of the given type
> +         * and length, returning the annotations for manipulation.
> +         */
> +        public Annotation[] newAnnotationArrayValue(String type, int length) {
> +            _value.value = null;
> +            _values = new Value[length]; 
> +            Annotation[] ret = new Annotation[length];
> +            for (int i = 0; i < length; i++) {
> +                ret[i] = new Annotation(this);
> +                ret[i].setType(type);
> +                _values[i] = new Value();
> +                _values[i].index = -1;
> +                _values[i].index2 = -1;
> +                _values[i].value = ret[i];
> +                _values[i].type = null;
> +            }
> +            return ret;
> +        }
> +
> +        public Project getProject() {
> +            return _owner.getProject();
> +        }
> +
> +        public ConstantPool getPool() {
> +            return _owner.getPool();
> +        }
> +
> +        public ClassLoader getClassLoader() {
> +            return _owner.getClassLoader();
> +        }
> +
> +        public boolean isValid() {
> +            return _owner != null && (_values != null || _value.index != -1
> +                || _value.value != null);
> +        }
> +
> +        public void acceptVisit(BCVisitor visit) {
> +            visit.enterAnnotationProperty(this);
> +            visit.exitAnnotationProperty(this);
> +        }
> +
> +        int getLength() {
> +            if (!isValid())
> +                throw new IllegalStateException();
> +
> +            int len = 2; // name
> +            if (_values == null)
> +                len += getLength(_value);
> +            else {
> +                len += 3; // arr length + tag
> +                for (int i = 0; i < _values.length; i++)
> +                    len += getLength(_values[i]);
> +            }
> +            return len;
> +        }
> +
> +        /**
> +         * Return the length of the given value.
> +         */
> +        private int getLength(Value val) {
> +            if (val.index2 != -1)
> +                return 5; // tag + enum type + enum name
> +            if (val.index != -1)
> +                return 3; // tag + constant or class
> +            return 1 + ((Annotation) val.value).getLength(); // tag + anno
> +        }
> +
> +        void read(DataInput in) throws IOException {
> +            _nameIndex = in.readUnsignedShort(); 
> +            int tag = in.readByte();
> +            if (tag == '[') {
> +                int len = in.readUnsignedShort();
> +                _values = new Value[len];
> +                for (int i = 0; i < len; i++) {
> +                    _values[i] = new Value();
> +                    read(_values[i], in.readByte(), in); 
> +                }
> +            } else
> +                read(_value, tag, in);
> +        }
> +
> +        /**
> +         * Read data into the given value.
> +         */
> +        private void read(Value val, int tag, DataInput in) throws IOException {
> +            switch (tag) {
> +            case 'B':
> +                val.index = in.readUnsignedShort();
> +                val.index2 = -1;
> +                val.value = null;
> +                val.type = byte.class;
> +                break;
> +            case 'C':
> +                val.index = in.readUnsignedShort();
> +                val.index2 = -1;
> +                val.value = null;
> +                val.type = char.class;
> +                break;
> +            case 'D':
> +            case 'F':
> +            case 'I':
> +            case 'J':
> +            case 'S':
> +            case 's':
> +                val.index = in.readUnsignedShort();
> +                val.index2 = -1;
> +                val.value = null;
> +                val.type = null;
> +                break;
> +            case 'Z':
> +                val.index = in.readUnsignedShort();
> +                val.index2 = -1;
> +                val.value = null;
> +                val.type = boolean.class;
> +                break;
> +            case 'c':
> +                val.index = in.readUnsignedShort();
> +                val.index2 = -1;
> +                val.value = null;
> +                val.type = Class.class;
> +                break;
> +            case 'e':
> +                val.index = in.readUnsignedShort();
> +                val.index2 = in.readUnsignedShort();
> +                val.value = null;
> +                val.type = null;
> +                break;
> +            case '@':
> +                Annotation anno = new Annotation(this);
> +                anno.read(in);
> +                val.index = -1;
> +                val.index2 = -1;
> +                val.value = anno;
> +                val.type = null;
> +                break;
> +            default:
> +                throw new IllegalStateException(String.valueOf(tag));
> +            }
> +        }
> +
> +        void write(DataOutput out) throws IOException {
> +            if (!isValid())
> +                throw new IllegalStateException();
> +
> +            out.writeShort(_nameIndex);
> +            if (_values == null)
> +                write(_value, out);
> +            else {
> +                out.writeByte('[');
> +                out.writeShort(_values.length);
> +                for (int i = 0; i < _values.length; i++)
> +                    write(_values[i], out);
> +            }
> +        }
> +
> +        /**
> +         * Write the data for the given value to the stream.
> +         */
> +        private void write(Value val, DataOutput out) throws IOException {
> +            if (val.index2 != -1) {
> +                out.writeByte('e');
> +                out.writeShort(val.index);
> +                out.writeShort(val.index2);
> +            } else if (val.index != -1) {
> +                if (val.type != null) {
> +                    switch (val.type.getName().charAt(0)) {
> +                    case 'b':
> +                        if (val.type == byte.class)
> +                            out.writeByte('B');
> +                        else 
> +                            out.writeByte('Z');
> +                        break;
> +                    case 'c':
> +                        out.writeByte('C');
> +                        break;
> +                    case 'j': // java.lang.Class
> +                        out.writeByte('c');
> +                        break;
> +                    case 's':
> +                        out.writeByte('S');
> +                        break;
> +                    default:
> +                        throw new IllegalStateException(val.type.getName());
> +                    }
> +                } else {
> +                    Entry entry = getPool().getEntry(val.index);
> +                    if (entry instanceof DoubleEntry) 
> +                        out.writeByte('D');
> +                    else if (entry instanceof FloatEntry)
> +                        out.writeByte('F');
> +                    else if (entry instanceof IntEntry)
> +                        out.writeByte('I');
> +                    else if (entry instanceof LongEntry)
> +                        out.writeByte('J');
> +                    else if (entry instanceof UTF8Entry)
> +                        out.writeByte('s');
> +                    else
> +                        throw new IllegalStateException(entry.getClass().
> +                            getName());
> +                }
> +                out.writeShort(val.index);
> +            } else {
> +                out.writeByte('@');
> +                ((Annotation) val.value).write(out);
> +            }
> +        }
> +
> +        /**
> +         * Property value struct.
> +         */ 
> +        private static class Value {
> +            public int index = -1;
> +            public int index2 = -1;
> +            public Class type = null;
> +            public Object value = null;
> +        }
> +    }
> +}
> 
> Propchange: labs/fluid/src/main/java/serp/bytecode/Annotation.java
> ------------------------------------------------------------------------------
>     svn:eol-style = native
> 
> Modified: labs/fluid/src/main/resources/org/apache/openjpa/sdo/localizer.properties
> URL: http://svn.apache.org/viewvc/labs/fluid/src/main/resources/org/apache/openjpa/sdo/localizer.properties?rev=886691&r1=886690&r2=886691&view=diff
> ==============================================================================
> --- labs/fluid/src/main/resources/org/apache/openjpa/sdo/localizer.properties (original)
> +++ labs/fluid/src/main/resources/org/apache/openjpa/sdo/localizer.properties Thu Dec  3 07:41:56 2009
> @@ -1,3 +1,8 @@
> +generate-unenhanced: Generating dynamic Java class {0} using classloader {1} child of {2}.
> +generate-enhanced: Enhancing dynamic Java class {0} using classloader {1} child of {2}.
> +load-enhanced: Loaded dynamic, enhanced Java class {0} into JVM using classloader {1} child of {2}.
> +load-enhanced-error: Error while loading dynamic, enhanced Java class {0} into JVM using classloader {1} child of {2}.
> +
>  type-mapping-new: Creating new SDO Type Mapping for "{0}" mapped to "{1}"
>  type-mapping-resolve: Resolving SDO Type Mapping for "{0}" mapped to "{1}"
>  resolve-mapping-failed: No cached metadata found for "{0}" in "{1}"
> 
> Modified: labs/fluid/src/test/java/example/basic/TestCRUD.java
> URL: http://svn.apache.org/viewvc/labs/fluid/src/test/java/example/basic/TestCRUD.java?rev=886691&r1=886690&r2=886691&view=diff
> ==============================================================================
> --- labs/fluid/src/test/java/example/basic/TestCRUD.java (original)
> +++ labs/fluid/src/test/java/example/basic/TestCRUD.java Thu Dec  3 07:41:56 2009
> @@ -13,8 +13,7 @@
>  import test.common.AbstractSDOTest;
>  
>  /**
> - * Test basic CRUD operation with a simpleton Type that has no relation but
> - * primitive properties.
> + * Test basic CRUD operation with a simpleton SDO Type that has no relation but primitive properties.
>   *  
>   * @author Pinaki Poddar
>   *
> @@ -99,9 +98,10 @@
>  			dataObject.setString("firstName", "Ron");
>  			em.getTransaction().begin();
>  			DataObject merged = em.merge(dataObject);
> -			int v1 = ImplHelper.getVersion(merged);
> -			assertTrue(v1>v0);
> +			assertNotSame(merged, dataObject);
>  			em.getTransaction().commit();
> +            int v1 = ImplHelper.getVersion(merged);
> +            assertTrue(v1>v0);
>  			assertEquals("Ron", merged.getString("firstName"));
>  			int after = count("Person");
>  			assertEquals(before, after);
> @@ -138,7 +138,7 @@
>  	 */
>  	// START SNIPPET:createPerson
>  	DataObject createPerson(String ssn, String first, String last, int age) {
> -		Type type = getType("Person");
> +		Type type = getSDOType("Person");
>  		DataObject data = DataFactory.INSTANCE.create(type);
>  		data.set("ssn", ssn);
>  		data.setString("firstName", first);
> 
> Added: labs/fluid/src/test/java/example/basic/TestConfiguration.java
> URL: http://svn.apache.org/viewvc/labs/fluid/src/test/java/example/basic/TestConfiguration.java?rev=886691&view=auto
> ==============================================================================
> --- labs/fluid/src/test/java/example/basic/TestConfiguration.java (added)
> +++ labs/fluid/src/test/java/example/basic/TestConfiguration.java Thu Dec  3 07:41:56 2009
> @@ -0,0 +1,27 @@
> +package example.basic;
> +
> +import javax.persistence.EntityManager;
> +
> +import org.apache.openjpa.persistence.test.SingleEMFTestCase;
> +import org.apache.openjpa.sdo.SDODynamicClassResolver;
> +import org.apache.openjpa.sdo.SDOEntityManager;
> +import org.apache.openjpa.sdo.SDOEntityManagerFactory;
> +
> +import test.common.AbstractSDOTest;
> +
> +public class TestConfiguration extends AbstractSDOTest {
> +    public void testEntityManagerFactory() {
> +        assertNotNull(emf);
> +        assertTrue(emf instanceof SDOEntityManagerFactory);
> +    }
> +    
> +    public void testEntityManager() {
> +        EntityManager em = emf.createEntityManager();
> +        assertNotNull(em);
> +        assertTrue(em instanceof SDOEntityManager);
> +    }
> +    
> +    public void testClassResolver() {
> +      assertTrue(emf.getConfiguration().getClassResolverInstance() instanceof SDODynamicClassResolver);
> +    }
> +}
> 
> Propchange: labs/fluid/src/test/java/example/basic/TestConfiguration.java
> ------------------------------------------------------------------------------
>     svn:eol-style = native
> 
> Modified: labs/fluid/src/test/java/example/basic/TestRelation.java
> URL: http://svn.apache.org/viewvc/labs/fluid/src/test/java/example/basic/TestRelation.java?rev=886691&r1=886690&r2=886691&view=diff
> ==============================================================================
> --- labs/fluid/src/test/java/example/basic/TestRelation.java (original)
> +++ labs/fluid/src/test/java/example/basic/TestRelation.java Thu Dec  3 07:41:56 2009
> @@ -149,8 +149,7 @@
>  	 * 
>  	 */
>  	DataObject createPurchaseOrder() {
> -		DataObject purchaseOrder = DataFactory.INSTANCE.create(
> -				getType("PurchaseOrderType"));
> +		DataObject purchaseOrder = DataFactory.INSTANCE.create(getSDOType("PurchaseOrderType"));
>  
>  		purchaseOrder.setString("orderDate", "1999-10-20");
>  
> 
> Modified: labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSDO.java
> URL: http://svn.apache.org/viewvc/labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSDO.java?rev=886691&r1=886690&r2=886691&view=diff
> ==============================================================================
> --- labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSDO.java (original)
> +++ labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSDO.java Thu Dec  3 07:41:56 2009
> @@ -37,20 +37,20 @@
>  public class TestSDO extends AbstractSDOTest {
>  	
>  	public void testPackage() {
> -		Type addressType = getType("USAddress");
> +		Type addressType = getSDOType("USAddress");
>  		assertNotNull(addressType);
>  		String pkg = ImplHelper.getPackageName(addressType);
>  		assertEquals("example.domain",pkg);
>  	}
>  	
>  	public void testInstanceClassIsNullForUserType() {
> -		Type addressType = getType("USAddress");
> +		Type addressType = getSDOType("USAddress");
>  		assertFalse(addressType.isDataType());
>  		assertNull(addressType.getInstanceClass());
>  	}
>  	
>  	public void testIdentityType() {
> -		Type poType = getType("PurchaseOrderType");
> +		Type poType = getSDOType("PurchaseOrderType");
>  		assertNotNull(poType);
>  		Property id2 = ImplHelper.getIdentityProperty(poType);
>  		assertNotNull(id2);
> @@ -64,8 +64,7 @@
>  	 * 
>  	 */
>  	public void testCreateModel() {
> -		DataObject purchaseOrder = DataFactory.INSTANCE.create(
> -				getType("PurchaseOrderType"));
> +		DataObject purchaseOrder = DataFactory.INSTANCE.create(getSDOType("PurchaseOrderType"));
>  
>  		purchaseOrder.setString("orderDate", "1999-10-20");
>  
> 
> Modified: labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSourceCode.java
> URL: http://svn.apache.org/viewvc/labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSourceCode.java?rev=886691&r1=886690&r2=886691&view=diff
> ==============================================================================
> --- labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSourceCode.java (original)
> +++ labs/fluid/src/test/java/org/apache/openjpa/sdo/TestSourceCode.java Thu Dec  3 07:41:56 2009
> @@ -90,20 +90,20 @@
>  		}
>  	}
>  	
> -	public void testDuplicateMethod() {
> -		SourceCode code = new SourceCode("some.pkg", "SomeClass");
> -		try {
> -			code.addMethod("add", "int")
> -			    .makePublic()
> -			    .makeStatic()
> -			    .addArgument("int", "a")
> -			    .addArgument("int", "b");
> -			code.addMethod("add", "float")
> -			    .addArgument("int", "a")
> -			    .addArgument("int", "b");
> -			fail("Expected DuplicateField exception");
> -		} catch (IllegalArgumentException e) {
> -			//good
> -		}
> -	}
> +//	public void testDuplicateMethod() {
> +//		SourceCode code = new SourceCode("some.pkg", "SomeClass");
> +//		try {
> +//			code.addMethod("add", "int")
> +//			    .makePublic()
> +//			    .makeStatic()
> +//			    .addArgument("int", "a")
> +//			    .addArgument("int", "b");
> +//			code.addMethod("add", "float")
> +//			    .addArgument("int", "a")
> +//			    .addArgument("int", "b");
> +//			fail("Expected DuplicateField exception");
> +//		} catch (IllegalArgumentException e) {
> +//			//good
> +//		}
> +//	}
>  }
> 
> Modified: labs/fluid/src/test/java/test/common/AbstractSDOTest.java
> URL: http://svn.apache.org/viewvc/labs/fluid/src/test/java/test/common/AbstractSDOTest.java?rev=886691&r1=886690&r2=886691&view=diff
> ==============================================================================
> --- labs/fluid/src/test/java/test/common/AbstractSDOTest.java (original)
> +++ labs/fluid/src/test/java/test/common/AbstractSDOTest.java Thu Dec  3 07:41:56 2009
> @@ -25,16 +25,15 @@
>  import junit.framework.TestCase;
>  
>  import org.apache.openjpa.meta.MetaDataFactory;
> -import org.apache.openjpa.meta.MetaDataRepository;
>  import org.apache.openjpa.persistence.OpenJPAEntityManager;
>  import org.apache.openjpa.sdo.SDOEntityManagerFactory;
> -import org.apache.openjpa.sdo.SDOMappingRepository;
>  import org.apache.openjpa.sdo.SDOMetaDataFactory;
> +import org.apache.openjpa.sdo.SDOTypeParser;
>  
>  import commonj.sdo.Type;
>  
>  /**
> - * Abstract Test case sets up JPA persitence unt and SDO metadata from XML
> + * Abstract Test case sets up JPA persistence unit and SDO meta data from XML
>   * schema.
>   * 
>   * @author Pinaki Poddar
> @@ -42,7 +41,7 @@
>   */
>  public abstract class AbstractSDOTest extends TestCase {
>  	protected static SDOEntityManagerFactory emf;
> -	protected static SDOMappingRepository repos;
> +	protected static SDOMetaDataFactory repos;
>  	
>  	/**
>  	 * Obtain a EntityManagerFactory and initialize SDO Types.
> @@ -54,26 +53,24 @@
>  			assertNotNull(tmp);
>  			assertTrue(tmp instanceof SDOEntityManagerFactory);
>  			emf = (SDOEntityManagerFactory)tmp;
> +			emf.createEntityManager();
>  		}
>  	}
>  	
> -	SDOMappingRepository getRepos() {
> +	SDOMetaDataFactory getRepos() {
>  		if (repos == null) {
>  			MetaDataFactory mdf = emf.getConfiguration()
>  			.getMetaDataRepositoryInstance().getMetaDataFactory();
>  			assertTrue(mdf instanceof SDOMetaDataFactory);
> -			repos = ((SDOMetaDataFactory)mdf).getSDOMappingRepository();
> +			repos = (SDOMetaDataFactory)mdf;
>  		}
>  		return repos;
>  	}
>  
>  	
> -	/**
> -	 * Gets the type of given name.
> -	 */
> -	protected Type getType(String name) {
> -		return getRepos().getType(name);
> -	}
> +    protected Type getSDOType(String name) {
> +        return SDOTypeParser.findType(name);
> +    }
>  	
>  	/**
>  	 * Count number of persistent instances of the given alias.
> @@ -88,6 +85,6 @@
>  	 * Get the name of the persistence unit to be used by this receiver.
>  	 */
>  	protected String getPersistenceUnitName() {
> -		return System.getProperty("persistence.unit", "test");
> +		return System.getProperty("persistence.unit", "sdo");
>  	}
>  }
> 
> Modified: labs/fluid/src/test/resources/META-INF/persistence.xml
> URL: http://svn.apache.org/viewvc/labs/fluid/src/test/resources/META-INF/persistence.xml?rev=886691&r1=886690&r2=886691&view=diff
> ==============================================================================
> --- labs/fluid/src/test/resources/META-INF/persistence.xml (original)
> +++ labs/fluid/src/test/resources/META-INF/persistence.xml Thu Dec  3 07:41:56 2009
> @@ -1,19 +1,29 @@
>  <?xml version="1.0" encoding="UTF-8"?>
>  <persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
> -   <persistence-unit name="test">
>  
> +   <persistence-unit name="sdo">
> +   		<description>
> +   		   Persistence unit for testing Fluid.
> +   		   The configuration properties are essentially same as any other JPA application except
> +   		        i) openjpa.EntityManagerFactory must be set to "sdo" 
> +   		   and ii) openjpa.MetaDataFactory must be set as shown with XML schema definitions.
> +   		   
> +   		   Also set openjpa.DynamicEnhancementAgent to "false" because Fluid generates the 
> +   		   enhanced bytecode for SDO Types dynamically.
> +   		</description>
>  		<properties>
> -			<property name="openjpa.EntityManagerFactory" value="sdo"/>
> -			<property name="openjpa.MetaDataFactory" value="sdo(Resources=META-INF/person.xsd)"/>
> +			<property name="openjpa.EntityManagerFactory"    value="sdo"/>
> +			<property name="openjpa.MetaDataFactory"         value="sdo(Resources=META-INF/person.xsd;META-INF/po.xsd)"/>
> +   			<property name="openjpa.DynamicEnhancementAgent" value="false"/>
> +			
>  			<property name="openjpa.ConnectionDriverName" value="com.mysql.jdbc.Driver"/>
> -			<property name="openjpa.ConnectionURL" value="jdbc:mysql://localhost/SDO2"/>
> -			<property name="openjpa.ConnectionUserName" value="root"/>
> -			<property name="openjpa.ConnectionPassword" value="hello"/>
> +			<property name="openjpa.ConnectionURL"        value="jdbc:mysql://localhost/fluid"/>
> +			<property name="openjpa.ConnectionUserName"   value="root"/>
> +			<property name="openjpa.ConnectionPassword"   value=""/>
> +			
>  			<property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema"/>
> -   			<property name="openjpa.QueryCompilationCache" value="false"/>
> -   			<property name="openjpa.Log" value="DefaultLevel=TRACE, SQL=TRACE, Query=TRACE"/>
> -  			<property name="openjpa.BrokerImpl" value="non-finalizing"/>
> -   			
> +   			<property name="openjpa.QueryCompilationCache"    value="false"/>
> +   			<property name="openjpa.Log"                      value="DefaultLevel=WARN, SQL=TRACE, Query=TRACE"/>
>        	</properties>
>     </persistence-unit>
>  </persistence>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
> For additional commands, e-mail: commits-help@labs.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni updated LABS-352:
-------------------------------

    Fix Version/s:     (was: Future)
                   Current

> [refactoring][beanview] Carve single mode creation pieces out of producers
> --------------------------------------------------------------------------
>
>                 Key: LABS-352
>                 URL: https://issues.apache.org/jira/browse/LABS-352
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>
> With LABS-351 we have intermediate types that can be inferred instead of more generic
types like String, byte[] or streams.
> Now we need to implement a way to have beansview pieces to cope with them.
> This should be done in a pluggable way. Most importantly, pluggability is needed to extend
both ShowBean and ShowList (and conseguently form and paginated list) customization.
> Right now, ShowBean delegates to a createMain method the creation of the inner content
of a leaf in the ViewTree, the form producer then further delegates to specific methods to
create drodowns, textareas etc..
> Similarly, ShowList delegates to createFieldNodeCell method, which is a bit less clean
than createMain.
> Probably, we could refactor these methods a bit to give a clear path for extension using
AspectJ around advices. For example, to handle file uploads, an around advice on createMain
could intercept when the node contains a File intermediate type and output an upload field
in the form or a link for downloading the file in a showbean.
> A similar approach should be taken for form binding, cause the two will most probably
go in pairs.
> The final objective could be to declare an abstract aspect to customize appearance of
certain intermediate types in lists, showbeans and forms, and parsing of incoming parameters
for forms binding.
> Such aspects could then be implemented to support different form/display technologies,
like JSF.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

    [ https://issues.apache.org/jira/browse/LABS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784307#action_12784307
] 

Simone Gianni commented on LABS-352:
------------------------------------

A lot of stuff has evolved in the mean time.

Let's redefine the scope of this issue better.

LABS-494 is evolving to use the dynamic configuration system ( LABS-365 ) to provide a simple
way for the user to customize rendering. While this could eventually also provide a way to
generate custom form fields or alter the default way a field is displayed (complete access
to the bean and property value could be permitted), it is intended primarily for customizing
the "external" part of the layout, like for example wrapping in an additional div, or similar
stuff.

This bug is related to "meta types", like a rich text or an uploaded file etc.. which need
to be rendered with a custom HTML.

There are already two layers regarding "rendering" the value of a field : converters for bidirectional
machine read-write, formatters for bidirectional and localized human read-write. These layers
both work on plain strings.

When these "meta types" comes into play, however, a string is not sufficient, cause we need
to create custom HTML for display in show bean and lists, custom HTML for editing in forms,
and a custom binding for forms that goes in pair with the custom HTML.

We don't expect users to customize these "internals". If they really need to, they can use
the system that is evolving in LABS-494, or write a custom aspect.

So, using service discovery, will make the whole system slower giving no real feature.

Going back to aspects, problems outlined in the previous comments still exist, but there could
be a way out.

Currently each BeanData contains a number of PropertyInfo objects. These have toString that
is used by converters, and toUser that is used by formatters. PropertyInfo objects are created
once and then cached (except in the future when LABS-232 will be implemented), so they should
be fast.

We could add methods to PropertyInfo to return propert HTML (or an instance that produces
proper HTML), ans use it for this new layer, as much as it is already done with toString and
toUser.

To have a simpler way to hook aspects on these PropertyInfo, we could subclass them, and have
one for each type we need to support. This could also remove the need for service discovery
for formatters and converters, replacing them with an aspect returning the correct subclass
of PropertyInfo.

> [refactoring][beanview] Carve single mode creation pieces out of producers
> --------------------------------------------------------------------------
>
>                 Key: LABS-352
>                 URL: https://issues.apache.org/jira/browse/LABS-352
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Future
>
>
> With LABS-351 we have intermediate types that can be inferred instead of more generic
types like String, byte[] or streams.
> Now we need to implement a way to have beansview pieces to cope with them.
> This should be done in a pluggable way. Most importantly, pluggability is needed to extend
both ShowBean and ShowList (and conseguently form and paginated list) customization.
> Right now, ShowBean delegates to a createMain method the creation of the inner content
of a leaf in the ViewTree, the form producer then further delegates to specific methods to
create drodowns, textareas etc..
> Similarly, ShowList delegates to createFieldNodeCell method, which is a bit less clean
than createMain.
> Probably, we could refactor these methods a bit to give a clear path for extension using
AspectJ around advices. For example, to handle file uploads, an around advice on createMain
could intercept when the node contains a File intermediate type and output an upload field
in the form or a link for downloading the file in a showbean.
> A similar approach should be taken for form binding, cause the two will most probably
go in pairs.
> The final objective could be to declare an abstract aspect to customize appearance of
certain intermediate types in lists, showbeans and forms, and parsing of incoming parameters
for forms binding.
> Such aspects could then be implemented to support different form/display technologies,
like JSF.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

    [ https://issues.apache.org/jira/browse/LABS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784290#action_12784290
] 

Simone Gianni commented on LABS-494:
------------------------------------

There is another approach we are experimenting, forced by the pressing demand of visual programmers
wanting to customize heavily.

Since now the lists and bean output and forms are generated from a velocity file, which is
cached for better performances, nothing is preventing from :
- Writing your own velocity file
- Writing your own velocity snippet for a single field

This has been done using custom aspects on a project we are working on, but could be incorporated
in Magma provided we find a good way for standardizing it. The target is having visual programmer
customize stuff without requiring modification on the java side, so a convention over configuration
(a certain file in a certain path) OR the dynamic configuration implemented for LABS-365.

The advantage of using dynamic configuration are :
- configuring a specific situation or a generic one (like that field in that situation, that
field always, etc..)
- overriding pre-existing configurations
- unification
The disadvantages are :
- need to specify a file, so a complete path? 
... a complete path, or using some placeholders, like {beanclass} or similar
- need to learn the syntax of the configuration
- would be an extension of the current late configuration system, cause it by default calls
setters
... or they could be setters on the style, but the syntax would be cumbersome, like "User.customDisplay=name,/path/to/my/name.vm"
to call BeanStyle.customDisplay(String field, String path). 
- how to cache it?
... if they are setters, we can cache it based on what setters are called
... moreover, if they are setters, they could be converted to aspects later

The advantage of using convention over configuration are :
- create the file, and that's it
The disadvantages are :
- need to rethink current conventions
... for example, each handler should have a folder to contain specifically named files
... must provide a convention for the two biggest cases (that field in that situation, that
field always)
- cannot specify the context in the same flexible way
... How to specify that I want that format only on that list, and that other in that show
bean, given they are both returned by the same handler?
- how to cache it?
... since the cache id must be calculated before actual execution, we'll end polling for the
presence of the file all the time
- need to learn a naming convention
... which will not be reused, as opposed to learning the configuration system which is used
in many more situations



> [web] More support for CSS styling
> ----------------------------------
>
>                 Key: LABS-494
>                 URL: https://issues.apache.org/jira/browse/LABS-494
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently Magma offers a flexible way to aggregate output from different methods in the
page. Howeverm, since the HTML is often generated by Magma components, great care is needed
in offering enough HTML elements and CSS classes to permit a complete CSS customization.
> Currently, most components (like lists and forms) do provide extensive CSS classes. The
template and compunding system however don't.
> When a template is outputting different parts in a zone (like for example boxes) it wraps
those pieces in divs, but which CSS classes are applied to that div is not clear.
> At the same time, for I18N and other systems, Magma keeps a kind of "stack" of the context
in which it is evaluating current HTML, making this information available on the page CSS
seems to be a simple and complete way of  having all the informations.
> So, each time the template is producing an HTML div around an HTML piece, it should include
all the non-already-outputted context as CSS classes, plus a "relation class", which will
always be the same.
> Moreover, whenever the compunding system outputs a compunded piece of HTML, it should
wrap it in a div, placing again the context as CSS classes, plus a relation class that indicates
the kind of compound.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

On Tue, Dec 1, 2009 at 1:58 PM, Benson Margulies <bimargulies@gmail.com> wrote:
> The policy implication is unclear to me. maybe since I'm a committer
> at all, they can give me access to their sandbox without giving me
> full commit, and maybe not....

I *think* it's much easier to get commit access on commons than on
other projects if you're already an Apache committer, but I'm not sure
of the current status - best is to ask there.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

I'm game. Commons, please be so kind as to give me a pail and shovel
in your sandbox, and I'll set to work.


On Mon, Nov 30, 2009 at 11:29 PM, James Carman
<james@carmanconsulting.com> wrote:
> Good idea, Henri.  I'm +1 to that.
>
> On Mon, Nov 30, 2009 at 11:24 PM, Henri Yandell <flamefew@gmail.com> wrote:
>> Or you could start up a sandbox project. We've had good success with
>> ASF committers creating a sandbox branch of a released component, and
>> after diving in for a while it's then merged in to trunk where they
>> then become one of the most active coders of that component.
>>
>> So +1 to a sandbox branch to primitives if you have ideas you'd like
>> to play with. ASF committers get karma to the sandbox on request, so
>> just need you to want to do that and we can add karma.
>>
>> Hen
>>
>> On Mon, Nov 30, 2009 at 5:01 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>>> Stephen,
>>>
>>> It's interesting to me that the world in general knows about Trove,
>>> but not so much this.
>>>
>>> The fact that the front page is labelled with a snapshot version might
>>> have something to do with it, but I am kind of mystified. One thing
>>> that I'd like to add that Trove has is a full generic object hash map
>>> that is an open hash to avoid the space bloat of the stock Java
>>> HashMap.
>>>
>>> I am willing to make time to work on this. Since I'm not a committer
>>> at commons, I'm thinking that my proposed lab is a reasonable place to
>>> put in some effort and then bring it back into commons. Or maybe I
>>> should just start teeing up patches at commons? I find that
>>> reorganizing changes that might be called for to do generics and such
>>> are really clumsy  in patches, so svn cp-ing to a lab might still make
>>> sense.
>>>
>>> I'm copy the labs list to test if I'm making a particle of sense.
>>>
>>> --benson
>>>
>>>
>>> On Mon, Nov 30, 2009 at 5:34 PM, Stephen Colebourne
>>> <scolebourne@btopenworld.com> wrote:
>>>> Benson Margulies wrote:
>>>>>
>>>>> I proposed a lab over at labs in which to start construction of
>>>>> something much like what commons-primitives describes itself as
>>>>> setting out to do. The web page for primitives suggests a rather
>>>>> dormant state. Is there anybody in there actively working on
>>>>> primitives?
>>>>
>>>> I think [primitives] is stable and complete, thus appears rather quiet.
>>>>
>>>> I'd also point out Joda-Primitives - http://joda-primitives.sourceforge.net/
>>>>
>>>> Its a fork of the concept of [primitives] but with an API design I felt more
>>>> comfortable with. However, I don't have time to work on it (generify,
>>>> release). I'll grant access to anyone that wants to help on it.
>>>>
>>>> Stephen
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

The policy implication is unclear to me. maybe since I'm a committer
at all, they can give me access to their sandbox without giving me
full commit, and maybe not.

On Tue, Dec 1, 2009 at 5:58 AM, Bertrand Delacretaz
<bdelacretaz@apache.org> wrote:
> On Mon, Nov 30, 2009 at 7:43 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>> ...Does it make sense for me to play with breathing life into this idea in a lab?...
>
> You might also suggest creating an experimental branch in commons for
> this http://commons.apache.org/primitives/ thing. I don't know what's
> the current policy in commons for this, but if I were them I would
> welcome such initiatives ;-)
>
> -Bertrand (would be +1 for your lab by the way, if that doesn't work in commons)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

On Mon, Nov 30, 2009 at 7:43 PM, Benson Margulies <bimargulies@gmail.com> wrote:
> ...Does it make sense for me to play with breathing life into this idea in a lab?...

You might also suggest creating an experimental branch in commons for
this http://commons.apache.org/primitives/ thing. I don't know what's
the current policy in commons for this, but if I were them I would
welcome such initiatives ;-)

-Bertrand (would be +1 for your lab by the way, if that doesn't work in commons)

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Stephen,

It's interesting to me that the world in general knows about Trove,
but not so much this.

The fact that the front page is labelled with a snapshot version might
have something to do with it, but I am kind of mystified. One thing
that I'd like to add that Trove has is a full generic object hash map
that is an open hash to avoid the space bloat of the stock Java
HashMap.

I am willing to make time to work on this. Since I'm not a committer
at commons, I'm thinking that my proposed lab is a reasonable place to
put in some effort and then bring it back into commons. Or maybe I
should just start teeing up patches at commons? I find that
reorganizing changes that might be called for to do generics and such
are really clumsy  in patches, so svn cp-ing to a lab might still make
sense.

I'm copy the labs list to test if I'm making a particle of sense.

--benson


On Mon, Nov 30, 2009 at 5:34 PM, Stephen Colebourne
<scolebourne@btopenworld.com> wrote:
> Benson Margulies wrote:
>>
>> I proposed a lab over at labs in which to start construction of
>> something much like what commons-primitives describes itself as
>> setting out to do. The web page for primitives suggests a rather
>> dormant state. Is there anybody in there actively working on
>> primitives?
>
> I think [primitives] is stable and complete, thus appears rather quiet.
>
> I'd also point out Joda-Primitives - http://joda-primitives.sourceforge.net/
>
> Its a fork of the concept of [primitives] but with an API design I felt more
> comfortable with. However, I don't have time to work on it (generify,
> release). I'll grant access to anyone that wants to help on it.
>
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Jukka,

This is news to me. Am I reading it right that it's pretty dormant?

It's goals are a bit smaller than mine, but it certainly seemed to
have set out in the same direction.

Does it make sense for me to play with breathing life into this idea in a lab?

I can certainly ask if anyone is in fact working on it.

--benson


On Mon, Nov 30, 2009 at 12:01 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Mon, Nov 30, 2009 at 5:56 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>> I propose to use labs to try out the initial implementation of a
>> storage-efficient set of associative data structures for Java.
>
> How does this compare to http://commons.apache.org/primitives/?
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Benson Margulies wrote:
> Dear labs,
> 
> I propose to use labs to try out the initial implementation of a
> storage-efficient set of associative data structures for Java. My
> frank goal is to deliver the capability of GNU Trove under the ASL,
> and perhaps then some. I'd like to use the labs to rough out with
> unambiguous ASF ownership as a lone wolf, and then, if I get
> somewhere, shop it commons-collections and/or Harmony. In the Harmony
> case, there would really be an opportunity to look at the possibility
> of a JSR process for the specific question of primitive type
> collections, which require new API. Anyway, that's way out there in
> the foggy future.

+1

  Bernd

> 
> I apologize for sending this initially with an uninformative subject
> line as just the XML slug.
> 
> --benson
> 
> 
> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns="http://usefulinc.com/ns/doap#"
> xmlns:foaf="http://xmlns.com/foaf/0.1/"
> xmlns:labs="http://labs.apache.org/doap-ext/1.0#"
> xmlns:projects="http://projects.apache.org/ns/asfext#"> <Project
> rdf:about="http://labs.apache.org/labs#ptcol"> <name>Primitive Type
> Collections</name> <shortname>ptcol</shortname> <shortdesc
> xml:lang="en">Efficient collections with primitive types</shortdesc>
> <description xml:lang="en">ASLicensed collections library optimized
> for space-efficiency, particularly when primitive Java types are
> involved.</description> <homepage
> rdf:resource="http://labs.apache.org/ptcol/"/> <license
> rdf:resource="http://usefulinc.com/doap/licenses/asl20"/>
> <created>2009-11-27</created> <labs:status>active</labs:status>
> <maintainer> <foaf:Person
> rdf:about="http://people.apache.org/~bimargulies@people.apache.org/#me">
> <foaf:name>Benson Margulies</foaf:name> <foaf:homepage
> rdf:resource="http://people.apache.org/~bimargulies@people.apache.org/"/>
> <foaf:mbox_sha1sum>d06f334ab199343861971265fcad6b475f0f7cdf</foaf:mbox_sha1sum>
> </foaf:Person> </maintainer> <repository> <SVNRepository> <location
> rdf:resource="http://svn.apache.org/repos/asf/labs/ptcol/"/> <browse
> rdf:resource="http://svn.apache.org/viewvc/labs/ptcol/"/>
> </SVNRepository> </repository>
> <programming-language>java</programming-language> </Project>
> </rdf:RDF>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Hi,

On Mon, Nov 30, 2009 at 5:56 PM, Benson Margulies <bimargulies@gmail.com> wrote:
> I propose to use labs to try out the initial implementation of a
> storage-efficient set of associative data structures for Java.

How does this compare to http://commons.apache.org/primitives/?

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Dear labs,

I propose to use labs to try out the initial implementation of a
storage-efficient set of associative data structures for Java. My
frank goal is to deliver the capability of GNU Trove under the ASL,
and perhaps then some. I'd like to use the labs to rough out with
unambiguous ASF ownership as a lone wolf, and then, if I get
somewhere, shop it commons-collections and/or Harmony. In the Harmony
case, there would really be an opportunity to look at the possibility
of a JSR process for the specific question of primitive type
collections, which require new API. Anyway, that's way out there in
the foggy future.

I apologize for sending this initially with an uninformative subject
line as just the XML slug.

--benson


<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://usefulinc.com/ns/doap#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:labs="http://labs.apache.org/doap-ext/1.0#"
xmlns:projects="http://projects.apache.org/ns/asfext#"> <Project
rdf:about="http://labs.apache.org/labs#ptcol"> <name>Primitive Type
Collections</name> <shortname>ptcol</shortname> <shortdesc
xml:lang="en">Efficient collections with primitive types</shortdesc>
<description xml:lang="en">ASLicensed collections library optimized
for space-efficiency, particularly when primitive Java types are
involved.</description> <homepage
rdf:resource="http://labs.apache.org/ptcol/"/> <license
rdf:resource="http://usefulinc.com/doap/licenses/asl20"/>
<created>2009-11-27</created> <labs:status>active</labs:status>
<maintainer> <foaf:Person
rdf:about="http://people.apache.org/~bimargulies@people.apache.org/#me">
<foaf:name>Benson Margulies</foaf:name> <foaf:homepage
rdf:resource="http://people.apache.org/~bimargulies@people.apache.org/"/>
<foaf:mbox_sha1sum>d06f334ab199343861971265fcad6b475f0f7cdf</foaf:mbox_sha1sum>
</foaf:Person> </maintainer> <repository> <SVNRepository> <location
rdf:resource="http://svn.apache.org/repos/asf/labs/ptcol/"/> <browse
rdf:resource="http://svn.apache.org/viewvc/labs/ptcol/"/>
</SVNRepository> </repository>
<programming-language>java</programming-language> </Project>
</rdf:RDF>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Benson Margulies wrote:
> Sure.
> 
> Have a look at http://people.apache.org/~bimargulies/memory-efficient-java-tutorial.pdf.

Wow, that's elaborate, a 140 slide PDF. ;-) I bailed out at slide 58ish.

I have 2 suggestions:
1. You write 1 or 2 sentences in a follow up post describing your lab so
that people can easily decide +1 or not.
2. You choose a subject like "Lab request: Primitive Type Collections",
so that people know what your post actually is about.

Thanks!

> 
> I think that the world needs something like GNU Trove with an Apache
> license. I'd like to use labs to experiment with this as a
> one-man-band. 

Sounds reasonable.

> If I can get it off the ground, I'll bring it to
> commons-collections.

+1. Alternatively, you could ping the Harmony project.

  Bernd

> 
> --benson
> 
> 
> On Mon, Nov 30, 2009 at 4:38 AM, Bernd Fondermann
> <bernd.fondermann@googlemail.com> wrote:
>> Hi Benson,
>>
>> can you elaborate a little bit more than only posting a RDF?
>>
>> Thanks,
>>
>>  Bernd
>>
>> On Fri, Nov 27, 2009 at 21:36, Benson Margulies <bimargulies@gmail.com> wrote:
>>> Dear Labs,
>>>
>>> Please forget about my previous inquiry about using labs as a target
>>> for some preexisting stable code. This is an entirely new project I'm
>>> contemplating.
>>>
>>>
>>> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>> xmlns="http://usefulinc.com/ns/doap#"
>>> xmlns:foaf="http://xmlns.com/foaf/0.1/"
>>> xmlns:labs="http://labs.apache.org/doap-ext/1.0#"
>>> xmlns:projects="http://projects.apache.org/ns/asfext#"> <Project
>>> rdf:about="http://labs.apache.org/labs#ptcol"> <name>Primitive Type
>>> Collections</name> <shortname>ptcol</shortname> <shortdesc
>>> xml:lang="en">Efficient collections with primitive types</shortdesc>
>>> <description xml:lang="en">ASLicensed collections library optimized
>>> for space-efficiency, particularly when primitive Java types are
>>> involved.</description> <homepage
>>> rdf:resource="http://labs.apache.org/ptcol/"/> <license
>>> rdf:resource="http://usefulinc.com/doap/licenses/asl20"/>
>>> <created>2009-11-27</created> <labs:status>active</labs:status>
>>> <maintainer> <foaf:Person
>>> rdf:about="http://people.apache.org/~bimargulies@people.apache.org/#me">
>>> <foaf:name>Benson Margulies</foaf:name> <foaf:homepage
>>> rdf:resource="http://people.apache.org/~bimargulies@people.apache.org/"/>
>>> <foaf:mbox_sha1sum>d06f334ab199343861971265fcad6b475f0f7cdf</foaf:mbox_sha1sum>
>>> </foaf:Person> </maintainer> <repository> <SVNRepository>
<location
>>> rdf:resource="http://svn.apache.org/repos/asf/labs/ptcol/"/> <browse
>>> rdf:resource="http://svn.apache.org/viewvc/labs/ptcol/"/>
>>> </SVNRepository> </repository>
>>> <programming-language>java</programming-language> </Project>
>>> </rdf:RDF>
>>>
>>> --benson margulies
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
>>> For additional commands, e-mail: labs-help@labs.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
>> For additional commands, e-mail: labs-help@labs.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Sure.

Have a look at http://people.apache.org/~bimargulies/memory-efficient-java-tutorial.pdf.

I think that the world needs something like GNU Trove with an Apache
license. I'd like to use labs to experiment with this as a
one-man-band. If I can get it off the ground, I'll bring it to
commons-collections.

--benson


On Mon, Nov 30, 2009 at 4:38 AM, Bernd Fondermann
<bernd.fondermann@googlemail.com> wrote:
> Hi Benson,
>
> can you elaborate a little bit more than only posting a RDF?
>
> Thanks,
>
>  Bernd
>
> On Fri, Nov 27, 2009 at 21:36, Benson Margulies <bimargulies@gmail.com> wrote:
>> Dear Labs,
>>
>> Please forget about my previous inquiry about using labs as a target
>> for some preexisting stable code. This is an entirely new project I'm
>> contemplating.
>>
>>
>> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>> xmlns="http://usefulinc.com/ns/doap#"
>> xmlns:foaf="http://xmlns.com/foaf/0.1/"
>> xmlns:labs="http://labs.apache.org/doap-ext/1.0#"
>> xmlns:projects="http://projects.apache.org/ns/asfext#"> <Project
>> rdf:about="http://labs.apache.org/labs#ptcol"> <name>Primitive Type
>> Collections</name> <shortname>ptcol</shortname> <shortdesc
>> xml:lang="en">Efficient collections with primitive types</shortdesc>
>> <description xml:lang="en">ASLicensed collections library optimized
>> for space-efficiency, particularly when primitive Java types are
>> involved.</description> <homepage
>> rdf:resource="http://labs.apache.org/ptcol/"/> <license
>> rdf:resource="http://usefulinc.com/doap/licenses/asl20"/>
>> <created>2009-11-27</created> <labs:status>active</labs:status>
>> <maintainer> <foaf:Person
>> rdf:about="http://people.apache.org/~bimargulies@people.apache.org/#me">
>> <foaf:name>Benson Margulies</foaf:name> <foaf:homepage
>> rdf:resource="http://people.apache.org/~bimargulies@people.apache.org/"/>
>> <foaf:mbox_sha1sum>d06f334ab199343861971265fcad6b475f0f7cdf</foaf:mbox_sha1sum>
>> </foaf:Person> </maintainer> <repository> <SVNRepository>
<location
>> rdf:resource="http://svn.apache.org/repos/asf/labs/ptcol/"/> <browse
>> rdf:resource="http://svn.apache.org/viewvc/labs/ptcol/"/>
>> </SVNRepository> </repository>
>> <programming-language>java</programming-language> </Project>
>> </rdf:RDF>
>>
>> --benson margulies
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
>> For additional commands, e-mail: labs-help@labs.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Hi Benson,

can you elaborate a little bit more than only posting a RDF?

Thanks,

  Bernd

On Fri, Nov 27, 2009 at 21:36, Benson Margulies <bimargulies@gmail.com> wrote:
> Dear Labs,
>
> Please forget about my previous inquiry about using labs as a target
> for some preexisting stable code. This is an entirely new project I'm
> contemplating.
>
>
> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns="http://usefulinc.com/ns/doap#"
> xmlns:foaf="http://xmlns.com/foaf/0.1/"
> xmlns:labs="http://labs.apache.org/doap-ext/1.0#"
> xmlns:projects="http://projects.apache.org/ns/asfext#"> <Project
> rdf:about="http://labs.apache.org/labs#ptcol"> <name>Primitive Type
> Collections</name> <shortname>ptcol</shortname> <shortdesc
> xml:lang="en">Efficient collections with primitive types</shortdesc>
> <description xml:lang="en">ASLicensed collections library optimized
> for space-efficiency, particularly when primitive Java types are
> involved.</description> <homepage
> rdf:resource="http://labs.apache.org/ptcol/"/> <license
> rdf:resource="http://usefulinc.com/doap/licenses/asl20"/>
> <created>2009-11-27</created> <labs:status>active</labs:status>
> <maintainer> <foaf:Person
> rdf:about="http://people.apache.org/~bimargulies@people.apache.org/#me">
> <foaf:name>Benson Margulies</foaf:name> <foaf:homepage
> rdf:resource="http://people.apache.org/~bimargulies@people.apache.org/"/>
> <foaf:mbox_sha1sum>d06f334ab199343861971265fcad6b475f0f7cdf</foaf:mbox_sha1sum>
> </foaf:Person> </maintainer> <repository> <SVNRepository> <location
> rdf:resource="http://svn.apache.org/repos/asf/labs/ptcol/"/> <browse
> rdf:resource="http://svn.apache.org/viewvc/labs/ptcol/"/>
> </SVNRepository> </repository>
> <programming-language>java</programming-language> </Project>
> </rdf:RDF>
>
> --benson margulies
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Dear Labs,

Please forget about my previous inquiry about using labs as a target
for some preexisting stable code. This is an entirely new project I'm
contemplating.


<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://usefulinc.com/ns/doap#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:labs="http://labs.apache.org/doap-ext/1.0#"
xmlns:projects="http://projects.apache.org/ns/asfext#"> <Project
rdf:about="http://labs.apache.org/labs#ptcol"> <name>Primitive Type
Collections</name> <shortname>ptcol</shortname> <shortdesc
xml:lang="en">Efficient collections with primitive types</shortdesc>
<description xml:lang="en">ASLicensed collections library optimized
for space-efficiency, particularly when primitive Java types are
involved.</description> <homepage
rdf:resource="http://labs.apache.org/ptcol/"/> <license
rdf:resource="http://usefulinc.com/doap/licenses/asl20"/>
<created>2009-11-27</created> <labs:status>active</labs:status>
<maintainer> <foaf:Person
rdf:about="http://people.apache.org/~bimargulies@people.apache.org/#me">
<foaf:name>Benson Margulies</foaf:name> <foaf:homepage
rdf:resource="http://people.apache.org/~bimargulies@people.apache.org/"/>
<foaf:mbox_sha1sum>d06f334ab199343861971265fcad6b475f0f7cdf</foaf:mbox_sha1sum>
</foaf:Person> </maintainer> <repository> <SVNRepository> <location
rdf:resource="http://svn.apache.org/repos/asf/labs/ptcol/"/> <browse
rdf:resource="http://svn.apache.org/viewvc/labs/ptcol/"/>
</SVNRepository> </repository>
<programming-language>java</programming-language> </Project>
</rdf:RDF>

--benson margulies

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Massimo Guidi updated LABS-497:
-------------------------------

    Description: 
problems sending emails from within a job.

exception stacktrace:

java.lang.NullPointerException
	at org.apache.magma.website.Producer.getBasePath(Producer.java:75)
	at org.apache.magma.email.AddWebBasedEmailMethods.ajc$interMethod$org_apache_magma_email_AddWebBasedEmailMethods$org_apache_magma_email_Email$html(AddWebBasedEmailMethods.aj:42)
	at org.apache.magma.email.Email.html(Email.java:1)
	at org.apache.magma.email.AddWebBasedEmailMethods.ajc$interMethodDispatch1$org_apache_magma_email_AddWebBasedEmailMethods$org_apache_magma_email_Email$html(AddWebBasedEmailMethods.aj)
	at org.apache.magma.web.newsletter.SendNewsletter.run(SendNewsletter.java:35)
	at org.apache.magma.jobs.simple.JobExecutingThread.run(JobExecutingThread.java:50)

> [email] problems sending emails from within a job
> -------------------------------------------------
>
>                 Key: LABS-497
>                 URL: https://issues.apache.org/jira/browse/LABS-497
>             Project: Labs
>          Issue Type: Bug
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Massimo Guidi
>             Fix For: Current
>
>
> problems sending emails from within a job.
> exception stacktrace:
> java.lang.NullPointerException
> 	at org.apache.magma.website.Producer.getBasePath(Producer.java:75)
> 	at org.apache.magma.email.AddWebBasedEmailMethods.ajc$interMethod$org_apache_magma_email_AddWebBasedEmailMethods$org_apache_magma_email_Email$html(AddWebBasedEmailMethods.aj:42)
> 	at org.apache.magma.email.Email.html(Email.java:1)
> 	at org.apache.magma.email.AddWebBasedEmailMethods.ajc$interMethodDispatch1$org_apache_magma_email_AddWebBasedEmailMethods$org_apache_magma_email_Email$html(AddWebBasedEmailMethods.aj)
> 	at org.apache.magma.web.newsletter.SendNewsletter.run(SendNewsletter.java:35)
> 	at org.apache.magma.jobs.simple.JobExecutingThread.run(JobExecutingThread.java:50)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

[email] problems sending emails from within a job
-------------------------------------------------

                 Key: LABS-497
                 URL: https://issues.apache.org/jira/browse/LABS-497
             Project: Labs
          Issue Type: Bug
          Components: Magma
    Affects Versions: Current
            Reporter: Massimo Guidi
             Fix For: Current




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Benson Margulies wrote:

> As an ASF member, it is my (perhaps mistaken) belief that bringing
> more useful resources under the ASF umbrella is a good thing.

I read, once in a while, that Apache is about communities
and not (just) code. What you have is just code, right?

> I described the situation
> on the ASF members list, and several people piped up and said, 'labs.'

I read parts of that conversation, and didn't like that
recommendation at all. Sorry, I don't have much time to
engage on those conversations, or else I would have posted
then.
I believe that the people who said "labs" have an incorrect
understanding of what labs is about. Maybe they think that
Labs is the place for anything that isn't big enough to
become a project of its own. But as I understand it, Labs
is a playground for Apache committers, where they can develop
code without growing a community first.

You have code that is already done. Finished. Nothing to
work on, or so I understood your situation. So I don't
think that creating a lab just to have a target for a
once-only code dump is appropriate.
I would also suggest Google Code, or some other project
hosting provider. Or you can put it on your private
homepage at Apache. Without development going on, there
is no need for version control and issue tracking, right?
If there is an active Apache project in the future that
is a fit for the code, then will be the right time to
move it there.

cheers,
   Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Martin,

As an ASF member, it is my (perhaps mistaken) belief that bringing
more useful resources under the ASF umbrella is a good thing.

So, here I am. The place I work has this resource, I/we would like to
contribute it to ASF, but for that to work there has to be someplace
to put it.

After determining a lack of fit with Mahout, I described the situation
on the ASF members list, and several people piped up and said, 'labs.'
Upon reading up on labs, I was disquieted by the same issues you
raise, which I why I sent a query instead of just asking for a lab to
be created.

In general, committers commit other people's work constantly. That's
how new people become committers, after all. And I'd imagine that most
corporate code contributions are committed by people who didn't write
all, or any of them. I can see how this would be inappropriate for the
lab, and, again, that's howcome I asked.

--benson



On Tue, Nov 24, 2009 at 11:11 AM, Martin Cooper <martinc@apache.org> wrote:
> On Tue, Nov 24, 2009 at 7:16 AM, Benson Margulies <bimargulies@gmail.com> wrote:
>> Dear labs,
>>
>> I have some code that I would like to publish at ASF.
>
> This first sentence bothers me. Why do you want to do this, in
> preference to, for example, creating a project at Google Code? And
> what does it mean to you to "publish" at the ASF given that Labs
> cannot have releases? In short, what would be the real motivation in
> bringing the code to the ASF, and bringing it here now?
>
> <snip/>
>
>> 2) Jethran is not a committer anywhere, and so while he is the author,
>> I'd be the person requesting the lab and committing. If that's not
>> appropriate, then I shouldn't do it.
>
> That does not sound appropriate to me. If the code is not yours, and
> you would just be committing someone else's code and changes for them,
> then the ASF as a whole is not appropriate, let alone Labs.
>
>> So, the question is, would you think it reasonable for me to request
>> an NLP lab, or should we just plop it on Google Code?
>
> Honestly, Google Code seems like a better fit from what you have
> described. Neither the ASF in general, nor Labs in particular, seem
> appropriate.
>
> --
> Martin Cooper
>
>
>> Thanks,
>>
>> benson margulies
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
>> For additional commands, e-mail: labs-help@labs.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

On Tue, Nov 24, 2009 at 7:16 AM, Benson Margulies <bimargulies@gmail.com> wrote:
> Dear labs,
>
> I have some code that I would like to publish at ASF.

This first sentence bothers me. Why do you want to do this, in
preference to, for example, creating a project at Google Code? And
what does it mean to you to "publish" at the ASF given that Labs
cannot have releases? In short, what would be the real motivation in
bringing the code to the ASF, and bringing it here now?

<snip/>

> 2) Jethran is not a committer anywhere, and so while he is the author,
> I'd be the person requesting the lab and committing. If that's not
> appropriate, then I shouldn't do it.

That does not sound appropriate to me. If the code is not yours, and
you would just be committing someone else's code and changes for them,
then the ASF as a whole is not appropriate, let alone Labs.

> So, the question is, would you think it reasonable for me to request
> an NLP lab, or should we just plop it on Google Code?

Honestly, Google Code seems like a better fit from what you have
described. Neither the ASF in general, nor Labs in particular, seem
appropriate.

--
Martin Cooper


> Thanks,
>
> benson margulies
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

Dear labs,

I have some code that I would like to publish at ASF. Some folks at
members@ suggested labs, but I'm a bit uncertain whether it is really
a good lab topic. (Me, I'm a committer and an ASF member).

The code is a mature implementation of a hard NLP algorithm of general
utility, written in C++. The author, Jethran Guinness, works with me
at Basis Technology Corp.

While the code is in the same general topic space as the Mahout piece
of the Lucene TLP, it's implementation is far away from their
technology center. Aside from all other considerations, that makes it
hard for me or Jethran to imagine earning committer status there. Thus
the idea of labs.

As I read the mission statement of the labs, I am left with two doubts.

1) The lab is defined as a place to innovate. Well, this might be
innovation in the sense that there's nothing else much like this at
ASF at the moment. But it's not going to change very much or very
often, and there's no telling whether it will attract any related code
from other committers. So it might just sit there forever.

2) Jethran is not a committer anywhere, and so while he is the author,
I'd be the person requesting the lab and committing. If that's not
appropriate, then I shouldn't do it.

So, the question is, would you think it reasonable for me to request
an NLP lab, or should we just plop it on Google Code?

Thanks,

benson margulies

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni resolved LABS-495.
--------------------------------

    Resolution: Fixed

> [beans][speed] Optimize useless calls to getters, using lazy as much as possible
> --------------------------------------------------------------------------------
>
>                 Key: LABS-495
>                 URL: https://issues.apache.org/jira/browse/LABS-495
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently there are a number of calls to beans getters made by the handler to pre-populate
its "local cache". Many of these calls are useless, cause those properties will not be always
used.
> Moreover, if those properties are somehow dynamically generated, cause an overhead which
can be huge.
> There are already in places some checks, to avoid for example loading of lazy relationships
in JPA, so it can work also without all pre-buffering. It would be better to not preload at
all, and have all work on lazy loading.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni updated LABS-496:
-------------------------------

    Remaining Estimate: 0h
     Original Estimate: 0h

A few hooks have been affected by recent refactorings.

> [Maps] Missings link to map view
> --------------------------------
>
>                 Key: LABS-496
>                 URL: https://issues.apache.org/jira/browse/LABS-496
>             Project: Labs
>          Issue Type: Bug
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Arianna Giancola
>            Priority: Critical
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Missings link for map view in list. Not access the function also by using the correct
URL.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni resolved LABS-496.
--------------------------------

    Resolution: Fixed

> [Maps] Missings link to map view
> --------------------------------
>
>                 Key: LABS-496
>                 URL: https://issues.apache.org/jira/browse/LABS-496
>             Project: Labs
>          Issue Type: Bug
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Arianna Giancola
>            Priority: Critical
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Missings link for map view in list. Not access the function also by using the correct
URL.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

[Maps] Missings link to map view
--------------------------------

                 Key: LABS-496
                 URL: https://issues.apache.org/jira/browse/LABS-496
             Project: Labs
          Issue Type: Bug
          Components: Magma
    Affects Versions: Current
            Reporter: Arianna Giancola
            Priority: Critical
             Fix For: Current


Missings link for map view in list. Not access the function also by using the correct URL.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

    [ https://issues.apache.org/jira/browse/LABS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777537#action_12777537
] 

Simone Gianni commented on LABS-494:
------------------------------------

Clients demand more support for customizing CSS classes and ids. So, I'm going to add the
following methods to HtmlProducer :
- addCssClass(String) : adds a custom CSS class on the enclosing div of that producer
- useDefaultClasses(boolean) : tells wether to inject or not the default Magma CSS classes
on the enclosing div of that producer
- setHtmlId(String) : sets a custom id on the enclosing div of that producer

Moreover, for compounded elements :
- addCompoundCssClass(String, CompoundType) : adds a custom CSS class on the enclosing div
of the compounded elements


> [web] More support for CSS styling
> ----------------------------------
>
>                 Key: LABS-494
>                 URL: https://issues.apache.org/jira/browse/LABS-494
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently Magma offers a flexible way to aggregate output from different methods in the
page. Howeverm, since the HTML is often generated by Magma components, great care is needed
in offering enough HTML elements and CSS classes to permit a complete CSS customization.
> Currently, most components (like lists and forms) do provide extensive CSS classes. The
template and compunding system however don't.
> When a template is outputting different parts in a zone (like for example boxes) it wraps
those pieces in divs, but which CSS classes are applied to that div is not clear.
> At the same time, for I18N and other systems, Magma keeps a kind of "stack" of the context
in which it is evaluating current HTML, making this information available on the page CSS
seems to be a simple and complete way of  having all the informations.
> So, each time the template is producing an HTML div around an HTML piece, it should include
all the non-already-outputted context as CSS classes, plus a "relation class", which will
always be the same.
> Moreover, whenever the compunding system outputs a compunded piece of HTML, it should
wrap it in a div, placing again the context as CSS classes, plus a relation class that indicates
the kind of compound.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni reopened LABS-494:
--------------------------------


> [web] More support for CSS styling
> ----------------------------------
>
>                 Key: LABS-494
>                 URL: https://issues.apache.org/jira/browse/LABS-494
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently Magma offers a flexible way to aggregate output from different methods in the
page. Howeverm, since the HTML is often generated by Magma components, great care is needed
in offering enough HTML elements and CSS classes to permit a complete CSS customization.
> Currently, most components (like lists and forms) do provide extensive CSS classes. The
template and compunding system however don't.
> When a template is outputting different parts in a zone (like for example boxes) it wraps
those pieces in divs, but which CSS classes are applied to that div is not clear.
> At the same time, for I18N and other systems, Magma keeps a kind of "stack" of the context
in which it is evaluating current HTML, making this information available on the page CSS
seems to be a simple and complete way of  having all the informations.
> So, each time the template is producing an HTML div around an HTML piece, it should include
all the non-already-outputted context as CSS classes, plus a "relation class", which will
always be the same.
> Moreover, whenever the compunding system outputs a compunded piece of HTML, it should
wrap it in a div, placing again the context as CSS classes, plus a relation class that indicates
the kind of compound.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

[beans][speed] Optimize useless calls to getters, using lazy as much as possible
--------------------------------------------------------------------------------

                 Key: LABS-495
                 URL: https://issues.apache.org/jira/browse/LABS-495
             Project: Labs
          Issue Type: Improvement
          Components: Magma
    Affects Versions: Current
            Reporter: Simone Gianni
             Fix For: Current


Currently there are a number of calls to beans getters made by the handler to pre-populate
its "local cache". Many of these calls are useless, cause those properties will not be always
used.

Moreover, if those properties are somehow dynamically generated, cause an overhead which can
be huge.

There are already in places some checks, to avoid for example loading of lazy relationships
in JPA, so it can work also without all pre-buffering. It would be better to not preload at
all, and have all work on lazy loading.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni updated LABS-207:
-------------------------------


It all seems to work correctly, so I'm closing this bug.

> [beansview] Make showbean table-less
> ------------------------------------
>
>                 Key: LABS-207
>                 URL: https://issues.apache.org/jira/browse/LABS-207
>             Project: Labs
>          Issue Type: Wish
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> ShowBean, and inherently forms, currently produce layout tables. These are quite well
done, and does not create problems with WAI/WCAG validations, but it would be better to find
another approach, eventually based on some CSS/JavaScript client layout framework.
> Eventually, this could be an additional package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni resolved LABS-207.
--------------------------------

    Resolution: Fixed

> [beansview] Make showbean table-less
> ------------------------------------
>
>                 Key: LABS-207
>                 URL: https://issues.apache.org/jira/browse/LABS-207
>             Project: Labs
>          Issue Type: Wish
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> ShowBean, and inherently forms, currently produce layout tables. These are quite well
done, and does not create problems with WAI/WCAG validations, but it would be better to find
another approach, eventually based on some CSS/JavaScript client layout framework.
> Eventually, this could be an additional package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni updated LABS-207:
-------------------------------


After a lot of work, I went another way to solve the problem. 

Now, ShowList and ShowBean (the basic producers) accepts a "style". The style is a class responsible
of generating the HTML. This class generates a velocity template, which is then cached and
reused, that contains calls to generate the actual content.

This approach permits to have different styles (currently the table based and ul/li based
for lists, the table based for show bean and form, and a "plain divs" for show bean only).

Also, since the HTML template is generated only once, it is no longer a performance issue.

The velocity template contains only the HTML part. Everything else is fetched doing calls
inside velocity. This includes labels, cause they have to generated every time due to i18n.

The choice of velocity is just because of simplicity. 

> [beansview] Make showbean table-less
> ------------------------------------
>
>                 Key: LABS-207
>                 URL: https://issues.apache.org/jira/browse/LABS-207
>             Project: Labs
>          Issue Type: Wish
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> ShowBean, and inherently forms, currently produce layout tables. These are quite well
done, and does not create problems with WAI/WCAG validations, but it would be better to find
another approach, eventually based on some CSS/JavaScript client layout framework.
> Eventually, this could be an additional package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni updated LABS-494:
-------------------------------

    Remaining Estimate: 0h
     Original Estimate: 0h

The context contains way too much informations, and selecting "proper" ones is not easy nor
a stable approach.

So, now, both the template and the compunding system generates divs, having three CSS classes
: the simple name of the handler class, the name of the handler method, and the relation.

The relation is "zonedElement" for elements inside a zone, and the CompundType name for compounded
elements.

> [web] More support for CSS styling
> ----------------------------------
>
>                 Key: LABS-494
>                 URL: https://issues.apache.org/jira/browse/LABS-494
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently Magma offers a flexible way to aggregate output from different methods in the
page. Howeverm, since the HTML is often generated by Magma components, great care is needed
in offering enough HTML elements and CSS classes to permit a complete CSS customization.
> Currently, most components (like lists and forms) do provide extensive CSS classes. The
template and compunding system however don't.
> When a template is outputting different parts in a zone (like for example boxes) it wraps
those pieces in divs, but which CSS classes are applied to that div is not clear.
> At the same time, for I18N and other systems, Magma keeps a kind of "stack" of the context
in which it is evaluating current HTML, making this information available on the page CSS
seems to be a simple and complete way of  having all the informations.
> So, each time the template is producing an HTML div around an HTML piece, it should include
all the non-already-outputted context as CSS classes, plus a "relation class", which will
always be the same.
> Moreover, whenever the compunding system outputs a compunded piece of HTML, it should
wrap it in a div, placing again the context as CSS classes, plus a relation class that indicates
the kind of compound.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni resolved LABS-494.
--------------------------------

    Resolution: Fixed

> [web] More support for CSS styling
> ----------------------------------
>
>                 Key: LABS-494
>                 URL: https://issues.apache.org/jira/browse/LABS-494
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently Magma offers a flexible way to aggregate output from different methods in the
page. Howeverm, since the HTML is often generated by Magma components, great care is needed
in offering enough HTML elements and CSS classes to permit a complete CSS customization.
> Currently, most components (like lists and forms) do provide extensive CSS classes. The
template and compunding system however don't.
> When a template is outputting different parts in a zone (like for example boxes) it wraps
those pieces in divs, but which CSS classes are applied to that div is not clear.
> At the same time, for I18N and other systems, Magma keeps a kind of "stack" of the context
in which it is evaluating current HTML, making this information available on the page CSS
seems to be a simple and complete way of  having all the informations.
> So, each time the template is producing an HTML div around an HTML piece, it should include
all the non-already-outputted context as CSS classes, plus a "relation class", which will
always be the same.
> Moreover, whenever the compunding system outputs a compunded piece of HTML, it should
wrap it in a div, placing again the context as CSS classes, plus a relation class that indicates
the kind of compound.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

[web] More support for CSS styling
----------------------------------

                 Key: LABS-494
                 URL: https://issues.apache.org/jira/browse/LABS-494
             Project: Labs
          Issue Type: Improvement
          Components: Magma
    Affects Versions: Current
            Reporter: Simone Gianni
            Assignee: Simone Gianni
             Fix For: Current


Currently Magma offers a flexible way to aggregate output from different methods in the page.
Howeverm, since the HTML is often generated by Magma components, great care is needed in offering
enough HTML elements and CSS classes to permit a complete CSS customization.

Currently, most components (like lists and forms) do provide extensive CSS classes. The template
and compunding system however don't.

When a template is outputting different parts in a zone (like for example boxes) it wraps
those pieces in divs, but which CSS classes are applied to that div is not clear.

At the same time, for I18N and other systems, Magma keeps a kind of "stack" of the context
in which it is evaluating current HTML, making this information available on the page CSS
seems to be a simple and complete way of  having all the informations.

So, each time the template is producing an HTML div around an HTML piece, it should include
all the non-already-outputted context as CSS classes, plus a "relation class", which will
always be the same.

Moreover, whenever the compunding system outputs a compunded piece of HTML, it should wrap
it in a div, placing again the context as CSS classes, plus a relation class that indicates
the kind of compound.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni updated LABS-207:
-------------------------------


It is still not possible to emulate what is done with tables using pure CSS. 

The problem is that table cells tend to fill the available space, while floating divs tend
to use minimal space. In current table-based forms, if I place a fixed size (like zipcode)
field on the side of a full size (like address) field, cells will correctly use the minimum
space for the fixed size field and filol all the rest with space for the full size one. On
the opposite, using divs and CSS this is not possible, unless display:table(-row|-cell) is
used, which is currently supported only in IE8, making it a solution for the future but not
right now.

There are some CSS+Javascript framework that manages to emulate the "fill as much as possible"
behaviour using floating divs, like ElastiCSS, and they are compatible back to IE6, but are
an intermediate solution.

So, I'll proceed with extracting the HTML generation part in a separate replaceable class,
but forms will now stay on the table based system, while the non-table based implementation
will not honor the side-by-side relations. Implementations based on display:table or css+javascript
framework will be a viable options once there is an easy way to replace the generated HTML.

> [beansview] Make showbean table-less
> ------------------------------------
>
>                 Key: LABS-207
>                 URL: https://issues.apache.org/jira/browse/LABS-207
>             Project: Labs
>          Issue Type: Wish
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> ShowBean, and inherently forms, currently produce layout tables. These are quite well
done, and does not create problems with WAI/WCAG validations, but it would be better to find
another approach, eventually based on some CSS/JavaScript client layout framework.
> Eventually, this could be an additional package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni updated LABS-207:
-------------------------------

         Fix Version/s:     (was: Future)
                        Current
    Remaining Estimate: 0h
     Original Estimate: 0h

We need to have ul/li/div/span based outputs for all of the current view elements :
- ShowBean
- ShowList
- SmartForm
- SmartList

This view should be an alternative to the table based one, cause while the table is well defined,
the non-table ones will require the user to write some CSS to display them properly.


> [beansview] Make showbean table-less
> ------------------------------------
>
>                 Key: LABS-207
>                 URL: https://issues.apache.org/jira/browse/LABS-207
>             Project: Labs
>          Issue Type: Wish
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>             Fix For: Current
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> ShowBean, and inherently forms, currently produce layout tables. These are quite well
done, and does not create problems with WAI/WCAG validations, but it would be better to find
another approach, eventually based on some CSS/JavaScript client layout framework.
> Eventually, this could be an additional package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org

     [ https://issues.apache.org/jira/browse/LABS-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni updated LABS-488:
-------------------------------

    Remaining Estimate: 0h
     Original Estimate: 0h

We need to split the current yui implementation in two different packages, one for tabs and
another one for the accordion.

This is because this demo, correctly, uses only tabs, which are part of the default yui package,
while accordions are not yet part of yui and are not available on yui CDN.

> [Demo] Petstore
> ---------------
>
>                 Key: LABS-488
>                 URL: https://issues.apache.org/jira/browse/LABS-488
>             Project: Labs
>          Issue Type: New Feature
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Arianna Giancola
>             Fix For: Current
>
>         Attachments: petstore-site.zip
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> This is a demo site for magma. Featuring most of fragments and Magma functionalities.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org