Is there a way to decouple ManagedBeans from each other in a way that it is possible to send and receive custom events - probably over the (cool) FacesContext?! I do not want to inject Beans as ManagedProperty, to reduce direct dependencies. Unfortunately #ListenerFor and all that new stuff does only work for components and renderers and seems completely the wrong approach.
Those of you who are familiar with Adobe Flex' event mechanism know what I mean and what I expect from a standardized web UI framework.
Please let me know an elegant way that is included in the JSF specification without the need to implement another framework around.
Is there a way to decouple ManagedBeans from each other in a way that it is possible to send and receive custom events - probably over the (cool) FacesContext?!
Not without adding the event to a component, and you would have to add it before the Event phase of the JSF lifecycle.
I do not want to inject Beans as ManagedProperty, to reduce direct dependencies
Just because you are not injecting needed dependencies into your bean, doesn't mean that those dependencies wouldn't exist anyway if you are trying to go with an event driven model. At least by injecting the dependencies you explicitly declare what the managed bean depends on. This seems like a much more maintainable solution than what you are proposing.
Those of you who are familiar with Adobe Flex' event mechanism know what I mean and what I expect from a standardized web UI framework.
You expect a desktop based event driven model in a web application framework? This is apples to oranges. Adobe Flex is a Rich Internet Application that behaves like a desktop application while communicating with outside web services. JSF is a web application framework standard for web based components powered by javascript and ajax, with reusable server components and a server lifecycle which includes an event phase for components.
Please let me know an elegant way that is included in the JSF specification without the need to implement another framework around.
Your language implies that you do not find JSF elegant and that you are actively trying to make it something that it is not. Please do not do this, you will create a nightmare for yourself and anybody who has to maintain your application.
JSF requires a different way of thinking about web application development than what you are used to. If you find it this unpalatable then I suggest abandoning it for a web application framework that fits your comfortability level. You mentioned Flex, there is also Silverlight with .NET.
Related
I'm building application at top of the Laravel. In my Domain layer I have services. One of these needs to send an EMail. Laravel has Illuminate\Mail package for these purposes.
But Mailer contract depends on \Illuminate\Mail\PendingMail class.
https://github.com/laravel/framework/blob/5.7/src/Illuminate/Contracts/Mail/Mailer.php
Does it mean I need to write my own interface (port) for my Domain layer to fully decouple my application from framework?
To be honest, I'm not sure what you are asking. But I'll try to answer anway.
If you use (any) framework functionality directly in your code, you obviously couple your application to the framework. That's the whole point of a framework. It offers you a lot of functionalities that are commonly used throughout different types of applications. It can be seen as foundation for an applciation. These functionalities are often made available through interfaces, so that the implementation can be swapped out if necessary. Swapping out the implementation doesn't make your application less coupled to the framework though. It just allows you to use a different kind of implementation; the interface will still be a framework one.
So, the only way to prevent (heavy) coupling with a framework would be to write your own interfaces that abstract all the framework functionalities. You could then have proxy classes that implement these new interfaces and do nothing else than proxying requests to the proper functions of the framework, allowing you to write other proxy classes in future for a different framework.
If you ask me, this sounds like a bad idea though. Because in the end, you are building your own framework based on your own interfaces. So you are using additional custom code which adds no additional functionality, but comes with the added risk of bugs and errors.
I am using Spring and JSF2 a lot and was wondering what the best way to integrate them is? Now i understand there are basically two ways to do this, but i have some problems with both:
a) Use normal #ManagedBean, and inject Spring-Services into that beans using #ManagedProperty: The problem is that i can't use Spring-AOP inside a #ManagedBean obviously, because it is not Spring-managed. I usually use an arround-aspect on every method annotated with my custom annotation #DatabaseOperation. Another example would be #Secured from Spring-Security and so on. I use a lot of AOP in my project and not beeing able to use them on "the top level" is really limiting for me.
b) Use SpringBeanFacesELResolver to make everything managed by Spring. On the pro side is that AOP works like a charm, but the cons are big too:
No ViewScope. I am not sure if i can trust custom view scope implementations like this https://github.com/michail-nikolaev/primefaces-spring-scopes on productive systems?
Serialization is not possible. It's already pretty complicated, but once i use AOP i can't get it to work because org.springframework.aop.aspectj.AspectJPointcutAdvisor is not Serializable
So my question is: How do you overcome this issues? How do YOU integrate JSF2 and Spring3.x? I have been using possibility b) mostly, but on my next project i need session replication..
Any further suggestions?
The main integration pain point of the two frameworks is that JSF is usually used in a stateful way. to make the integration the most seamless, you would have to let Spring handle the statefulness and page navigations aspects himself instead of JSF, as well as bean creation and scoping.
The second important integration point is at the level of the view expression language. We want to be able to access spring beans while building the view, which means the managed bean layer is no longer needed.
The best integration available for the two frameworks is provided by introducing Spring webflow, see here for further details. With SWF, JSF no longer manages beans itself, this is done by Spring. JSF does not manage page navigation anymore, this handled in the SWF flow definition.
Also the statefulness is handled by SWF. The flow definition XML file replaces large parts of the faces-config.xml for view navigation, transition actions, bean definition, etc.
Using the SWF JSF integration means that your faces-config.xml is mostly empty. Expression language accessing directly spring beans can be used while building the view, and a view scope is available.
If you want to keep a page isolated from the rest of the application, youcan create a flow with a single view state and self-transitions. An advantage of SWF is that it prevents duplicate form submissions via a POST-REDIRECT-GET mechanism that works transparently out of the box.
Does spring have a mechanism which allows multi war projects communicate with each other?
I want to create a solution whereby the features in my application are controlled by a central point (possibly a html page in one of the WAR files) and when an update is made to turn on/off the feature this change is propagated down to the correct WAR which may use annotations or possibly spring profiles to act on the communicated change.
I've looked at a couple of frameworks like Togglz and Fitchy which provide a feature toggle solution however neither is ideal for my requirements.
All suggestions welcome.
Thanks,
Spring have an integration with JMS that can be used in such situation. Check it out. All available options are listed here (including RMI, Spring's HTTP invoker, Hessian, Burlap, JAX-RPC and JAX-WS). Advantage of asyncronous approach like JMS is that it is better from fault tolerance point of view (you can more easily handle the situation where app1 sends a message to app2 which is temporarily turned off). On the other hand if fault tolerance does not metter then some syncronous solution like JAX-WS may be more easy to do. Hope it helps.
I've inherited an incomplete but small web project (Java EE 5, running on WebSphere 7).
The project consists mostly of JSPs that are accessed directly via their URL, and most JSPs look up their own reference to the EJBs (services) they need. Also, there's a Servlet for every form that gets submitted by the HTML code in the JSPs.
Architecturally speaking, is there anything wrong with this?
I was thinking it would be better to have an MVC design. I don't want to convert everything to JSF because I don't want to convert all the HTML and embedded Java scriptlets into JSF tags and managed beans.
I don't really want to use Struts or Spring MVC because they're not part of the Java EE 5 toolkit that comes out of the box with WebSphere, and I don't want to add additional complexity with the additional libs and config files.
I was thinking about building my own little MVC with a "ControllerServlet" that accepts a command and dynamically build and execute the command object, and redirect to the JSP view.
But I ask myself again, is there anything "wrong" with JSPs that post to Servlets? It's actually kind of elegant in its simplicity.
What do you think?
Any suggestions are GREATLY appreciated! Rob
You're asking a rather subjective/localized question. But ala.
There's technically nothing wrong with individual JSPs that submit to individual servlets. The only real problem is when the servlets turn out to contain duplicated code for quite common tasks like collecting request parameters, converting/validating them, setting bean properties, invoking actions, performing navigation. That is not DRY and is what a MVC framework with a single front controller and a well definied lifecycle is supposed to solve.
Or, if the servlet's tasks are actually well refactored with homegrown code to perform those common tasks, then this is in turn not very maintainable as no one else than the original developer knows the ins and outs of this custom framework. So it's hard to find anyone else willing to maintain this webapp without learning another framework again which the new developer wouldn't likely to see in other future webapps. That is why companies usually adopt an existing and well-developed MVC framework like JSF, Spring MVC, Stripes, Struts, etc.
I'm coming to SpringMVC from the world of PHP, precisely I was working with Symfony for several years.
For your information, in Symfony, there are plugins and bundles that are created by other developers so that you could use them in your project. When I come to Spring, I don't find these notions or may be I've missed something !?.
For example, I'm looking for a component that does the registration and login form, which I think that must be done many times already, and I don't want to reinvent the wheels certainly.
So, my question is, I wonder if in Spring, are there possibilities to have and how to use reusable components?
Authentication is directly supported by the Java EE spec. You don't even need any particular framework for that. Every web container supports it out of the box. If you want some additional functionalities (like remember-me, etc.), loot at spring-security.