March 2008 - jboss-dev-forums - Jboss List Archives

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : | You've confused me :-) Is this doable now, or is this a feature that needs adding to JBossXB? I know how to use xsd:redefine if there is a schema, but seeing as jbossxb doesn't use that musn't there be an annotation to set this up? I'll repeat again. xsd:redefine is the default behaviour of the jbossxb builder from annotations. anonymous wrote : | If it is doable now, what do I need to do to make it happen? | Create a schema you can xsd:redefine. The schema document is still required for a validating xml parser or modifying the xml in some tools. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134673#4134673 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134673

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reflection and MetaDataRepository refactoring

by adrian＠jboss.org

I'm well behind schedule on this :-( I thought it would take me a couple of hours on Monday and most of that would maven problems ;-) Anyway its been a good excercise none the less, because I've found and fixed a lot of problems that I wouldn't otherwise have known existed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134669#4134669 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134669

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: State of the JAXB parsing

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | * Old xml parsing tests where validation was in the xml parsing layer. | I moved all these to the initial visit so there's really only 4 failures due the wrapper problem, if you exclude the alias and policy parsing. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134665#4134665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134665

18 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: State of the JAXB parsing

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | * 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? ;-) | This was caused by there already being a "whenRequired" on the AbstractLifecycleMetaData, except it justs called "state" as a property. I removed the redundant property from the CallbackMetaData. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134651#4134651 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134651

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Using a CompositeMetaType for a Map with String keys?

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | In the CompositeValueFactoryUnitTestCase case, the type has to be obtained from Configuration.getTypeInfo(value.getClass()), | No it doesn't. "You pay your money and take your choice" ;-) >From AbstractMetaValueFactoryTest: | | /** | * Create a meta value | * | * @param value the value | * @return the meta value | */ | protected MetaValue createMetaValue(Object value) | { | return metaValueFactory.create(value); | } | | /** | * Create a meta value | * | * @param value the value | * @param type the type | * @return the meta value | */ | protected MetaValue createMetaValue(Object value, Type type) | { | return metaValueFactory.create(value, type); | } | There's also one with TypeInfo on the real factory, but not in the test helper. I guess there should also be methods where you pass in the MetaType????? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134650#4134650 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134650

18 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Another wrong implementation

by adrian＠jboss.org

I've fixed up some other issues by moving cross initialization in the initialVisit() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134637#4134637 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134637

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Another wrong implementation

by adrian＠jboss.org

The parameter index was only set by the xml parsing so again programmatic deployment is broken. Don't put logic in the xml parsing! Always write two tests - xml and programmatic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134633#4134633 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134633

18 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008