My setup is a small JSF2.2 application. This application has two ManagedBean classes, which both implement the same Interface. One written in Mockito used for development and unit testing (we're using TestNG) and one written in ActiveMQ, used for Production and CI. How do I tell the Facelet which implementation to use? In spring I would use a different application-context, in Guice a different AbstractModule. Now before you say use CDI or EJB for this, there's a little catch, for various legacy reasons, beyond my control, or sphere of influence, we're not using a proper JavaEE container (we're using Jetty 9 (upgraded less than 2 months ago from Jetty 6, so yeah).
Now my first reaction would be "Go with what you know", but wiring Guice or Spring Beans into a JSF/PrimeFaces application just feels redundant and wrong.
So my somewhat long-winded question is, is there something I'm overlooking? What is the pure-JSF equivalent of a Spring #Configuration or Guice AbstractModule? Is Spring/Guice/CDI really a requirement for this?
Related
I like dagger2 a lot and want to use it in my new project. The only gotcha is with dagger2 we still have to write some boilerplate code and its missing support for CDI.
Since Google is developing and maintaining dagger2 and also using it for their Android development, I am wondering if they are thinking of replacing the DI implementation in Guice with dagger2, which is my first question.
If they are, then I can start using guice expecting that with some future update I will get the goodness of dagger.
But if they are not, is there a way that I can use both in the same project where guice can be limited to CDI.
I'm not a Dagger expert, but I'll try to answer your question... (and I hope to do it well)
I am wondering if they are thinking of replacing the DI implementation in Guice with dagger2,
Nope. There is no good reason to do it. Dagger and Guice present totally different approach to the Dependency Injection concept. The former uses a code generation, the latter - runtime reflection.
(...) is there a way that I can use both in the same project where guice can be limited to CDI?
I don't think it's a good idea to mix CDI, Dagger and Guice in the same project. Beside fact, that CDI is only a specification, not an actual implementation like Weld or OpenWebBeans - so I guess you wanted to say "DI"?.
Anyway: there is dagger-adapter extension which allows using Dagger2 modules with Guice (using DaggerAdapter) if you really want to mix Dagger with Guice 4.
By the way, I would like to give you an idea of what Dagger is and what it never will be. Below is a quote from Christian Gruber (who worked on Dagger) on this subject:
Guice will always have a superset of features compared to Dagger, though we do have projects using Dagger on the server and in stand-alone java apps. But Dagger is not as evolved in terms of the surrounding "scaffolding" code (servlet support, etc.) as Guice, and won’t be for quite some time. Additionally, some teams will need or want some advanced Guice features that will never make it in to Dagger.
You may ask what are these "advanced features"? It is e.g. AOP support, like intercepting methods, which might be crucial for many developers.
You can read the whole discussion (February 2014) which is available here.
As someone working on Java application framework development at Google, I can assure you that Google has large important projects built both with Guice and with Dagger, and both DI systems will continue to be used and developed for the foreseeable future.
My personal idea (which is not an official Google plan or statement) is that over time we will build both more powerful abstractions on top of Dagger (likely in add-on frameworks and/or libraries) so that Dagger continues to become suitable for a larger and larger set of applications, and also more powerful tooling around Guice to make the Guice developer experience become more and more comparable to the Dagger developer experience, at least for a subset of Guice applications that are doing "normal" things.
Both Dagger and Guice are useful tools, each with a different set of trade-offs and a different target audience. Using both in the same project is something that should be possible, although that isn't really the ideal solution because then you can't fully take advantage of the strengths of either of them. But better interoperability is a goal, and the Guice and Dagger teams regularly communicate about how to standardize and coordinate efforts.
Stumbled upon this after having issues with Guice and Java 11. As we barely use guice anyway, I intend to rip it out in favor of dagger for now. Guice is giving me a mega complicated asm based exception that is buried, hard to get a RCA read on and apparently not addressed by the framework. I also, having stepped through the guice code trying to figure this out over a week or so, find the "scaffolding" to be too much for at least my use case and it has me questioning the merits of DI frameworks generally. Dagger2 at least operates at compile time.
We are in the process of disentangling a classic legacy monolithic EAR-packaged Java EE application. Our (most complex) component wiring pattern is as follows: component A 'requires' interface X, whilst components B and C (... N) each 'provide' interface X. Our requirement is to package and deploy A, B, C and X separately and independently in order to minimize downtime and minimize business impact.
We therefore require the necessary robustness to allow providers (B,C) of interfaces to be removed and added (redeployed), at runtime, without requiring a redeployment of the consumers (A) of the interface, nor a restart of the server. The solution will run on Wildfly 8, but can make use or other technologies as long as they work on Wildfly 8.
We've implemented a POC using JBoss-OSGI and Weld-OSGI which fulfilled all of our requirements, and offered us an excellent migration path as well. However, in Wildfly 8 Alpha 3, JBoss-OSGI was removed from the default distribution. This made us think we should explore alternatives that are more in line with the thinking of the people behind Wildfly.
The question therefore is, on Wildfly 8, what is the alternative to OSGI for inter-module service injection that would meet our requirements?
For the sake of budgets, simplicity, performance overheads and company policies, we've had to eliminate the following:
1. Remote EJB's
2. Web Services
3. JSon/Rest
4. SCA
Please note that this is not a request for a debate on the viability of OSGI nor for an evaluation or comparison of different solutions. I am simply looking for any solution(s) that would meet our criteria and is NOT based on OSGI.
Since you're asking about the thinking of the people behind WildFly, I will refer you to the following mail-list message. It was posted to the Jigsaw development list by David Lloyd, who is (I believe) the designer of JBoss Modules on which WildFly is based. The context was a discussion about the introduction of a service model into Jigsaw: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-February/002161.html
What David seems to be saying is either that the idea of services itself flawed – i.e. you don't need them! – or that the requirement is already sufficiently solved by the ServiceLoader API which was introduced in Java 6.
However, ServiceLoader is known not to work on module systems that use classloader isolation, which includes both OSGi and JBoss Modules. This is because ServiceLoader uses classpath scanning, and in a module system there is no "classpath". In OSGi we have specced a way of adapting ServiceLoader (though it's yucky and requires bytecode munging). Perhaps JBoss Modules also has a way of handling this, but I couldn't find anything from a quick scan of their docs.
Anyway as I said in my comment above, I'm puzzled about your motivation. You clearly get benefits from the service model provided by OSGi, and JBoss-OSGi is still available and supported by Red Hat... so why not continue to use it? Especially if there is nothing clearly provided by WildFly out-of-the-box that does what you want.
Apache Felix can be embedded in your application server as 'OSGI host'. Then you can create plugin mechanism for the required system. All of your services can be implemented as 'bundles'. OSGI host in the server can find the bundles in a deployment folder, and installs/starts them. You can then enable your web service,rest and other services without restarting the application server.
Where I work, we had to pick something in order to continue the project when JBoss-OSGi was declared dead. We went with JBoss Modules + EJB approach, since they're actually supported by Red Hat. JBoss Modules is used for static module dependencies, and EJB for runtime injection of services.
We don't use remote EJB but EJB 3.x local EJBs, and that wasn't thrown away in your list, so I guess it's ok to offer this.
EJB achieved many improvements in 3.x versions, Spring is also commonly used and version 3 is a good alternative.
There are many articles on web, but no exact comparison about ejb3x versus spring3x.. Do you have any ideas about them, in real world examples which one is better at which conditions?
For example, we want to separate db and server, which means our application will be on a server, our database will be in another server.. EJB remoting vs Cluster4Spring etc ?
Doing everyting #Annotation is always good? configuration never needed?
For your use case where the application runs on one server and the database runs on another, the choice between EJB and Spring is irrelevant. Every platforms supports this, be it a Java SE application, a simple Servlet container like Tomcat or Jetty, PHP, Ruby on Rails, or whatever.
You don't need any kind of explicit remoting for that. You just define a datasource, provide the URL where your DB server lives and that's it.
That said, both EJB and Spring Beans do make it easier to work with datasources. They both help you defining a datasource, injecting it in beans and managing transactions associated with them.
Of the two, EJB (and Java EE in general) is more lightweight and adheres more to the convention over configuration principle. Spring requires more verbosity to get the same things and depends a lot on XML files which can quickly become very big and unwieldy. The flip side of the coin is that Spring can be less magical and you might feel more in control after having everything you want spelled out.
Another issue is the way EJB and Spring are developed.
EJB is free (as in free beer), open-source and non-proprietary. There are implementations of EJB being made by non profit organizations (Apache), open source companies (Redhat/JBoss) and deeply commercial closed source enterprises (IBM). I personally would avoid the latter, but to each his own.
Spring on the other hand is free and open-source, but strongly proprietary. There is only one company making Spring and that's Springsource. If you don't agree with Rod, then tough luck for you. This is not necessarily a bad thing, but a difference you might want to be aware of.
Doing everyting #Annotation is always good? configuration never needed?
It's an endless debate really. Some argue that XML is hard to maintain, others argue that annotations pollute an otherwise pure POJO model.
I think that annotating a bean as being an EJB stateless bean (#Stateless) or a JPA entity (#Entity) is more cleanly done using annotations. Same goes for the #EJB or #Inject dependency injections. On the other hand, I prefer JPQL named queries to be in XML files instead of annotations, and injections that represent pure configuration data (like a max value for something) to be in XML as well.
In Java EE, every annotation can also be specified in XML. If both the annotation and the XML equivalent are present, the XML overrules the annotation. This makes it really convenient to start with an annotation for the default case, but override it later via XML for a specific use case.
The current preference in Java EE seems to be more towards (simple) annotations combined with a large amount of convention over configuration.
The real question you should be asking is CDI/EJB or Spring
It's often not Spring vs EJB, but Spring vs Java EE. EJB itself compares to Spring Beans. Both of them are a kind of managed beans running inside a container (the EJB container resp. Spring container).
Overall the two technologies are rather similar. Reza Rahman did a great comparison between the two a while back.
EJB's are more advantageous because of standardization. If you are working with a lightweight application I think going with Spring is fine but if you expect that your application will be big and will require lots of memory access and data connections access you may consider starting your development with EJBs. The main reason being clustering and load balancing are built into the EJB framework.
In an EJB environment, when an EAR ('E'nterprise 'AR'chive) is deployed, it may be deployed with multiple EJBs beans that each could have a specific purpose. Let say you wrote a bean for user management and another bean for product management. Maybe one day you find that your user services way exceed your products access services, and you want to move your user bean to a different server on a different machine. This can actually be done in runtime without altering your code. Beans can be moved between servers and databases, to accomodate clustering and load/data balancing without affecting your developers or your users because most of it can be configured at the deployment level.
Another reason for supporting a standard is knowing that most large third party vendors will likely support it resulting in less issues when integrating with new standard/service/technology - and let's face it, those come out like new flavours of ice-cream. And if it is in a public specification new start-up companies or kind developers can create an open-source version.
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
It is most unfortunate that even the most intelligent designers or programmers cannot predict which of their features may or may not be embraced by the development community which is the main reason software becomes bloated... Java EE is definitely that!
Choose one or the other, but not both.
My personal preference is Spring. I've used on projects with great success for the past six years. It's as solid as any software out there.
Spring can work with EJBs if you choose to have them in your app, but I don't believe the reverse is true.
I would recommend separate physical machines for web, app, and database servers if you can afford it.
Spring can work with several remoting options, including SOAP and REST web services. A comparison of Spring beans with EJB is beyond the scope of this question. I don't see what it has to do with your implementation. If you use Spring POJO services they're in-memory rather than requiring another network hop like remote EJBs. Think of Fowler's Law of Distributed Objects: "Don't". Only introduce latency with good reason.
I'd mention unit testing here.
In common web application (controller->service->data->...->view) EJB and Spring both provide similar result, but spring offers easier testing.
In my humble experience the way you develop is different in couple of aspects:
Unit test (spring wins). In spring its done pretty stright forward, while in ejb you have to use Arqullian with ShrinkWrap (sic!) which is slow to run on every build.
Persistence (ejb wins). In spring there is struggle around it, i.e. google "how to autowire persistence in entity listener" http://bit.ly/1P6u5WO
Configuration (ejb wins). As newbie coming to spring from ejb I was surprised by swarm of annotations and .xml files.
EJB 3.1 is the best while being the standard for Java 6 EE applications.
Spring still does not support Java 6 CDI(weld) also still depends a lot on XML configuration. EJB 3.1 is powerful and smart.
I think that Spring 3.1 doesn't need any XML configuration. You have the option to use annotations for configuration.
Is it possible to use JSF 2.0 (PrimeFaces for example) as view layer for Play Framework? I'd like to combine elastic hot redeployment of Play with easy component driven JSF developement (instead of MVC and template driven GUI design).
I think all I need is -
1. Run FAces Servlet (javax.faces.webapp.FacesServlet) and maybe some other servlet
2. Tweak el-resolver in faces-config.xml just like org.springframework.web.jsf.el.SpringBeanFacesELResolver does.
Have anyone did something like this? I'm new in Play Framework. I use JSF + Spring + JPA now.
JSF is fully based on the stateful aspect of Java EE web stack and on the servlet API!
Play is just a full stateless framework and doesn't use servlet API at all!
So the answer is "No you shouldn't use JSF as the view layer of Play". I use "shouldn't" instead of "can't" because everything is possible but it was be really bad thing!
Nevertheless, you really should think about leaving JSF after wanting to leave MVC. If Play! exists, it's not only because of Rails/Django/Symfony are good, it's also because JSF-like frameworks aren't good, efficient and viable solutions for many reasons you can find everywhere on the web or even in your own experience maybe.
I would advise you just to give a try to Play+JPA (or even something else to replace JPA such as Siena) for real. Don't begin by mixing Java EE stuff with it, use Play 100% to see how it performs. If you need to use Spring with Play, there is no problem but it's not required in many cases. You will discover how easy and efficient it is to build apps from the smallest to the biggest enterprise ones. In my experience, since I use Play, I find this framework promises things and keeps them which is very rare in this world!
Have fun!
By default, no this is not possible.
Play does not conform to the J2EE specification, and as such does not implement the Servlet specification.
However, it may be possible, with a fair amount of effort. Play developers have already created a ServletWrapper that allows Play to be deployed to standard servlet containers (like JBoss and Tomcat etc), so they have shown that you can integrate with J2EE technology, if you want to spend the time and effort to write your own Plugin that overwrites the default nature of Play.
I wouldn't bother though. Just take a look at the template engine that comes with Play. It is very good, and I have not missed JSPs at all since using Groovy.
You can use JSF2.2+Primefaces and Spring + AKKA framework which is better and faster than play.
I absolutely need to use an IoC container for decoupling dependencies in an ever increasingly complex system of enterprise services. The issue I am facing is one related to configuration (a.k.a. registration). We currently have 4 different environments -- development to production and in between. These environments have numerous configurations that slightly vary from environment to environment; however, in all cases that I can currently think of, dependencies between components do not differ from environment to environment, though I could have missed something and/or this could obviously change.
So, the ultimate question is, does anybody have a similar experience using an IoC framework? Or, can anybody recommend one framework over another that would provide flexible registration be it through some sort of convention or simplified configuration information? Would I still be able to benefit from a fluent interface or am I stuck with XML -- I'd like to avoid XML-hell.
Edit: This is a .Net environment and I have been looking at Windsor, Ninject and Autofac. They all seem to now support both methods of registration (fluent and XML), though Autofac's support for lambda expressions seems to be a little different than the others. Anybody use that in a similar multi-deployment environment?
If you want to abstract your container, and be able to use different ones, look into having it injectable in a way I tried to do it here
I use Ninject. I like the fact that I don't have to use Xml to configure the dependencies. I can just use straight up C# code. There are multiple ways of doing it also. I know other libraries have that feature, but Ninject offers fast instantiation, it is pretty lightweight, it has conditional binding, supports compact framework, and it supports Silverlight, 2.0. I also use a wrapper on top of it, in case I do switch it out for another framework in the future. You should definitely try Ninject when deciding on a framework.
I'm not sure whether it will suit your particular case, you didn't mention what platform you're working in, but I've had great success with Castle Windsor's IOC framework. The dependencies are setup in the config file (it's a .NET framework)
Look at Ayendes rhino commons. He uses an abstraction over the IoC container. So that you can switch containers whenever you want. Something like container.Resolve is always there in every container.
I use Structuremap to do the dirty work it has a fluent interface and the XML things and it is powerfull enough for most things you want to do. Each one has it's own pros and cons so a little abstraction so you can easily switch (you never know how long they are going to be around) is good. For the rest I think Spring.Net, Castle windsor, Ninject and StructureMap aren't that far apart anymore.