In Spring Integration, all the examples I see show #Configuration classes also annotated with #EnableIntegration.
The thing is, I am building some pretty complicated flows, and I don't like the idea of having one massive #Configuration file. I prefer to break Java projects down into packages by feature, and allow each feature to have its own #Configuration class (separation of concerns, etc.). So I'd like to do the same thing with each of my individual flows.
Do I:
Add #EnabledIntegration/#EnabledIntegrationManagement to all my #Configuration classes?; or
Only add #EnabledIntegration/#EnabledIntegrationManagement to only one of my #Configuration classes (and if so, does it matter which one?); or
Add #EnabledIntegration/#EnabledIntegrationManagement to my #SpringBootApplication main class?; or
Something else?!
You declare it only once per application context, as any other #Enable… in Spring. On any of your #Configuration class which contributes to the application context with Spring Integration. You don’t need it with Spring Boot, though, it does declare that one for us.
Related
Back in the middle age, my company created his own IoC container and since then our application is running with it. But the day has come for us to switch to CDI/Weld. Instead of switching the whole thing to CDI (we honeslty can't...), we would like to do this bits by bits starting with our front-end JSF.
The idea is to leave some of the bean resolution to Weld (e.g controller) and some to our old IoC container (e.g services)
For instance:
#Named
#RequestSCoped
ControllerA {
#Inject
private ServiceB service:
}
ControllerA should be managed by Weld, and ServiceB should remain in our old IoC container. Though, Weld should know to resolve it.
So far, our best clue is most probably to use cdi extensions and play with lifecycle events. Any example, feedback or advice is appreciated.
First, welcome to CDI! It's a great framework and a joy to use, especially in combination with JSF. I recommend reading Pro CDI in JavaEE8: https://link.springer.com/book/10.1007/978-1-4842-4363-3 for a deep dive into this which will help explain my answers below
There's a couple of routes you should choose. The simplest would be to use a #Produces annotation in a class that delegates to the older IOC container. See here for an example: https://www.baeldung.com/java-ee-cdi
The really slick, but slightly more complicated way, would be to create a CDI Portable Extension the can delegate resolution to your older container. This is very powerful and gives you hooks into several parts of the CDI container. For reference, see here: https://docs.jboss.org/weld/reference/latest/en-US/html/extend.html#extend
In either scenario, you're going to have to understand the CDI lifecycle (everything is a proxy that delegates to a managed instance) thoroughly and how that interacts with your existing IOC container or you could face memory leaks.
Good luck!
Can anyone could elaborate about PowerMock and PowerMockito.
I didn't even get documentation for powermockito.
Both used for mocking static and private methods in different way I guess.
what are the similarities and usages? which one is better?
The main aim of PowerMock is to extend the existing mocking frameworks APIs with some annotations and methods to provide extra features that make unit testing quite easy. The PowerMock framework uses a custom classloader and bytecode manipulation techniques to enable the mocking of static methods, final classes, final methods, private methods, constructor, and removal of static initializers.
The PowerMockito is a class provided by PowerMock Framework used to create mock objects and initiates verification and expectation. The PowerMockito provides the functionality to work with the Java reflection API.
I'm a little confused by the mixed use of JSF2+Spring+EJB3 or any combination of those. I know one of the Spring principal characteristics is dependency injection, but with JSF managed beans I can use #ManagedBean and #ManagedProperty anotations and I get dependency injection functionality. With EJB3 I'm even more confused about when to use it along with JSF or if there is even a reason to use it.
So, in what kind of situation would it be a good idea to use Spring+JSF2 or EJB3+JSF2?
Until now I have created just some small web applications using only JSF2 and never needed to use Spring or EJB3. However, I'm seeing in a lot of places that people are working with all this stuff together.
First of all, Spring and EJB(+JTA) are competing technologies and usually not to be used together in the same application. Choose the one or the other. Spring or EJB(+JTA). I won't tell you which to choose, I will only tell you a bit of history and the facts so that you can easier make the decision.
Main problem they're trying to solve is providing a business service layer API with automatic transaction management. Imagine that you need to fire multiple SQL queries to perform a single business task (e.g. placing an order), and one of them failed, then you would of course like that everything is rolled back, so that the DB is kept in the same state as it was before, as if completely nothing happened. If you didn't make use of transactions, then the DB would be left in an invalid state because the first bunch of the queries actually succeeded.
If you're familiar with basic JDBC, then you should know that this can be achieved by turning off autocommit on the connection, then firing those queries in sequence, then performing commit() in the very same try in whose catch (SQLException) a rollback() is performed. This is however quite tedious to implement everytime.
With Spring and EJB(+JTA), a single (stateless) business service method call counts by default transparently as a single full transaction. This way you don't need to worry about transaction management at all. You do not need to manually create EntityManagerFactory, nor explicitly call em.getTransaction().begin() and such as you would do when you're tight-coupling business service logic into a JSF backing bean class and/or are using RESOURCE_LOCAL instead of JTA in JPA. You could for example have just the following EJB class utilizing JPA:
#Stateless
public class OrderService {
#PersistenceContext
private EntityManager em;
#EJB
private ProductService productService;
public void placeOrder(Order newOrder) {
for (Product orderedproduct : newOrder.getProducts()) {
productService.updateQuantity(orderedproduct);
}
em.persist(newOrder);
}
}
If you have a #EJB private OrderService orderService; in your JSF backing bean and invoke the orderService.placeOrder(newOrder); in the action method, then a single full transaction will be performed. If for example one of the updateQuantity() calls or the persist() call failed with an exception, then it will rollback any so far executed updateQuantity() calls, and leave the DB in a clean and crisp state. Of course, you could catch that exception in your JSF backing bean and display a faces message or so.
Noted should be that "Spring" is a quite large framework which not only competes EJB, but also CDI and JPA. Previously, during the dark J2EE ages, when EJB 2.x was extremely terrible to implement (the above EJB 3.x OrderService example would in EJB 2.x require at least 5 times more code and some XML code). Spring offered a much better alternative which required less Java code (but still many XML code). J2EE/EJB2 learned the lessons from Spring and came with Java EE 5 which offers new EJB3 API which is even more slick than Spring and required no XML at all.
Spring also offers IoC/DI (inversion of control; dependency injection) out the box. This was during the J2EE era configured by XML which can go quite overboard. Nowadays Spring also uses annotations, but still some XML is required. Since Java EE 6, after having learned the lessons from Spring, CDI is offered out the box to provide the same DI functionality, but then without any need for XML. With Spring DI #Component/#Autowired and CDI #Named/#Inject you can achieve the same as JSF does with #ManagedBean/#ManagedProperty, but Spring DI and CDI offers many more advantages around it: you can for example write interceptors to pre-process or post-process managed bean creation/destroy or a managed bean method call, you can create custom scopes, producers and consumers, you can inject an instance of narrower scope in an instance of broader scope, etc.
Spring also offers MVC which essentially competes JSF. It makes no sense to mix JSF with Spring MVC. Further Spring also offers Data which is essentially an extra abstraction layer over JPA, further minimizing DAO boilerplate (but which essentially doesn't represent the business service layer as whole).
See also:
What exactly is Java EE?
JSF Controller, Service and DAO
#Stateless beans versus #Stateful beans
There's no real easy answer here as Spring is many things.
On a really high level, Spring competes with Java EE, meaning you would use either one of them as a full stack framework.
On a finer grained level, the Spring IoC container and Spring Beans compete with the combination of CDI & EJB in Java EE.
As for the web layer, Spring MVC competes with JSF. Some Spring xyzTemplate competes with the JPA interfaces (both can use eg Hibernate as the implementation of those).
It's possible to mix and match; eg use CDI & EJB beans with Spring MVC, OR use Spring Beans with JSF.
You will normally not use 2 directly competing techs together. Spring beans + CDI + EJB in the same app, or Spring MVC + JSF is silly.
What are good framework choices for web security in a Scala web application. We would like to try out Scala web development, but couldn't yet find good Scala web app security frameworks.
From the Java side I know at least Spring Security and Apache Shiro.
Do you have experience with Scala web app security frameworks or with Spring Security / Apache Shiro in a Scala context?
Lift has security baked in as described here by David Pollak, the author of Lift.
I used Spring Security in small Scala web application. I created it as I started to learn Scala and I tried to use complete Java stack: Spring MVC + Spring + Spring Security + Hibernate + BlazeDS (I also used Flex in this project for the frontend). Now I can tell that it was really nice and positive experience. Generally the question is how good scala integrates with Spring and Hibernate. I had to use #BeanProperty or #BeanInfo and java collections in entities.
But I have not faced any real issues from the spring security side. It was working as expected. I can remember only one minor issue with Spring AOP: service classes were publishing their methods through BlazeDS to the flex application. I also secured them with Spring Security's object ACLs (with <security:intercept-methods /> and <security:protect />). All this stuff, of course, is possible because of AOP magic. So I noticed this wired Spring AOP's behavior - if your class implements some interfaces, then it will use JDK's proxies to implement them and delegate all calls to target, but if class does not implementing any interfaces, then it will use cglib to extend your class and delegate each method call. The problem is that my public service classes does not implement any interfaces, but AOP was not working properly. The reason is ScalaObject interface that is implemented by all scala classes. So I created new traits for all public services in order to solve this problem (I have not found any way to configure Spring AOP - seems that this behavior is hardcoded).
So as you can see it's not a problem to use Spring Security with Scala. I believe that it should be even easier to use Apache Shiro because it claims to be completely container or environment independent (I heard that it's possible to use Spring Security outside Spring, but I also heard that it's pretty painful). Generally in Scala you can archive everything you can in Java. The question is how pretty/idiomatic/pure/side-effect-free resulting code would be.
By the way, there is a new project that integrates Lift with Apache Shiro: lift-shiro. Here you can also find small blog post about it.
Hope this helps.
I have a Java\Spring\Hibernate application - complete with domain classes which are basically Hibernate POJOs
There is a piece of functionality that I think can be written well in Grails.
I wish to reuse the domain classes that I have created in the main Java app
What is the best way to do so ?
Should I write new domain classes extending the Java classes ? this sounds tacky
Or Can I 'generate' controllers off the Java domain classes ?
What are the best practices around reusing Java domain objects in Grails\Groovy
I am sure there must be others writing some pieces in grails\groovy
If you know about a tutorial which talks about such an integration- that would be awesome !!!
PS: I am quite a newbie in grails-groovy so may be missing the obvious. Thanks !!!
Knowing just how well Groovy and Grails excel at integrating with existing Java code, I think I might be a bit more optimistic than Michael about your options.
First thing is that you're already using Spring and Hibernate, and since your domain classes are already POJOs they should be easy to integrate with. Any Spring beans you might have can be specified in an XML file as usual (in grails-app/conf/spring/resources.xml) or much more simply using the Spring bean builder feature of Grails. They can then be accessed by name in any controller, view, service, etc. and worked with as usual.
Here are the options, as I see them, for integrating your domain classes and database schema:
Bypass GORM and load/save your domain objects exactly as you're already doing.
Grails doesn't force you to use GORM, so this should be quite straightforward: create a .jar of your Java code (if you haven't already) and drop it into the Grails app's lib directory. If your Java project is Mavenized, it's even easier: Grails 1.1 works with Maven, so you can create a pom.xml for your Grails app and add your Java project as a dependency as you would in any other (Java) project.
Either way you'll be able to import your classes (and any supporting classes) and proceed as usual. Because of Groovy's tight integration with Java, you'll be able to create objects, load them from the database, modify them, save them, validate them etc. exactly as you would in your Java project. You won't get all the conveniences of GORM this way, but you would have the advantage of working with your objects in a way that already makes sense to you (except maybe with a bit less code thanks to Groovy). You could always try this option first to get something working, then consider one of the other options later if it seems to make sense at that time.
One tip if you do try this option: abstract the actual persistence code into a Grails service (StorageService perhaps) and have your controllers call methods on it rather than handling persistence directly. This way you could replace that service with something else down the road if needed, and as long as you maintain the same interface your controllers won't be affected.
Create new Grails domain classes as subclasses of your existing Java classes.
This could be pretty straightforward if your classes are already written as proper beans, i.e. with getter/setter methods for all their properties. Grails will see these inherited properties as it would if they were written in the simpler Groovy style. You'll be able to specify how to validate each property, using either simple validation checks (not null, not blank, etc.) or with closures that do more complicated things, perhaps calling existing methods in their POJO superclasses.
You'll almost certainly need to tweak the mappings via the GORM mapping DSL to fit the realities of your existing database schema. Relationships would be where it might get tricky. For example, you might have some other solution where GORM expects a join table, though there may even be a way to work around differences such as these. I'd suggest learning as much as you can about GORM and its mapping DSL and then experiment with a few of your classes to see if this is a viable option.
Have Grails use your existing POJOs and Hibernate mappings directly.
I haven't tried this myself, but according to Grails's Hibernate Integration page this is supposed to be possible: "Grails also allows you to write your domain model in Java or re-use an existing domain model that has been mapped using Hibernate. All you have to do is place the necessary 'hibernate.cfg.xml' file and corresponding mappings files in the '%PROJECT_HOME%/grails-app/conf/hibernate' directory. You will still be able to call all of the dynamic persistent and query methods allowed in GORM!"
Googling "gorm legacy" turns up a number of helpful discussions and examples, for example this blog post by Glen Smith (co-author of the soon-to-be-released Grails in Action) where he shows a Hibernate mapping file used to integrate with "the legacy DB from Hell". Grails in Action has a chapter titled "Advanced GORM Kungfu" which promises a detailed discussion of this topic. I have a pre-release PDF of the book, and while I haven't gotten to that chapter yet, what I've read so far is very good, and the book covers many topics that aren't adequately discussed in other Grails books.
Sorry I can't offer any personal experience on this last option, but it does sound doable (and quite promising). Whichever option you choose, let us know how it turns out!
Do you really want/need to use Grails rather than just Groovy?
Grails really isn't something you can use to add a part to an existing web app. The whole "convention over configuration" approach means that you pretty much have to play by Grails' rules, otherwise there is no point in using it. And one of those rules is that domain objects are Groovy classes that are heavily "enhanced" by the Grails runtime.
It might be possible to have them extend existing Java classes, but I wouldn't bet on it - and all the Spring and Hibernate parts of your existing app would have to be discarded, or at least you'd have to spend a lot of effort to make them work in Grails. You'll be fighting the framework rather than profiting from it.
IMO you have two options:
Rewrite your app from scratch in Grails while reusing as much of the existing code as possible.
Keep your app as it is and add new stuff in Groovy, without using Grails.
The latter is probably better in your situation. Grails is meant to create new web apps very quickly, that's where it shines. Adding stuff to an existing app just isn't what it was made for.
EDIT:
Concerning the clarification in the comments: if you're planning to write basically a data entry/maintenance frontend for data used by another app and have the DB as the only communication channel between them, that might actually work quite well with Grails; it can certainly be configured to use an existing DB schema rather than creating its own from the domain classes (though the latter is less work).
This post provides some suggestions for using grails for wrapping existing Java classes in a web framework.