|
»
Disabling Bean Validation JNDI binder deployer in 5.2 Beta
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Disabling Bean Validation JNDI binder deployer in 5.2 Beta
by Jason T. Greene
::
Rate this Message:
The big reason for this is to allow user deployments to do their own
validation, and they don't typically have access to the DeploymentUnit. Even though the location will change in the final version, doesn't it seem worth keeping, so that folks can try out BV? If the bug isnt a simple fix, and it only affects ws dynamic endpoints then I don't see it as a beta release blocker. Stan Silvert wrote: > The simplest way to solve the issue below is to just disable the > ValidatorFactoryJndiBinderDeployer. > > I've been thinking that using this deployer is probably the wrong way to > go. Originally, it was supposed to put a bean validator factory into > the deployment's java:comp context, as required by the JEE6 spec. But > when this deployer runs, that context isn't available yet. So the best > it could do was to bind it to global JNDI and hope that some later code > could bind it to the right place. But that "later code" can just as > easily get its reference from the DeploymentUnit. > > So right now it creates a global JNDI reference for each deployment > under BeanValidatorFactories/<deployment simple name>. We know this is > wrong and I don't think anyone is relying on the global JNDI reference, > BUT IF YOU ARE PLEASE LET ME KNOW. > > To be clear, the ValidatorFactoryDeployer that puts the factory into the > DeploymentUnit will still do its job. It's just that I want to get rid > of this failed attempt to satisfy the JNDI requirement. There are a > couple of ways to actually satisfy it, and I expect to do this post-beta. > > Stan > > Richard Opalka (JIRA) wrote: >> [ https://jira.jboss.org/jira/browse/JBAS-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] >> >> Richard Opalka reassigned JBAS-7384: >> ------------------------------------ >> >> Assignee: Stan Silvert (was: Ales Justin) >> >> >> Reassigning to Stan (he's repsonsible for BV code) >> >> >>> org.jboss.test.webservice.endpoint.EndpointTestCase fails because of beanvalidation deployer >>> -------------------------------------------------------------------------------------------- >>> >>> Key: JBAS-7384 >>> URL: https://jira.jboss.org/jira/browse/JBAS-7384 >>> Project: JBoss Application Server >>> Issue Type: Sub-task >>> Security Level: Public(Everyone can see) >>> Components: Web Services >>> Reporter: Shelly McGowan >>> Assignee: Stan Silvert >>> Fix For: JBossAS-5.2.0.Beta1 >>> >>> >>> These newly added tests are failing. Filing to track. >>> testWSDLAccess: >>> javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: Unable to resolve imported document at 'http://localhost:8080/jaxws-endpoint?wsdl'.: java.io.FileNotFoundException: This file was not found: http://localhost:8080/jaxws-endpoint?wsdl >>> testClientAccess: >>> javax.xml.ws.WebServiceException: java.io.IOException: Could not transmit message >>> Caused by: org.jboss.ws.WSException: Invalid HTTP server response [404] - Not Found >>> testServletAccess: >>> java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8080/jaxws-endpoint-servlet?param=hello-world >>> >> > > > _______________________________________________ > jboss-development mailing list > jboss-development@... > https://lists.jboss.org/mailman/listinfo/jboss-development -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: Disabling Bean Validation JNDI binder deployer in 5.2 Beta
by Stan Silvert-2
::
Rate this Message:
Either way is fine with me.
Note that JSF Managed Beans will still use BV, so folks can try that out. And non-JSF developers can still create their own BV Factory instead of having it injected from JNDI. It just seems to make sense to go ahead and get rid of something that is going to go away next release. Stan Jason T. Greene wrote: > The big reason for this is to allow user deployments to do their own > validation, and they don't typically have access to the DeploymentUnit. > > Even though the location will change in the final version, doesn't it > seem worth keeping, so that folks can try out BV? > > If the bug isnt a simple fix, and it only affects ws dynamic endpoints > then I don't see it as a beta release blocker. > > Stan Silvert wrote: >> The simplest way to solve the issue below is to just disable the >> ValidatorFactoryJndiBinderDeployer. >> I've been thinking that using this deployer is probably the wrong way >> to go. Originally, it was supposed to put a bean validator factory >> into the deployment's java:comp context, as required by the JEE6 >> spec. But when this deployer runs, that context isn't available >> yet. So the best it could do was to bind it to global JNDI and hope >> that some later code could bind it to the right place. But that >> "later code" can just as easily get its reference from the >> DeploymentUnit. >> >> So right now it creates a global JNDI reference for each deployment >> under BeanValidatorFactories/<deployment simple name>. We know this >> is wrong and I don't think anyone is relying on the global JNDI >> reference, BUT IF YOU ARE PLEASE LET ME KNOW. >> >> To be clear, the ValidatorFactoryDeployer that puts the factory into >> the DeploymentUnit will still do its job. It's just that I want to >> get rid of this failed attempt to satisfy the JNDI requirement. >> There are a couple of ways to actually satisfy it, and I expect to do >> this post-beta. >> >> Stan >> >> Richard Opalka (JIRA) wrote: >>> [ >>> https://jira.jboss.org/jira/browse/JBAS-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>> ] >>> >>> Richard Opalka reassigned JBAS-7384: >>> ------------------------------------ >>> >>> Assignee: Stan Silvert (was: Ales Justin) >>> >>> >>> Reassigning to Stan (he's repsonsible for BV code) >>> >>> >>>> org.jboss.test.webservice.endpoint.EndpointTestCase fails because >>>> of beanvalidation deployer >>>> -------------------------------------------------------------------------------------------- >>>> >>>> >>>> Key: JBAS-7384 >>>> URL: https://jira.jboss.org/jira/browse/JBAS-7384 >>>> Project: JBoss Application Server >>>> Issue Type: Sub-task >>>> Security Level: Public(Everyone can see) Components: >>>> Web Services >>>> Reporter: Shelly McGowan >>>> Assignee: Stan Silvert >>>> Fix For: JBossAS-5.2.0.Beta1 >>>> >>>> >>>> These newly added tests are failing. Filing to track. >>>> testWSDLAccess: >>>> javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: >>>> Unable to resolve imported document at >>>> 'http://localhost:8080/jaxws-endpoint?wsdl'.: >>>> java.io.FileNotFoundException: This file was not found: >>>> http://localhost:8080/jaxws-endpoint?wsdl >>>> testClientAccess: >>>> javax.xml.ws.WebServiceException: java.io.IOException: Could not >>>> transmit message >>>> Caused by: org.jboss.ws.WSException: Invalid HTTP server response >>>> [404] - Not Found >>>> testServletAccess: >>>> java.io.IOException: Server returned HTTP response code: 500 for >>>> URL: http://localhost:8080/jaxws-endpoint-servlet?param=hello-world >>>> >>> >> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development@... >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: Disabling Bean Validation JNDI binder deployer in 5.2 Beta
by Jason T. Greene
::
Rate this Message:
Ah, thats a good point. Ok, I'm fine with removing it for now.
Stan Silvert wrote: > Either way is fine with me. > Note that JSF Managed Beans will still use BV, so folks can try that > out. And non-JSF developers can still create their own BV Factory > instead of having it injected from JNDI. It just seems to make sense to > go ahead and get rid of something that is going to go away next release. > > Stan > > Jason T. Greene wrote: >> The big reason for this is to allow user deployments to do their own >> validation, and they don't typically have access to the DeploymentUnit. >> >> Even though the location will change in the final version, doesn't it >> seem worth keeping, so that folks can try out BV? >> >> If the bug isnt a simple fix, and it only affects ws dynamic endpoints >> then I don't see it as a beta release blocker. >> >> Stan Silvert wrote: >>> The simplest way to solve the issue below is to just disable the >>> ValidatorFactoryJndiBinderDeployer. >>> I've been thinking that using this deployer is probably the wrong way >>> to go. Originally, it was supposed to put a bean validator factory >>> into the deployment's java:comp context, as required by the JEE6 >>> spec. But when this deployer runs, that context isn't available >>> yet. So the best it could do was to bind it to global JNDI and hope >>> that some later code could bind it to the right place. But that >>> "later code" can just as easily get its reference from the >>> DeploymentUnit. >>> >>> So right now it creates a global JNDI reference for each deployment >>> under BeanValidatorFactories/<deployment simple name>. We know this >>> is wrong and I don't think anyone is relying on the global JNDI >>> reference, BUT IF YOU ARE PLEASE LET ME KNOW. >>> >>> To be clear, the ValidatorFactoryDeployer that puts the factory into >>> the DeploymentUnit will still do its job. It's just that I want to >>> get rid of this failed attempt to satisfy the JNDI requirement. >>> There are a couple of ways to actually satisfy it, and I expect to do >>> this post-beta. >>> >>> Stan >>> >>> Richard Opalka (JIRA) wrote: >>>> [ >>>> https://jira.jboss.org/jira/browse/JBAS-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>>> ] >>>> >>>> Richard Opalka reassigned JBAS-7384: >>>> ------------------------------------ >>>> >>>> Assignee: Stan Silvert (was: Ales Justin) >>>> >>>> >>>> Reassigning to Stan (he's repsonsible for BV code) >>>> >>>> >>>>> org.jboss.test.webservice.endpoint.EndpointTestCase fails because >>>>> of beanvalidation deployer >>>>> -------------------------------------------------------------------------------------------- >>>>> >>>>> >>>>> Key: JBAS-7384 >>>>> URL: https://jira.jboss.org/jira/browse/JBAS-7384 >>>>> Project: JBoss Application Server >>>>> Issue Type: Sub-task >>>>> Security Level: Public(Everyone can see) Components: >>>>> Web Services >>>>> Reporter: Shelly McGowan >>>>> Assignee: Stan Silvert >>>>> Fix For: JBossAS-5.2.0.Beta1 >>>>> >>>>> >>>>> These newly added tests are failing. Filing to track. >>>>> testWSDLAccess: >>>>> javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: >>>>> Unable to resolve imported document at >>>>> 'http://localhost:8080/jaxws-endpoint?wsdl'.: >>>>> java.io.FileNotFoundException: This file was not found: >>>>> http://localhost:8080/jaxws-endpoint?wsdl >>>>> testClientAccess: >>>>> javax.xml.ws.WebServiceException: java.io.IOException: Could not >>>>> transmit message >>>>> Caused by: org.jboss.ws.WSException: Invalid HTTP server response >>>>> [404] - Not Found >>>>> testServletAccess: >>>>> java.io.IOException: Server returned HTTP response code: 500 for >>>>> URL: http://localhost:8080/jaxws-endpoint-servlet?param=hello-world >>>>> >>>> >>> >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development@... >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> > > -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: Disabling Bean Validation JNDI binder deployer in 5.2 Beta
by Emmanuel Bernard
::
Rate this Message:
+1
esp since the real application use is through injection and we won't support that for this beta @Resource Validator validator; / @Inject Validator validator; On 23 oct. 09, at 22:31, Jason T. Greene wrote: > Ah, thats a good point. Ok, I'm fine with removing it for now. > > Stan Silvert wrote: >> Either way is fine with me. >> Note that JSF Managed Beans will still use BV, so folks can try that >> out. And non-JSF developers can still create their own BV Factory >> instead of having it injected from JNDI. It just seems to make >> sense to >> go ahead and get rid of something that is going to go away next >> release. >> >> Stan >> >> Jason T. Greene wrote: >>> The big reason for this is to allow user deployments to do their own >>> validation, and they don't typically have access to the >>> DeploymentUnit. >>> >>> Even though the location will change in the final version, doesn't >>> it >>> seem worth keeping, so that folks can try out BV? >>> >>> If the bug isnt a simple fix, and it only affects ws dynamic >>> endpoints >>> then I don't see it as a beta release blocker. >>> >>> Stan Silvert wrote: >>>> The simplest way to solve the issue below is to just disable the >>>> ValidatorFactoryJndiBinderDeployer. >>>> I've been thinking that using this deployer is probably the wrong >>>> way >>>> to go. Originally, it was supposed to put a bean validator factory >>>> into the deployment's java:comp context, as required by the JEE6 >>>> spec. But when this deployer runs, that context isn't available >>>> yet. So the best it could do was to bind it to global JNDI and >>>> hope >>>> that some later code could bind it to the right place. But that >>>> "later code" can just as easily get its reference from the >>>> DeploymentUnit. >>>> >>>> So right now it creates a global JNDI reference for each deployment >>>> under BeanValidatorFactories/<deployment simple name>. We know >>>> this >>>> is wrong and I don't think anyone is relying on the global JNDI >>>> reference, BUT IF YOU ARE PLEASE LET ME KNOW. >>>> >>>> To be clear, the ValidatorFactoryDeployer that puts the factory >>>> into >>>> the DeploymentUnit will still do its job. It's just that I want to >>>> get rid of this failed attempt to satisfy the JNDI requirement. >>>> There are a couple of ways to actually satisfy it, and I expect >>>> to do >>>> this post-beta. >>>> >>>> Stan >>>> >>>> Richard Opalka (JIRA) wrote: >>>>> [ >>>>> https://jira.jboss.org/jira/browse/JBAS-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>>>> ] >>>>> >>>>> Richard Opalka reassigned JBAS-7384: >>>>> ------------------------------------ >>>>> >>>>> Assignee: Stan Silvert (was: Ales Justin) >>>>> >>>>> >>>>> Reassigning to Stan (he's repsonsible for BV code) >>>>> >>>>> >>>>>> org.jboss.test.webservice.endpoint.EndpointTestCase fails because >>>>>> of beanvalidation deployer >>>>>> -------------------------------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> Key: JBAS-7384 >>>>>> URL: https://jira.jboss.org/jira/browse/JBAS-7384 >>>>>> Project: JBoss Application Server >>>>>> Issue Type: Sub-task >>>>>> Security Level: Public(Everyone can see) Components: >>>>>> Web Services >>>>>> Reporter: Shelly McGowan >>>>>> Assignee: Stan Silvert >>>>>> Fix For: JBossAS-5.2.0.Beta1 >>>>>> >>>>>> >>>>>> These newly added tests are failing. Filing to track. >>>>>> testWSDLAccess: >>>>>> javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: >>>>>> Unable to resolve imported document at >>>>>> 'http://localhost:8080/jaxws-endpoint?wsdl'.: >>>>>> java.io.FileNotFoundException: This file was not found: >>>>>> http://localhost:8080/jaxws-endpoint?wsdl >>>>>> testClientAccess: >>>>>> javax.xml.ws.WebServiceException: java.io.IOException: Could not >>>>>> transmit message >>>>>> Caused by: org.jboss.ws.WSException: Invalid HTTP server response >>>>>> [404] - Not Found >>>>>> testServletAccess: >>>>>> java.io.IOException: Server returned HTTP response code: 500 for >>>>>> URL: http://localhost:8080/jaxws-endpoint-servlet?param=hello-world >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development@... >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >>> >> >> > > > -- > Jason T. Greene > JBoss, a division of Red Hat > _______________________________________________ > jboss-development mailing list > jboss-development@... > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: Disabling Bean Validation JNDI binder deployer in 5.2 Beta
by Pete Muir
::
Rate this Message:
FTR, we do support @Inject Validator validator in Branch_5_x, and we
don't use JNDI, but access it from the deployment. On 24 Oct 2009, at 10:22, Emmanuel Bernard wrote: > +1 > esp since the real application use is through injection and we won't > support that for this beta > > @Resource Validator validator; / @Inject Validator validator; > > On 23 oct. 09, at 22:31, Jason T. Greene wrote: > >> Ah, thats a good point. Ok, I'm fine with removing it for now. >> >> Stan Silvert wrote: >>> Either way is fine with me. >>> Note that JSF Managed Beans will still use BV, so folks can try that >>> out. And non-JSF developers can still create their own BV Factory >>> instead of having it injected from JNDI. It just seems to make >>> sense to >>> go ahead and get rid of something that is going to go away next >>> release. >>> >>> Stan >>> >>> Jason T. Greene wrote: >>>> The big reason for this is to allow user deployments to do their >>>> own >>>> validation, and they don't typically have access to the >>>> DeploymentUnit. >>>> >>>> Even though the location will change in the final version, doesn't >>>> it >>>> seem worth keeping, so that folks can try out BV? >>>> >>>> If the bug isnt a simple fix, and it only affects ws dynamic >>>> endpoints >>>> then I don't see it as a beta release blocker. >>>> >>>> Stan Silvert wrote: >>>>> The simplest way to solve the issue below is to just disable the >>>>> ValidatorFactoryJndiBinderDeployer. >>>>> I've been thinking that using this deployer is probably the wrong >>>>> way >>>>> to go. Originally, it was supposed to put a bean validator >>>>> factory >>>>> into the deployment's java:comp context, as required by the JEE6 >>>>> spec. But when this deployer runs, that context isn't available >>>>> yet. So the best it could do was to bind it to global JNDI and >>>>> hope >>>>> that some later code could bind it to the right place. But that >>>>> "later code" can just as easily get its reference from the >>>>> DeploymentUnit. >>>>> >>>>> So right now it creates a global JNDI reference for each >>>>> deployment >>>>> under BeanValidatorFactories/<deployment simple name>. We know >>>>> this >>>>> is wrong and I don't think anyone is relying on the global JNDI >>>>> reference, BUT IF YOU ARE PLEASE LET ME KNOW. >>>>> >>>>> To be clear, the ValidatorFactoryDeployer that puts the factory >>>>> into >>>>> the DeploymentUnit will still do its job. It's just that I want >>>>> to >>>>> get rid of this failed attempt to satisfy the JNDI requirement. >>>>> There are a couple of ways to actually satisfy it, and I expect >>>>> to do >>>>> this post-beta. >>>>> >>>>> Stan >>>>> >>>>> Richard Opalka (JIRA) wrote: >>>>>> [ >>>>>> https://jira.jboss.org/jira/browse/JBAS-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>>>>> ] >>>>>> >>>>>> Richard Opalka reassigned JBAS-7384: >>>>>> ------------------------------------ >>>>>> >>>>>> Assignee: Stan Silvert (was: Ales Justin) >>>>>> >>>>>> >>>>>> Reassigning to Stan (he's repsonsible for BV code) >>>>>> >>>>>> >>>>>>> org.jboss.test.webservice.endpoint.EndpointTestCase fails >>>>>>> because >>>>>>> of beanvalidation deployer >>>>>>> -------------------------------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> Key: JBAS-7384 >>>>>>> URL: https://jira.jboss.org/jira/browse/JBAS-7384 >>>>>>> Project: JBoss Application Server >>>>>>> Issue Type: Sub-task >>>>>>> Security Level: Public(Everyone can see) Components: >>>>>>> Web Services >>>>>>> Reporter: Shelly McGowan >>>>>>> Assignee: Stan Silvert >>>>>>> Fix For: JBossAS-5.2.0.Beta1 >>>>>>> >>>>>>> >>>>>>> These newly added tests are failing. Filing to track. >>>>>>> testWSDLAccess: >>>>>>> javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: >>>>>>> Unable to resolve imported document at >>>>>>> 'http://localhost:8080/jaxws-endpoint?wsdl'.: >>>>>>> java.io.FileNotFoundException: This file was not found: >>>>>>> http://localhost:8080/jaxws-endpoint?wsdl >>>>>>> testClientAccess: >>>>>>> javax.xml.ws.WebServiceException: java.io.IOException: Could not >>>>>>> transmit message >>>>>>> Caused by: org.jboss.ws.WSException: Invalid HTTP server >>>>>>> response >>>>>>> [404] - Not Found >>>>>>> testServletAccess: >>>>>>> java.io.IOException: Server returned HTTP response code: 500 for >>>>>>> URL: http://localhost:8080/jaxws-endpoint-servlet?param=hello-world >>>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development@... >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> >>> >>> >> >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-development mailing list >> jboss-development@... >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development@... > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
| Free embeddable forum powered by Nabble | Forum Help |
