[Design of JBossXB] - Duplicate attributes
by adrian@jboss.org
I just found an interesting case that we should probably validate and fail.
| public class BaseClass
| {
| @XmlAttribute(name="something");
| public void setSomething(String value) {}
| }
|
| public class MyClass extends BaseClass
| {
| @XmlAttribute(name="something")
| public void setSomethingElse(String value) {}
| }
|
I gues which one gets used depends upon the order they appear
in the properties retriefved from BeanInfo?
But this should really be an error. You should have to do:
| public class MyClass extends BaseClass
| {
| @XmlTransient
| public void setSomething(String value) { super.setSomething(value); }
|
| @XmlAttribute(name="something")
| public void setSomethingElse(String value) {}
| }
|
The same issue probably exists for properties on the same class
and elements as well?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134656#4134656
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134656
18 years, 1 month
[Design the new POJO MicroContainer] - Re: Using a CompositeMetaType for a Map with String keys?
by scott.stark@jboss.org
So I'm creating a proper test in CompositeValueFactoryUnitTestCase, and there is a descrepency with how the value TypeInfo is being obtained vs what is seen in CompositeMetaTypeFactoryUnitTestCase. There, the type is obtained from the field.getGenericType():
| /**
| * JBMICROCONT-238, Map<String,?> should map to a MapCompositeMetaType(MetaValue<?>)
| * @throws Exception
| */
| public void testMapWithStringKeyComposite() throws Exception
| {
| Field field = getClass().getField("compositeSignature");
| Type mapSignature = field.getGenericType();
| CompositeMetaType result = assertInstanceOf(resolve(mapSignature), CompositeMetaType.class);
| MapCompositeMetaType expected = new MapCompositeMetaType(SimpleMetaType.STRING);
|
| testComposite(expected, result);
|
| Map<String, MetaValue> itemValues = new HashMap<String, MetaValue>();
| itemValues.put("key1", SimpleValueSupport.wrap("value1"));
| itemValues.put("key2", SimpleValueSupport.wrap("value2"));
| itemValues.put("key3", SimpleValueSupport.wrap("value3"));
| MapCompositeValueSupport mapValue = new MapCompositeValueSupport(itemValues, expected);
| assertEquals(SimpleValueSupport.wrap("value1"), mapValue.get("key1"));
| assertEquals(SimpleValueSupport.wrap("value2"), mapValue.get("key2"));
| assertEquals(SimpleValueSupport.wrap("value3"), mapValue.get("key3"));
| }
|
In the CompositeValueFactoryUnitTestCase case, the type has to be obtained from Configuration.getTypeInfo(value.getClass()), whcih relies on WeakTypeCache.get(Type). Somewhere along the lines the parameterized info on the HashMap is being lost, so the MetaType is not MapCompositeMetaType.
I guess this goes back to why the type test cannot be written as:
| public void testMapWithStringKeyComposite() throws Exception
| {
| Map<String,String> map = new HashMap<String,String>();
| CompositeMetaType result = assertInstanceOf(resolve(map.getClass()), CompositeMetaType.class);
| MapCompositeMetaType expected = new MapCompositeMetaType(SimpleMetaType.STRING);
| ...
|
This fails because the parameter types on the map are lost.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134641#4134641
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134641
18 years, 1 month
[Design the new POJO MicroContainer] - State of the JAXB parsing
by adrian@jboss.org
I've managed to get the testsuite down to 1 error and 54 failures
with the new parser.
The tests failing fall into the following categories:
* Attributes on the wrapped objects, which is a known issue with the way I implemented
this in JBossXB - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131304
* Two issues with with the cardinality tests which I haven't figured out
CardinalityCallbackTestCase and BadCardinalityCallbackTestCase
all the other problems in this part of the testsuite were caused by
initialization code only being the old xml parsing layer (see other threads),
so I guess this is similar but I can't spot what it is? ;-)
* Old xml parsing tests failing because they are expecting the wrong
GenericBeanMetaDataFactory class
* Old xml parsing tests where validation was in the xml parsing layer.
These checks need moving to the initialVisit() of the relevant metadata
e.g. This code in ValueFactoryHandler should be in
AbstractValueFactoryMetaData::initialVisit()
| public Object endElement(Object o, QName qName, ElementBinding element)
| {
| AbstractValueFactoryMetaData vf = (AbstractValueFactoryMetaData)o;
| if (vf.getUnderlyingValue() == null || vf.getMethod() == null)
| throw new IllegalArgumentException("Bean or method cannot null: " + vf);
| if (vf.getParameter() != null && vf.getParameters() != null)
| throw new IllegalArgumentException("Both parameter and parameters cannot be set: " + vf);
|
* Related to the previous point, its actually pointless to test the parsing
layer throws these errors since we don't actually install the metadata
where the initial visit and other initialization occurs where this validation
can be properly performed.
* AliasMetaData - there's no support for this at all in the new xml parsing
and the way it is done in the old version is wrong (I didn't think this
was useful anyway so it could just be dropped?).
The reason it is wrong, is because it is trying to use the classloader
(well actually it is not but it should be if it means anything)
and replace properties in the parsing stage rather than the more
relevant initialVisit() stage.
* policy metadata - I think Ales is working on this? Although this isn't high
priority since nobody is using it at the moment.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134640#4134640
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134640
18 years, 1 month