I'm using the #Scope annotation with value of "request".
How do I check if the given object with the "Scope" annotation is instantiated on each http request ?
Do the object (bean) have some identifier (hashcode ) ? And, I don't mean the bean id.
System.identityHashCode(theBeanVariable)
Print the hashes and check the objects are the same or not.
You gotta believe!
No, I'm kidding. Methods I used so far:
In eclipse if you stop application on a breakpoint you can check the id of every object in Variables tab. Every new instance of object has new id. You probably can find a place in your code that is executed after every (or some) request.
If you can set some fields of this bean via a web page, go and do it and then open the same page in new tab in your web browser. If request scope is working, fields you set should have old values (the one that are set on creation of object).
Maybe these are not uber-pro methods, but may be enough in some cases and you don't have to add anything in your code.
Related
I am experiencing a weird issue using spring mvc and session items.
We have a controller class annotated as follows:
#SessionAttributes({"customerPosition"})
according to the Spring doc, if I put into the model an object with the key customerPosition it gets automatically put into the session.
When I "manually" set the item with session.setAttribute("customerPosition",customerPosition) I exepect the item to be saved in session. if I get this item from the session by means of session.getAttribute("customerPosition") I get a different Item, not the one I expect. Actually what I get is data from previous iterations of the software flow.
It looks like that session.setAttribute("customerPosition",customerPosition) is not overwriting the object in session.
Does using #SessionAttributes prevents the possibility to manually control the session by means of session.setAttribute("customerPosition", customerPosition)
I have a few classes that interact with databases (more than one). Some classes are reused so for example "obs.table1" is used to interact with table1 in database "obs" while "ref.table1" is used to interact with table1 in database "ref". These databases are at different URLs and each gets its own connection pool, etc... obs.table1 and ref.table1 are both instances of MyTable1Class, defined in beans file.
I have a pointcut that intercepts calls to methods annotated with #Transactional or with a custom annotation #MyTablesAnnotation and have it set so those calls will all get routed into a #Around advice.
This all works and the flow through the advice is correct.
What I am trying to add is reporting on what is going on in there. Currently I can tell where in there I am, but I can't tell if it was obs.table1 or ref.table1 object that got me there.
Is there a way to extract the bean id of the object on whose method the advice was invoked on?
ProceedingJoinPoint that is passed to the method the only thing I do with it is call a .proceed on it and the rest is just various checks and catches. I see that I can get either the target class or proxy class out of it, but... not sure how to go from there to knowing what the bean id was.
Is it possible?
Firstly it is not recommended to depend on bean id as it creates tight coupling with framework.
To quote from docs Note that it is not usually recommended that an object depend on its bean name, as this represents a potentially brittle dependence on external configuration, as well as a possibly unnecessary dependence on a Spring API.
Now to answer your question yes it is possible to fetch the name of bean via org.springframework.beans.factory.BeanNameAware.
The class for which you require the bean name should implement it and spring will auto-magically inject the name of the bean. However there is a gotcha which you should be aware and is mentioned in docs here
I have a page with a dataTable, which is populated based on the query parameters (e.g., username and pagenum). Each entry in the table has a delete commandButton
When the pagenum != 0 and we click delete, the list of records to display is generated during the "apply" phase. During this phase the view parameters have not been set, so the list of records is empty so nothing get's deleted (our delete method doesn't get called)
To work around this I've added a #PostConstruct method that retrieves the query parameters from the Servlet request and sets the values in the bean, so they are available when we get the list of away records, which allows my delete method to be called.
I'm certain that JSF has a better way of handling this scenario and the #PostConstruct work around is a hack.
What is the correct way to implement this scenario, without resorting to a View or Session scoped bean?
Surely there must be a way to just POST the form and delete the appropriate record without having to waste time regenerating the list of records.
What is the correct way to implement this scenario, without resorting to a View or Session scoped bean? Surely there must be a way to just POST the form and delete the appropriate record without having to waste time regenerating the list of records
Sorry, there's no way. At least not when using a standard <h:commandButton> inside a standard <h:dataTable>. This is the consequence of the stateful nature of JSF. JSF just wants to ensure that the view is exactly the same during processing the postback as it was during generating the HTML output.
This is part of JSF's safeguard against tampered requests wherein the enduser/hacker can manipulate the request parameters in such way that it could do hazardful things, e.g. changing the ID of entry to delete, or bypassing the check on rendered attribute, etc. All those things on which you would/should do additional pre-validation anyway if JSF didn't do that for you and are easily overlooked by starters (they would then blame JSF for being insecure instead of themselves). See also Why JSF saves the state of UI components on server? and commandButton/commandLink/ajax action/listener method not invoked or input value not updated.
In case of <h:commandButton> inside <h:dataTable>, JSF simply needs to have the data model available during the apply request values phase, so that it can iterate over the <h:dataTable> in the component tree in order to find the pressed button and queue the action event. If there's no datamodel, then it can't find the pressed button and the action event won't be queued. Normally, this is to be solved by placing the managed bean in the JSF view scope. See also How to choose the right bean scope?
In case of request scoped beans, the <f:viewParam> is indeed not the right tool for the job of preserving the data model before apply request values phase takes place. You need to do the job in a #PostConstruct annotated method instead. The request parameters can in case of JSF managed beans be injected via #ManagedProperty. See also ViewParam vs #ManagedProperty(value = "#{param.id}"). In case of CDI or Spring managed beans, there's no standard annotation available to inject a HTTP request parameter as a bean property. For CDI, the JSF utility library OmniFaces has a #Param for the very purpose. See also OmniFaces #Param showcase. For Spring, you'd need to homegrow it yourself. I, as non-Spring-user have however no idea how to do that. Google also doesn't seem to reveal much.
Alternatively, you can also just put the bean in the view scope by #ViewScoped. It'll then live as long as you postback to the same view. JSF 2.2 has a CDI compatible annotation for that in javax.faces.view package. The one in javax.faces.bean package is the old JSF 2.0/2.1 annotation for #ManagedBean. Spring has no annotation out the box for this as that would otherwise put a dependency on JSF API. You'd need to homegrow it yourself. Google shows several examples.
What is the correct way to implement this scenario
Before executing the any logic on the backing bean, JSF always have to rebuild the view in order to get information about what to execute. For displaying and updating purpose, the best (and correct) solution is certainly the #ViewScoped.
without resorting to a View or Session scoped bean?
If you insist on using #RequestScoped, I'd say there're no correct ways but work-arounds or hacks. One way is to initialise the list in a #PostConstruct method like you've mentioned. Another way may be to use a JavaScript function for the onclick attribute of your delete button. The JS function, for example, will make a call to the server using a URL to request a delete. Or else, you can also use PrimeFace's RemoteCommand for the JS function.
Suppose I have a certain operation that should be available to every process running in Spring MVC.
Say string normalization--
i need to run a method that normalizes the string fields before doing anything else on that form/data.
One thing specific to do is, to normalize the String fields on every input form before
they are dispatched to the back-end services. Likewise, that operation (normalization)
should be run on data from the back-end before it is dispatched to the view component.
One way of doing this that I can think of is:
Code a bean doing it-- the normalization. Then, define this bean somewhere at the top in
the context hierarchy of Spring-- ApplicationContext.xml or WebApplicationContext.xml(?),
so that it will be visible and can be used
accross all the processes/servlets in the application.
Then, Whenever and from wherever needed, invoke that method on the bean defined up there.
Or, inject it to the relevant fields in the bean definitions(?)
In this case, is there a way to call it before or during a HandlerMapping is running? if so, how?
Another i can come up with is:
Code a validator (implement Validator) to run that process and "validate" the String fields for you.
But i dont see how this would be of good help.
From what i know, a validator runs on specific object types. I can define that type generically(?)
but then I'm operating on the fields-- not objects as a whole each.
Coding validator(s) seems too costly to me for this use-- even if it is an option here.
I'm new to Spring. pls bear with me on this.
I.e. I only want a nice way to retrieve existing objects from my Model (mostly some SessionAttributes).
I don't want new objects to be created and I especially don't want objects to be instantiated from request parameters and put into the model. This just sounds like a back door to me.
It would also be great if an Exception can be thrown if no matching parameter is in the model.
I got the answer to this by reading the source code. According to the implementation of org.springframework.web.bind.annotation.support.HandlerMethodInvoker.resolveModelAttribute, a new bind Object will not be created if the name of the model attribute is declared as a session attribute using the #SessionAttributes annotation.
If the attribute is not present in the session, an Exception will be thrown.
So it is relatively safe to bind session attributes this way.