JavaServer Faces - $1500 – August 15, 2012

[shachar]

This is what we have done, the pointcut expression is

execution(public void Validator.validate(FacesContext, UIComponent, Object))

There is another pointcut for @FacesValidator:

public pointcut collectionPoint()
        : execution(public * (@FacesValidator *).*(..))
                && !execution(public void Validator.validate(FacesContext, UIComponent, Object));

[rhart]

Thanks for that. I'll have another iteration of the plugin and see if that's closer to your expectations. I'll post back as soon as it's available

[staceyeschneider]

Hi rhart,

Here is the reply from engineering's review. Overall they said it was a great start - but there are a few issues/suggestions:

1. Insight 1.8.3 was officially released so there is no need to use Insight 1.5.0
2. Managed beans which are declared in faces-confog.xml are not captured by this plugin
3. There is no need to capture all the managed bean's public methods, just the action methods
4. There is no need to capture all the validator's public method, just the "validate" method
5. More useful data should be extracted for the different operations and a FTL template should be provided for each operation type
6. JSF Lifecycle execute: what action was executed? what was returned?, for example (taken from travel app):
Screen shot 2012-08-21 at 15.01.18 PM.jpg
7. JSF Lifecycle render: what view was rendered?
8. JSF validator:
a. What value or component was validated?
b. Add TraceErrorAnalyzer to locate validation errors
9. JSF endpoint: JSF endpoint label should be more informational, and the endpoint name must be unique for every action - this is very important since insight collects metrics only on resources (Endpoint is a resource)
10. There isn't any reference to Ajax (was introduced in JSF 2.0)
11. There isn't any reference to phase listeners, action listeners and system events

There is an additional 12th comment for navigation - but I am not sure what engineering wanted to see here. I am clarifying.

[rhart]

Thanks. One of the developers had already posted them on this thread. I'm adressing them now and will post back when done. Cheers.

[staceyeschneider]

Sweet! Weird it didn't show that reply in my UI. I had asked Shachar to post here earlier because I couldn't get his screencap. I'll leave you two to work this out.

[rhart]

2. a. I believe that both annotated beans and faces-config.xml beans are resolved the same way

I've been doing some digging and ultimatley the managed beans are resolved by javax.el.ELResolver which I'm thinking is too general a class to collect on as the application itself may use these classes.

Both Mojarra and MyFaces invoke actions using an action listener which I can use to get the action source. This though only gives me the action expression and not the actual resolved class name. So, is this ok do you think? Would you be happy if the plugin reported the action expression rather than class#method?

Hope that makes sense.

[staceyeschneider]

Hi Rus, have we completed the iterations yet for engineering acceptance? Not sure if shachar got back to you on your question. Love to get this wrapped up, posted for all to use, and of course, you paid!

[rhart]

Hi,

I'm still waiting for an answer from shachar. I private messaged yesterday as it happens.

A lot of the changes have been made though so hopefully I won't be much longer after I get a reply and work out a way forward with "actions".

Thanks

[rhart]

Hi Rus, have we completed the iterations yet for engineering acceptance? Not sure if shachar got back to you on your question. Love to get this wrapped up, posted for all to use, and of course, you paid!

Hi. I still have had no reply to my question.

[shachar]

I've been doing some digging and ultimatley the managed beans are resolved by javax.el.ELResolver which I'm thinking is too general a class to collect on as the application itself may use these classes.

Both Mojarra and MyFaces invoke actions using an action listener which I can use to get the action source. This though only gives me the action expression and not the actual resolved class name. So, is this ok do you think? Would you be happy if the plugin reported the action expression rather than class#method?

Hope that makes sense.

Hi,

Sorry for the (very) late response (my apologies)

1. class#method - it's sufficient, though I think there is a way to get the class from the context (I'm not sure it's working it is just an idea)

public static Class<?> getBeanClass(Stirng expression) {
Class<?> toReturn = null;
int index = expression.indexOf('.');
if (index > -1) {
FacesContext ctx = FacesContext.getCurrentInstance();
String beanName = expression.substring(0, index+1);
Object bean = ctx.getApplication().createValueBinding("#{" + beanName + "}").getValue(ctx);
toReturn = bean != null ? bean.getClass() : null;
}
return toReturn;
}

2. ELResolver - I agree that it's very general (there might another way to do it) but I must emphasis the importance of resolving the actions - one of the main and useful Insight features is the metrics collection and aggregation. Insight is not a profiler (though some think it is). Insight only collects metrics on resources such as servers, applications and endpoints. To help the user locate and understand the problems in his applications we must supply a way to distinguish between the different endpoints and to give as much hints as we can so the developer will be able to track back the problematic piece of code.