-
1. Re: Beta3 blocking issues
starksm64 Sep 21, 2007 12:56 PM (in response to starksm64)Note that the DataSource deployment template stuff needed to get the ProfileServiceUnitTestCase running (could be part of http://jira.jboss.com/jira/browse/JBAS-3415, Port RARDeployer) is something Weston is working.
-
2. Re: Beta3 blocking issues
ccrouch Sep 21, 2007 1:55 PM (in response to starksm64)So comparing your list will all the Beta3 critical/blockers in jira:
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=12311212&pid=10030&resolution=-1&priority=1&priority=2&sorter/field=priority&sorter/order=DESC
You don't have in your list:
http://jira.jboss.com/jira/browse/JBAS-4687 Use a tagged release for the new jboss-ejb3-cache module
http://jira.jboss.com/jira/browse/JBAS-4660 Fix jboss-head-testsuite-sun-1.5 regression when the testsuite runs under hudson
I guess if these shouldn't be in the release we should drop them from being critical.
What about the other subtasks and dependencies of
http://jira.jboss.com/jira/browse/JBAS-4562 Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3,
which are currently only marked as major, i.e.
http://jira.jboss.com/jira/browse/JBAS-4689 Upgrade JBoss messaging to 1.4.0.GA
http://jira.jboss.com/jira/browse/JBAS-4716 Update common-core to 2.2.2.GA
Should these be upped to being critical?
Thanks -
3. Re: Beta3 blocking issues
starksm64 Sep 21, 2007 2:55 PM (in response to starksm64)All the JBAS-4562 subtasks need to be done in terms of non-snapshot releases. Carlo is trying to do JBAS-4687 as we speak.
messaging to 1.4.0.GA and common-core to 2.2.2.GA don't change the apis, so I don't see these as critical.
Dimitris, what is the JBAS-4660 issue? -
4. Re: Beta3 blocking issues
alesj Sep 22, 2007 5:14 AM (in response to starksm64)I'm done with moving MC's IoC annotations:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=118700
We've to make sure people are aware that this will break their existing MC annotated beans.
And just before we include this new MC beta5 into AS trunk, let me know, and I'll fix all the MC annotation usage in the AS trunk.
But I take no responsibility for other projects, after all this was Adrian's cosmetic 'wish'. :-) -
5. Re: Beta3 blocking issues
dimitris Sep 23, 2007 4:06 AM (in response to starksm64)JBAS-4660 is about the testsuite not doing well when the server is bound to an IP address, other than localhost.
Rajesh has created a testsuite run that doesn't bind to a non-localhost ip, so the issue is not exactly critical.
http://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15-noip/
In Branch_4_2, I think we have fixed this, but we have also changed jboss to bind to localhost by default, and we should probably do the same for trunk. -
6. Re: Beta3 blocking issues
aloubyansky Sep 24, 2007 1:12 PM (in response to starksm64)JBXB-109 Element type causes parse error
I added a hack to make it work. I.e. I added a wildcard property to the InvokerProxyBinfingMetaData and made the proxy-factory-config parsed as an unresolved content of the wildcard. I hope you can proceed further now. I left the issue open and will be working on a proper fix. -
7. Re: Beta3 blocking issues
starksm64 Sep 24, 2007 3:27 PM (in response to starksm64)What is the hack that allows the
public Element getWildcard() { return getProxyFactoryConfig(); } /** * This is a hack to make proxy-factory-config parsed as * unresolved element of a wildcard */ @XmlAnyElement(lax=true) public void setWildcard(Element e) { setProxyFactoryConfig(e); }
but not the previouspublic Element getProxyFactoryConfig() { return proxyFactoryConfig; } @XmlAnyElement(lax=true) public void setProxyFactoryConfig(Element proxyFactoryConfig) { this.proxyFactoryConfig = proxyFactoryConfig; }
You have a hard-coded callback for the wildcard element contents? -
8. Re: Beta3 blocking issues
aloubyansky Sep 24, 2007 4:10 PM (in response to starksm64)If you mean hard-coded property name then no.
The way it works currently is only unresolved elements are unmarshalled into DOM elements. Each property is bound to an element. So this element is not going to be unresolved. That's why I didn't bind the proxyFactoryConfig property at all. So, the proxy-factory-config element is going to be unresolved and added as a value of the wildcard property. -
9. Re: Beta3 blocking issues
starksm64 Sep 26, 2007 6:17 AM (in response to starksm64)Ok, but replace the wildcard property with proxyFactoryConfig and I don't see the difference in the binding configuration. How does it know to call setWildcard for the unresolved element(s)?
-
10. Re: Beta3 blocking issues
aloubyansky Sep 26, 2007 8:58 AM (in response to starksm64)Because it's annotated with the XmlAnyElement. It's a catch-all property. Explained here http://java.sun.com/javaee/5/docs/api/javax/xml/bind/annotation/XmlAnyElement.html#annotation_type_element_detail
I already have a fix for having just the proxyFactoryConfig property. Not committed yet. I think it makes sense to bind any property of type DOM Element to wildcard even if it's not explicitly bound to it.