-
30. Re: Deploying ValidatorFactory
ssilvert Aug 18, 2009 8:31 AM (in response to epbernard)"alesj" wrote:
"stan.silvert@jboss.com" wrote:
Because I don't yet have a JSFDeployer, I do this in our JSF ServletContextListener. The only way I can do it is to create the VF myself or get it from JNDI.
Stan
Not true. ;-)
You can use my MC-int/servlet code and get VF from DeploymentUnit or VFF for that matter.
You should definitely not create it yourself, if we want to have a common VF for the whole module.
For MC-int usage see here:
- http://anonsvn.jboss.org/repos/jbossas/projects/mc-tools/grapher/trunk/src/main/java/org/jboss/mctools/grapher/GrapherServlet.java
VDFConnector as an entry point.
Is that better than getting it from JNDI?
Stan -
31. Re: Deploying ValidatorFactory
alesj Aug 18, 2009 8:43 AM (in response to epbernard)"stan.silvert@jboss.com" wrote:
Is that better than getting it from JNDI?
Dunno. :-)
I never liked JNDI, depending too much on that magic name.
If I can get it more type safe, I would use that.
But I guess you used JNDI a lot more than me.
And it's probably trivial to support both use cases - with proper simple abstraction;
e.g. if you port your code to other app server, there won't be mc-int -
32. Re: Deploying ValidatorFactory
ssilvert Aug 18, 2009 8:57 AM (in response to epbernard)It's great to know that I can get to the deployment unit from a Servlet or ServletContextListener. That's pretty cool.
But I want to keep my code as simple as possible. So I think a simple JNDI lookup will be best unless there is a perf reason or something else I'm not seeing.
Since we must choose a JNDI name that can never change, I think I'm OK depending on that name. This is JBoss AS integration code, so I'm not worried about portability to Glassfish. :-)
So are we set to go with the ValidatorFactoryJndiBinderDeployer? Is it in AS5.2 yet? What is the name I will use to find my VF?
Stan -
33. Re: Deploying ValidatorFactory
pmuir Aug 19, 2009 1:39 PM (in response to epbernard)Stan, JNDI does have a performance overhead, especially if you call it extensively at runtime.
-
34. Re: Deploying ValidatorFactory
ssilvert Aug 19, 2009 3:13 PM (in response to epbernard)"pete.muir@jboss.org" wrote:
Stan, JNDI does have a performance overhead, especially if you call it extensively at runtime.
Sure. But I'm talking about calling it once per JSF app. Will that be significant? Will it be any worse than going through all the machinations required to get the VF from the deployment unit?
I don't know the answer without profiling. But I do know which one is simpler and I'd like to go with JNDI first. Since we are required to put a reference in JNDI anyway, I'd like to go ahead and try getting it from there.
So what do we need to do to have the JNDI part working?
Stan -
35. Re: Deploying ValidatorFactory
pmuir Aug 19, 2009 3:32 PM (in response to epbernard)"stan.silvert@jboss.com" wrote:
"pete.muir@jboss.org" wrote:
Stan, JNDI does have a performance overhead, especially if you call it extensively at runtime.
Sure. But I'm talking about calling it once per JSF app. Will that be significant?
No, we were seeing issues calling JNDI hundreds of times a request. -
36. Re: Deploying ValidatorFactory
ssilvert Aug 19, 2009 4:00 PM (in response to epbernard)For AS6, I'll get it from the deployment unit. I will have easy access because I'll be adding a JSF Deployer that can set this up. But I can't use the JSF Deployer in AS5, so the VF has to be obtained from a ServletContextListener.
Stan -
37. Re: Deploying ValidatorFactory
alesj Aug 24, 2009 8:11 AM (in response to epbernard)"stan.silvert@jboss.com" wrote:
But I can't use the JSF Deployer in AS5, so the VF has to be obtained from a ServletContextListener.
Is this an issue or what?
With MC-int/Servlet code this is trivial to do,
if you need me to hack it, just point me to the code that requires it. -
38. Re: Deploying ValidatorFactory
ssilvert Aug 24, 2009 9:49 AM (in response to epbernard)"alesj" wrote:
"stan.silvert@jboss.com" wrote:
But I can't use the JSF Deployer in AS5, so the VF has to be obtained from a ServletContextListener.
Is this an issue or what?
With MC-int/Servlet code this is trivial to do,
if you need me to hack it, just point me to the code that requires it.
If you want to do it that way it's fine with me. Here is the code:
http://fisheye.jboss.org/browse/JBossAS/branches/Branch_5_x/tomcat/src/main/org/jboss/web/jsf/integration/config/JBossJSFConfigureListener.java?r=92409
My thought was that we need to put the instance into JNDI anyway, so I might as well get it from there. I understand JNDI a lot better than MC. But if you want to do it using MC then you just need to change this method:private void addBeanValidatorFactory() { this.servletContext.setAttribute(BeanValidator.VALIDATOR_FACTORY_KEY, Validation.buildDefaultValidatorFactory()); }
The ServletContext attribute must be set as shown, but we just need to get the VF instance that is created at deployment time instead of calling buildDefaultValidatorFactory().
If you decide to do it then please commit your code against this jira:
https://jira.jboss.org/jira/browse/JBAS-7178
Stan -
39. Re: Deploying ValidatorFactory
alesj Aug 24, 2009 12:15 PM (in response to epbernard)Done - committed to Branch 5_x.
Can you merge with trunk? -
40. Re: Deploying ValidatorFactory
ssilvert Aug 24, 2009 12:21 PM (in response to epbernard)"alesj" wrote:
Done - committed to Branch 5_x.
Can you merge with trunk?
Yes. I'll run the unit test against the new code and then merge to trunk.
Thanks,
Stan -
41. Re: Deploying ValidatorFactory
alesj Aug 24, 2009 12:24 PM (in response to epbernard)"stan.silvert@jboss.com" wrote:
I'll run the unit test against the new code and then merge to trunk.
Does this then mean that you already ported my VF-deployer code to trunk?
Otherwise new code won't kick in - it fall backs to old V::buildDefaultValidatorFactory code. -
42. Re: Deploying ValidatorFactory
ssilvert Aug 24, 2009 1:40 PM (in response to epbernard)"alesj" wrote:
"stan.silvert@jboss.com" wrote:
I'll run the unit test against the new code and then merge to trunk.
Does this then mean that you already ported my VF-deployer code to trunk?
Otherwise new code won't kick in - it fall backs to old V::buildDefaultValidatorFactory code.
No, I'm not that fast! :-)
I'm going to make sure it works in 5.2 before I port to trunk. Unfortunately, right now there is an error that keeps testsuite from building.
Stan -
43. Re: Deploying ValidatorFactory
ssilvert Aug 24, 2009 2:55 PM (in response to epbernard)I did another svn update and I got everything to build now. Your code isn't working:
14:40:28,347 ERROR [[/jbossws]] Error configuring application listener of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener java.lang.NoClassDefFoundError: org/jboss/mc/servlet/vdf/spi/VDFConnector at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
If you want to run my unit test:
1) Build AS 5.2
2) Build testsuite
3) Start AS 5.2
4) cd to testsuite and run:build one-test -Dtest=org.jboss.test.web.test.JSFIntegrationUnitTestCase
-
44. Re: Deploying ValidatorFactory
alesj Aug 24, 2009 3:01 PM (in response to epbernard)"stan.silvert@jboss.com" wrote:
"alesj" wrote:
"stan.silvert@jboss.com" wrote:
I'll run the unit test against the new code and then merge to trunk.
Does this then mean that you already ported my VF-deployer code to trunk?
Otherwise new code won't kick in - it fall backs to old V::buildDefaultValidatorFactory code.
No, I'm not that fast! :-)
Ah, I actually meant 5_x branch.
So, currently the VF deployer is not ported anywhere?
(ported in the same sense as we do it with WB deployer)