TRUNK CODE FREEZE!
by Jason T. Greene
We need to release CR2 tonight. So I am declaring trunk a code freeze.
So, no new features, only regression fixes please.
Thanks,
-Jason
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Jason T. Greene
Senior Software Engineer
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 6 months
RE: [jbossws-dev] jaxb fault marshalling is done
by Jason T. Greene
Good work Alejandro. It's just in time for the JBoss 5 beta release.
I reopened the issue though since there is still a dependency on
accessors. I can take care of that. So don't worry about it.
-Jason
> -----Original Message-----
> From: jbossws-dev-bounces(a)lists.jboss.org [mailto:jbossws-dev-
> bounces(a)lists.jboss.org] On Behalf Of Alejandro Guizar
> Sent: Friday, November 17, 2006 11:00 AM
> To: jbossws-dev(a)lists.jboss.org
> Subject: [jbossws-dev] jaxb fault marshalling is done
>
> It took a while to learn and then capture all the details in the
> specification, but jaxb fault marshalling is resolved now. All tests
> that were previously disabled with a "FIXME: JBWS-1297" are active and
> working.
>
> As of revision 1455, twelve tests are failing. They seem unrelated to
> this issue, tough:
>
> org.jboss.test.ws
> + jaxrpc
> + enventry.EnvEntryJSETestCase
> - testHandlers
> + jaxws
> + binding.SOAPBindingTestCase
> - testClientAccess
> + context.WebServiceContextTestCase
> - testWSDLAccess
> - testClientAccess
> + jbws944.JBWS944TestCase
> - testRemoteAccess
> + jsr181.webservice.JSR181WebServiceEJB3TestCase
> - testRemoteAccess
> + samples.jsr181ejb.JSR181WebServiceEJB3TestCase
> - testRemoteAccess
> + samples.retail.RetailSampleTestCase
> - testWebService
> + samples.wsaddressing.AddressingStatefulTestCase
> - testAddItem
> - testGetItems
> - testCheckout
> + webserviceref.WebServiceRefEJB3TestCase
> - testEJB3Client
>
> -Alejandro
>
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev
17 years, 6 months
RE: [jbossws-dev] JSR181 Changes added in async changes
by Jason T. Greene
> -----Original Message-----
> From: jbossws-dev-bounces(a)lists.jboss.org [mailto:jbossws-dev-
> bounces(a)lists.jboss.org] On Behalf Of Jason T. Greene
> Sent: Friday, November 17, 2006 7:59 AM
> To: Thomas Diesler
> Cc: jbossws-dev(a)lists.jboss.org
> Subject: RE: [jbossws-dev] JSR181 Changes added in async changes
>
> > From: Thomas Diesler [mailto:thomas.diesler@redhat.com]
> > Sent: Friday, November 17, 2006 7:44 AM
> > To: Jason T. Greene
> > Cc: Heiko Braun; jbossws-dev(a)lists.jboss.org
> > Subject: Re: [jbossws-dev] JSR181 Changes added in async changes
> >
>
-snip-
>
> >>
> >>The spec requires you to specify endpointInterface using a string!
So
> a
> >>simple refactor moving the interface would break the WS deployment.
>
> > @WebService (endpointInterface = MySEI.class.getName())
>
> Yes although in that case the spec should have defined the value as a
> Class instead of a string (just like @Remote).
Actually, this won't work at all, annotation values must be a constant
expression.
-Jason
17 years, 6 months
RE: [jbossws-dev] JSR181 Changes added in async changes
by Jason T. Greene
> From: Thomas Diesler [mailto:thomas.diesler@redhat.com]
> Sent: Friday, November 17, 2006 7:44 AM
> To: Jason T. Greene
> Cc: Heiko Braun; jbossws-dev(a)lists.jboss.org
> Subject: Re: [jbossws-dev] JSR181 Changes added in async changes
>
-snip-
>>
>>The spec requires you to specify endpointInterface using a string! So
a
>>simple refactor moving the interface would break the WS deployment.
> @WebService (endpointInterface = MySEI.class.getName())
Yes although in that case the spec should have defined the value as a
Class instead of a string (just like @Remote).
>>Also, it's normal java practice to actually implement the interface.
So
>>the information for which interface to use is right there, in the
>>implements line. Further, if someone doesn't specify endpointInterface
>>by accident, and yet they do implement the endpointInterface, then it
>>will be ignored but the deployment will still work (since the bean
class
>>is used). However, this will be confusing to the user, because they
will
>>potentially get different output since all of the specialized
>>annotations are on the interface.
> The deployment should fail because there is no @WebMethod on the bean
Actually, according to the spec the lack of @WebMethod annotations
result in all methods being added, and all super class methods being
added. This weird behavior lead to @WebMethod(exclude = "true").
-Jason
-----Original Message-----
From: Thomas Diesler [mailto:thomas.diesler@redhat.com]
Sent: Friday, November 17, 2006 2:17 AM
To: Jason T. Greene
Cc: Heiko Braun; jbossws-dev(a)lists.jboss.org
Subject: Re: [jbossws-dev] JSR181 Changes added in async changes
IMO this is fuzzy logic and should be avoided.
There should at least be a comment that states the compelling reason
to
do this guess-work.
Jason T. Greene wrote:
Heiko,
I noticed the following change, which adds some non spec compliant
behavior. I am not against it, but we probably should all discuss
this
further before we decide to do it. Do you have anything right now
that
depends on it?
Also, it breaks the JSR181HandlerTestCase (although I will change
the
test in the mean time)
if (anWebService.endpointInterface().length() > 0)
{
seiName = anWebService.endpointInterface();
seiClass = udi.classLoader.loadClass(seiName);
anWebService =
(WebService)seiClass.getAnnotation(WebService.class);
+
if (anWebService == null)
throw new WSException("Interface does not have a
@WebService annotation: " + seiName);
}
+ else
+ {
+ WebService seiAnnotation = null;
+
+ for(Class potentialSEI : sepClass.getInterfaces())
+ {
+
if(potentialSEI.isAnnotationPresent(WebService.class))
+ {
+ seiClass = potentialSEI;
+ seiName = seiClass.getName();
+ seiAnnotation =
sepClass.getAnnotation(WebService.class);
+ break;
+ }
+ }
+
+ if(seiAnnotation!=null)
+ anWebService = seiAnnotation;
+ }
+
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Jason T. Greene
Senior Software Engineer
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jbossws-dev mailing list
jbossws-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbossws-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 6 months
RE: CR2 release for JBW
by Jason T. Greene
We will have to if want to be compatible with the AS beta release. I
will take a deeper look into the regression. IMO we can just disable
failures for complex regression, and create JIRA issues for CR3. If you
want we can sync up on this tomorrow morning.
-Jason
> -----Original Message-----
> From: Thomas Diesler [mailto:thomas.diesler@redhat.com]
> Sent: Thursday, November 16, 2006 4:57 PM
> To: Jason T. Greene; jbossws-dev(a)lists.jboss.org
> Subject: CR2 release for JBW
>
> Jason,
>
> what are the chances for a CR2 release ready for JBW? Ideally this
would
> be the one we use for JAXWS demos.
> There is however some regression in the jbossws testsuite since we had
> CR1 ten days ago.
>
> cheers
> -thomas
>
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> Web Service Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 6 months
RE: [jbossws-dev] JSR181 Changes added in async changes
by Jason T. Greene
This relates one of the big complaints (which was ignored) I had with
the JAX-WS spec before it was released. (Bill raised it as part of the
Java EE spec and EJB3 specs). The behavior Heiko implemented is actually
inline with the rest of EJB3 (@Remote, @Local).
The current spec behavior for @WebService is clumsy, and error prone.
The spec requires you to specify endpointInterface using a string! So a
simple refactor moving the interface would break the WS deployment.
Also, it's normal java practice to actually implement the interface. So
the information for which interface to use is right there, in the
implements line. Further, if someone doesn't specify endpointInterface
by accident, and yet they do implement the endpointInterface, then it
will be ignored but the deployment will still work (since the bean class
is used). However, this will be confusing to the user, because they will
potentially get different output since all of the specialized
annotations are on the interface.
So even though I agree that this is how it SHOULD have been implemented,
it's just not that way in the spec, so if we add the interface search,
we still have to keep the spec behavior. The combination of the two
creates situations (although odd ones) that would fail on our stack but
work on others.
For example:
@WebService
@HandlerChain(file = "server-handlers.xml")
public class FooImpl implements Foo {}
@WebService
@HandlerChain(file = "client-handlers.xml")
public class Foo
{}
In this peculiar case, we have 2 definitions, the server side, and the
client side. They must be different because they specify different
handlers, thus endpointInterface is not specified. However, to ensure
consistency the server side implements the client side. It can however
be fixed on our stack by removing the implements line.
So the question is it worth it to add this behavior, which would only
work on our stack? Perhaps the better solution is to push it on a
maintenance release of the spec.
-Jason
> -----Original Message-----
> From: Thomas Diesler [mailto:thomas.diesler@redhat.com]
> Sent: Friday, November 17, 2006 2:17 AM
> To: Jason T. Greene
> Cc: Heiko Braun; jbossws-dev(a)lists.jboss.org
> Subject: Re: [jbossws-dev] JSR181 Changes added in async changes
>
>
> IMO this is fuzzy logic and should be avoided.
> There should at least be a comment that states the compelling reason
to
> do this guess-work.
>
> Jason T. Greene wrote:
> > Heiko,
> >
> > I noticed the following change, which adds some non spec compliant
> > behavior. I am not against it, but we probably should all discuss
this
> > further before we decide to do it. Do you have anything right now
that
> > depends on it?
> >
> > Also, it breaks the JSR181HandlerTestCase (although I will change
the
> > test in the mean time)
> >
> > if (anWebService.endpointInterface().length() > 0)
> > {
> > seiName = anWebService.endpointInterface();
> > seiClass = udi.classLoader.loadClass(seiName);
> > anWebService =
> > (WebService)seiClass.getAnnotation(WebService.class);
> > +
> > if (anWebService == null)
> > throw new WSException("Interface does not have a
> > @WebService annotation: " + seiName);
> > }
> > + else
> > + {
> >
> > + WebService seiAnnotation = null;
> > +
> > + for(Class potentialSEI : sepClass.getInterfaces())
> > + {
> > +
if(potentialSEI.isAnnotationPresent(WebService.class))
> > + {
> > + seiClass = potentialSEI;
> > + seiName = seiClass.getName();
> > + seiAnnotation =
> > sepClass.getAnnotation(WebService.class);
> > + break;
> > + }
> > + }
> > +
> > + if(seiAnnotation!=null)
> > + anWebService = seiAnnotation;
> > + }
> > +
> >
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Jason T. Greene
> > Senior Software Engineer
> > JBoss, a division of Red Hat
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> >
> > _______________________________________________
> > jbossws-dev mailing list
> > jbossws-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbossws-dev
> >
>
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> Web Service Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 6 months
JSR181 Changes added in async changes
by Jason T. Greene
Heiko,
I noticed the following change, which adds some non spec compliant
behavior. I am not against it, but we probably should all discuss this
further before we decide to do it. Do you have anything right now that
depends on it?
Also, it breaks the JSR181HandlerTestCase (although I will change the
test in the mean time)
if (anWebService.endpointInterface().length() > 0)
{
seiName = anWebService.endpointInterface();
seiClass = udi.classLoader.loadClass(seiName);
anWebService =
(WebService)seiClass.getAnnotation(WebService.class);
+
if (anWebService == null)
throw new WSException("Interface does not have a
@WebService annotation: " + seiName);
}
+ else
+ {
+ WebService seiAnnotation = null;
+
+ for(Class potentialSEI : sepClass.getInterfaces())
+ {
+ if(potentialSEI.isAnnotationPresent(WebService.class))
+ {
+ seiClass = potentialSEI;
+ seiName = seiClass.getName();
+ seiAnnotation =
sepClass.getAnnotation(WebService.class);
+ break;
+ }
+ }
+
+ if(seiAnnotation!=null)
+ anWebService = seiAnnotation;
+ }
+
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Jason T. Greene
Senior Software Engineer
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 6 months
Reminder: Please don't commit unless all tests pass
by Jason T. Greene
I noticed regression in the testsuite. Some of it is due to JBossAS
changes, but some of it is also due to changes we have made in trunk.
Please verify that ant tests pass cleanly before committing code.
Unless, of course, the failures happened before your changes, and in
that case please send an email so we can catch these early.
Thanks,
-Jason
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Jason T. Greene
Senior Software Engineer
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 6 months
CR2 release for JBW
by Thomas Diesler
Jason,
what are the chances for a CR2 release ready for JBW? Ideally this would
be the one we use for JAXWS demos.
There is however some regression in the jbossws testsuite since we had
CR1 ten days ago.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 6 months
