JavaServer Faces - $1500 – August 15, 2012

[rhart]

You have the code ready today?

It should be complete tonight but may run into tomorrow. I can either email the source and instructions to you or give you access to the private Git repository it's currently hosted in? Whatever you prefer.

[staceyeschneider]

We need it hosted on Git. (weird fact - laws on encryption prevent us from being able to accept code not publicly hosted) By all means though, I would encourage posting it publicly for the community to review as well.

[rhart]

Ok, no problem. I'll post the URL here when it's up.

Shall I PM you my payment details?

[rhart]

The plugin is now available.

The code and instructions can be found here https://github.com/rhart/spring-insight-jsf-plugin

The sample app and instructions can be found here https://github.com/rhart/spring-insi...culator-webapp

Pre built downloads can be found here https://github.com/rhart/spring-insi...ugin/downloads

And screen shots can be seen here https://github.com/rhart/spring-insi...n-Screen-Shots

[shachar]

Hi Rus,

My name is Shachar and I am a Spring Insight Dev team member

I reviewed your plugin and it's a great start, but there some changes to be made, in order to adhere to Insight standards regarding plugins:

1. General issues:
   
   1. Insight 1.8.3 was officially released so there is no need to use Insight 1.5.0
   2. More useful data should be extracted for the different operations - e.g., what value was returned from an action, view name that was rendered, value that was validated...
   3. FTL template file (for rendering the captured operation in the dashboard) should be provided for each operation type - see examples in other plugins
2. Managed/Backing beans:
   
   1. Beans declared in faces-config.xml are not captured by this plugin - they should also be monitored by the plugin
   2. There is no need to capture all public methods, just the action methods
3. Validators:
   
   1. There is no need to capture all public methods, just validate(FacesContext,UIComponent,Object)
   2. Validation using backing/managed bean methods is not captured by this plugin
   3. What value or component was validated? (more useful data...)
   4. Supply a TraceErrorAnalyzer to capture validation errors
4. Lifecycle execute:
   
   1. What action was executed?
   2. What was returned?
5. Lifecycle render:
   
   1. Which view was resolved?
   2. Which view was rendered?
6. Endpoint
   
   1. Label should be more informational (for example: PersonBean#calculateSalary)
   2. EndpointName (a.k.a. resource key in the code) must be unique for every action executed - e.g. should include at least the method signature
7. Listeners(phase listeners, action listeners...)
   None is captured by this plugin
8. Ajax
   There is no reference for Ajax calls

Shachar

[rhart]

Hi Shachar,

Thanks for your prompt evaluation. Please see my comments to your suggested changes below:

1. c. we thought that the default template provided sufficient information but can create a template per operation type.

2. a. I don't think this is possible. What pointcut expression could you use to know a bean is declared in faces-config??
2. b. How do you know what method is an 'action' method?? I dont think it's possible to create a pointcut expression to do this. Also, why would someone add a public method to a managed bean if it wasnt JSF related?

3. b. This contradicts 2. b

4. a. I'm not sure what you mean here. The lifecycle execute doesnt call an action, it co-ordinates the calling of the various phases. Maybe this 'grouping' of the phases should be removed?

4. b. Nothing is returned, comment as per 4. a.

5. Will see what can be done here.


Other than the above I can make a start on the changes. I may need to ask for more clarifications as I start making them :-)

Many thanks,

Rus

[Marten Deinum]

Hi Rus,

Just had a look at the plugin and as I'm working in a JSF2.x/CDI environment beans annotated with javax.inject.Named or javax.annotation.ManagedBean can also be JSF beans.

Maybe you can rewrite your pointcut from an execute on javax.faces.bean.ManagedBeans to something else. The managed beans are called from an ELResolver (probably) so maybe you can use that to trigger the monitoring (that way it doesn't matter where the managed bean comes from). Just a thought.

[rhart]

Maybe you can rewrite your pointcut from an execute on @ManagedBeans to something else. The managed beans are called from an ELResolver (probably) so maybe you can use that to trigger the monitoring (that way it doesn't matter where the managed bean comes from). Just a thought.

Thanks for the suggestion, sounds like a good one. I'll have a look at doing this.

[rhart]

There is no need to capture all public methods, just validate(FacesContext,UIComponent,Object)

This is what we have done, the pointcut expression is

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

[shachar]

Hi,

2. a. I believe that both annotated beans and faces-config.xml beans are resolved the same way
2. b. I do not think you can assume anything about the way applications are written. The plugin should capture the relevant data and filter out noise

3. b. and 2. b. complete each other - don't capture all public methods, capture action methods and validation methods

4 and 5 - because of these two issues one can not see how a certain action lead to a certain view (navigation). You are right that nothing is returned from Lifecycle#execute

Feel free to contact me at any time

Shachar