From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To-" "Cc:" "Subject:" "Date:" "Resent-Date:" "Content-Type:" "Content-Transfer-Enc-ding:" "X-Md4-Signature:" "Mime-Version:") nil X-VM-Bookmark: 14 X-VM-Labels: nil X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n" X-VM-IMAP-Retrieved: nil X-VM-POP-Retrieved: nil X-VM-Last-Modified: (19991 31995 95837) X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4756" "Wednesday" "4" "November" "2009" "22:53:37" "-0600" "Tim Quinn" "Timothy.Quinn@Sun.COM" "<4AF25A51.9020403@sun.com>" "125" "Question about a JSR-303 and EE 6 use case" "^From:" "Bill.Shannon@Sun.COM, Roberto.Chinnici@Sun.COM, Ed.Burns@Sun.COM, Cheng.Fang@Sun.COM, Kenneth.Saks@Sun.COM" "Bill Shannon, Roberto Chinnici, Ed Burns, Cheng Fang, Kenneth Saks" "11" "2009110420:53:37" "Question about a JSR-303 and EE 6 use case" nil nil nil nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 05:27:32 -0800 (PST) Received: from fe-amer-09.sun.com ([unknown] [192.18.109.79]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSM009FHDLEUQ70@sfbay3-mail1.sfbay.sun.com>; Wed, 04 Nov 2009 20:53:38 -0800 (PST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSM00B00DH5MA00@mail-amer.sun.com>; Wed, 04 Nov 2009 21:53:38 -0700 (MST) Received: from timothy-quinns-macbook-pro-2.local ([unknown] [67.163.34.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSM003OSDLDGU30@mail-amer.sun.com>; Wed, 04 Nov 2009 21:53:38 -0700 (MST) Message-id: <4AF25A51.9020403@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) From: Tim Quinn Sender: Timothy.Quinn@Sun.COM To: Bill Shannon , Roberto Chinnici Cc: Ed Burns , Cheng Fang , Kenneth Saks Subject: Question about a JSR-303 and EE 6 use case Date: Wed, 04 Nov 2009 22:53:37 -0600 Content-type: multipart/alternative; boundary="Boundary_(ID_11JG12fy2sKvUfP8MW1AwA)" MIME-version: 1.0 This is a multi-part message in MIME format. --Boundary_(ID_11JG12fy2sKvUfP8MW1AwA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, Roberto and Bill. JSR-303 (bean validator) support is working in the app client container with the client injecting a validator or a validator factory using @Resource. Cheng has a failing CTS test which does the above but also declares app-level resources for the validator and factory in application.xml. The ORB's attempt to deliver the referenced app-level resource (validator) from the server into the client fails: Class org.hibernate.validator.engine.ValidatorImpl is not Serializable Cheng points to the platform spec (EE.5.16) which says (in part) A Validator or ValidatorFactory object reference may also be declared in a deployment descriptor in the same way as a resource environment reference. which suggests that this is a legitimate use case. I've talked to Ed a little about this and we've exchanged e-mail, and I've also talked with Ken. Ed is at a conference this week and said he'd have intermittent access to e-mail at best. Because I know very little about 303, I wanted to get your input on this as well given the impending code freeze on the 9th. One fix would be to "short-circuit" such cross-VM references and resolve them locally instead, but I am not sure this would be right. Based on my limited understanding, it seems that a server-side validation.xml could affect the behavior of the server-instantiated (and named) validator or factory. Short-circuiting a client's reference would deliver a "default" validator or factory, without the added configuration the server-side validation.xml might declare. Another fix would be to change the RI implementation class so that it is serializable and therefore could be sent back to the client. Another "fix" would be to declare this as unsupported, at least for now. I think that getting the ValidatorImpl class to be Serializable (assuming that's possible) is the way to go, based on the platform spec clause Cheng cites and the presumed ability to configure validators and/or factories. Thoughts? Thanks. - Tim --Boundary_(ID_11JG12fy2sKvUfP8MW1AwA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, Roberto and Bill.

JSR-303 (bean validator) support is working in the app client container with the client injecting a validator or a validator factory using @Resource. 

Cheng has a failing CTS test which does the above but also declares app-level resources for the validator and factory in application.xml.  The ORB's attempt to deliver the referenced app-level resource (validator) from the server into the client fails:

    Class org.hibernate.validator.engine.ValidatorImpl is not Serializable


 Cheng points to the platform spec (EE.5.16) which says (in part)

A Validator or ValidatorFactory object reference may also be declared in a deployment descriptor in the same way as a resource environment reference.
which suggests that this is a legitimate use case.


I've talked to Ed a little about this and we've exchanged e-mail, and I've also talked with Ken.  Ed is at a conference this week and said he'd have intermittent access to e-mail at best.  Because I know very little about 303, I wanted to get your input on this as well given the impending code freeze on the 9th.

One fix would be to "short-circuit" such cross-VM references and resolve them locally instead, but I am not sure this would be right.  Based on my limited understanding, it seems that a server-side validation.xml could affect the behavior of the server-instantiated (and named) validator or factory.  Short-circuiting a client's reference would deliver a "default" validator or factory, without the added configuration the server-side validation.xml might declare. 

Another fix would be to change the RI implementation class so that it is serializable and therefore could be sent back to the client.

Another "fix" would be to declare this as unsupported, at least for now.

