It stays.
Does that concern you? Other than looking weird, does it cause any real problems?
Antonio Goncalves wrote on 10/30/12 3:23 PM:
> Bill, if you look
> at http://java.sun.com/xml/ns/javaee/javaee_web_services_1_3.xsd it
> includes <xsd:include schemaLocation="javaee_6.xsd"/>
>
> Suppose JAX-WS / WS_Metadata are not updated. What happens with this XSD ? Is
> it at least updated to include javaee7.xsd or does it stay with javaee6.xsd ?
>
> On Tue, Oct 30, 2012 at 8:54 PM, Bill Shannon <bill.shannon_at_oracle.com
> <mailto:bill.shannon_at_oracle.com>> wrote:
>
> At this point, it's all about resources. Not just the "writing words on
> paper" resources of the spec leads, but the resources to implement and
> test any change. We've already got a queue of things that seemed simple
> to define but imply significant work in the implementation. It's
> extremely unlikely that we would find the resources to make the suggested
> change to JAX-WS for EE 7.
>
> We still have to complete our Managed Beans alignment discussion, and it's
> possible that the outcome of that discussion would impact this case.
>
> So, to summarize, addressing this issue on its own for EE 7 is very
> unlikely. Addressing this issue as a side effect of our Managed Beans
> discussion is possible, but it's too early to tell. And yes, in that
> latter case, we may have a serious resource issue, depending on the
> outcome of that discussion.
>
>
> Antonio Goncalves wrote on 10/30/12 01:14:
>> Bill, what do you mean by "at some point" ? Do you think this will happen
>> during EE 7 or will it be pushed to EE 8 ? I suppose this goes also with
>> our thread about Managed Bean alignement.
>>
>> On Mon, Oct 29, 2012 at 11:50 PM, Bill Shannon <bill.shannon_at_oracle.com
>> <mailto:bill.shannon_at_oracle.com>> wrote:
>>
>> JAX-WS is *not* being replaced by JAX-RS. We have no current plans
>> to prune JAX-WS.
>>
>> That said, we're not planning big updates to JAX-WS, mostly because
>> we're busy doing other things and resources are finite. Having
>> JAX-WS endpoints be CDI managed beans, with all the associated
>> advantages, is definitely worth considering at some point.
>>
>> Antonio Goncalves wrote on 10/29/12 12:55:
>>> Hum... Werner, what you are saying is very important : is the EE EG
>>> clearly saying "we will not update JAX-WS because it's being
>>> replaced by JAX-RS" ? Prunning a technologie has a strong meaning
>>> but what do we want to say about JAX-WS (and JSP) ? "it's not
>>> prunned but we are not updating it" ?
>>>
>>> I think we should agree on the future of JAX-WS (and why not JSP)
>>> and express it loudly to the community. But it will be strange to
>>> have method level validation, injection, interception work in every
>>> spec, except JAX-WS
>>>
>>> On Mon, Oct 29, 2012 at 8:08 PM, Werner Keil <werner.keil_at_gmail.com
>>> <mailto:werner.keil_at_gmail.com>> wrote:
>>>
>>> Emmanuel/All,
>>>
>>> Thanks for that, and to Antonio for sharing.
>>> As JAX-WS 2.0 is only in MR and there is no "real" update
>>> scheduled any time soon, that seems like a problem not so easy
>>> to tackle.
>>> JAX-WS unlike RS has grown out of fashion to many, though I know
>>> first hand, large companies still use it and SOAP a lot,
>>> especially in projects already in production.
>>>
>>> Unless there was a demand and consensus to make such "soon
>>> legacy" JSRs optional at the very least with EE 8, maybe a "2.1"
>>> release could use CDI after all, but of course that depends on
>>> demand.
>>>
>>> Werner
>>>
>>> Am 29.10.2012 19:51 schrieb "Antonio Goncalves"
>>> <antonio.goncalves_at_gmail.com <mailto:antonio.goncalves_at_gmail.com>>:
>>>
>>> Emmanuel's answer (he has no write access to the ML) :
>>>
>>> "The Java EE interception technology does not allow to
>>> intercept methods
>>> calls when calling a method from within the bean. That's a
>>> general
>>> problem that applies for all Java EE so at least that is
>>> consistent.
>>>
>>> I think it makes a lot of sense to support JAX-WS. But
>>> JAX-WS has no
>>> integration with CDI so we could not ride along the CDI
>>> integration to
>>> validate method calls.
>>>
>>> About servlets, I don't see the validation of methods called
>>> by the
>>> servlet container as very useful. In your example, when is a
>>> request
>>> object null?
>>>
>>> I discussed the JAXB validation integration possibilities
>>> with the spec
>>> lead a long time ago but unfortunately, I don't think either
>>> of us
>>> worked further on the subject. That is something I've seen
>>> asked several
>>> times by the community though.
>>>
>>> Emmanuel"
>>>
>>> On Sat, Oct 27, 2012 at 5:49 PM, Antonio Goncalves
>>> <antonio.goncalves_at_gmail.com
>>> <mailto:antonio.goncalves_at_gmail.com>> wrote:
>>>
>>> Hi all,
>>>
>>> A few months ago in the EJB 3.2 EG ML we talked about
>>> aligning BV in EJBs. We've also exchanged a few emails
>>> with Emmanuel Bernard (CCed) about BV aligment in other
>>> specification. As a developer I expect BV method level
>>> validation to work in every EE specification. What do
>>> you think ? If it's the case, I would expect this to work :
>>>
>>>
>>> *_at_WebServlet*
>>> public class MyServlet {
>>>
>>> public void doGet(*_at_NotNull* HttpServletRequest req,
>>> @NotNull HttpServletResponse resp) {}
>>> }
>>>
>>> or
>>>
>>> *_at_WebService*
>>> public class MyWS {
>>>
>>> @WebMethod
>>> *_at_NotNull*
>>> public String methodA(@WebParam(name = "myParam")
>>> *_at_NotNull* String s )
>>> }
>>>
>>>
>>> So that means a JAX-WS update will have to be made
>>> (JAX-WS 2.3 ?). With WebServices that would also mean
>>> that BV will be integrated with JAXB (but I think it's
>>> planned, Emmanuel correct me if I'm wrong).
>>>
>>>
>>> What do you think ?
>>> Antonio
>>>
>>>
>>> On Wed, Aug 29, 2012 at 10:05 AM, Antonio Goncalves
>>> <antonio.goncalves_at_gmail.com
>>> <mailto:antonio.goncalves_at_gmail.com>> wrote:
>>>
>>> Hi all,
>>>
>>> With the new Bean Validation 1.1 method-level
>>> validation I expect something to work out of the box
>>> (with or without CDI) :
>>>
>>> @Stateless
>>> public class AccountService {
>>>
>>> public Account get(*_at_NotNull* Account model) { }
>>> }
>>>
>>>
>>> As for Stateful bean the question is "is there a
>>> possible integration between BV and EJB like JPA or
>>> JSF" ? For example, in the following code, shall we
>>> automatically validate the bean on @Remove (like
>>> @PreRemove on JPA) :
>>>
>>> @Stateful
>>> public class ShoppingCart {
>>>
>>> *_at_NotNull*
>>> private List<CartItem> cartItems;
>>>
>>> *_at_Remove*
>>> public voide checkout { // validate cartItems ? }
>>> }
>>>
>>> I don't really see the point in something like that,
>>> but I might miss something. Could there be another
>>> possible integration ?
>>>
>>> Antonio
>>>
>>> On Wed, Aug 29, 2012 at 12:41 AM, Marina Vatkina
>>> <marina.vatkina_at_oracle.com
>>> <mailto:marina.vatkina_at_oracle.com>> wrote:
>>>
>>> Experts,
>>>
>>> As you know, EJB spec currently doesn't support
>>> Bean Validation. Do we want to change that?
>>>
>>> Let me know if you think that:
>>>
>>> a) BV should be supported for EJBs without CDI
>>> being enabled (probably with an opt-in flag to
>>> be backward compatible)
>>> b) BV should be supported for EJBs only if CDI
>>> is enabled
>>> c) there is no need for standardizing BV with
>>> respect to EJBs
>>> d) you don't care either way :(
>>>
>>>
>>> thanks,
>>> -marina
>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>>
>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>>> <http://www.parisjug.org> | Devoxx France
>>> <http://www.devoxx.fr>
>>>
>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>>
>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>>> <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>>
>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>>
>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>>> <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>> <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>