I know that #postconstruct annotation is used when we want a method to call at the time of creation of its object after constructor. But my question is can we use it inside OSGI service?
It depends on the dependency injection framework you use. If you use declarative services the equivalent would be #Activate. A good example is the enroute microservice example.
If you use Aries CDI then indeed #PostConstruct works. Unfortunately there are not yet good examples for this as it is still quite new but it works for the most part like normal CDI in Java EE.
Related
I'm currently in the making of an EJB Module, which could not be complete without persistence.
My initial instinct led me to use Spring Boot, since it has some wild implementations of how one could use JPA and to be honest, I'm kinda spoiled.
However, I couldn't really get Spring up and running in my EJB Module. I created the usual class with the public static void main(String[]) method, but my fear, that this method never runs became reality and using a #PostConstruct method to initialize Spring sounds ridiculous.
How can I initialize Spring Boot on an EJB module? Should I make another module and somehow refer to that from my EJBs? How can I do that? Is it something that people actually do, or should I just get my lazy back-side down in front of the computer and learn "proper" JPA?
Thanks in advance
You will have to use SpringBootServletInitializer to get Spring online inside container.
https://www.baeldung.com/spring-boot-war-tomcat-deploy
It is possible to use Google Guice (any other DI framework) for injecting EJBs in Java EE 5? By default Java EE 5 uses JNDI to injecting EJBs.
I have no direct experience with Guice - but yes, it's possible to use other frameworks for injecting EJBs in a JEE5 application. For instance, Seam does just that. So in principle, it should be possible as there isn't an inherent restriction in the kind of objects that can be injected, as long as the framework takes care of all the lookup details.
UPDATE:
Take a look at this post detailing how to inject EJBs using Guice.
I have an ApplicationContextProvider class, which can used to access Spring ApplicationContext from beans not managed by Spring. Something like mentioned here
For the spring managed beans however I can make them ApplicationContextAware, so they can get access to ApplicationContext.
My question is, is it a good idea to use the common ApplicationContextProvider to get spring application context from the spring-managed beans as well or should I continue to use ApplicationContextAware?
Using a singleton with static reference to application context is asking for trouble. It is almost never a good idea to use such utility class in any case. When dealing with legacy web application use WebApplicationContextUtils instead.
I once reinvented this solution in a project during migration from EJB 2.1 to Spring - but after migration we get rid of it and could sleep again.
Back to your question - using such utility for Spring managed beans has no sense at all. To be honest, I rarely need ApplicationContextAware interface as well. Spring is suppose to inject dependencies, you shouldn't ask Spring for them all the time!
Can you show us some use case when you need quoted utility class (both for managed- and umanaged beans)? Looks like you are refusing to accept support Spring gives you.
We are starting a new project based on EJB 3.0. I have a "spring" based background (and love it), so for me loose coupling and testability is a big must have. This post should not be about "ejb vs. spring". It would be perfect if you already have real project experience with this.
here is some example code to demonstrate the problem:
client -> ejb -> collaborator 1 -> collaborator .. -> collaborator n
<!-- language: java -->
#Stateless
public class SampleService {
// or #Inject via CDI
// or #Autowired via Spring
#EJB // or just use a stateless session bean via EJB 3.0
private Bank bank;
// same for this component
#EJB
private Calculator calc;
// both collaborators must be settable from outside, to make everything testable (and mockable)
/**
* sample "business service" called from client
*/
public void debit(BigDecimal amount){
calc.calculate(amount.subtract(new BigDecimal(100)));
bank.debit(amount);
}
}
// or via #Component (Spring), or CDI?
#Stateless // or Stateless Session bean with optional #Service/#Singleton annotation?
public class Calculator {
public void calculate(BigDecimal subtract) {
// calculate stuff....
}
}
// or via #Component (Spring), or CDI?
#Stateless // or Stateless Session bean with optional #Service/#Singleton annotation?
public class Bank {
public void debit(BigDecimal amount) {
// ...
}
}
i want to know what is the best way to implement dependency injection for all the collaborators and their collaborators in ejb 3.0? collaborators in this sense can be very very small dedicated classes.
we have discussed the the following options so far and like always don't have a proper conclusion yet :)
only use the ejb standard with everything beeing a stateless session bean and all consequences (like pooling, resource handling etc.)
use stateless session beans as "business components" (entry points) and from there on
a) spring wired dependencies (via "jboss snowdrop" integration)
b) CDI wired dependencies (via WELD for ejb 3.0 and jboss eap 5.1)
i don't need to know how i can use the beans in a unit test. the answer i am after is what is the best approach to wire up all the dependencies inside the running appserver (spring vs. guice vs. CDI vs. EJB). i only need to know the graph from the outer EJB ("business entry point") downwards. so everything outside (servlets, frontend etc.) is not scope of this question :)
please, assume EJB 3.0 and jboss eap 5.1 are set for the project :)
looking forward to your answers and hopefully some project based knowledge.
If you need method level transaction management, security, concurrency management or any other services that a session bean can offer then make them EJB session beans. You can start out with managed beans and then make them session beans as and when you need to.
If you want to inject these session beans into managed beans (which in CDI is anything in a jar file that contains a beans.xml file in the meta-inf directory) then use #EJB. If you want to inject a plain managed bean into a session bean use #Inject.
If you want to inject remote session beans (or any Java EE remote resource) then this link explains how you can do this via an adapter class. Essentially it keeps all of your nasty strings for lookups etc in one place and allows you then to treat these remote resources just like any other injectable bean (via the #Produces annotation on the adapter member variables). You don't have to do this but it is recommended.
Typesafe resource injection
I would definitely vote against mixing frameworks.
I'm working on a project that is hooked on EJB, Spring and JBoss Seam (and also has half-Flex, half-JSF front-end). A true technology zoo!
Anyway, wiring it all together is not the worst part, those frameworks have flexible injection capabilities. Testing is also more or less bearable.
The most painful was to get rid of memory leaks caused by different lifecylce models, synchronize transaction, and clean up threading behavior.
Now we're moving to pure Java EE 6 (getting rid of Spring, Flex and shifting from Seam to CDI). So far we're really pleased with the results.
BTW, I'm not criticizing Spring. Stick with either Java EE or Spring stack, mixing them is just asking for trouble.
Well in general in Java there are "too many choices," so certainly in this area as well. I would not describe EJB as a general purpose Dependency Injection framework, rather they use DI for their purposes. If that is how you want to code, you should look to add a framework for this purpose. If you know and like Spring, go for it. I have used Guice with EJB's (here is a nice cookbook) to good effect as well, if you needed yet another framework to figure out how to do this.
If your main goal is to allow dependency injection for testing I would recommend just letting those values be settable via changing them to protected or giving them setters. I'm a fan of using Mockito to stub everything in Java EE EJB 3.0 and when doing any testing outside of integration testing to just allow Mockito to stub the methods for me, but if you are looking for full dependency injection like the capability to have several different beans based off of the same class, but with different dependencies I would recommend as Yishai said and going with Spring on top.
we have a frontend application that that uses Swing. We use Spring framework, but currently it is used just to autowire few beans...
What are reasonable next steps to use Spring more often?
Is it worth for non web application?
What would be advantages and disadvantages?
The advantages of using Spring (or any other dependency-injection) framework, is that you get a (hopefully) loosely coupled system, i.e you classes does not create instances of their collaborators, so you can easily change the implementation.
This is widely known as the Inversion-of-control principle (IoC, also the I in SOLID), and this is a good principle to follow. This means that spring is not limited to web applications, but can be used in any application that want to use an IoC-container (which is basically what spring-core is).
Disadvantages:
This really depends on how you look at things. There is more code (you have to define a entry-point for the injected collaborators), but that also makes the code more testable (the entry-points are seams which you can use to inject mocks and stubs in testing).
Also, you can't look at the code and immediately see which implementation of the collaborators that are used. But that also makes for good code, since you depend on interfaces, not implementations.
You get more config: either in an xml-file (old-style spring), or with annotations. Up until recently you had to rely on non-standard spring annotations to inject (#Autowired) resources, but now you can use the standard java dependency injection annotations, which means that you can switch out spring as your IoC-container without changing your code.
There are probably alot more advantages and disadvantages to using spring in your application, but this should get you started on deciding if using Dependency Inversion is a good thing for your application
More to the point of your question about Swing and Spring. In an application I have been working on we have been using spring to wire up the whole application. The different dialogs get their logic injected (no application logic should (in my opinion) be located together with gui logic). We are using JPA/hibernate as the database-layer, so we use spring spring to create and inject the entitymanager to our DAOs, and set up transactional settings.
I've written swing UI's that are backed by spring.
cons
the startup can be slower but you have to have a large app for that to happen.
and a splashscreen is a good idea in those situations.
its easy to "overbean" or over-zealously make everything a bean, which gets messy.
pros
spring works fine behind a GUI.
it provides a lot of services you can use
the obvious dependency injection and decoupling
a global event system, simpifying some of your own event listeners, for events that will only ever be fired by one source
resource accessing
database access is eays in 2 tier apps
rpc for 3 tier apps is easy
There are other services the spring application context provides, but that I haven't used.
If you go this direction, also look into the java-based configuration for spring, which is new in 3.0. I find that helpful as well, as it makes my spring configuration type-safe.
One disadvantage of using Spring in a Swing application is that Spring DI will make startup slower.
well one would be , if you ever decide to migrate to a web app , all you need ( well almost) to change would be the views. That's the beauty of MVC applications.