I am a beginner creating a SEAM (2.2) application with JBoss AS6
I am integrating the Paypal express checkout code which acts as an http servlet, this seems to work ok with the payments processing correctly by paypal, the problem is I cannot seem to inject my stateful backing beans into the servlet to verify the payment and update the database on my side. I have tried a variety of methods including the following...
#In PaymentBean paymentBean
PaymentBean paymentBean = (PaymentBean) Contexts.getConversationContext().get("PaymentBean")
paymentBean = ((PaymentBean)Component.getInstance("paymentBean"));
In each case I am left with a null pointer exception, I dont think its a problem with the bean as it wont even inject the messages files
As I have seen a lot of similar issues I am not even sure if this is possible with my setup? Is there some further configuration I am missing?
Can somebody suggest a solution, or a way to access my backing beans from the servlet?
Thanks
It turns out the answer to my question lives here...
http://seamframework.org/Documentation/ReplacingServletsWithSeamResources
Related
This is a more general Spring question that isn't necessarily a Spring Social Facebook issue; however, I'm asking the question here because it is not clear to me how Spring is managing the Facebook reference that is passed into the controller constructor.
I'm running this in a Spring boot app, version 1.5.3.RELEASE.
I've googled around and have read many things about how scoped-proxies work and whether the Controller is a singleton and such; but something is still not clear to me with this particular use case. My concern is over whether or not two or more simultaneous request will cause one reference to interfere with the other. It seems to me that there will be a conflict regardless of the scoped-proxy solution. To address this concern, I injected a Facebook and ConnectionRepository object into the controller constructor wrapped in a Provider class.
#Inject
public CopyGroupController(
Provider<Facebook> facebook,
Provider<ConnectionRepository> connectionRepository) {
It appears to have injected meaningful data; but when attempting to run this code:
#PostConstruct
public void init() {
ConnectionRepository repo = connectionRepository.get();
this.userManager.createOrGetUser(
repo.findPrimaryConnection(Facebook.class));
}
This failure occurs:
java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
This creates more uncertainty because I thought the FacebookTemplate was being managed as a request or session scoped bean and that it would Inject as a Provider so the object would reside on ThreadLocale; so two or more concurrent requests will not conflict. Passing a request scoped bean in a controller singleton constructor doesn't make any sense to me either. So I'm puzzled as to why a user specific reference would even be passed into a constructor that should only be called once.
I've tried setting breakpoints in the constructor to verify whether or not there is a conflict; but The same error as above would occur. Could someone please explain to me whether or not this is an issue and if so; how is the best, most modern way to resolve it.
Any assistance would be greatly appreciated.
Thank you in advance.
You have to register a RequestContextListener
Here you can find the problem detail
And here you can get how to add in using spring boot
I have a JSF2 controller/bean/view that is invoked the standard JSF way. Now I have a need to access this logic from a legacy part of the app that knows servlets and URL params only.
I thought of creating a "loader.xhtm" view that bridges the gap between non-jsf requester and the jsf part of the app. Loader will take URL params and make the necessary JSF post to backing bean. etc. One downside of this approach is - it's one extra client/server hop, a programmatic redirect. However it is simple to implement.
But is there a more clever way? I found someone who created servlet filter and explicitly created a FacesContext, started the lifecycle and the ViewRoot. Conceptually I see what is being done, but I don't know how to put it into practice. Has anyone interfaced with JSF lifecycle directly from a servlet? Do you have a sample?
Another mention of this concept.
At application start our application connects to the database and fetches a language translation table and caches it into memory. The code that does this is placed in Application_Start in Global.ascx
The problem with this approach is that if the database is not available, there will be a completely unhandled exception. Because the code is set at Application_Start, Request and Response are not available.
I was wondering if there's a general lightweight approach to this.
My plan is to implement a singleton to store the state of the connection attempt, and then check that on the default routed page. It's a solution, but I feel there's something missing. Are there any other approaches to this?
The problem with this approach is that if the database is not
available, there will be a completely unhandled exception.
Well handle it then. You could implement some retry policy in your code so that if the result is not cached in memory it will fetch it from the database once again.
The excellent article about the error handling can be find at http://blog.gauffin.org/2011/11/how-to-handle-errors-in-asp-net-mvc/#.UZsZ6LVTAus
. And jgauffin also had a discussion's thread at What is best practice for global error/exception handling in ASP.NET MVC?
Hope this help.
I'm developing servlets and register them into my OSGI container thanks to HttpService.
My goal is to secure all the servlets registered in my OSGI container.
I saw that I can register my Servlet with an HttpContext with my own handleSecurity method implementation to process my security.
But I'm thinking to the case where a bundle registers a servlet with the default HttpContext (with implies no security).
So my question is, is there a way to force the security of all the servlets deployed in my OSGI container once for all?
I'm going to use the Service hook feature (OSGI 4.3) in order to override the behaviour of HttpService.registerServlet. In my hook I'll force the usage of my HttContext implementation.
With this solution, any bundle that register a servlet with the HttpService will be secured by my HttpContext implementation.
The short answer is No for using the HttpService.
The longer answer, you might achieve something like this if you use the whiteboard-extender which isn't available per OSGi spec yet, but felix and pax-web do provide it.
When using the whiteboard-extender you're able to register your servlet in combination with a reference to a HttpContext (as property). Of course this HttpContext would also need to be a "customized" one but you only need to register it once and are able to reference it from your Servlets.
This is probably the closest you get to your question.
If you use the Apache Felix whiteboard extender you can register a Servlet Filter, this is a much better way to handle security since it is easy to support different strategies. The intention is that Filters and whiteboard will be supported in the next update of the Http Service: https://github.com/osgi/design/tree/master/rfcs/rfc0189
You could use hooks as suggested, but please don't. Hooks were intended for deep middleware, not for application oriented aspects. They create start/stop ordering issues, they make the system more opaque for debugging tools, in short they make your system much more complex. If you start using hooks for these purposes you will find many more use cases and they will start to interact. Stay away from them except for very core system middleware.
I have seen lots of documentation on how Agile Asp.Net Request handling is? I want to know is the case same with WCF Request handling. Can we rely on the fact that the Thread that starts Wcf request handling will finish it?
I am maintaining a Wcf Application where at lots of places ThreadStatic variables are used. Although the code is working but is it reliable? Is it worth changing it or should I keep it as it is?
When creating a WCF service you can set the threading and service instantiating behaviour, by decorating the service implementation class with a ServiceBehavior attribute:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
class SingleCachingHttpFetcher : IHttpFetcher
The above code snippet is from http://msdn.microsoft.com/en-us/library/system.servicemodel.servicebehaviorattribute.concurrencymode.aspx
EDIT
I dit a bit more research and found this article: http://blogs.microsoft.co.il/blogs/applisec/archive/2009/11/23/wcf-thread-affinity-and-synchronization.aspx. It basically says that no, you cannot be sure that the same thread starting the request will be the one finishing it.
EDIT 2
This question has been discussed before at StackOverflow. It links to How to make a WCF service STA (single-threaded) where there is a description on how to create an OperationBehavior which will force a single threaded apartment. The example deals with calling GUI components, but it should work for other single threaded requirements as well.