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>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>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>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>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>:
>>>>
>>>>> 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> 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> 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> 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>