jaxp-api exclusion from parent/pom.xml
Hi there, cxf includes the jaxp-ri as a dependency when needed in a couple of places (only when running with the ibm jdk), but I notice that in the parent/pom.xml, jaxp-api is specifically excluded: com.sun.xml.parsers jaxp-ri 1.4.2 javax.xml.parsers jaxp-api Is there a good reason to exclude it? I'm seeing some test failures in common/common when using the ibm jdk (StaxUtilsTest, W3CDOMStreamReaderTest, and XMLUtilsTest). They hit a NoClassDefFoundError for javax.xml.transform.stax.StAXResult. If I don't exclude the jaxp-api, the tests run fine, and thus why I am wondering if there is a good reason... Regards, Peter -------- Peter Jones Progress Software 570 Newfoundland Drive St. John's, NL, Canada A1A 5B1 Tel: +1 (709) 738-3725 ext 321 Internal wiki: http://wiki.progress.com/display/PRODENG/Home
RE: jaxp-api exclusion from parent/pom.xml
Hi Dan, Yeah that does kind of suck. I'll remove the exclusion from the dependency. Regards, Peter Peter Jones Progress Software 570 Newfoundland Drive St. John's, NL, Canada A1A 5B1 Tel: +1 (709) 738-3725 ext 321 Internal wiki: http://wiki.progress.com/display/PRODENG/Home -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: Thu 7/16/2009 3:04 PM To: dev@cxf.apache.org Cc: Peter Jones Subject: Re: jaxp-api exclusion from parent/pom.xml Well, ideally all of the stuff in jaxp-api are part of the JDK or pulled from stax-api.It looks like there are two classes (StAXResult and StAXSource) that aren't in either unless running on IBM Java 6. That kind of sucks. I guess that exclusion should be removed. Dan On Wed July 15 2009 5:58:05 pm Peter Jones wrote: > Hi there, > > cxf includes the jaxp-ri as a dependency when needed in a couple of > places (only when running with the ibm jdk), but I notice that in > the parent/pom.xml, jaxp-api is specifically excluded: > > > com.sun.xml.parsers > jaxp-ri > 1.4.2 > > > javax.xml.parsers > jaxp-api > > > > > Is there a good reason to exclude it? I'm seeing some test > failures in common/common when using the ibm jdk > (StaxUtilsTest, W3CDOMStreamReaderTest, and XMLUtilsTest). They > hit a NoClassDefFoundError for javax.xml.transform.stax.StAXResult. > If I don't exclude the jaxp-api, the tests run fine, and thus why > I am wondering if there is a good reason... > > Regards, > Peter > > > Peter Jones > Progress Software > 570 Newfoundland Drive > St. John's, NL, Canada A1A 5B1 > Tel: +1 (709) 738-3725 ext 321 > > Internal wiki: http://wiki.progress.com/display/PRODENG/Home -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
JMSConduitTest failure with ibm jdk
Hi there, I'm seeing the JMSConduitTest.testJMSMessageMarshal() fail regularly when run with the ibm jdk 5. It seems that for some reason the JMSConduit is finalized in the midst of the jmsTemplate.execute() call in that test. This closes the connection and the test gets an error like this: "org.springframework.jms.IllegalStateException: The connection is already closed;" Adding an assertNotNull(conduit) after the jmsTemplate.execute() call prevents the JMSConduit from being finalized before the test method completes, and so makes the test pass every time. But, it seems odd to me since the conduit really should still be in scope while jmsTemplate.execute() is called. Just wondering if anyone had any thoughts on that. Anyway, I'll commit that work-around for the ibm jdk as long as there are no moral objections. Regards, Peter ---- Peter Jones Progress Software 570 Newfoundland Drive St. John's, NL, Canada A1A 5B1 Tel: +1 (709) 738-3725 ext 321 Internal wiki: http://wiki.progress.com/display/PRODENG/Home
RE: JMSConduitTest failure with ibm jdk
Hi Christian, For sure, will do. Cheers, Peter Peter Jones Progress Software 570 Newfoundland Drive St. John's, NL, Canada A1A 5B1 Tel: +1 (709) 738-3725 ext 321 Internal wiki: http://wiki.progress.com/display/PRODENG/Home -Original Message- From: Christian Schneider [mailto:ch...@die-schneider.net] Sent: Fri 9/11/2009 6:20 PM To: dev@cxf.apache.org Subject: Re: JMSConduitTest failure with ibm jdk Hi Peter, that is really strange. I also have no idea why the conduit is finalized. You should write a good comment in front of the assert to avoid that someone will later remove it again because he thinks it is unnecessary. Greetings Christian Peter Jones schrieb: > Hi there, > > I'm seeing the JMSConduitTest.testJMSMessageMarshal() fail > regularly when run with the ibm jdk 5. It seems that for > some reason the JMSConduit is finalized in the midst of the > jmsTemplate.execute() call in that test. This closes the > connection and the test gets an error like this: > > "org.springframework.jms.IllegalStateException: The connection is already > closed;" > > Adding an assertNotNull(conduit) after the > jmsTemplate.execute() call prevents the JMSConduit from > being finalized before the test method completes, and so > makes the test pass every time. But, it seems odd to me > since the conduit really should still be in scope while > jmsTemplate.execute() is called. Just wondering if anyone > had any thoughts on that. > > Anyway, I'll commit that work-around for the ibm jdk as > long as there are no moral objections. > > Regards, > Peter > > > Peter Jones > Progress Software > 570 Newfoundland Drive > St. John's, NL, Canada A1A 5B1 > Tel: +1 (709) 738-3725 ext 321 > > Internal wiki: http://wiki.progress.com/display/PRODENG/Home > > > >
Re: System tests failing with AbstractMethodError on DeferredDocumentImpl.getInputEncoding()
xf.endpoint.ClientLifeCycleManager,org.apache.cxf.transports.http.QueryHandlerRegistry,org.apache.cxf.endpoint.EndpointResolverRegistry,org.apache.cxf.headers.HeaderManager,org.apache.cxf.catalog.OASISCatalogManager,org.apache.cxf.endpoint.ServiceContractResolverRegistry,org.apache.cxf.binding.corba.CorbaBindingFactory,org.apache.cxf.jaxws.context.WebServiceContextResourceResolver,org.apache.cxf.jaxw > s.context.WebServiceContextImpl,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.binding.xml.XMLBindingFactory,org.apache.cxf.ws.addressing.policy.AddressingAssertionBuilder,org.apache.cxf.ws.addressing.policy.AddressingPolicyInterceptorProvider,org.apache.cxf.ws.addressing.policy.UsingAddressingAssertionBuilder,org.apache.cxf.management.jmx.InstrumentationManagerImpl,org.apache.cxf.binding.jbi.JBIBindingFactory,org.apache.cxf.transport.jbi.JBITransportFactory,org.apache.cxf.binding.http.HttpBindingFactory,org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder,org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder,org.apache.cxf.transport.http.ClientOnlyHTTPTransportFactory,org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory,org.apache.cxf.transport.local.LocalTransportFactory,org.apache.cxf.transport.jms.JMSTransportFactory,org.apache.c > xf.ws.rm.RMManager,org.apache.cxf.ws.rm.policy.RMPolicyInterceptorProvider,org.apache.cxf.ws.rm.RMAssertionBuilder,org.apache.cxf.ws.policy.AssertionBuilderRegistry,org.apache.cxf.ws.policy.PolicyConstants,org.apache.cxf.ws.policy.PolicyInterceptorProviderRegistry,org.apache.cxf.ws.policy.attachment.external.DomainExpressionBuilderRegistry,org.apache.cxf.ws.policy.attachment.external.EndpointReferenceDomainExpressionBuilder,org.apache.cxf.ws.policy.PolicyBuilder,org.apache.cxf.ws.policy.PolicyEngine,org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider,org.apache.cxf.ws.policy.attachment.ServiceModelPolicyProvider,org.apache.cxf.ws.policy.mtom.MTOMAssertionBuilder,org.apache.cxf.ws.policy.mtom.MTOMPolicyInterceptorProvider,org.apache.cxf.jaxrs.JAXRSBindingFactory]; > > root of factory hierarchy > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] > org.apache.xerces.dom.DeferredDocumentImpl.getInputEncoding()Ljava/lang/String; > > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 47 seconds > [INFO] Finished at: Fri May 23 16:34:23 EDT 2008 > [INFO] Final Memory: 31M/56M > [INFO] > > > > > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- Peter Jones IONA Technologies E-Mail: mailto:[EMAIL PROTECTED] Tel: 709-738-3725 x321 | Fax: 709-738-3745 570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
Re: [VOTE] Release CXF 2.0.7
+1 Cheers, Peter On Tue, Jun 17, 2008 at 10:44:28AM -0400, Daniel Kulp wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > This is a vote to release CXF 2.0.7 > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.0.7 release. Over 48 JIRA issues are > resolved for 2.0.7 which is a large number of fixes for the 2.0.x > branch. > > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.0.7 > > The distributions are in the "dist" directory. The "maven" directory > contains the stuff that will by pushed to the central repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.7 > > > Here is my +1. The vote will be open here for at least 72 hours. > > > - --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.4 (Darwin) > > iD8DBQFIV83Qq8juObtVB0YRAk9IAJ94zSGaE98mw4z2UOdcCeX8HzAntACfb4Zv > Px3oDUHzRTC53LDAs2yxIz8= > =fif0 > -END PGP SIGNATURE- -- Peter Jones IONA Technologies E-Mail: mailto:[EMAIL PROTECTED] Tel: 709-738-3725 x321 | Fax: 709-738-3745 570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
unrecognized parameter -Xdv
Hi there,
When building the cxf-2.1.1 source distribution, or trunk for that matter,
with a clean local maven repo, from the top level directory, I see an error
like this when it reaches testutils:
[...]
[INFO] [cxf-codegen:wsdl2java {execution: generate-sources}]
[INFO] [cxf-common-xsd:xsdtojava {execution: generate-sources}]
unrecognized parameter -Xdv
Usage: xjc [-options ...] ... [-b ] ...
If dir is specified, all schema files in it will be compiled.
If jar is specified, /META-INF/sun-jaxb.episode binding file will be
compiled.
Options:
[...]
org.apache.tools.ant.ExitException: ExitException: status -1
at
org.apache.tools.ant.util.optional.NoExitSecurityManager.checkExit(NoExitSecurityManager.java:38)
at java.lang.Runtime.exit(Runtime.java:88)
at java.lang.System.exit(System.java:869)
at com.sun.tools.xjc.Driver._main(Driver.java:126)
at com.sun.tools.xjc.Driver.access$000(Driver.java:74)
at com.sun.tools.xjc.Driver$1.run(Driver.java:96)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] ExitException: status -1
If I build inside the testutils directory, there's no problem. So it only
happens from the top level directory. Has anyone else seen this?
Using java 1.5.0_12 and I've tried with maven 2.0.7 and 2.0.9.
Cheers,
Peter
--
Peter Jones
IONA Technologies
E-Mail: mailto:[EMAIL PROTECTED]
Tel: 709-738-3725 x321 | Fax: 709-738-3745
570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
Re: [VOTE] Release CXF 2.0.8
+1 Cheers, Peter On Tue, Jul 22, 2008 at 09:36:48PM -0400, Daniel Kulp wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > This is a vote to release CXF 2.0.8 > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.0.8 release. Over 28 JIRA issues > are resolved for 2.0.8. Most importantly, this contains a critical > fix that was preventing Geronimo from being able to upgrade to our > recent releases. They need this so they can release Geronimo 2.1.2 > which they would like to do next week. > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313269&styleName=Html&projectId=12310511&Create=Create > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.0.8 > > The distributions are in the "dist" directory. The "maven" directory > contains the stuff that will by pushed to the central repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.8 > > > Here is my +1. The vote will be open here for at least 72 hours. > > - --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.4 (Darwin) > > iD8DBQFIhos1q8juObtVB0YRAu+GAJ9wlLmUL603COMNIv52xwvB2+XMgACaA8K2 > 0OImzd5F9+EtcKeWx+Rf7i0= > =kqY9 > -END PGP SIGNATURE- -- Peter Jones IONA Technologies E-Mail: mailto:[EMAIL PROTECTED] Tel: 709-738-3725 x321 | Fax: 709-738-3745 570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
Re: mvn -Pfastinstall failure with current trunk
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -------- > [INFO] Total time: 21 seconds > [INFO] Finished at: Wed Aug 13 20:42:26 EDT 2008 > [INFO] Final Memory: 36M/64M > [INFO] > > puck% -- Peter Jones IONA Technologies E-Mail: mailto:[EMAIL PROTECTED] Tel: 709-738-3725 x321 | Fax: 709-738-3745 570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
Re: [VOTE] Christian Schneider for committer
+1 Cheers, Peter On Fri, Sep 19, 2008 at 09:28:30AM -0400, Daniel Kulp wrote: > > Christian has been doing quite a bit of very good work doing an almost > "ground > up" re-write of the JMS transport which is a very challenging and complicated > task. > > He's done quite a bit of work documenting various JMS things on the Wiki and > even wrote an article about how to integrate the Camel transport into CXF. > > He's also been very good about talking about his ideas on the dev list, > responding to user queries about the areas he's familiar with, etc... > > Basically, I think he's already been a valuable asset to the project and has > earned a spot as a committer. > > [ ] +1 > [ ] -1 > > Vote will remain open for at least 72 hours. > > -- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog -- Peter Jones IONA Technologies E-Mail: mailto:[EMAIL PROTECTED] Tel: 709-738-3725 x321 | Fax: 709-738-3745 570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
aegis JaxbTypeTest
Hi there,
Think there's a small discrepancy in the rt/databinding/aegis JaxbTypeTest.
Note the type which is checked for when the element QName is
"elementProperty" in the two checks below:
AnnotatedTypeInfo info = new AnnotatedTypeInfo(tm, JaxbBean1.class,
"urn:foo", new TypeCreationOptions());
...
QName element = (QName)elements.next();
...
Type custom = info.getType(element);
if ("bogusProperty".equals(element.getLocalPart())) {
assertTrue(custom instanceof StringType);
} else if ("elementProperty".equals(element.getLocalPart())) {
assertTrue(custom instanceof CustomStringType);
} else {
fail("Unexpected element name: " + element.getLocalPart());
}
element = (QName)elements.next();
...
custom = info.getType(element);
if ("bogusProperty".equals(element.getLocalPart())) {
assertTrue(custom instanceof StringType);
} else if ("elementProperty".equals(element.getLocalPart())) {
assertTrue(custom instanceof StringType);
} else {
fail("Unexpected element name: " + element.getLocalPart());
}
If the "elementProperty" is the first QName, we check that the type is an
instance of CustomStringType, but if its the second Qname we check that
its an instance of StringType.
This is the annotation in the JaxbBean1 class:
@XmlElement(type = CustomStringType.class)
public String getElementProperty() {
Would that suggest the type should be a CustomStringType? In the test, it's
always a StringType.
The test passes with the sun jdk as "elementProperty" is always the second
QName returned, but if you run this test with the ibm jdk, it fails since
"elementProperty" is the first QName returned.
If the test is wrong and it should check for StringType both times, fair
enough, otherwise, I can file a jira. Let me know if you have any thoughts.
Cheers,
Peter
--
Peter Jones
Progress Software
E-Mail: mailto:[EMAIL PROTECTED]
Tel: 709-738-3725 x321 | Fax: 709-738-3745
570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
Re: aegis JaxbTypeTest
Hi Benson,
Thanks for checking this out. Just to clarify, do you think the test
should be checking that its an instance of StringType in both places, or do
you think the wrong type is being returned (i.e. it should be a
CustomStringType in both cases)?
Cheers,
Peter
On Wed, Oct 01, 2008 at 05:57:55PM -0400, Benson Margulies wrote:
> I think I agree with you. I'm in no position to test with the IBM JDK. Could
> you tack a patch onto a JIRA and I'll apply it.
>
> On Mon, Sep 29, 2008 at 7:47 AM, Benson Margulies <[EMAIL PROTECTED]>wrote:
>
> > It may take me a day or two to get to this, but I will.
> >
> >
> > On Sun, Sep 28, 2008 at 10:52 PM, Peter Jones <[EMAIL PROTECTED]>wrote:
> >
> >>
> >> Hi there,
> >>
> >> Think there's a small discrepancy in the rt/databinding/aegis
> >> JaxbTypeTest.
> >> Note the type which is checked for when the element QName is
> >> "elementProperty" in the two checks below:
> >>
> >>AnnotatedTypeInfo info = new AnnotatedTypeInfo(tm, JaxbBean1.class,
> >>"urn:foo", new TypeCreationOptions());
> >>...
> >>QName element = (QName)elements.next();
> >>...
> >>Type custom = info.getType(element);
> >>if ("bogusProperty".equals(element.getLocalPart())) {
> >>assertTrue(custom instanceof StringType);
> >>} else if ("elementProperty".equals(element.getLocalPart())) {
> >>assertTrue(custom instanceof CustomStringType);
> >>} else {
> >>fail("Unexpected element name: " + element.getLocalPart());
> >>}
> >>element = (QName)elements.next();
> >>...
> >>custom = info.getType(element);
> >>if ("bogusProperty".equals(element.getLocalPart())) {
> >>assertTrue(custom instanceof StringType);
> >>} else if ("elementProperty".equals(element.getLocalPart())) {
> >>assertTrue(custom instanceof StringType);
> >>} else {
> >>fail("Unexpected element name: " + element.getLocalPart());
> >>}
> >>
> >> If the "elementProperty" is the first QName, we check that the type is an
> >> instance of CustomStringType, but if its the second Qname we check that
> >> its an instance of StringType.
> >>
> >> This is the annotation in the JaxbBean1 class:
> >>
> >>@XmlElement(type = CustomStringType.class)
> >>public String getElementProperty() {
> >>
> >> Would that suggest the type should be a CustomStringType? In the test,
> >> it's
> >> always a StringType.
> >>
> >> The test passes with the sun jdk as "elementProperty" is always the second
> >> QName returned, but if you run this test with the ibm jdk, it fails since
> >> "elementProperty" is the first QName returned.
> >>
> >> If the test is wrong and it should check for StringType both times, fair
> >> enough, otherwise, I can file a jira. Let me know if you have any
> >> thoughts.
> >>
> >> Cheers,
> >> Peter
--
Peter Jones
Progress Software
E-Mail: mailto:[EMAIL PROTECTED]
Tel: 709-738-3725 x321 | Fax: 709-738-3745
570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
Re: aegis JaxbTypeTest
Hi Benson,
I attached a patch to CXF-1840 which fixes the issue using the sun and ibm
jdks. Could you review my change and let me know if you think that fix is
appropriate?
Cheers,
Peter
On Thu, Oct 02, 2008 at 10:23:55AM -0400, Benson Margulies wrote:
> The annotation seems to me to call for the custom type both times.
>
> On Thu, Oct 2, 2008 at 9:16 AM, Peter Jones <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi Benson,
> >
> > Thanks for checking this out. Just to clarify, do you think the test
> > should be checking that its an instance of StringType in both places, or do
> > you think the wrong type is being returned (i.e. it should be a
> > CustomStringType in both cases)?
> >
> > Cheers,
> > Peter
> >
> > On Wed, Oct 01, 2008 at 05:57:55PM -0400, Benson Margulies wrote:
> > > I think I agree with you. I'm in no position to test with the IBM JDK.
> > Could
> > > you tack a patch onto a JIRA and I'll apply it.
> > >
> > > On Mon, Sep 29, 2008 at 7:47 AM, Benson Margulies <[EMAIL PROTECTED]
> > >wrote:
> > >
> > > > It may take me a day or two to get to this, but I will.
> > > >
> > > >
> > > > On Sun, Sep 28, 2008 at 10:52 PM, Peter Jones <[EMAIL PROTECTED]
> > >wrote:
> > > >
> > > >>
> > > >> Hi there,
> > > >>
> > > >> Think there's a small discrepancy in the rt/databinding/aegis
> > > >> JaxbTypeTest.
> > > >> Note the type which is checked for when the element QName is
> > > >> "elementProperty" in the two checks below:
> > > >>
> > > >>AnnotatedTypeInfo info = new AnnotatedTypeInfo(tm, JaxbBean1.class,
> > > >>"urn:foo", new TypeCreationOptions());
> > > >>...
> > > >>QName element = (QName)elements.next();
> > > >>...
> > > >>Type custom = info.getType(element);
> > > >>if ("bogusProperty".equals(element.getLocalPart())) {
> > > >>assertTrue(custom instanceof StringType);
> > > >>} else if ("elementProperty".equals(element.getLocalPart())) {
> > > >>assertTrue(custom instanceof CustomStringType);
> > > >>} else {
> > > >>fail("Unexpected element name: " + element.getLocalPart());
> > > >>}
> > > >>element = (QName)elements.next();
> > > >>...
> > > >>custom = info.getType(element);
> > > >>if ("bogusProperty".equals(element.getLocalPart())) {
> > > >>assertTrue(custom instanceof StringType);
> > > >>} else if ("elementProperty".equals(element.getLocalPart())) {
> > > >>assertTrue(custom instanceof StringType);
> > > >>} else {
> > > >>fail("Unexpected element name: " + element.getLocalPart());
> > > >>}
> > > >>
> > > >> If the "elementProperty" is the first QName, we check that the type is
> > an
> > > >> instance of CustomStringType, but if its the second Qname we check
> > that
> > > >> its an instance of StringType.
> > > >>
> > > >> This is the annotation in the JaxbBean1 class:
> > > >>
> > > >>@XmlElement(type = CustomStringType.class)
> > > >>public String getElementProperty() {
> > > >>
> > > >> Would that suggest the type should be a CustomStringType? In the
> > test,
> > > >> it's
> > > >> always a StringType.
> > > >>
> > > >> The test passes with the sun jdk as "elementProperty" is always the
> > second
> > > >> QName returned, but if you run this test with the ibm jdk, it fails
> > since
> > > >> "elementProperty" is the first QName returned.
> > > >>
> > > >> If the test is wrong and it should check for StringType both times,
> > fair
> > > >> enough, otherwise, I can file a jira. Let me know if you have any
> > > >> thoughts.
> > > >>
> > > >> Cheers,
> > > >> Peter
--
Peter Jones
Progress Software
E-Mail: mailto:[EMAIL PROTECTED]
Tel: 709-738-3725 x321 | Fax: 709-738-3745
570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