I think that getting the ValidatorImpl class to be Serializable (assuming that's possible) is the way to go, based on the platform spec clause Cheng cites and the presumed ability to configure validators and/or factories.


Thoughts?  Thanks.


- Tim
--Boundary_(ID_11JG12fy2sKvUfP8MW1AwA)-- From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] ["2513" "Wednesday" "4" "November" "2009" "23:44:50" "-0800" "Bill Shannon" "Bill.Shannon@Sun.COM" "<4AF28272.4090009@sun.com>" "62" "Re: Question about a JSR-303 and EE 6 use case" "^From:" nil nil "11" "2009110423:44:50" "Question about a JSR-303 and EE 6 use case" nil "<4AF25A51.9020403@sun.com>" ("<4AF25A51.9020403@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/barbara.louis Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 05:27:36 -0800 (PST) Received: from fe-sfbay-10.sun.com ([unknown] [192.18.34.120]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSM00IU0LIZDK00@sfbay3-mail1.sfbay.sun.com>; Wed, 04 Nov 2009 23:44:59 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSM00800LCE3D00@fe-sfbay-10.sun.com>; Wed, 04 Nov 2009 23:44:59 -0800 (PST) Received: from phys-sfbay3-1.sfbay.sun.com ([unknown] [129.145.47.22]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSM00GEMLIZZ860@fe-sfbay-10.sun.com>; Wed, 04 Nov 2009 23:44:59 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([unknown] [129.145.155.118]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSM00ITXLIZDK00@sfbay3-mail1.sfbay.sun.com>; Wed, 04 Nov 2009 23:44:59 -0800 (PST) Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA57iwmk007188; Wed, 04 Nov 2009 23:44:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA57inbX016569; Thu, 05 Nov 2009 15:44:53 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSM00D05LISLB00@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 00:44:52 -0700 (MST) Received: from nissan.sfbay.sun.com ([129.150.12.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSM00J1XLIROG60@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 00:44:52 -0700 (MST) Received: from [192.168.0.101] (home-101 [192.168.0.101]) by nissan.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nA57ip9C011600; Wed, 04 Nov 2009 23:44:51 -0800 (PST) In-reply-to: <4AF25A51.9020403@sun.com> Message-id: <4AF28272.4090009@sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4AF25A51.9020403@sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) From: Bill Shannon To: Tim Quinn Cc: Roberto Chinnici , Ed Burns , Cheng Fang , Kenneth Saks Subject: Re: Question about a JSR-303 and EE 6 use case Date: Wed, 04 Nov 2009 23:44:50 -0800 Content-type: text/plain; charset=ISO-8859-1 MIME-version: 1.0 I don't know enough about JSR 303. Where is the validation.xml file packaged? If @Resource in the app client references a validator, and the validator needs a validation.xml file to configure itself properly, I would expect the valdation.xml file to be in some place accessible to the client, just like any class the client might access. Tim Quinn wrote on 11/4/09 8:53 PM: > Hi, Roberto and Bill. > > JSR-303 (bean validator) support is working in the app client container > with the client injecting a validator or a validator factory using > @Resource. > > Cheng has a failing CTS test which does the above but also declares > app-level resources for the validator and factory in application.xml. > The ORB's attempt to deliver the referenced app-level resource > (validator) from the server into the client fails: > > Class org.hibernate.validator.engine.ValidatorImpl is not Serializable > > > Cheng points to the platform spec (EE.5.16) which says (in part) > > A Validator or ValidatorFactory object reference may also be > declared in a deployment descriptor in the same way as a resource > environment reference. > > which suggests that this is a legitimate use case. > > > I've talked to Ed a little about this and we've exchanged e-mail, and > I've also talked with Ken. Ed is at a conference this week and said > he'd have intermittent access to e-mail at best. Because I know very > little about 303, I wanted to get your input on this as well given the > impending code freeze on the 9th. > > One fix would be to "short-circuit" such cross-VM references and resolve > them locally instead, but I am not sure this would be right. Based on > my limited understanding, it seems that a server-side validation.xml > could affect the behavior of the server-instantiated (and named) > validator or factory. Short-circuiting a client's reference would > deliver a "default" validator or factory, without the added > configuration the server-side validation.xml might declare. > > Another fix would be to change the RI implementation class so that it is > serializable and therefore could be sent back to the client. > > Another "fix" would be to declare this as unsupported, at least for now. > > I think that getting the ValidatorImpl class to be Serializable > (assuming that's possible) is the way to go, based on the platform spec > clause Cheng cites and the presumed ability to configure validators > and/or factories. > > > Thoughts? Thanks. > > > - Tim From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["8201" "Thursday" "5" "November" "2009" "02:14:01" "-0600" "Tim Quinn" "Timothy.Quinn@Sun.COM" "<4AF28949.9050008@sun.com>" "211" "Re: Question about a JSR-303 and EE 6 use case" "^From:" "Bill.Shannon@Sun.COM, Roberto.Chinnici@Sun.COM, Ed.Burns@Sun.COM, Cheng.Fang@Sun.COM, Kenneth.Saks@Sun.COM" "Bill Shannon, Roberto Chinnici, Ed Burns, Cheng Fang, Kenneth Saks" "11" "2009110500:14:01" "Question about a JSR-303 and EE 6 use case" nil "<4AF28272.4090009@sun.com>" ("<4AF25A51.9020403@sun.com>" "<4AF28272.4090009@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 05:27:36 -0800 (PST) Received: from fe-amer-10.sun.com ([unknown] [192.18.109.80]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSM00IG0MVEDK50@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 00:14:03 -0800 (PST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSM00700MUIFB00@mail-amer.sun.com>; Thu, 05 Nov 2009 01:14:02 -0700 (MST) Received: from timothy-quinns-macbook-pro-2.local ([unknown] [67.163.34.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSM00EP2MVDXKE0@mail-amer.sun.com>; Thu, 05 Nov 2009 01:14:02 -0700 (MST) In-reply-to: <4AF28272.4090009@sun.com> Message-id: <4AF28949.9050008@sun.com> References: <4AF25A51.9020403@sun.com> <4AF28272.4090009@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) From: Tim Quinn Sender: Timothy.Quinn@Sun.COM To: Bill Shannon Cc: Roberto Chinnici , Ed Burns , Cheng Fang , Kenneth Saks Subject: Re: Question about a JSR-303 and EE 6 use case Date: Thu, 05 Nov 2009 02:14:01 -0600 Content-type: multipart/alternative; boundary="Boundary_(ID_gk4INBRKQVvCvSzhBkQK6w)" MIME-version: 1.0 This is a multi-part message in MIME format. --Boundary_(ID_gk4INBRKQVvCvSzhBkQK6w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Bill Shannon wrote: > I don't know enough about JSR 303. Where is the validation.xml file > packaged? > The validation.xml resides in META-INF/ or WEB-INF/ of the module creating the validator or factory. > If @Resource in the app client references a validator, and the > validator needs a validation.xml file to configure itself properly, > I would expect the valdation.xml file to be in some place accessible > to the client, just like any class the client might access. > I would agree - for a validator created in the client and therefore configured in the client. For the use case in question, the validator is created and configured on the server. Because it is declared in the application.xml, the validator is also added to the name space. The current implementation is resolving the client's reference against that app-level declaration. (In the test case that works, there is no resource definition in application.xml for the validator so the system resolves the client's reference by creating the validator locally in the client.) If I understand the role of validation.xml, and that's a big "if," then in the test case which fails it seems sensible for the client to retrieve the app-level-named validator from the server because that validator has been configured a certain way and advertised through naming. This retrieval fails only because of the non-serializability of the validator implementation class. - Tim > > Tim Quinn wrote on 11/4/09 8:53 PM: > >> Hi, Roberto and Bill. >> >> JSR-303 (bean validator) support is working in the app client container >> with the client injecting a validator or a validator factory using >> @Resource. >> >> Cheng has a failing CTS test which does the above but also declares >> app-level resources for the validator and factory in application.xml. >> The ORB's attempt to deliver the referenced app-level resource >> (validator) from the server into the client fails: >> >> Class org.hibernate.validator.engine.ValidatorImpl is not Serializable >> >> >> Cheng points to the platform spec (EE.5.16) which says (in part) >> >> A Validator or ValidatorFactory object reference may also be >> declared in a deployment descriptor in the same way as a resource >> environment reference. >> >> which suggests that this is a legitimate use case. >> >> >> I've talked to Ed a little about this and we've exchanged e-mail, and >> I've also talked with Ken. Ed is at a conference this week and said >> he'd have intermittent access to e-mail at best. Because I know very >> little about 303, I wanted to get your input on this as well given the >> impending code freeze on the 9th. >> >> One fix would be to "short-circuit" such cross-VM references and resolve >> them locally instead, but I am not sure this would be right. Based on >> my limited understanding, it seems that a server-side validation.xml >> could affect the behavior of the server-instantiated (and named) >> validator or factory. Short-circuiting a client's reference would >> deliver a "default" validator or factory, without the added >> configuration the server-side validation.xml might declare. >> >> Another fix would be to change the RI implementation class so that it is >> serializable and therefore could be sent back to the client. >> >> Another "fix" would be to declare this as unsupported, at least for now. >> >> I think that getting the ValidatorImpl class to be Serializable >> (assuming that's possible) is the way to go, based on the platform spec >> clause Cheng cites and the presumed ability to configure validators >> and/or factories. >> >> >> Thoughts? Thanks. >> >> >> - Tim >> > > --Boundary_(ID_gk4INBRKQVvCvSzhBkQK6w) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Bill Shannon wrote: 
I don't know enough about JSR 303.  Where is the validation.xml file
packaged?
The validation.xml resides in META-INF/ or WEB-INF/ of the module creating the validator or factory.
If @Resource in the app client references a validator, and the
validator needs a validation.xml file to configure itself properly,
I would expect the valdation.xml file to be in some place accessible
to the client, just like any class the client might access.
I would agree - for a validator created in the client and therefore configured in the client. 

For the use case in question, the validator is created and configured on the server.  Because it is declared in the application.xml, the validator is also added to the name space.  The current implementation is resolving the client's reference against that app-level declaration.  (In the test case that works, there is no resource definition in application.xml for the validator so the system resolves the client's reference by creating the validator locally in the client.)

If I understand the role of validation.xml, and that's a big "if," then in the test case which fails it seems sensible for the client to retrieve the app-level-named validator from the server because that validator has been configured a certain way and advertised through naming.  This retrieval fails only because of the non-serializability of the validator implementation class.

- Tim


Tim Quinn wrote on 11/4/09 8:53 PM:
  
Hi, Roberto and Bill.

JSR-303 (bean validator) support is working in the app client container
with the client injecting a validator or a validator factory using
@Resource. 

Cheng has a failing CTS test which does the above but also declares
app-level resources for the validator and factory in application.xml. 
The ORB's attempt to deliver the referenced app-level resource
(validator) from the server into the client fails:

    Class org.hibernate.validator.engine.ValidatorImpl is not Serializable


 Cheng points to the platform spec (EE.5.16) which says (in part)

    A Validator or ValidatorFactory object reference may also be
    declared in a deployment descriptor in the same way as a resource
    environment reference.

which suggests that this is a legitimate use case.


I've talked to Ed a little about this and we've exchanged e-mail, and
I've also talked with Ken.  Ed is at a conference this week and said
he'd have intermittent access to e-mail at best.  Because I know very
little about 303, I wanted to get your input on this as well given the
impending code freeze on the 9th.

One fix would be to "short-circuit" such cross-VM references and resolve
them locally instead, but I am not sure this would be right.  Based on
my limited understanding, it seems that a server-side validation.xml
could affect the behavior of the server-instantiated (and named)
validator or factory.  Short-circuiting a client's reference would
deliver a "default" validator or factory, without the added
configuration the server-side validation.xml might declare. 

Another fix would be to change the RI implementation class so that it is
serializable and therefore could be sent back to the client.

Another "fix" would be to declare this as unsupported, at least for now.

I think that getting the ValidatorImpl class to be Serializable
(assuming that's possible) is the way to go, based on the platform spec
clause Cheng cites and the presumed ability to configure validators
and/or factories.


Thoughts?  Thanks.


- Tim

--Boundary_(ID_gk4INBRKQVvCvSzhBkQK6w)-- From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3051" "Thursday" "5" "November" "2009" "06:10:56" "-0800" "Ed Burns" "ed.burns@sun.com" "<19186.56560.575070.657121@sun.com>" "81" "Re: Question about a JSR-303 and EE 6 use case" "^From:" nil nil "11" "2009110509:10:56" "Question about a JSR-303 and EE 6 use case" nil "<4AF28272.4090009@sun.com>" ("<4AF25A51.9020403@sun.com>" "<4AF28272.4090009@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Bill.Shannon Content-Transfer-Encoding: 7bit Message-ID: <19186.56560.575070.657121@sun.com> In-Reply-To: Re: Question about a JSR-303 and EE 6 use case on 4 November 2009 References: <4AF25A51.9020403@sun.com> <4AF28272.4090009@sun.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Reply-To: Ed Burns From: Ed Burns To: Bill Shannon Cc: Tim Quinn , Barbara.Louis@Sun.COM, Roberto Chinnici , Ed Burns , Cheng Fang , Kenneth Saks Subject: Re: Question about a JSR-303 and EE 6 use case Date: Thu, 5 Nov 2009 06:10:56 -0800 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Tim, I have a new build for you to try, see below. >>>>> On Wed, 04 Nov 2009 23:44:50 -0800, Bill Shannon said: B> I don't know enough about JSR 303. Where is the validation.xml file B> packaged? Per section 4.4.6, it is in META-INF/validation.xml on the classpath. B> If @Resource in the app client references a validator, and the B> validator needs a validation.xml file to configure itself properly, B> I would expect the valdation.xml file to be in some place accessible B> to the client, just like any class the client might access. Yes, that seems reasonable. TQ> Class org.hibernate.validator.engine.ValidatorImpl is not Serializable TQ> I've talked to Ed a little about this and we've exchanged e-mail, and TQ> I've also talked with Ken. Ed is at a conference this week and said TQ> he'd have intermittent access to e-mail at best. Because I know very TQ> little about 303, I wanted to get your input on this as well given the TQ> impending code freeze on the 9th. TQ> One fix would be to "short-circuit" such cross-VM references and resolve TQ> them locally instead, but I am not sure this would be right. Based on TQ> my limited understanding, it seems that a server-side validation.xml TQ> could affect the behavior of the server-instantiated (and named) TQ> validator or factory. Short-circuiting a client's reference would TQ> deliver a "default" validator or factory, without the added TQ> configuration the server-side validation.xml might declare. I assert that the validator impl needs to be executed on the same VM where the class that has the constraint annotations lives. Is that always the server? Can it be the client too? TQ> Another fix would be to change the RI implementation class so that it is TQ> serializable and therefore could be sent back to the client. My instinct tells me that this change would just be the tip of the iceberg of changes that would have to be made to enable this uses case. BV was not designed for the use case where the ValidatorImpl is on a different VW from the instance it is validating. TQ> TQ> Another "fix" would be to declare this as unsupported, at least for now. Always an option, and sometimes not a bad one! TQ> TQ> I think that getting the ValidatorImpl class to be Serializable TQ> (assuming that's possible) is the way to go, based on the platform spec TQ> clause Cheng cites and the presumed ability to configure validators TQ> and/or factories. Again, I don't think simply making the class serializable will do it. Tim, I have prepared a special build of BV that has the class marked as serializable, just so you can test it. I really doubt this is going to be all that is required. In any case, the build is at http://mediacast.sun.com/users/edburns00/media/bean-validator-3.0-JBoss-4.0.1_03.jar Replace modules/bean-validator.jar with the one you downloaded. Ed TQ> TQ> TQ> Thoughts? Thanks. TQ> TQ> TQ> - Tim -- | ed.burns@sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/ From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["10138" "Thursday" "5" "November" "2009" "09:54:48" "-0600" "Tim Quinn" "Timothy.Quinn@Sun.COM" "<4AF2F548.5090202@sun.com>" "239" "Re: Question about a JSR-303 and EE 6 use case" "^From:" nil nil "11" "2009110507:54:48" "Question about a JSR-303 and EE 6 use case" nil "<19186.56560.575070.657121@sun.com>" ("<4AF25A51.9020403@sun.com>" "<4AF28272.4090009@sun.com>" "<19186.56560.575070.657121@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 10:28:57 -0800 (PST) Received: from fe-amer-10.sun.com ([unknown] [192.18.109.80]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN00FOQ87MFP00@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 07:54:58 -0800 (PST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00I007DE2G00@mail-amer.sun.com>; Thu, 05 Nov 2009 08:54:58 -0700 (MST) Received: from timothy-quinns-macbook-pro-2.local ([unknown] [67.163.34.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSN00AV887C2BB0@mail-amer.sun.com>; Thu, 05 Nov 2009 08:54:49 -0700 (MST) In-reply-to: <19186.56560.575070.657121@sun.com> Message-id: <4AF2F548.5090202@sun.com> References: <4AF25A51.9020403@sun.com> <4AF28272.4090009@sun.com> <19186.56560.575070.657121@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) From: Tim Quinn Sender: Timothy.Quinn@Sun.COM To: Ed Burns Cc: Bill Shannon , Barbara.Louis@Sun.COM, Roberto Chinnici , Cheng Fang , Kenneth Saks Subject: Re: Question about a JSR-303 and EE 6 use case Date: Thu, 05 Nov 2009 09:54:48 -0600 Content-type: multipart/alternative; boundary="Boundary_(ID_d5hy41nbZYfaFsw9EIpvFA)" MIME-version: 1.0 This is a multi-part message in MIME format. --Boundary_(ID_d5hy41nbZYfaFsw9EIpvFA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Roberto, a platform spec question for you is embedded below. Thanks for the patch JAR, Ed. And great thanks to Cheng for running the test with the patch JAR. Cheng reported that the server now logs this error: [#|2009-11-05T10:03:58.785-0500|WARNING|glassfishv3.0|javax.enterprise.resource.corba.ee._CORBA_.util|_ThreadID=28;_ThreadName=Thread-1;|"IOP00100006: (BAD_PARAM) Class org.hibernate.validator.metadata.BeanMetaDataCache is not Serializable" Ed, you noted that the earlier error might be the tip of the iceberg. I assume that in building the patch JAR you did not drill down into the various fields that the ValidatorImpl class owns to make sure their types (and further referenced types) were also serializable (or transient)? As you've alluded to, that's what'd be needed to make ValidatorImpl serializable. It looks as if the latest error Cheng reported is due to the beanMetaDataCache field on ValidatorImpl, and the trail winds on from there. A few more responses below... Ed Burns wrote: > Tim, I have a new build for you to try, see below. > > >>>>>> On Wed, 04 Nov 2009 23:44:50 -0800, Bill Shannon said: >>>>>> > > B> I don't know enough about JSR 303. Where is the validation.xml file > B> packaged? > > Per section 4.4.6, it is in META-INF/validation.xml on the classpath. > > B> If @Resource in the app client references a validator, and the > B> validator needs a validation.xml file to configure itself properly, > B> I would expect the valdation.xml file to be in some place accessible > B> to the client, just like any class the client might access. > > Yes, that seems reasonable. > See my comment in my earlier reply to Bill. > TQ> Class org.hibernate.validator.engine.ValidatorImpl is not Serializable > > TQ> I've talked to Ed a little about this and we've exchanged e-mail, and > TQ> I've also talked with Ken. Ed is at a conference this week and said > TQ> he'd have intermittent access to e-mail at best. Because I know very > TQ> little about 303, I wanted to get your input on this as well given the > TQ> impending code freeze on the 9th. > > TQ> One fix would be to "short-circuit" such cross-VM references and resolve > TQ> them locally instead, but I am not sure this would be right. Based on > TQ> my limited understanding, it seems that a server-side validation.xml > TQ> could affect the behavior of the server-instantiated (and named) > TQ> validator or factory. Short-circuiting a client's reference would > TQ> deliver a "default" validator or factory, without the added > TQ> configuration the server-side validation.xml might declare. > > I assert that the validator impl needs to be executed on the same VM > where the class that has the constraint annotations lives. Is that > always the server? Can it be the client too? > What seems to be happening currently is that a copy of the validator, rather than a remote reference/proxy to it, is (trying to be) returned to the client. > TQ> Another fix would be to change the RI implementation class so that it is > TQ> serializable and therefore could be sent back to the client. > > My instinct tells me that this change would just be the tip of the > iceberg of changes that would have to be made to enable this uses case. > BV was not designed for the use case where the ValidatorImpl is on a > different VW from the instance it is validating. > Roberto, if this use case falls outside the design for bean validation, is there clarification needed in the platform spec to rule out or more fully describe this use case where a client injects a @Resource for a validator that is defined in application.xml and therefore resides on the server? > TQ> > TQ> Another "fix" would be to declare this as unsupported, at least for now. > > Always an option, and sometimes not a bad one! > Indeed! > TQ> > TQ> I think that getting the ValidatorImpl class to be Serializable > TQ> (assuming that's possible) is the way to go, based on the platform spec > TQ> clause Cheng cites and the presumed ability to configure validators > TQ> and/or factories. > > Again, I don't think simply making the class serializable will do it. > Yeah, I wasn't expecting that adding "implements Serializable" would be sufficient! - Tim --Boundary_(ID_d5hy41nbZYfaFsw9EIpvFA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Roberto, a platform spec question for you is embedded below.

Thanks for the patch JAR, Ed.

And great thanks to Cheng for running the test with the patch JAR.

Cheng reported that the server now logs this error:

[#|2009-11-05T10:03:58.785-0500|WARNING|glassfishv3.0|javax.enterprise.resource.corba.ee._CORBA_.util|_ThreadID=28;_ThreadName=Thread-1;|"IOP00100006: (BAD_PARAM) Class org.hibernate.validator.metadata.BeanMetaDataCache is not Serializable"

Ed, you noted that the earlier error might be the tip of the iceberg.  I assume that in building the patch JAR you did not drill down into the various fields that the ValidatorImpl class owns to make sure their types (and further referenced types) were also serializable (or transient)?  As you've alluded to, that's what'd be needed to make ValidatorImpl serializable.  It looks as if the latest error Cheng reported is due to the  beanMetaDataCache field on ValidatorImpl, and the trail winds on from there.

A few more responses below...

Ed Burns wrote: 
Tim, I have a new build for you to try, see below.

  
On Wed, 04 Nov 2009 23:44:50 -0800, Bill Shannon <Bill.Shannon@Sun.COM> said:
            

B> I don't know enough about JSR 303.  Where is the validation.xml file
B> packaged?

Per section 4.4.6, it is in META-INF/validation.xml on the classpath.

B> If @Resource in the app client references a validator, and the
B> validator needs a validation.xml file to configure itself properly,
B> I would expect the valdation.xml file to be in some place accessible
B> to the client, just like any class the client might access.

Yes, that seems reasonable.
See my comment in my earlier reply to Bill.  
TQ> Class org.hibernate.validator.engine.ValidatorImpl is not Serializable

TQ> I've talked to Ed a little about this and we've exchanged e-mail, and
TQ> I've also talked with Ken.  Ed is at a conference this week and said
TQ> he'd have intermittent access to e-mail at best.  Because I know very
TQ> little about 303, I wanted to get your input on this as well given the
TQ> impending code freeze on the 9th.

TQ> One fix would be to "short-circuit" such cross-VM references and resolve
TQ> them locally instead, but I am not sure this would be right.  Based on
TQ> my limited understanding, it seems that a server-side validation.xml
TQ> could affect the behavior of the server-instantiated (and named)
TQ> validator or factory.  Short-circuiting a client's reference would
TQ> deliver a "default" validator or factory, without the added
TQ> configuration the server-side validation.xml might declare. 

I assert that the validator impl needs to be executed on the same VM
where the class that has the constraint annotations lives.  Is that
always the server?  Can it be the client too?
What seems to be happening currently is that a copy of the validator, rather than a remote reference/proxy to it, is (trying to be) returned to the client.  
TQ> Another fix would be to change the RI implementation class so that it is
TQ> serializable and therefore could be sent back to the client.

My instinct tells me that this change would just be the tip of the
iceberg of changes that would have to be made to enable this uses case.
BV was not designed for the use case where the ValidatorImpl is on a
different VW from the instance it is validating.
Roberto, if this use case falls outside the design for bean validation, is there clarification needed in the platform spec to rule out or more fully describe this use case where a client injects a @Resource for a validator that is defined in application.xml and therefore resides on the server?
TQ> 
TQ> Another "fix" would be to declare this as unsupported, at least for now.

Always an option, and sometimes not a bad one!
Indeed! 
TQ> 
TQ> I think that getting the ValidatorImpl class to be Serializable
TQ> (assuming that's possible) is the way to go, based on the platform spec
TQ> clause Cheng cites and the presumed ability to configure validators
TQ> and/or factories.

Again, I don't think simply making the class serializable will do it.
Yeah, I wasn't expecting that adding "implements Serializable" would be sufficient!

- Tim
--Boundary_(ID_d5hy41nbZYfaFsw9EIpvFA)-- From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["954" "Thursday" "5" "November" "2009" "08:55:15" "-0800" "Roberto Chinnici" "Roberto.Chinnici@Sun.COM" "<4AF30373.8080806@sun.com>" "18" "Re: Question about a JSR-303 and EE 6 use case" "^From:" nil nil "11" "2009110508:55:15" "Question about a JSR-303 and EE 6 use case" nil "<4AF2F548.5090202@sun.com>" ("<4AF25A51.9020403@sun.com>" "<4AF28272.4090009@sun.com>" "<19186.56560.575070.657121@sun.com>" "<4AF2F548.5090202@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 10:29:03 -0800 (PST) Received: from fe-sfbay-10.sun.com ([unknown] [192.18.34.120]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN00GUMB0JTQA0@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 08:55:31 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00G00AQZAV00@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 08:55:27 -0800 (PST) Received: from dhcp-usfo07-89-199.sfbay.sun.com ([unknown] [129.144.89.199]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSN008QHB057Z40@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 08:55:17 -0800 (PST) In-reply-to: <4AF2F548.5090202@sun.com> Message-id: <4AF30373.8080806@sun.com> Organization: Sun Microsystems, Inc. Content-transfer-encoding: 7BIT References: <4AF25A51.9020403@sun.com> <4AF28272.4090009@sun.com> <19186.56560.575070.657121@sun.com> <4AF2F548.5090202@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) From: Roberto Chinnici Sender: Roberto.Chinnici@Sun.COM To: Tim Quinn Cc: Ed Burns , Bill Shannon , Barbara.Louis@Sun.COM, Cheng Fang , Kenneth Saks Subject: Re: Question about a JSR-303 and EE 6 use case Date: Thu, 05 Nov 2009 08:55:15 -0800 Content-type: text/plain; format=flowed; charset=ISO-8859-1 MIME-version: 1.0 Tim Quinn wrote: >> TQ> Another fix would be to change the RI implementation class so that it is >> TQ> serializable and therefore could be sent back to the client. >> >> My instinct tells me that this change would just be the tip of the >> iceberg of changes that would have to be made to enable this uses case. >> BV was not designed for the use case where the ValidatorImpl is on a >> different VW from the instance it is validating. >> > Roberto, if this use case falls outside the design for bean > validation, is there clarification needed in the platform spec to rule > out or more fully describe this use case where a client injects a > @Resource for a validator that is defined in application.xml and > therefore resides on the server? It's not clear to me that you have to serialize anything. Couldn't you create an instance of whatever validator impl class is needed right in the client VM, when you populate the JNDI context there? From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1803" "Thursday" "5" "November" "2009" "11:09:53" "-0600" "Tim Quinn" "Timothy.Quinn@Sun.COM" "<4AF306E1.6080302@sun.com>" "41" "Re: Question about a JSR-303 and EE 6 use case" "^From:" nil nil "11" "2009110509:09:53" "Question about a JSR-303 and EE 6 use case" nil "<4AF30373.8080806@sun.com>" ("<4AF25A51.9020403@sun.com>" "<4AF28272.4090009@sun.com>" "<19186.56560.575070.657121@sun.com>" "<4AF2F548.5090202@sun.com>" "<4AF30373.8080806@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 10:29:05 -0800 (PST) Received: from fe-amer-09.sun.com ([unknown] [192.18.109.79]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN00INHBOICW00@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 09:09:55 -0800 (PST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00H00AR0VD00@mail-amer.sun.com>; Thu, 05 Nov 2009 10:09:54 -0700 (MST) Received: from timothy-quinns-macbook-pro-2.local ([unknown] [67.163.34.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSN00B4BBOHP350@mail-amer.sun.com>; Thu, 05 Nov 2009 10:09:54 -0700 (MST) In-reply-to: <4AF30373.8080806@sun.com> Message-id: <4AF306E1.6080302@sun.com> Content-transfer-encoding: 7BIT References: <4AF25A51.9020403@sun.com> <4AF28272.4090009@sun.com> <19186.56560.575070.657121@sun.com> <4AF2F548.5090202@sun.com> <4AF30373.8080806@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) From: Tim Quinn Sender: Timothy.Quinn@Sun.COM To: Roberto Chinnici Cc: Ed Burns , Bill Shannon , Barbara.Louis@Sun.COM, Cheng Fang , Kenneth Saks Subject: Re: Question about a JSR-303 and EE 6 use case Date: Thu, 05 Nov 2009 11:09:53 -0600 Content-type: text/plain; format=flowed; charset=ISO-8859-1 MIME-version: 1.0 Roberto Chinnici wrote: > Tim Quinn wrote: >>> TQ> Another fix would be to change the RI implementation class so >>> that it is >>> TQ> serializable and therefore could be sent back to the client. >>> >>> My instinct tells me that this change would just be the tip of the >>> iceberg of changes that would have to be made to enable this uses case. >>> BV was not designed for the use case where the ValidatorImpl is on a >>> different VW from the instance it is validating. >>> >> Roberto, if this use case falls outside the design for bean >> validation, is there clarification needed in the platform spec to >> rule out or more fully describe this use case where a client injects >> a @Resource for a validator that is defined in application.xml and >> therefore resides on the server? > > It's not clear to me that you have to serialize anything. Couldn't you > create an instance of whatever validator impl class is needed right in > the client VM, when you populate the JNDI context there? > In an earlier note I described how that is what happens now if the client uses @Resource Validator validator; and the application.xml does NOT contain a declaration for the validator. The error occurs if application.xml DOES declare the validator. In that case, the current implementation attempts to access the named object and that is leading to the serialization issues. Another question I posed is this: Ed's validator proxy could always create an instance locally, even if the validator were added to the name space by a declaration in application.xml or programmatically. My concern is that this locally-created validator would not be configured the same as the server-created one in the name space and that this might lead to behavior the user does not expect. - Tim From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2992" "Thursday" "5" "November" "2009" "09:40:34" "-0800" "Roberto Chinnici" "Roberto.Chinnici@Sun.COM" "<4AF30E12.6070201@sun.com>" "64" "Re: Question about a JSR-303 and EE 6 use case" "^From:" nil nil "11" "2009110509:40:34" "Question about a JSR-303 and EE 6 use case" nil "<4AF306E1.6080302@sun.com>" ("<4AF25A51.9020403@sun.com>" "<4AF28272.4090009@sun.com>" "<19186.56560.575070.657121@sun.com>" "<4AF2F548.5090202@sun.com>" "<4AF30373.8080806@sun.com>" "<4AF306E1.6080302@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 10:29:09 -0800 (PST) Received: from fe-sfbay-10.sun.com ([unknown] [192.18.34.120]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN00IZ0D4ICWD0@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 09:41:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00800C3L0L00@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 09:41:06 -0800 (PST) Received: from dhcp-usfo07-89-199.sfbay.sun.com ([unknown] [129.144.89.199]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSN00M90D3OOM40@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 09:40:37 -0800 (PST) In-reply-to: <4AF306E1.6080302@sun.com> Message-id: <4AF30E12.6070201@sun.com> Organization: Sun Microsystems, Inc. Content-transfer-encoding: 8BIT References: <4AF25A51.9020403@sun.com> <4AF28272.4090009@sun.com> <19186.56560.575070.657121@sun.com> <4AF2F548.5090202@sun.com> <4AF30373.8080806@sun.com> <4AF306E1.6080302@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) From: Roberto Chinnici Sender: Roberto.Chinnici@Sun.COM To: Tim Quinn Cc: Ed Burns , Bill Shannon , Barbara.Louis@Sun.COM, Cheng Fang , Kenneth Saks Subject: Re: Question about a JSR-303 and EE 6 use case Date: Thu, 05 Nov 2009 09:40:34 -0800 Content-type: text/plain; format=flowed; charset=windows-1252 MIME-version: 1.0 Tim Quinn wrote: > Roberto Chinnici wrote: >> Tim Quinn wrote: >>>> TQ> Another fix would be to change the RI implementation class so >>>> that it is >>>> TQ> serializable and therefore could be sent back to the client. >>>> >>>> My instinct tells me that this change would just be the tip of the >>>> iceberg of changes that would have to be made to enable this uses >>>> case. >>>> BV was not designed for the use case where the ValidatorImpl is on a >>>> different VW from the instance it is validating. >>> Roberto, if this use case falls outside the design for bean >>> validation, is there clarification needed in the platform spec to >>> rule out or more fully describe this use case where a client injects >>> a @Resource for a validator that is defined in application.xml and >>> therefore resides on the server? >> >> It's not clear to me that you have to serialize anything. Couldn't >> you create an instance of whatever validator impl class is needed >> right in the client VM, when you populate the JNDI context there? >> > In an earlier note I described how that is what happens now if the > client uses > > @Resource Validator validator; > > and the application.xml does NOT contain a declaration for the validator. > The error occurs if application.xml DOES declare the validator. In > that case, the current implementation attempts to access the named > object and that is leading to the serialization issues. I see. You can do this even without application.xml. A server-side class can say: @Resource(name="java:app/env/validator") Validator v; and a client-side one: @Resource(lookup="java:app/env/validator") Validator v; The spec says (EE.5.2.1): --- For each environment entry, the Application Component Provider can also specify in the deployment descriptor, or via annotations, the JNDI name of another environment entry whose value should be used to initialize the environment entry being defined (“lookup” functionality). --- I think that for the app client it means that if the corresponding JNDI lookup fails, then it's an error. In general, doing @Resource(lookup="java:app/env/validator") and ic.lookup("java:app/env/validator") should either both succeed and return equivalent results or both fail. > Another question I posed is this: Ed's validator proxy could always > create an instance locally, even if the validator were added to the > name space by a declaration in application.xml or programmatically. My > concern is that this locally-created validator would not be configured > the same as the server-created one in the name space and that this > might lead to behavior the user does not expect. So that's the case where the code that does @Resource(name="java:app/env/validator") inside a server-side module that has a validation.xml descriptor, right? I think it's impossible to do this with application.xml alone. Anyway, it seems wrong to silently return to the client a validator that is not properly configured. From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1681" "Thursday" "5" "November" "2009" "11:04:53" "-0800" "Ed Burns" "Ed.Burns@Sun.COM" "<19187.8661.791927.886279@sun.com>" "39" "Bean Validator Reality Check" "^From:" nil nil "11" "2009110511:04:53" "Bean Validator Reality Check" nil nil nil nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Content-Length: 1681 Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 11:09:21 -0800 (PST) Received: from fe-amer-09.sun.com ([unknown] [192.18.109.79]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN000KOH0C1I10@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 11:05:00 -0800 (PST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00100FYZMJ00@mail-amer.sun.com>; Thu, 05 Nov 2009 12:05:00 -0700 (MST) Received: from sr1-usca-32 ([unknown] [129.145.155.59]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSN00JB3H06OL30@mail-amer.sun.com>; Thu, 05 Nov 2009 12:04:55 -0700 (MST) Reply-to: Ed Burns Message-id: <19187.8661.791927.886279@sun.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Content-transfer-encoding: 7BIT From: Ed Burns Sender: Ed.Burns@Sun.COM To: Timothy.Quinn@Sun.COM, Bill Shannon Cc: Roberto Chinnici , Ed Burns , Cheng Fang , Kenneth Saks , Barbara.Louis@Sun.COM Subject: Bean Validator Reality Check Date: Thu, 05 Nov 2009 11:04:53 -0800 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 Tim, Roberto and Bill, I would like to ask for a reality check on the timing of: 1. the reporting and discovery of this issue and 2. the likelyhood of getting the JSR-303 to accept this spec change after they've already gone final. 1. as we know, hard code freeze is Monday. The changes you are proposing are nontrivial. To complicate matters further, the latest BV integration we have from JBoss, which I packaged up as bean-validator-3.0-JBoss-4.0.1_03.jar, has been rolled back from glassfish nightlies due to apparent problems with SQE tests regarding BV and JPA. So, software engineering best practice suggests that we fix these other problems first, which are not yet even understood. Once those problems are fixed, THEN we should consider any changes of the magnitude you propose. 2. Declaring that the Validator instances created by the factory is in fact a spec change. This is more evidence that the JSR-303 EG did not consider the use case of sending a pre-configured validator instance over the wire from the server to the client. In order to do the changes you propose I think it would require a spec revision. Certainly out of the question with HCF Monday. I am going to mail Emmanuel and Hardy about this topic right now. I could be wrong but as a member of the EG, I don't think this use case was discussed. It seems to make sense that the validation code, the data being validated, and the actions that deal with the failure and success of the validation should all be on the same VM. I think we need a phone call on this. Bill? Roberto? Ed -- | ed.burns@sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/ From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2758" "Thursday" "5" "November" "2009" "11:35:55" "-0800" "Bill Shannon" "Bill.Shannon@Sun.COM" "<4AF3291B.7040505@sun.com>" "60" "Re: Bean Validator Reality Check" "^From:" nil nil "11" "2009110511:35:55" "Bean Validator Reality Check" nil "<4AF324BA.9050906@sun.com>" ("<19187.8661.791927.886279@sun.com>" "<4AF323F7.80000@sun.com>" "<4AF324BA.9050906@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Content-Length: 2758 Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 11:39:25 -0800 (PST) Received: from fe-sfbay-10.sun.com ([unknown] [192.18.34.120]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN000RIIDA1IE0@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 11:34:22 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00J00I2A9J00@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 11:34:22 -0800 (PST) Received: from phys-sfbay3-1.sfbay.sun.com ([unknown] [129.145.47.22]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN002RGICYP3E0@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 11:34:10 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([unknown] [129.146.11.31]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN000Q3ICY1IE0@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 11:34:10 -0800 (PST) Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA5JYAo8006199; Thu, 05 Nov 2009 11:34:10 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA5JY01Q017023; Thu, 05 Nov 2009 11:34:08 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSN00F07ICVJA00@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 12:34:07 -0700 (MST) Received: from nissan.sfbay.sun.com ([129.150.12.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSN005R8ICUPX90@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 12:34:07 -0700 (MST) Received: from [192.168.0.4] (vostro [192.168.0.4]) by nissan.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nA5JY6vW012335; Thu, 05 Nov 2009 11:34:06 -0800 (PST) In-reply-to: <4AF324BA.9050906@sun.com> Message-id: <4AF3291B.7040505@sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19187.8661.791927.886279@sun.com> <4AF323F7.80000@sun.com> <4AF324BA.9050906@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) From: Bill Shannon To: Tim Quinn Cc: Roberto Chinnici , Ed Burns , Cheng Fang , Kenneth Saks , Barbara.Louis@Sun.COM Subject: Re: Bean Validator Reality Check Date: Thu, 05 Nov 2009 11:35:55 -0800 Content-type: text/plain; format=flowed; charset=ISO-8859-1 MIME-version: 1.0 Tim Quinn wrote: > Roberto Chinnici wrote: >> Ed Burns wrote: >>> Tim, Roberto and Bill, I would like to ask for a reality check on the >>> timing of: 1. the reporting and discovery of this issue and 2. the >>> likelyhood of getting the JSR-303 to accept this spec change after >>> they've already gone final. >>> >>> 1. as we know, hard code freeze is Monday. The changes you are proposing >>> are nontrivial. To complicate matters further, the latest BV >>> integration we have from JBoss, which I packaged up as >>> bean-validator-3.0-JBoss-4.0.1_03.jar, has been rolled back from >>> glassfish nightlies due to apparent problems with SQE tests regarding BV >>> and JPA. So, software engineering best practice suggests that we fix >>> these other problems first, which are not yet even understood. Once >>> those problems are fixed, THEN we should consider any changes of the >>> magnitude you propose. >>> >>> 2. Declaring that the Validator instances created by the factory is in >>> fact a spec change. This is more evidence that the JSR-303 EG did not >>> consider the use case of sending a pre-configured validator instance >>> over the wire from the server to the client. In order to do the changes >>> you propose I think it would require a spec revision. Certainly out of >>> the question with HCF Monday. >>> >>> I am going to mail Emmanuel and Hardy about this topic right now. I >>> could be wrong but as a member of the EG, I don't think this use case >>> was discussed. >>> >>> It seems to make sense that the validation code, the data being >>> validated, and the actions that deal with the failure and success of the >>> validation should all be on the same VM. I think we need a phone call >>> on this. >>> >>> Bill? Roberto? >>> >> >> I can do pretty much any time today. How about at 1pm PT? >> > OK for me. Can we make it 1:15? Back to the original problem... I would never expect the spec to effectively require that a serialized validator instance be sent from the server to the client. What's more reasonable is that the instructions for creating a validator be made available to the client, so that it can create its own instance based on the same instructions the server used. Of course, those instructions would need to be independent of the server or client environment; I don't know anything about validation.xml so I don't if that's possible. I guess the tricky part is if a server module declares a validator in the app namespace and the client references it from that namespace, the configuration instructions (validation.xml?) from the server module need to be saved and made available to the client. Using serialization might be one implementation technique, but I wouldn't expect the spec to require it. From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3745" "Thursday" "5" "November" "2009" "15:54:12" "-0600" "Tim Quinn" "Timothy.Quinn@Sun.COM" "<4AF34984.3080806@sun.com>" "82" "Re: Bean Validator Reality Check" "^From:" nil nil "11" "2009110513:54:12" "Bean Validator Reality Check" nil "<19187.8661.791927.886279@sun.com>" ("<19187.8661.791927.886279@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Content-Length: 3745 Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 13:59:59 -0800 (PST) Received: from fe-amer-09.sun.com ([unknown] [192.18.109.79]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN006I6OUEG460@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 13:54:14 -0800 (PST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00F00OGG1G00@mail-amer.sun.com>; Thu, 05 Nov 2009 14:54:14 -0700 (MST) Received: from timothy-quinns-macbook-pro-2.local ([unknown] [67.163.34.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSN00DQSOUD44B0@mail-amer.sun.com>; Thu, 05 Nov 2009 14:54:13 -0700 (MST) In-reply-to: <19187.8661.791927.886279@sun.com> Message-id: <4AF34984.3080806@sun.com> Content-transfer-encoding: 7BIT References: <19187.8661.791927.886279@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) From: Tim Quinn Sender: Timothy.Quinn@Sun.COM To: Ed Burns Cc: Bill Shannon , Roberto Chinnici , Cheng Fang , Kenneth Saks , Barbara.Louis@Sun.COM Subject: Re: Bean Validator Reality Check Date: Thu, 05 Nov 2009 15:54:12 -0600 Content-type: text/plain; format=flowed; charset=ISO-8859-1 MIME-version: 1.0 Hi, everyone. Bill, Roberto, and I discussed this during a phone call this afternoon. There's wide agreement that the 303 spec does not address this use case. Given the current state and the current date, here's what we're proposing. For GlassFish v3 (i.e., the hard code freeze), GlassFish will resolve all Validator and ValidatorFactory references from app clients within the app client only. That is, even if the developer declares a Validator or ValidatorFactory in application.xml, the proxies running in the ACC will disregard those and return local objects, configured according to the META-INF/validation.xml in the app client module (if any). Roberto said that in adding the note in the EE platform spec about allowing declarations of these in the application.xml he intended such declarations to use the built-in names, not arbitrary names or scopes. Bill also mentioned something that Ken hit on during an earlier phone call with me, which is that there are just some kinds of objects that do not make sense to be used across VMs: local EJBs, for example. In essence, we're saying that GlassFish v3 will treat Validator and ValidatorFactory objects that way as well, at least as far as use from the app client container is concerned. Ed, do you agree with this approach? From my discussion with Ken earlier in the week and from looking at some code I understand that the proxies you created for Validator and ValidatorFactory objects handle this resolution now, so that's where the change would probably be. Cheng, if Ed agrees with this approach then once the changes are made (Ed, I'm assuming you'll be able to do that work?) the cts test should work. Note that app client references to Validator or ValidatorFactory objects will not use any configuration information on the server, even if application.xml declares them and even if the client refers to the name defined in application.xml. I'm also going to transfer the CR over to you, Ed, to reflect the upcoming changes to the Validator and ValidatorFactory proxies. - Tim Ed Burns wrote: > Tim, Roberto and Bill, I would like to ask for a reality check on the > timing of: 1. the reporting and discovery of this issue and 2. the > likelyhood of getting the JSR-303 to accept this spec change after > they've already gone final. > > 1. as we know, hard code freeze is Monday. The changes you are proposing > are nontrivial. To complicate matters further, the latest BV > integration we have from JBoss, which I packaged up as > bean-validator-3.0-JBoss-4.0.1_03.jar, has been rolled back from > glassfish nightlies due to apparent problems with SQE tests regarding BV > and JPA. So, software engineering best practice suggests that we fix > these other problems first, which are not yet even understood. Once > those problems are fixed, THEN we should consider any changes of the > magnitude you propose. > > 2. Declaring that the Validator instances created by the factory is in > fact a spec change. This is more evidence that the JSR-303 EG did not > consider the use case of sending a pre-configured validator instance > over the wire from the server to the client. In order to do the changes > you propose I think it would require a spec revision. Certainly out of > the question with HCF Monday. > > I am going to mail Emmanuel and Hardy about this topic right now. I > could be wrong but as a member of the EG, I don't think this use case > was discussed. > > It seems to make sense that the validation code, the data being > validated, and the actions that deal with the failure and success of the > validation should all be on the same VM. > > I think we need a phone call on this. > > Bill? Roberto? > > Ed > > From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4337" "Thursday" "5" "November" "2009" "14:12:39" "-0800" "Bill Shannon" "Bill.Shannon@Sun.COM" "<4AF34DD7.2020600@sun.com>" "90" "Re: Bean Validator Reality Check" "^From:" nil nil "11" "2009110514:12:39" "Bean Validator Reality Check" nil "<4AF34984.3080806@sun.com>" ("<19187.8661.791927.886279@sun.com>" "<4AF34984.3080806@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Content-Length: 4337 Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Thu, 05 Nov 2009 14:20:02 -0800 (PST) Received: from fe-sfbay-10.sun.com ([unknown] [192.18.34.120]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN006TYPN2G4D0@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 14:11:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00600PCKJY00@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 14:11:26 -0800 (PST) Received: from phys-sfbay3-1.sfbay.sun.com ([unknown] [129.145.47.22]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN005EAPM8ZD20@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 14:10:56 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([unknown] [129.146.11.31]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSN006N3PM7G4D0@sfbay3-mail1.sfbay.sun.com>; Thu, 05 Nov 2009 14:10:56 -0800 (PST) Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA5MAtnS012505; Thu, 05 Nov 2009 14:10:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA5MAgOl027121; Thu, 05 Nov 2009 22:10:52 +0000 (GMT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSN0081FPM2EZ00@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 15:10:50 -0700 (MST) Received: from nissan.sfbay.sun.com ([129.150.12.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSN00HPXPM1G780@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 15:10:50 -0700 (MST) Received: from [192.168.0.4] (vostro [192.168.0.4]) by nissan.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nA5MAn2B012439; Thu, 05 Nov 2009 14:10:49 -0800 (PST) In-reply-to: <4AF34984.3080806@sun.com> Message-id: <4AF34DD7.2020600@sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19187.8661.791927.886279@sun.com> <4AF34984.3080806@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) From: Bill Shannon To: Tim Quinn Cc: Ed Burns , Roberto Chinnici , Cheng Fang , Kenneth Saks , Barbara.Louis@Sun.COM Subject: Re: Bean Validator Reality Check Date: Thu, 05 Nov 2009 14:12:39 -0800 Content-type: text/plain; format=flowed; charset=ISO-8859-1 MIME-version: 1.0 Put another way... You can use whatever name you want for the reference to a Validator or ValidatorFactory, but the reference always resolves to *the* object for the module referencing it, not some object defined or configured by another module. And it doesn't matter which module created the reference in what namespace of what scope. The reference always resolves to the calling module's object. In that sense it's similar to UserTransaction or the ORB. Tim Quinn wrote: > Hi, everyone. > > Bill, Roberto, and I discussed this during a phone call this afternoon. > There's wide agreement that the 303 spec does not address this use > case. Given the current state and the current date, here's what we're > proposing. > > For GlassFish v3 (i.e., the hard code freeze), GlassFish will resolve > all Validator and ValidatorFactory references from app clients within > the app client only. That is, even if the developer declares a > Validator or ValidatorFactory in application.xml, the proxies running in > the ACC will disregard those and return local objects, configured > according to the META-INF/validation.xml in the app client module (if > any). Roberto said that in adding the note in the EE platform spec > about allowing declarations of these in the application.xml he intended > such declarations to use the built-in names, not arbitrary names or scopes. > > Bill also mentioned something that Ken hit on during an earlier phone > call with me, which is that there are just some kinds of objects that do > not make sense to be used across VMs: local EJBs, for example. > In essence, we're saying that GlassFish v3 will treat Validator and > ValidatorFactory objects that way as well, at least as far as use from > the app client container is concerned. > > Ed, do you agree with this approach? > From my discussion with Ken earlier in the week and from looking at > some code I understand that the proxies you created for Validator and > ValidatorFactory objects handle this resolution now, so that's where the > change would probably be. > Cheng, if Ed agrees with this approach then once the changes are made > (Ed, I'm assuming you'll be able to do that work?) the cts test should > work. Note that app client references to Validator or ValidatorFactory > objects will not use any configuration information on the server, even > if application.xml declares them and even if the client refers to the > name defined in application.xml. > > I'm also going to transfer the CR over to you, Ed, to reflect the > upcoming changes to the Validator and ValidatorFactory proxies. > > - Tim > > Ed Burns wrote: >> Tim, Roberto and Bill, I would like to ask for a reality check on the >> timing of: 1. the reporting and discovery of this issue and 2. the >> likelyhood of getting the JSR-303 to accept this spec change after >> they've already gone final. >> >> 1. as we know, hard code freeze is Monday. The changes you are proposing >> are nontrivial. To complicate matters further, the latest BV >> integration we have from JBoss, which I packaged up as >> bean-validator-3.0-JBoss-4.0.1_03.jar, has been rolled back from >> glassfish nightlies due to apparent problems with SQE tests regarding BV >> and JPA. So, software engineering best practice suggests that we fix >> these other problems first, which are not yet even understood. Once >> those problems are fixed, THEN we should consider any changes of the >> magnitude you propose. >> >> 2. Declaring that the Validator instances created by the factory is in >> fact a spec change. This is more evidence that the JSR-303 EG did not >> consider the use case of sending a pre-configured validator instance >> over the wire from the server to the client. In order to do the changes >> you propose I think it would require a spec revision. Certainly out of >> the question with HCF Monday. >> >> I am going to mail Emmanuel and Hardy about this topic right now. I >> could be wrong but as a member of the EG, I don't think this use case >> was discussed. >> >> It seems to make sense that the validation code, the data being >> validated, and the actions that deal with the failure and success of the >> validation should all be on the same VM. >> I think we need a phone call on this. >> >> Bill? Roberto? >> >> Ed >> >> > From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3578" "Thursday" "5" "November" "2009" "19:01:57" "-0800" "Ed Burns" "ed.burns@sun.com" "<19187.37285.340692.982388@sun.com>" "88" "Re: Bean Validator Reality Check" "^From:" nil nil "11" "2009110522:01:57" "Bean Validator Reality Check" nil "<4AF34984.3080806@sun.com>" ("<19187.8661.791927.886279@sun.com>" "<4AF34984.3080806@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Content-Transfer-Encoding: 7bit Message-ID: <19187.37285.340692.982388@sun.com> In-Reply-To: Re: Bean Validator Reality Check on 5 November 2009 References: <19187.8661.791927.886279@sun.com> <4AF34984.3080806@sun.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Reply-To: Ed Burns From: Ed Burns To: Tim Quinn Cc: Ed Burns , Bill Shannon , Roberto Chinnici , Cheng Fang , Kenneth Saks , Barbara.Louis@Sun.COM Subject: Re: Bean Validator Reality Check Date: Thu, 5 Nov 2009 19:01:57 -0800 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 >>>>> On Thu, 05 Nov 2009 15:54:12 -0600, Tim Quinn said: TQ> Hi, everyone. TQ> Bill, Roberto, and I discussed this during a phone call this afternoon. TQ> There's wide agreement that the 303 spec does not address this use TQ> case. Given the current state and the current date, here's what we're TQ> proposing. [...] TQ> In essence, we're saying that GlassFish v3 will treat Validator and TQ> ValidatorFactory objects that way as well, at least as far as use from TQ> the app client container is concerned. TQ> Ed, do you agree with this approach? Yes I do. TQ> From my discussion with Ken earlier in the week and from looking at TQ> some code I understand that the proxies you created for Validator and TQ> ValidatorFactory objects handle this resolution now, so that's where the TQ> change would probably be. TQ> Cheng, if Ed agrees with this approach then once the changes are made TQ> (Ed, I'm assuming you'll be able to do that work?) the cts test should TQ> work. Note that app client references to Validator or ValidatorFactory TQ> objects will not use any configuration information on the server, even TQ> if application.xml declares them and even if the client refers to the TQ> name defined in application.xml. Tim, as you know I'm traveling and speaking at a conference this week. Even if I wasn't traveling I feel you would be able to do the work faster. Can you please explain the changes that need to be made? TQ> I'm also going to transfer the CR over to you, Ed, to reflect the TQ> upcoming changes to the Validator and ValidatorFactory proxies. I understand wanting to get no bugs on you but if it's possible for you to make the changes, I'd really appreciate it. Thanks, Ed TQ> - Tim TQ> Ed Burns wrote: >> Tim, Roberto and Bill, I would like to ask for a reality check on the >> timing of: 1. the reporting and discovery of this issue and 2. the >> likelyhood of getting the JSR-303 to accept this spec change after >> they've already gone final. >> >> 1. as we know, hard code freeze is Monday. The changes you are proposing >> are nontrivial. To complicate matters further, the latest BV >> integration we have from JBoss, which I packaged up as >> bean-validator-3.0-JBoss-4.0.1_03.jar, has been rolled back from >> glassfish nightlies due to apparent problems with SQE tests regarding BV >> and JPA. So, software engineering best practice suggests that we fix >> these other problems first, which are not yet even understood. Once >> those problems are fixed, THEN we should consider any changes of the >> magnitude you propose. >> >> 2. Declaring that the Validator instances created by the factory is in >> fact a spec change. This is more evidence that the JSR-303 EG did not >> consider the use case of sending a pre-configured validator instance >> over the wire from the server to the client. In order to do the changes >> you propose I think it would require a spec revision. Certainly out of >> the question with HCF Monday. >> >> I am going to mail Emmanuel and Hardy about this topic right now. I >> could be wrong but as a member of the EG, I don't think this use case >> was discussed. >> >> It seems to make sense that the validation code, the data being >> validated, and the actions that deal with the failure and success of the >> validation should all be on the same VM. >> >> I think we need a phone call on this. >> >> Bill? Roberto? >> >> Ed >> >> -- | ed.burns@sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/ From mairix@mairix Mon Jan 1 12:34:56 1970 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["9564" "Friday" "6" "November" "2009" "16:02:05" "-0600" "Tim Quinn" "Timothy.Quinn@Sun.COM" "<4AF49CDD.9000304@sun.com>" "256" "Re: Bean Validator Reality Check" "^From:" nil nil "11" "2009110617:02:05" "Bean Validator Reality Check" nil "<19187.37285.340692.982388@sun.com>" ("<19187.8661.791927.886279@sun.com>" "<4AF34984.3080806@sun.com>" "<19187.37285.340692.982388@sun.com>") nil nil nil nil nil] nil) X-source-folder: /home/edburns/mail/bellsouth/.mail/Timothy.Quinn Content-Length: 9564 Return-path: Received: from mail-sfbay.sun.com [192.18.34.10] by sr1-usca-32 with IMAP (fetchmail-6.3.8) for (single-drop); Sat, 07 Nov 2009 07:13:31 -0800 (PST) Received: from fe-amer-09.sun.com ([unknown] [192.18.109.79]) by sfbay3-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KSP00IGPJVNT490@sfbay3-mail1.sfbay.sun.com>; Fri, 06 Nov 2009 14:02:11 -0800 (PST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSP00400JBKVM00@mail-amer.sun.com>; Fri, 06 Nov 2009 15:02:11 -0700 (MST) Received: from timothy-quinns-macbook-pro-2.local ([unknown] [67.163.34.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSP0085FJVHSZ30@mail-amer.sun.com>; Fri, 06 Nov 2009 15:02:06 -0700 (MST) In-reply-to: <19187.37285.340692.982388@sun.com> Message-id: <4AF49CDD.9000304@sun.com> References: <19187.8661.791927.886279@sun.com> <4AF34984.3080806@sun.com> <19187.37285.340692.982388@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) From: Tim Quinn Sender: Timothy.Quinn@Sun.COM To: Ed Burns Cc: Bill Shannon , Roberto Chinnici , Cheng Fang , Kenneth Saks , Barbara.Louis@Sun.COM Subject: Re: Bean Validator Reality Check Date: Fri, 06 Nov 2009 16:02:05 -0600 Content-type: multipart/alternative; boundary="Boundary_(ID_QrMORQaRtJCc8j6Pe+w26g)" MIME-version: 1.0 This is a multi-part message in MIME format. --Boundary_(ID_QrMORQaRtJCc8j6Pe+w26g) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Ed Burns wrote: >>>>>> On Thu, 05 Nov 2009 15:54:12 -0600, Tim Quinn said: >>>>>> > > TQ> Hi, everyone. > TQ> Bill, Roberto, and I discussed this during a phone call this afternoon. > TQ> There's wide agreement that the 303 spec does not address this use > TQ> case. Given the current state and the current date, here's what we're > TQ> proposing. > > [...] > > TQ> In essence, we're saying that GlassFish v3 will treat Validator and > TQ> ValidatorFactory objects that way as well, at least as far as use from > TQ> the app client container is concerned. > > TQ> Ed, do you agree with this approach? > > Yes I do. > OK. It's unanimous then. > TQ> From my discussion with Ken earlier in the week and from looking at > TQ> some code I understand that the proxies you created for Validator and > TQ> ValidatorFactory objects handle this resolution now, so that's where the > TQ> change would probably be. > > TQ> Cheng, if Ed agrees with this approach then once the changes are made > TQ> (Ed, I'm assuming you'll be able to do that work?) the cts test should > TQ> work. Note that app client references to Validator or ValidatorFactory > TQ> objects will not use any configuration information on the server, even > TQ> if application.xml declares them and even if the client refers to the > TQ> name defined in application.xml. > > Tim, as you know I'm traveling and speaking at a conference this week. > Even if I wasn't traveling I feel you would be able to do the work > faster. Can you please explain the changes that need to be made? > > TQ> I'm also going to transfer the CR over to you, Ed, to reflect the > TQ> upcoming changes to the Validator and ValidatorFactory proxies. > > I understand wanting to get no bugs on you but if it's possible for you > to make the changes, I'd really appreciate it. > Normally I'd have offered earlier to make the changes, but I have a very full plate through the weekend and Monday. The parts of the code potentially affected - the proxies and naming, perhaps? - are not ones at all familiar to me and I'd need time to understand what's happening now and what has to change to yield the behavior we want to see. Let's take stock again on Monday but I'm pessimistic that I'll have the cycles for this prior to the HCF. - Tim > Thanks, > > Ed > > TQ> - Tim > > TQ> Ed Burns wrote: > >>> Tim, Roberto and Bill, I would like to ask for a reality check on the >>> timing of: 1. the reporting and discovery of this issue and 2. the >>> likelyhood of getting the JSR-303 to accept this spec change after >>> they've already gone final. >>> >>> 1. as we know, hard code freeze is Monday. The changes you are proposing >>> are nontrivial. To complicate matters further, the latest BV >>> integration we have from JBoss, which I packaged up as >>> bean-validator-3.0-JBoss-4.0.1_03.jar, has been rolled back from >>> glassfish nightlies due to apparent problems with SQE tests regarding BV >>> and JPA. So, software engineering best practice suggests that we fix >>> these other problems first, which are not yet even understood. Once >>> those problems are fixed, THEN we should consider any changes of the >>> magnitude you propose. >>> >>> 2. Declaring that the Validator instances created by the factory is in >>> fact a spec change. This is more evidence that the JSR-303 EG did not >>> consider the use case of sending a pre-configured validator instance >>> over the wire from the server to the client. In order to do the changes >>> you propose I think it would require a spec revision. Certainly out of >>> the question with HCF Monday. >>> >>> I am going to mail Emmanuel and Hardy about this topic right now. I >>> could be wrong but as a member of the EG, I don't think this use case >>> was discussed. >>> >>> It seems to make sense that the validation code, the data being >>> validated, and the actions that deal with the failure and success of the >>> validation should all be on the same VM. >>> >>> I think we need a phone call on this. >>> >>> Bill? Roberto? >>> >>> Ed >>> >>> >>> > > --Boundary_(ID_QrMORQaRtJCc8j6Pe+w26g) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT

Ed Burns wrote: 
On Thu, 05 Nov 2009 15:54:12 -0600, Tim Quinn <Timothy.Quinn@Sun.COM> said:
            

TQ> Hi, everyone.
TQ> Bill, Roberto, and I discussed this during a phone call this afternoon.  
TQ> There's wide agreement that the 303 spec does not address this use 
TQ> case.  Given the current state and the current date, here's what we're 
TQ> proposing.

[...]

TQ> In essence, we're saying that GlassFish v3 will treat Validator and 
TQ> ValidatorFactory objects that way as well, at least as far as use from 
TQ> the app client container is concerned.

TQ> Ed, do you agree with this approach? 

Yes I do.
OK.  It's unanimous then.
TQ>  From my discussion with Ken earlier in the week and from looking at 
TQ> some code I understand that the proxies you created for Validator and 
TQ> ValidatorFactory objects handle this resolution now, so that's where the 
TQ> change would probably be. 

TQ> Cheng, if Ed agrees with this approach then once the changes are made 
TQ> (Ed, I'm assuming you'll be able to do that work?) the cts test should 
TQ> work.  Note that app client references to Validator or ValidatorFactory 
TQ> objects will not use any configuration information on the server, even 
TQ> if application.xml declares them and even if the client refers to the 
TQ> name defined in application.xml.

Tim, as you know I'm traveling and speaking at a conference this week.
Even if I wasn't traveling I feel you would be able to do the work
faster.  Can you please explain the changes that need to be made?

TQ> I'm also going to transfer the CR over to you, Ed, to reflect the 
TQ> upcoming changes to the Validator and ValidatorFactory proxies.

I understand wanting to get no bugs on you but if it's possible for you
to make the changes, I'd really appreciate it.
Normally I'd have offered earlier to make the changes, but I have a very full plate through the weekend and Monday. 

The parts of the code potentially affected - the proxies and naming, perhaps? - are not ones at all familiar to me and I'd need time to understand what's happening now and what has to change to yield the behavior we want to see. 

Let's take stock again on Monday but I'm pessimistic that I'll have the cycles for this prior to the HCF.

- Tim
Thanks,

Ed

TQ> - Tim

TQ> Ed Burns wrote:
  
Tim, Roberto and Bill, I would like to ask for a reality check on the
timing of: 1. the reporting and discovery of this issue and 2. the
likelyhood of getting the JSR-303 to accept this spec change after
they've already gone final.

1. as we know, hard code freeze is Monday. The changes you are proposing
are nontrivial.  To complicate matters further, the latest BV
integration we have from JBoss, which I packaged up as
bean-validator-3.0-JBoss-4.0.1_03.jar, has been rolled back from
glassfish nightlies due to apparent problems with SQE tests regarding BV
and JPA.  So, software engineering best practice suggests that we fix
these other problems first, which are not yet even understood.  Once
those problems are fixed, THEN we should consider any changes of the
magnitude you propose.

2. Declaring that the Validator instances created by the factory is in
fact a spec change.  This is more evidence that the JSR-303 EG did not
consider the use case of sending a pre-configured validator instance
over the wire from the server to the client.  In order to do the changes
you propose I think it would require a spec revision.  Certainly out of
the question with HCF Monday.

I am going to mail Emmanuel and Hardy about this topic right now.  I
could be wrong but as a member of the EG, I don't think this use case
was discussed.

It seems to make sense that the validation code, the data being
validated, and the actions that deal with the failure and success of the
validation should all be on the same VM.  

I think we need a phone call on this.

Bill? Roberto?

Ed

--Boundary_(ID_QrMORQaRtJCc8j6Pe+w26g)--