Based on advice posted here and here, I looked into and installed MyFaces CODI with my application. My biggest concern was overcoming the shortcomings of Weld's implementation of #ConversationScoped feature. After some hiccups I got it running on my GlassFish 3.1 development platform, and I converted all my beans to use
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped;
In the end it seems like I am now not much further along than I was before. I do not have to call the conversation.begin() method anymore, which is good, but the beans hang around after the browser has left the page and come back.
What I was hoping for was the functionality of JSF 2.0 #ViewScoped that works with CDI. Once the user leaves the page, the backing bean should be discarded and re-created again if the user comes back. Is there a way to do this with CODI?
Incidentally, the documentation says it will pick up the #ViewScoped annotations and process them properly. I tried this and got and Weld wouldn't deploy it.
P.S. I am using myfaces-extcdi-dist-jsf20 version 0.9.5. I tried installing the core and JSF 2 optional module akibe but it would not deploy on my GlassFish/Weld platform. Any advice here much appreciated.
UPDATE 1: I ended up trying the ViewAccessScope annotation supported by CODI, and that seems to do what I wanted.
Follow-up question. The latest bundle that the maven repository that Apache maintains is 0.9.5 -- Can someone post the pom.xml segment that fetches the latest version?
Call conversation.close() before returning - ensure that you imported the correct annotation org.apache... and not javax... - see Wiki or use the ViewAccessScope instead. We are using: bundle in Glassfish 3.1.1 without problems. myfaces-extcdi-bundle-jsf20-1.0.1.jar is the only jar you need. Please also note that there is no "it". With CODI you have fine-grained groupable conversations instead of the monolithic and inflexible stuff you get with standard CDI conversations.
The set-up for the latest version with a Maven build is also in the Wiki.
Related
I have upgraded Grails and Spring Security to latest (3.3.0.RC1 and 3.2.0.M1 respectively) by following all of the migration paths but now my annotations no longer work. Control follows through to my not authorised callback (grails.plugin.springsecurity.adh.errorPage).
I have my own list of enum backed Permissions that I use to populate my list of authorities which are being correctly loaded for my user object but they no longer work in my annotations using the hasRole expression as follows;
#Secured(["hasAnyRole('PERM_VIEW_REPORTS'"])
other expressions are working fine such as the following
#Secured("authentication.name == 'sys_admin'")
#Secured("hasRole('PERM_VIEW_REPORTS')")
I don't suppose anyone has had any similar experience with the latest Spring Security release for Grails. Remember the above has worked perfectly until I upgraded but I don't see anything in the migration path that suggests there might be a problem with this system.
Thanking for any suggestions in advance.
This came down to the "ROLE_" prefix being mandatory again in the new Spring Security 3.2.0.M1 release. As can be seen from above, I had being using a "PERM_" prefix up to now to indicate that I'm using a permission based instead of role based paradigm.
I'm hoping to add this to the migration guide for the plugin as it's a major omission AFAIC. I would hope this would become a configuration option for the plugin in a future release.
EDIT:
It turns out Spring Security have introduced new methods hasAuthority() and hasAnyAuthority() which do not use the default role prefix and so can be used in place of hasRole() and hasAnyRole().
I have forked and updated the Spring Security docs for 3.2 and sent a pull request.
Please try with
#Secured ('ROLE_USER')
If you're trying to secured with more than one Role
#Secured(['ROLE_USER','ROLE_ADMIN'])
Tomcat 7
Orbeon 4.1CE
After using 4.1CE, it cannot read the handwritten form in "orbeon/conf/resources/forms/"
Is there any new file need to define in 4.1 version?
Now, I know that the properties-local.xml affects this problem.
Is there any sample of properties-local.xml for 4.1CE?
First, if you're upgrading, I'd recommend you upgrade to the latest version (4.9 at the time of this writing), since 4.1 is already quite old.
Now, regarding your specific question, I can't remember Orbeon Forms ever using a orbeon/conf/resources/forms folder. Maybe orbeon/conf/resources was setup as a resource folder in your web.xml? If not, this must have been a directory your app was explicitly reading from.
About the properties-local.xml, you can define your own values for properties to configure the way Orbeon Forms works, and for more on this I'd recommend you go through the documentation about properties.
I have an existing, eclipse based web servlet application that authenticates using http basic authentication. I am looking to convert this to Spring based security. I understand what has to be done programatically, but am having problems with the details of configuring the project itself in eclipse. I am using the Spring STS toolkit, and I am able to successfully import one of the Spring Security sample apps (openid-xml) and it works fine.
My existing application also works properly when run under STS, but without Spring support
I would like a recommendation for either a tutorial on making this conversion, or some useful advice. For example, is it easier to
a) create a new Spring application and try to migrate my existing code into it, or b) try to convert my code by importing the various spring libraries, etc? c) convert my existing app to use maven instead of eclipse (Spring just doesn't seem to want to work without maven, and i am at a loss here) - naturally, I have no idea how to do this.
Any advice will be most gratefully received, after a day of hit and miss frustration.
I have answered my own question, and will try to provide some details for those who may be having the same problem.
First, there is some relatively useless info available on stackoverflow, but some good stuff as well.
This (https://stackoverflow.com/a/14867188/1374167) is completely wrong. It is certainly possible to secure a servlet with Spring Security. The trick is to realize that you are going to have to use Maven and Gradle to build the libraries for Spring and Spring Security.
Once you have built these jar files, you simply import them into Eclipse (it doesn't really seem to matter which version) and set up your web.xml and security contraints.
I used this project as a starting point. It's not perfect, but it got me on the right track, after I updated the spring and spring security jar files. The full blog post is here
I had a frustrating experience getting to this point but I hope this information will help others. It's quite simple once you understand what to do.
I have a Java EE app where I use JSF2 + PrettyFaces + EBJ3 + Glassfish
I just recently updated to Glassfish4 which is the default Server implementation for Java EE 7 and I started getting issues with PrettyFaces.
I have configured on my faces-config.xml:
<lifecycle>
<phase-listener>com.ocpsoft.pretty.faces.event.MultiPageMessagesSupport</phase-listener>
</lifecycle>
to enable for Faces Messages to be passed around correctly and displayed on screen.
But since I upgraded from Glassfish3 to 4 I started getting this issue:
java.lang.IllegalStateException: Cannot create a session after the response has
been committed
...
at com.ocpsoft.pretty.faces.util.FacesMessagesUtils.saveMessages(FacesMe
ssagesUtils.java:56)
at com.ocpsoft.pretty.faces.event.MultiPageMessagesSupport.afterPhase(Mu
ltiPageMessagesSupport.java:66)
If I remove the listener from faces-config.xml none of the Faces messages are displayed on screen.
I am using PrettyFaces to have nice well formatted URLs to enhance SEO on my site. I wish I couldn't have to replace it or refactor my app to not use it since I already mapped a lot of the navigation flow using it. Does somebody know a better option for this scenario?
I really appreciate any suggestions. Thanks.
I don't recommend to use MultiPageMessagesSupport if you are deploying to a "modern" container with JSF 2.2 support. The MultiPageMessagesSupport phase listener has been developed for JSF 1.x. JSF 2.x added support for persisting messages across redirects. Just execute this code before redirecting:
FacesContext.getCurrentInstance().getExternalContext().getFlash().setKeepMessages(true);
Does Grails have any plugins with functionality similar to the django-debug-toolbar (djdt)?
See this screencast for an introduction to djdt.
Why yes it does grails debug-toolbar:
Grails Debug Toolbar is a plugin
inspired from Django Debug Toolbar
While it doesn't have all the features of djdt it is planned to expand the feature set in the future, here is relevant section from their webpage:
Future work
Currently the views of debugtoolbar
need to go in the grails-app/views of
the application. When you install the
plugin they are automatically copied
to your application grails-app/views.
Need to avoid this.
JavaScript and
static resources for the toolbar
reside in web-app/debugtoolbar. It is
also copied to your application
web-app/debugtoolbar. Need to avoid
this.
A way of ordering the panels in
the toolbar. Currently it is random
depending on how beans are found
during execution of tag.
More useful panels such as Timing the requests, SQL queries, logging etc
It not quite a toolbar (and not a plugin) but Spring Insight gives you detailled request timing right down to the JDBC level. It integrates pretty nicely with Spring Tool Suite from what I've seen.
Check out Peter's screencast: http://www.grails.org/blog/view/pledbrook/New+screencast%3A+Profiling+with+STS+%26+Spring+Insight
You need to deploy your app to Spring's tcServer rather than a plain tomcat which might be fine for development tuning.
cheers
Lee