I have a singleton startup ejb A which depends on another singleton startup ejb B which is in another module. I added depends on annotation but the deployment failed with no ejb found exception.
Then I moved the startup ejb to the module where the other startup ejb is placed. The startup ejb are initializing fine now.
Then I tried injecting the singleton ejb A using inject annotation in a stateless ejb from another module and the deployment failed with no ejb exception.
Can anyone help me fix this issue.
P.S
Also I would like to know how to use dependson annotation when the startup singleton ejb are in different modules. I used the jarname.jar#EjbName but it did not work.
Related
I am using Anypont Studio 5.3.0 and server runtime 3.7.0. I want to invoke a main() method from my component. Application is developed using Maven, SpringBoot and JPA. It sits in the jar file and have the following structure.
com
package
Application.class (with main method)
another package
Other classes
lib
other jars
META-INF
persistance.xml
MANIFEST.MF
Org
springframework boot loader and other spring classes.
when file arrives with file pattern that I detect with mule polling component I would like to invoke Java component in mule flow that has main class and all the supporting classes.
Thanks,
David
did you mavenize your Application? If yes, you can add that as a dependency in your mule project pom, which is also mavenize. But you need to make sure that the jars are added in your maven repository i.e. execute first "mvn clean install" to your java application. Otherwise, add the jars in you build path. When you are able to do those, you can create a spring bean or create a java component in mule where they could call your class with main() method.
I never came across this kind of production scenario where there is a need to call main method of java class in enterprise application. Are you sure you have only main method to access other classes, it should have initialize, spring way of injection etc. Simple answer to you question, create a mule java component and override onCall method to call Application(class).main. I will never do this kind of stuff [for sure it will give more problems based on what is being written in main method]. In general we will use main method invocation in desktop application. if possible work on (or let the application team to work on) jar file to have better initializing options
Following is project structure:
MVC 4 application
1) Project is for MVC having controller has injected interfaces.
2) interfaces are existed into this application.
Manager library project.
1) Project contain refernece of MVC application.
2) Implementation of each interfaces into this assembly.
3) NinjectMOdule is existed into this project where binded interface with related manager class.
PROBLEM: unable to get injected classes into web application.
it gives following error:
Error No matching bindings are available, and the type is not self-bindable.
Activation path:
2) Injection of dependency ILeadInformation into parameter leadInformation of constructor of type HomeController
1) Request for HomeController
Usually in the "root" project which manages the kernel you need to load all the modules. This has to be done during initialization of the application i.E. before the application relies on the binding being there.
Let's say the module which binds the ILeadInformation is called LeadModule. It would look like:
IKernel.Load<LeadModule>();
EDIT:
For your concrete scenario, you have your MVCApplication Assembly which contains the application and some interfaces and you have your Manager assembly, which references the MVCApplication assembly, like so:
Now you ought to place the Composition Root in the MVCApplication assembly. But, uh no, you can't reference the Manager assembly, since that would lead to a circular dependency.
So we got to fix this. We need to move the interfaces into a new assembly. And adjust the references so it will look like:
I have 2 modules: ejb and war, and ear module, that contains them. Modules build successfully, but when I try to deploy ear to glassfish, I recieve this error:
glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=17;_ThreadName=Thread-2;|Exception while deploying the app [EarModule] : Invalid ejb jar [BackEnd-1.0-SNAPSHOT.jar]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or message-driven bean.
2. EJB3+ entity beans (#Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component level annotations (#Stateless, #Stateful, #MessageDriven, #Singleton), please check server.log to see whether the annotations were processed properly.|#]
I really don't know what to do, I've found a lot of questions like mine, but there was no solution.
I understood, what was wrong. The problem was in run configurations, I'm using Intellij Idea and in run configurations there was build and make before run of my ear module. I removed this and after maven install it deployed successfully.
You have to add an EJB into your WAR or EAR file. Just Create a new Class and annotate it with #Stateless
I know this is very build specific and it uses Netbeans instead of the OP's IDE but because I was lead here and this will likely be useful to some users:
I had the following build:
Netbeans Enterprise Application with Maven
Glassfish 4.1
Java EE 7
I had tried migrating from a previous non-maven enterprise application and the clone didn't quite work the way I expected, there was some old ejb jars lying around that I deleted.
I had done quite a few things to fix it:
Ensure theres no ejb jars lying around that shouldn't be there. Ensure that you don't have accidently have the ejb module jar included more than once as this can result in the same error too (Manually deploying the ear and deployment through netbeans sometimes gave me different errors).
I used the #Remote interface on my EJB applications. Now you should not be importing your EJB into your War, you should use the annotations correctly as described https://docs.oracle.com/javaee/7/tutorial/ejb-intro004.htm
(This is more of a note) When you update any of your war or ejb, clean and build them before cleaning and building your ear (sounds funny right?).
If you are using interfaces for your session beans then you should put them in a separate jar, make a new project maven > java application. Do the same thing with your persistence entities. Add these as dependencies to both your ejb and war project.
This doesn't relate to me in particular but you should have at least 1 #stateless (or I think #stateful) annotation in a java class inside your ejb module for it to run (for the module to be considered an ejb).
I likely had to do a few more things that I forgot but if you still run into issues comment below and I'll try to update.
Just try to build & install your project using Maven , and then , deploy it in glassfish ( do not run your project directly from your IDE )
I encountered this problem as well. It occurred when I had imported a new EJB project into my Eclipse workspace. The project didn't have a reference to the Glassfish libraries then, since it was not yet included in the EAR deployment assembly.
Upon saving the Bean file, the IDE automatically imported javax.inject.Singleton instead of javax.ejb.Singleton. This made the code compile without warnings, but throw the same error as in the original post.
I have an .ear file with the standard lib directory.
I have a .jar file in that lib directory. It contains UserInfoManager, which is an interface. It contains (for these purposes) no other classes. It also contains a META-INF/beans.xml file.
I have another .jar file in that lib directory. It contains a class named UserInfoResource that is a JAX-RS resource class. That class has the following inside it:
#Inject
private UserInfoManager userManager;
Next, I have an EJB .jar file at the root of the .ear file. It contains a class named UserManagerBean that implements the UserInfoManager interface. This class is annotated with #Stateless and basically nothing else (thus making it a local stateless session bean exposed via its local business interface (UserInfoManager). This .jar file also has a META-INF/beans.xml file.
Next, I have a .war file with an Application class in it and nothing else. This serves as the "mounting point" for any and all JAX-RS resources discovered at deployment time present in the lib directory. I do not declare this Java EE 6 module as a CDI bean archive since it contains no beans.
This spec-compliant arrangement fails at deployment time. Weld (the CDI implementation in GlassFish 3.1.2) claims that the injection point detailed above cannot be satisfied, as there are no known implementations of UserInfoManager available to it.
When that injection point is annotated with #EJB instead, everything works fine.
How do I get CDI to inject a local stateless session bean reference into a JAX-RS resource that is present on the classpath?
Update: Because no matter how I look at this it seems like a specification violation, I have filed a bug with a testcase attached. I encourage readers to take a look and see if they can get it to work.
Update: The workaround is to make sure that your JAX-RS classes are not bean archives, but are annotated with #ManagedBean. In addition, the {{.war}} file that serves as their mount point must be a bean archive (must have a {{WEB-INF/beans.xml}} file). Some combination of these requirements is a CDI specification violation. The following bug tracks these issues: http://java.net/jira/browse/GLASSFISH-18793
Jersey does not treat Resources as managed beans unless there is an explicit scope/#ManagedBean annotation attached to it. So, you need to annotate your resource with #ManagedBean or #RequestScoped for the injection to work.
Seems the problem occurs only if beans.xml is included in the resource jar file. When I remove it and attach #ManagedBean annotation to the resource class (instead of #RequestScoped, since #RequestScoped does not work if no beans.xml is present) it works. I am not a CDI expert, so not sure if this is as designed or a bug.
I'm not sure if this is a bug in Weld or Glassfish or if I'm doing something just plain wrong.
I have three jars: api, impl and base. These jars are packaged to war that is deployed to Glassfish 3.1 (b37). The outcome is an error that states that injection point is unsatisfied in a pojo that is in impl. The failing pojo to inject is in base jar. The curious thing is that I can inject that very same failing pojo to a backing bean in my war with no fuss, and I can also just instantiate the injection dependency by hand using the old fashioned new keyword.
Any thoughts? I also have Maven based test project that replicates this if anyone is interested to see that.
Every jar has beans.xml in META-INF - even the war has beans.xml.
Ville
This problem can be solved by replacing module weld-osgi-bundle.jar (Glassfish is shipped with weld 1.1.0.Final) in Glassfish modules directory with the newest one - 1.1.1.Final. After that remove all files from domains/domain1/osgi-cache directory.