-
30. Re: Unifying metadata
aloubyansky Sep 20, 2007 9:45 AM (in response to starksm64)"adrian@jboss.org" wrote:
"scott.stark@jboss.org" wrote:
1. The existing ObjectModelFactoryDeployer based deployers producing legacy metadata need to be converted to SchemaResolverDeployer type deployers that produce the new metadata, and then create the legacy wrapper using the new metadata as the delegate. The JBossXBBuilder would be used to create the SchemaBinding for the new metadata.
One little issue here is that the SchemaResolverDeployer does not have a SchemaBindingResolver getResolver() method to allow subclasses to easily extend the default resolver.
This was something I asked Alex to look at.
I'm not sure how much he has done?
I haven't looked into the deployer issues above. -
31. Re: Unifying metadata
adrian.brock Sep 20, 2007 9:45 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
if we agree to merge
Ok with me. The only reason it was a seperate project was that JBossXB/Common
hadn't been updated to compile against JDK5 and retro when first I did it. -
32. Re: Unifying metadata
wolfc Sep 20, 2007 12:42 PM (in response to starksm64)App client 1.4/5 and JBoss client 5 are done. Will do JBoss client 1.4 tomorrow.
More issues: the model assumes that meta data from an override xml is mappable on top of the overriden xml. But these might be overrides for annotations. So either we removed that requirement (which may lead to EJB 2 issues) or we process annotations before allowing jboss override files. -
33. Re: Unifying metadata
starksm64 Sep 20, 2007 2:41 PM (in response to starksm64)Another issue is the need to parse multiple documents into one object instance. This shows up in the org.jboss.test.xml.metadata.JBossEjbObjectFactoryUnitTestCase test where both the standardjboss.xml and jboss.xml need to go into the JBoss50MetaData override.
I'm looking into how that can be handled. -
34. Re: Unifying metadata
alesj Sep 20, 2007 3:12 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
Another issue is the need to parse multiple documents into one object instance. This shows up in the org.jboss.test.xml.metadata.JBossEjbObjectFactoryUnitTestCase test where both the standardjboss.xml and jboss.xml need to go into the JBoss50MetaData override.
I'm looking into how that can be handled.
I guess this is related:
- http://jira.jboss.com/jira/browse/JBMICROCONT-184
I can look at this first thing in the morning, and we can discuss it during the MC call? -
35. Re: Unifying metadata
starksm64 Sep 20, 2007 3:31 PM (in response to starksm64)"alesj" wrote:
I guess this is related:
- http://jira.jboss.com/jira/browse/JBMICROCONT-184
I can look at this first thing in the morning, and we can discuss it during the MC call?
Not quite as the problem is really one of ejb-jar.xml/standardjboss.xml/jboss.xml. The current unified metadata already handles the ejb-jar.xml/jboss.xml case, but not merging multiple jboss.xml documents into the same JBoss50MetaData instance.
I don't see how this can be added to the org.jboss.xb.builder.runtime.BeanHandler that creates the metadata instance.
The root org.jboss.ejb.metadata.jboss.JBossMetaData would have to add a mergeOverridenMetaData method that took the existing override and merged the second override into it. -
36. Re: Unifying metadata
starksm64 Sep 20, 2007 6:22 PM (in response to starksm64)A bigger problem is lack of support for dom Elements as is needed for the standardjboss.xml proxy-factory-config elements. The content of these depends on the invoker type:
<proxy-factory-config> <client-interceptors> <home> <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor> <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor> <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor> </home> <bean> <interceptor>org.jboss.proxy.ejb.EntityInterceptor</interceptor> <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor> <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor> </bean> <list-entity> <interceptor>org.jboss.proxy.ejb.ListEntityInterceptor</interceptor> <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor> <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor> </list-entity> </client-interceptors> </proxy-factory-config> ... <proxy-factory-config> <JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI> <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI> <CreateJBossMQDestination>false</CreateJBossMQDestination> <!-- WARN: Don't set this to zero until a bug in the pooled executor is fixed --> <MinimumSize>1</MinimumSize> <MaximumSize>15</MaximumSize> <KeepAliveMillis>30000</KeepAliveMillis> <MaxMessages>1</MaxMessages> <MDBConfig> <ReconnectIntervalSec>10</ReconnectIntervalSec> <DLQConfig> <DestinationQueue>queue/DLQ</DestinationQueue> <MaxTimesRedelivered>10</MaxTimesRedelivered> <TimeToLive>0</TimeToLive> </DLQConfig> </MDBConfig> </proxy-factory-config>
-
37. Re: Unifying metadata
starksm64 Sep 20, 2007 7:22 PM (in response to starksm64)I raised this http://jira.jboss.com/jira/browse/JBXB-109 issue which has a failing test.
-
38. Re: Unifying metadata
wolfc Sep 21, 2007 4:08 AM (in response to starksm64)I don't like all the merge logic in the binding classes. Can't we have a separate class hierarchy for that?
Then it would become: new MergedJBossMetaData(ejbJarMetaData, jbossMetaData);
And standardjboss.xml: new MergedJBossMetaData(standardJbossMetaData, new MergedJBossMetaData(ejbJarMetaData, jbossMetaData));
(it still needs some polishing)
And no more the need to ask for merged beans or stuff. -
39. Re: Unifying metadata
adrian.brock Sep 21, 2007 7:59 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
The root org.jboss.ejb.metadata.jboss.JBossMetaData would have to add a mergeOverridenMetaData method that took the existing override and merged the second override into it.
Why do you need to merge standardjboss.xml?
standardjboss.xml should just be parsed once into a JBossMetaData
and then it should just be a case of delegating.
If you merge standardjboss.xml into the JBossMetaData then you'll loose the
reversability. Let's not make the same mistakes as the old metadata did! -
40. Re: Unifying metadata
adrian.brock Sep 21, 2007 8:02 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
A bigger problem is lack of support for dom Elements as is needed for the standardjboss.xml proxy-factory-config elements. The content of these depends on the invoker type:
This works in the MC stuff, so its obviously not defined correctly in the annotations
for the ejb stuff.
It shouldn't be trying to construct a javabean for an array of xml Elements.
It shouldn't even be going through the base jbossxb bean code.
There are seperate interceptors/handlers that understand xml wildcards
(and their collections) in the builder project. -
41. Re: Unifying metadata
adrian.brock Sep 21, 2007 8:05 AM (in response to starksm64)"wolfc" wrote:
I don't like all the merge logic in the binding classes. Can't we have a separate class hierarchy for that?
Then it would become: new MergedJBossMetaData(ejbJarMetaData, jbossMetaData);
And standardjboss.xml: new MergedJBossMetaData(standardJbossMetaData, new MergedJBossMetaData(ejbJarMetaData, jbossMetaData));
(it still needs some polishing)
And no more the need to ask for merged beans or stuff.
That's ok as long as you can get back to the original metadata.
If you can't ask for the original ejb-jar and jboss metadata and marshal them
back to the original xml then its no good. -
42. Re: Unifying metadata
adrian.brock Sep 21, 2007 9:34 AM (in response to starksm64)"adrian@jboss.org" wrote:
This works in the MC stuff, so its obviously not defined correctly in the annotations
for the ejb stuff.
This is how you define it genericallypublic class ListElementWildcard { private List<Element> wildcard; public List<Element> getWildcard() { return wildcard; } @XmlAnyElement(lax=true) public void setWildcard(List<Element> wildcard) { this.wildcard = wildcard; }
You can also make it recognise specific types, e.g. we could define
the known JMSContainerInvoker config, etc. by adding @XmlElements
and specific types but then you need to makeList<Object>
if you also want it to have raw Elements as well as real types.
The real problem is that it just isn't implemented
(at least in the version in the JBossXB project)@XmlType(name="invoker-proxy-bindingType") public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions { ... /** The proxy factory config */ // TODO DOM private Element proxyFactoryConfig;
-
43. Re: Unifying metadata
starksm64 Sep 21, 2007 10:24 AM (in response to starksm64)"adrian@jboss.org" wrote:
Why do you need to merge standardjboss.xml?
standardjboss.xml should just be parsed once into a JBossMetaData
and then it should just be a case of delegating.
If you merge standardjboss.xml into the JBossMetaData then you'll loose the
reversability. Let's not make the same mistakes as the old metadata did!
Ok, I'll look at that approach. -
44. Re: Unifying metadata
starksm64 Sep 21, 2007 10:32 AM (in response to starksm64)"adrian@jboss.org" wrote:
This is how you define it genericallypublic class ListElementWildcard { private List<Element> wildcard; public List<Element> getWildcard() { return wildcard; } @XmlAnyElement(lax=true) public void setWildcard(List<Element> wildcard) { this.wildcard = wildcard; }
You can also make it recognise specific types, e.g. we could define
the known JMSContainerInvoker config, etc. by adding @XmlElements
and specific types but then you need to makeList<Object>
if you also want it to have raw Elements as well as real types.
The real problem is that it just isn't implemented
(at least in the version in the JBossXB project)@XmlType(name="invoker-proxy-bindingType") public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions { ... /** The proxy factory config */ // TODO DOM private Element proxyFactoryConfig;
I had unquoted this section in the merged jbossxb project, and that is what produced the errors seen in the JBXB-109 issue. Even if I change this to:@XmlType(name="invoker-proxy-bindingType") public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions { /** The proxy factory config */ private List<Element> proxyFactoryConfig; ... public List<Element> getProxyFactoryConfig() { return proxyFactoryConfig; } @XmlAnyElement(lax=true) public void setProxyFactoryConfig(List<Element> proxyFactoryConfig) { this.proxyFactoryConfig = proxyFactoryConfig; } }
I'm seeing the same error, which is happening on an xml fragment that does not even have the proxy-factory-config element:
Caused by: java.lang.ClassCastException: java.util.ArrayList
at org.jboss.javaee.metadata.support.MappedAnnotationMetaData.add(MappedAnnotationMetaData.java:39)
at org.jboss.xb.builder.runtime.CollectionPropertyHandler.handle(CollectionPropertyHandler.java:133)
... 40 more
If you or Alexey can look into the JBXB-109 issue it would help.