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.
Related
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.
In a Spring MVC application using Sitemesh to decorate my views, I want to inject into every Model a security attribute called sec of type WebSecurityExpressionRoot.
This way I could call hasAnyRole(), hasAuthority()... in all my views so administrators would be presented extra stuff by the underlying templating engine (Thymeleaf BTW).
A custom HandlerInterceptorAdapter with an overridden postHandle(...) seems to be Spring MVC's way of accomplishing this, but it seems that my master Sitemesh decorator is kind of stealing my security attribute, because whenever I try to reference in some views it is null.
BUT only the views rendered after one of my controllers are affected, the ones
mapped with mvc:view-controller do have the sec attribute.
I'm considering writing a Filter to stash sec into the current HttpServletRequest to solve this issue but I'm maybe missing something.
Thanks in advance!
Are you sure the mvc:view-controller views/path are hitting the interceptor?
Also, I don't know about Thymeleaf, but using JSPs (eg, JstlView) makes Spring MVC copy Model into Request attributes (for purposes of rendering the view) -- the fact that Sitemesh also gets the values via request attributes is, I think, a consequence.
We have a flex application that connects to a proxy server which handles authentication. If the authentication has timeout out the proxy server returns a json formatted error string. What I would like to do is inspect every URLRequest response and check if there's an error message and display it in the flex client then redirect back to login screen.
So I'm wondering if its possible to create an event listener to all URLRequests in a global fashion. Without having to search through the project and add some method to each URLRequest. Any ideas if this is possible?
Unless you're only using one service, there is no way to set a global URLRequest handler. If I were you, I'd think more about architecting your application properly by using a delegate and always checking the result through a particular service which is used throughout the app.
J_A_X has some good suggestions, but I'd take it a bit farther. Let me make some assumptions based on the limited information you've provided.
The services are scattered all over your application means that they're actually embedded in multiple Views.
If your services can all be handled by the same handler, you notionally have one service, copied many times.
Despite what you see in the Adobe examples showing their new Service generation code, it's incredibly bad practice to call services directly from Views, in part because of the very problem you are seeing--you can wind up with lots of copies of the same service code littered all over your application.
Depending on how tightly interwoven your application is (believe me, I've inherited some pretty nasty stuff, so I know this might be easier said than done), you may find that the easiest thing is to remove all of those various services and replace them by having all your Views dispatch a bubbling event that gets caught at the top level. At the top level, you respond to that event by calling one instance of your service, which is again handled in one place.
You may or may not choose to wrap that single service in a delegate, but once you have your application archtected in a way where the service is decoupled from your Views, you can make that choice at any time.
Would you be able to extend the class and add an event listener in the object's constructor? I don't like this approach but it could work.
You would just have to search/replace the whole project.
Ok, so the problem is:
I've got some 'order' entity, and it has 'status' property. On changing status, i wanted some other objects to be informed of this event, so i've decided to use Observer pattern. One of the observers notifies clients via email. Now i want to render Email text's from some of the twig templates. As i get from the Book, rendering templates in controllers are done with 'templating' service.
So the question as it follows: How can i access 'templating' service in my Observer class?
Specification:
I was advised, to implement my Observer as a service, but i'm not sure 'bout that. I've tried to solve this problem, and here is my options:
Use Registry. Solution that is straight and hard as rail. I guess it misses the whole point of DI and Service Container. Huge plus of this solution, is that i can access all common services from any point of my application.
To pass needed services from the context via constructor, or via setters. This is more like in Sf2 spirit. There comes another list of problems, which are not related to this question field.
Use observers as a service. I'm not really sure 'bout this option 'cos, in the book it is written, that service is a common functionality, and i don't think that observing entity with number of discrete properties is a common task.
I'm looking for a Sf2 spirit solution, which will be spread over whole project, so all answers with an explanation are appreciated.
As with any other service in a Symfony2 project, you can access it from within other classes through the dependency injector container. Basically what you would do is register your observer class as a service, and then inject the templating service into your observer service. See the docs for injecting services.
If you're not familiar with how Symfony handles dependency injection, I'd suggest reading that entire chapter of the documentation - it's very helpful. Also, if you want to find all the services that are registered for application, you can use the console command container:debug. You can also append a service name after that to see detailed info about the service.
Edit
I read your changes to the question, but still recommend going down the DI route. That is the Symfony2 spirit :) You're worried that your observer isn't common enough to be used as a service, but there's no hard rule saying "You must use this piece of code in X locations in order for it to be 'common'".
Using the DIC comes with another huge benefit - it handles other dependencies for you. Let's say the templating service has 3 services injected into itself. When using the DIC, you don't need to worry about the templating service's dependencies - they are handled for you. All you care about is telling it "inject the templating service into this other service" and Symfony takes care of all the heavy lifting.
If you're really opposed to defining your observer as a service, you can use constructor or setter injection as long as you're within a container-aware context.
I'm currently working with web services that return objects such as a list of files e.g. File array.
I wanted to know whether its best practice to bind this type of object directly to my front end code for example a repeater/listview or whether to first parse it into my own list of "file class" e.g. customFiles[]
If the web service changes then it will break my front end code, however if I create my own CustomFile class, then i would only need to change my code in one place to fix the issue, but it just seems like a lot of extra work to create the same classes from a web service, i wanted to know what is the best practice for this type of work.
There is a delicate balancing act in properly encapsulating implementation details. Too little encapsulation is a maintenance nightmare as small changes in any area break the application. Too many layers is a different kind of maintenance headache altogether.
In this particular case I would create a small layer in your application to encapsulate the web service calls. This will ease your maintenance in both the application and the service as they will be loosely coupled.
It sounds like you have already answered your own problem. Best practice is to create your own custom class for the reasons you point out, but it is significant extra work.
If the webservice isn't likely to change then just use the existing classes, but if you need to cater for change then create your own.
Returning a class is fine as long as your client knows how to deserialize it. If it's truly a web service, where you don't have control over both ends of the conversation, it's more common to start with schemas for XML request and response streams. That decouples the client from the web service a bit more and allows any client that can send XML via HTTP and consume an XML response fair game.