[ssilvert]

"alesj" 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

[alesj]

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

[ssilvert]

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

[pmuir]

Stan, JNDI does have a performance overhead, especially if you call it extensively at runtime.

[ssilvert]

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

[pmuir]

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.

[ssilvert]

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

[alesj]

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.

[ssilvert]

"alesj" 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

[alesj]

Done - committed to Branch 5_x.
Can you merge with trunk?

[ssilvert]

"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

[alesj]

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.

[ssilvert]

"alesj" 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

[ssilvert]

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

[alesj]

"alesj" 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)