I am using google guice as DI framework to bind my interfaces to the different Implementation. The server operates normally but whenever i try to call the Resource class the following error occurs. It is not that the binding never works but most of time it fails. I don't know what i am missing . I've given some of my source code below.
ModuleClass
public class ABCModule extends AbstractModule {
#Override
protected void configure() {
bind(IConnection.class).to(ABCConnection.class);
}
Resource class where injection is done
public class Resource {
Logger log = LoggerFactory.getLogger(Resource.class);
private final IContact contact;
private final IContactFolder contactFolder;
#Inject
public MLContact(IConnection con, IContactFolder contactFolder) {
this.contact = contact;
this.con = con;
this.contactFolder = contactFolder;
}
//Resource class methods
..
......
}
I am using guice-3.0.jar
EDIT 1:
INFO: Initiating Jersey application, version 'Jersey: 1.17 01/17/2013 04:27 PM' Aug 8, 2013 9:54:59 AM com.sun.jersey.spi.inject.Errors processErrorMessages
SEVERE: The following errors and warnings have been detected with resource and/or provider classes:
SEVERE: Missing dependency for constructor public com.motilink.server.services.MLContact(com.motilink.connector.IContact,com.motilink.connector.IConnection,com.motilink.connector.IContactFolder) at parameter index 0
SEVERE: Missing dependency for constructor public com.motilink.server.services.MLContact(com.motilink.connector.IContact,com.motilink.connector.IConnection,com.motilink.connector.IContactFolder) at parameter index 1
Related
Using NetBeans, I have successfully run the shopping-cart example presented in the Java EE 6 tutorial on the Oracle website. It's an EAR with two modules: an EJB module and an application client module. I have cut short some details of the code in order to focus on the confusions I am facing. Firstly, below is the code.
The remote interface in the EJB module
package cart.ejb;
import cart.util.BookException;
import java.util.List;
import javax.ejb.Remote;
#Remote
public interface Cart {
public void initialize(String person) throws BookException;
public void initialize(
String person,
String id) throws BookException;
public void addBook(String title);
public void removeBook(String title) throws BookException;
public List<String> getContents();
public void remove();
}
The stateful session bean in the EJB module
package cart.ejb;
import cart.util.BookException;
import cart.util.IdVerifier;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.Remove;
import javax.ejb.Stateful;
#Stateful
public class CartBean implements Cart {
List<String> contents;
String customerId;
String customerName;
public void initialize(String person) throws BookException {
.................
}
public void initialize(
String person,
String id) throws BookException {
.....................
}
public void addBook(String title) {
contents.add(title);
}
public void removeBook(String title) throws BookException {
.................
}
public List<String> getContents() {
return contents;
}
#Remove()
public void remove() {
contents = null;
}
}
The client in the application client module
package cart.client;
import java.util.Iterator;
import java.util.List;
import javax.ejb.EJB;
import cart.ejb.Cart;
import cart.util.BookException;
public class CartClient {
#EJB
private static Cart cart;
public CartClient(String[] args) {
}
public static void main(String[] args) {
CartClient client = new CartClient(args);
client.doTest();
}
public void doTest() {
..................
}
}
Now my confusions begin!!
Confusion-1: The tutorial says it is a remote client. But it is not! It is packaged as a module within the same EAR as the EJB module. Wouldn't #Local be more appropriate?
Confusion-2: If glassfish does consider it a remote communication between the client and the session bean, will the client's container supply a fake instance of the session bean (i.e. proxy) representing the actual instance of the session bean in the EJB container, just like in a "real" remote case? I mean, does remote mean remote, not matter what?
Confusion-3: I am thinking about creating a client in a non-EE environment and then getting it to communicate with the bean from outside that EAR, to get a taste of "real" remote. So, if I launch Eclipse and create a Java SE 7 client program by copying contents from the client in EAR, are these the changes I have to make?
Replace dependency injection
#EJB
private static Cart cart;
with JNDI
private static Cart cart = (Cart) InitialContext.lookup("java:global/cart/cart-ejb/CartBean/Cart");
and add the Cart interface's source code in the Java Standard Edition client project.
Confusion-4: I am unable to find the location of that EAR file. On NetBeans, I can see under cart there are two jar files. But, where is the EAR file? I deployed the project by directly opening it from C:\glassfish-4.1.1\docs\javaee-tutorial\examples\ejb\cart with NetBeans.
#Local would be enough yes, apparently they were lazy with the demonstration and chose to package it all in one. Regardless, your deployment unit is the scope of you #Local interface, so 2 different EARS in the same container could not access each-others #Local interfaces
Yes and no: the outside behavior will be completely identical to a real remote case (with serialization and proxying of objects), but how this is really handled behind the scenes depends on the container implementation. To my knowledge most containers will leverage the fact that even though it's #Remote it is located in the same JVM so for example they will not make an actual remote socket connection.
3.
You need the remote interfaces of your beans
Configure glassfish to allow remote calls on a specific port with specific credentials
Do a JNDI lookup against this setup
I am currently building a Dropwizard + Guice + Jersey-based application where the database access is being handled by JDBI for the time being.
What I am trying to achieve is to have your typical enterprise architecture, where Resources access Service classes accessing a DAO class that in turn accesses the database. It would be nice to get all this wired up in a proper DI way, although I guess I can build my object graph in the run() method of the application if all else fails.
So, I'm running into this problem that has been mentioned here before: Getting a DBIFactory requires both the Environment and the Configuration, which somehow need to be available at the time when Guice does its injection magic and not at run()-time.
Being a Dropwizard and Guice noob, what I've managed to put together so far is that I need a Provider for my DAO objects, something to the tune of
public class UserDAOProvider implements Provider<UserDAO> {
#Inject
Environment environment;
#Inject
Configuration configuration;
#Override
public UserDAO get() {
final DBIFactory factory = new DBIFactory();
final (MyConfiguration) config = (MyConfiguration) configuration;
DBI jdbi = null;
try {
jdbi = factory.build(environment, config.getDataSourceFactory(),
"mysql");
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return jdbi.onDemand(UserDAO.class);
}
}
Registering this as a singleton provider should let me then inject the UserDAO into my Services.
Now, how do we actually get the environment injected into the Provider? Currently I am stuck at Guice complaining about not finding a suitable constructor for the Environment, so it is trying to instantiate it and not grab it from Dropwizard itself.
It seems like this is doable; there is the dropwizard-guice package whose DropWizardEnvironmentModule is, I think, what I need. But I feel like I'm just missing some piece of the puzzle here for an understanding of how to put things together. I've not managed to find a complete working example so far...
I had the same issue as OP but using Hibernate rather than JDBI. My simple solution is applicable to JDBI, though - just switch DBIFactory for SessionFactory.
First add an injection provider for a singleton SessionFactory in your Guice module:
public class MyModule extends AbstractModule {
private SessionFactory sessionFactory;
#Override
protected void configure() {
}
#Provides
SessionFactory providesSessionFactory() {
if (sessionFactory == null) {
throw new ProvisionException("The Hibernate session factory has not yet been set. This is likely caused by forgetting to call setSessionFactory during Application.run()");
}
return sessionFactory;
}
public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
}
}
You need to set the singleton SessionFactory from your application's run() method. In your case, using JDBI, this is where you would create and configure your DBIFactory before handing it over to the Guice module:
public void run(MyConfiguration configuration, Environment environment) {
myModule.setSessionFactory(hibernateBundle.getSessionFactory());
...
}
Now SessionFactory can be injected wherever it is needed. I now use implicit binding for my DAO classes by just annotating the constructor with #Inject and injecting the SessionFactory singleton. I don't explicitly create providers for DAO classes:
#Singleton
public class WidgetDAO extends AbstractDAO<App> {
#Inject
public WidgetDAO(SessionFactory factory) {
super(factory);
}
public Optional<Widget> findById(Long id) {
return Optional.fromNullable(get(id));
}
...
}
Now I can inject my DAO singleton instances into resources:
#Path("/widgets")
#Produces(MediaType.APPLICATION_JSON)
public class WidgetsResource {
private final WidgetDAO widgetDAO;
#Inject
public WidgetsResource(WidgetDAO widgetDAO) {
this.widgetDAO = widgetDAO;
}
...
}
Note that this approach follows the Guice recommendation of injecting direct dependencies only. Don't try to inject Envrionment and Configuration just so that you can create a DBI factory - inject the prebuilt DBI factory itself.
This is how I use Guice with Dropwizard. Inside your run() method add the line
Guice.createInjector(new ConsoleModule());
You cannot inject Environ
Create the class ConsoleModule
public class ConsoleModule extends AbstractModule {
//configuration and env variable declaration
public ConsoleModule(ConsoleConfiguration consoleConfig, Environment env)
{
this.consoleConfig = consoleConfig;
this.env= env;
}
protected void configure()
{
//You should not inject Configuration and Environment in your provider since you are mixing
//dropwizard framework stuff with Guice.Neverthless you will have to bind them in the below order
bind(Configuration.class).toInstance(consoleConfig.class);
bind(Environment.class).toInstance(env.class);
bind(UserDAO.class).toProvider(UserDAOProvider.class).in(Singleton.class);
}
}
We have the same configuration (dw-jdbi-guice) and also an abstract 'base' Application class which complicates things even more.
Since a lot of things happen during run method, and many things depend on the configuration objects we ended up creating the injector in the run method. But since we need objects from bootsrap also (e.g. ObjectMapper), we ended up having a List<Module> field in the Application class. Not the prettiest solution but can handle variety of scenarios.
I've written an HttpServlet which gets deployed to a Wildfly container in a WAR file. The servlet looks like this:
public class MyCallback extends HttpServlet {
#Inject
#Any
private Event<MyEvent> event;
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
String eventName = request.getParameter("EVENT_NAME");
MyEvent e = new MyEvent(eventName);
event.fire(e);
}
}
I also created a beans.xml file (as detailed here) and placed it in my WEB-INF directory. Unfortunately, I still get a NullPointerException when the code tries to execute the event.fire(e) line, which suggests to me the injection isn't working.
What am I doing wrong?
Try adding at least one CDI bean (it doesn't have to do anything), e.g.
#ApplicationScoped
public class JustABean { }
I had similar issue on Wildfly beta, it seems without a single "normal" bean CDI engine just wouldn't kick in.
Also Wildfly ships CDI 1.1 where beans.xml is optional.
I have a Java EE 6 War project containing the following:
An EJB declared as so (it's also a JAX-RS Service):
#Path("/booksList")
#Produces("application/json")
#Stateless
#LocalBean
#Local(BooksListEJB.class)
public class BooksListEJBImpl implements BooksListEJB
A WebComponent declared as so:
#WebServlet(urlPatterns="/initDbData")
public class DataInitListener extends HttpServlet {
#EJB
private BooksListEJB booksListEJB;
An empty beans.xml file in the WEB-INF folder
When I deploy it in WebLogic 12c, I get the following error:
<Warning> <weblogic.jaxrs.onwls.deploy.ejb.provider.EJBComponentProviderFactory> <BEA-000000> <An instance of EJB class com.shivandragon.jee6TestService.ejb.impl.BooksListEJBImpl could not be looked up using simple form name. Attempting to look up using the fully-qualified form name.
javax.naming.NameNotFoundException: While trying to look up comp/env/BooksListEJBImpl in /app/webapp/jee6Test-service-0.1-SNAPSHOT.war/2039754748.; remaining na
me 'comp/env/BooksListEJBImpl'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1180)
at weblogic.jndi.internal.ApplicationNamingNode.lookup(ApplicationNamingNode.java:146)
at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:253)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:426)
at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(ReadOnlyContextWrapper.java:45)
Truncated. see log file for complete stacktrace
I've looked similar questions, and found the suggestion to add #ManagedBean to the servlet. Tried that but had the same error.
My question is:
Shouldn't this work, am I misusing some Java EE 6 directive/standard?
In EJB 3.1 have been added new Bean view - LocaBean. You can develop a bean without need implement any inerfaces. That beans view is "no-interface view", annotated with #LocalBean and injected by classname. There are beans that implemented some local interfaces and has "local view" and should be injected via local interface. In your code you mixed no-interface view bean and local view bean. You should delete the #LocalBean annotation as #Sam answered.
Updated
I test it on WebLogic Server 12.1.1.0.
Create a simple interface with one method:
package ejbrest;
public interface SessionEJBLocal {
public String hello();
}
Then create a EJB with the RESTful annotations:
package ejbrest;
// ... imports
#Path("/booksList")
#Produces("application/json")
#Stateless
#Local(SessionEJBLocal.class)
public class SessionEJBBean implements SessionEJBLocal {
public SessionEJBBean() {
}
#Override
#GET
public String hello() {
return "Hello, world";
}
}
The deployment descriptor, web.xml (you can see it does not have any servlet definitions):
<?xml version = '1.0' encoding = 'UTF-8'?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
</web-app>
You can create a servlet for the local bean injection demo:
package ejbrest;
// ... imports
#WebServlet(name = "DemoServlet", urlPatterns = { "/demoservlet" })
public class DemoServlet extends HttpServlet {
private static final String CONTENT_TYPE = "text/html; charset=UTF-8";
#EJB
private SessionEJBLocal ejb;
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
response.setContentType(CONTENT_TYPE);
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head><title>DemoServlet</title></head>");
out.println("<body>");
out.println("<p>The servlet has received a GET. This is the reply: " +
ejb.hello() + "</p>");
out.println("</body></html>");
out.close();
}
}
After deployment you can try call your RESTful service by url:
http://[host]:[port]/[appcontext]/resources/booksList
Response:
Hello, world
Also, your demo servlet will be accessable by url:
http://[host]:[port]/[appcontext]/demoservlet
Response:
The servlet has received a GET. This is the reply:Hello, world
By default Oracle WebLogic Server use resources as link on Jersey servlet. Please read the official documentation for informs about all supported deployments variants.
Currently I am trying to inject a stateless EJB into a CDI managed controller on Jboss 6 AS Final. The controller is managed in the context an accessible from the JSF pages. If I inject the stateless bean with #EJB it is working. If I inject the stateless EJB with #Inject I get the following Exception:
My controller:
#Named("TestController")
public class TestController {
#Inject
private TestManagerLocal myTestManager;
...
}
}
My stateless bean:
#SuppressWarnings("unchecked")
#Stateless
public class TestManagerBean implements TestManagerLocal {
#PersistenceContext
private EntityManager em;
...
}
The Interface of the Bean is annotated with #Local.
If I try to call myTestManager I get the following exception:
WELD-000079 Could not find the EJB in JNDI: class
de.crud.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$usr$local$jboss$server$default$deploy$test$ear"-SessionBean-TestManagerBean_$$_WeldProxy
THX a lot.
For those not having the luxury to change an ear to a war, I've found the following workaround:
Create an EJB in the war
Inject that EJB with the EJBs from the EJB module
Add CDI producer methods
Qualify #Inject with the qualifier for those producer methods:
Code:
// This bean is defined in the WEB module
#Stateless
public class EJBFactory {
#EJB
protected UserDAO userDAO;
// ~X other EJBs injected here
#Produces #EJBBean
public UserDAO getUserDAO() {
return userDAO;
}
// ~X other producer methods here
}
Now EJBs from anywhere in the EAR can be injected with:
// This bean is also defined in the web module
#RequestScoped
public class MyBean {
#Inject #EJBBean
private UserDAO userDAO; // injection works
public void test() {
userDao.getByID(...); // works
}
}
EJBBean is a simple standard qualifier annotation. For completeness, here it is:
#Qualifier
#Retention(RUNTIME)
#Target({TYPE, METHOD, FIELD, PARAMETER})
public #interface EJBBean {
}
The problem was, that I built and deployed my application as an ear. Weld is working when I deploy my application as an war including all EJBs.
Currently there are various problems arising from the fact that WARs in EAR-Deployments don't share the same classloader. See https://issues.jboss.org/browse/JBAS-8683 for the ongoing discussion in the JBoss-AS JIRA (and vote it up :-) )
UPDATE I found this information on how to disable separate classloaders, option 1 worked for me, but be extremely careful with this. The separation of classloaders hasn't been introduced for no reason, so apparently there are new problems on the road ahead...