You have to have them anyway because you have to support deployment of
applications using old descriptors, and you have to validate those descriptors
against the corresponding schema, not the latest schema.
I closed the Jira issue.
Antonio Goncalves wrote on 11/01/2012 05:57 AM:
> No special concern except that it does not encourage homogenization between
> specs. I find it weired to hava javaee_6.xsd or javaee_5.xsd (if you keep on
> not updating XSDs) all around when talking about Java EE 7. But as you say, it
> doesn't cause any real problem.
>
> I've created a JIRA, just in case : http://java.net/jira/browse/JAVAEE_SPEC-13
>
> Antonio
>
> On Wed, Oct 31, 2012 at 10:34 PM, Bill Shannon <bill.shannon_at_oracle.com
> <mailto:bill.shannon_at_oracle.com>> wrote:
>
> 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>
>
>
>
>
> --
> 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>