I had a managed bean called controlBean and i deleted it. Then i tried to add a new bean with the same name. I also had deleted it from faces-config.xml file, which was looking like this:
<managed-bean>
<managed-bean-name>controlBean</managed-bean-name>
<managed-bean-class>com.app.managedbeans.ControlBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
The problem is, even though i specify its name as controlBean again, NetBeans calls it controlBean1, and if i delete and add again it is called controlBean2 etc. Does anyone know the reason? What can i see to fix it?
Thanks
Please check you have added a default constructors for other managed beans.
I had the same issue with Netbeans 7.3. I have used annotations instead in that case. I added some methods to the few other beans. Stopped the GlassFish server. Deleted the dis and build folders manually. Clean and build the project again. Ant that error was not there for the time being. Don't know the exact cause. I had to do this few times for other beans as well.
If still not response, create a new bean and let it be there until a proper solution is available.
Get rid of all this XML and use the #ManagedBean annotation.
Related
I have a internet shop application. I wanted to improve "removing from the cart" feature. I don't want to ask an user if he wants to "really remove" the position from the cart, instead I'd like to allow him cancel the operation.
Currently when user clicks "X" button at the product in the cart, row of table changes to "removed, click to cancel". In the back there is a list of CartPosition objects every with flag removed. Removed product is still on list, but the flag is set to true. It makes product still visible in proper position on the list, but on the view side I can render it another way. When user clicks another "X", previous one is premamently removed from the list and new one is marked as removed.
Shopping cart is session scoped CDI bean. It means, when I mark some position removed and go somewhere else, then go back to the cart, I'll still have one row marked as removed. I just don't want this.
I thought about changing the bean to JSF one, then create another view scoped which could keep record marked as removed and check if it's empty, if so I could remove the one from list. I have no idea if it's going to work. I'll try this approach, but I'd rather keep my beans managed by CDI.
Is there a way to handle this without implementing my above idea?
EDIT: #BalusC, your assumptions are wrong. You should rather suppose, that I don't exactly know how can I mix CDI and JSF. I actually use JSF 2.2, what means that javax.faces.view.ViewScoped annotation is available for me. Anyway I still don't understand the idea. I understood, that I have to rely on some ViewScoped bean. It's clear, but how it has to be composed. Can you explain your idea? I tried few things, but it looked it didn't work correctly. For example my #PreDestroy method of ViewScoped bean was never called and it's constructed lazily only when I try to use it.
Do the actual remove job in #PreDestroy annotated method of the session or view scoped bean.
#PreDestroy
public void destroy() {
// Do the actual remove job here.
}
Given that your question implies that you don't have CDI based javax.faces.view.ViewScoped available, which is new since JSF 2.2, this in turn suggests that you're still on JSF 2.0/2.1 and thus only have JSF based javax.faces.bean.ViewScoped at hands, then it should be noted that its #PreDestroy is broken in several circumstances. You'd then best do the #PreDestroy in the CDI based #SessionScoped bean. Alternatively, you could use OmniFaces #ViewScoped which has fixed and improved the #PreDestroy of a #ViewScoped bean in several ways. It even gets invoked on window unload.
As far as I understood your problem is the session. One way to solve the problem is to set the list of removed products in a request attribute and remove it from the session bean so that on the next request they will disappear.
Hope that helps
Environment:
JSF 2.1.11
el-api 2.2
Eclipse Kepler
Tomcat 7
Chrome
IE-11
I have a working xhtml and bean which contains several action methods and work fine.
I added another commandButton:
<h:commandButton id="idBtnSave" value="Save"
action="#{imageMetadataEditProvider.saveLabelWithBox}"></h:commandButton>
...and the action method:
public void saveLabelWithBox() {
saveBoundingBox();
saveImage();
}
... then for some inexplicable reason, EL cannot find method saveLabelWithBox on the bean.
I did several rounds of renaming the method, rebuilding, undeploying and cleaning the Tomcat environment, redeploy. That almost always failed.
HOWEVER, What seemed to work was simply to move the saveLabelWithBox(){} block to elsewhere in the bean. Suddenly, it worked again, so I gullibly renamed the method to something more meaningful, then it failed again... EL could not find the method. So I again renamed it and moved it, rebuilt, redeployed, now it works again.
I'm curious whether others have had such quirky behavior and what you think might cause this, beyond the typical suspects of corrupt Eclipse workspace, or being on a microwave beam path.
I finally resolved this quirky problem which seemed related to corruption in the environment. The cure seemed to be to create a new bean with a different name and import all the methods from the formerly unreliable bean. I also did the usual Eclipse -clean startup, although that seemed to have no effect. I also removed the Eclipse .metadata and restarted, although that also seemed to have no effect.
Oddly, after building a new replacement bean, it would not load via annotations:
#ManagedBean
#ViewScoped
...so I was obliged to define the replacement bean in faces-config, and then it would load at page request time. I think there is still something screwed up in the environment. But all the methods are now being resolved and it's been working OK for a couple of days.
Your mileage may vary.
If I create my own managed bean is it possible to get the type ahead to work in Domino Designer with my own Bean / Java Code?
I have a MB DebugHelper. As you can see from the screenshot, it shows the bean method debugPrint() as soon as I type the dot. Is this, what you asked for?
Can anyone tell me if it is possible to keep managed beans in separate .xsp-config configuration files?
And if yes than how to do this? I have tried and it only worked if I put them into faces-config.xml file.
If you want to split your bean definitions into multiple configuration files, you'll need to create an OSGi plugin. XSP libraries can contain more than one faces-config file (and you can name them whatever you want, because you specify in the library class which XML files contain faces-config definitions). But in an NSF, you're limited to just the auto-generated faces-config.xml file.
Yes, Managed beans must be defined in the faces-config.xml file.
For a good reference on all the different options within faces-config and xsp-config take a look at this website. It describes the format of pretty much everything you might ever want to add to a faces-config or xsp-config and a brief description of the options.
As far as I know they have to be in the faces-config.xml
faces-config is a JSF implementation, you should check out the JSF specification for this, there are even some good post in this forum like this one:
JSF faces config file outside WEB-INF?
I have One Jsf form that contains 2 Beans. First Bean scope: Session. Second Bean scope: request.
When some values are added via First Bean to second Bean, the updated value is not displayed in the form. I don't know how to do. Please help me.
Either you fired a redirect which caused the request scoped bean being renewed, or the values are updated at the wrong moment which caused them being overridden later in the JSF lifecycle.
To fix the first, ensure that you aren't including <redirect/> in navigation case nor did call ExternalContext#redirect() in bean action method. To fix the second, well, run a debugger. This article may also help a lot in understanding what's going on under the JSF hoods.
BalusC has shown what are the possible reasons for this problem.
In case it is the redirection one, removing the redirect solves the problem, but adds another - the user is asked to resubmit the form if he refreshes the page.
A preferred way to achieve such transitions from one page to another is to use a conversation. MyFaces Orchestra provides a special conversation scope to solve this and many more problems.