Develop Reference

Spring: error using Java Mapper from ibatis library. The interface is not a bean

I am developing a Back-end application using Java and Spring framework.
I start from an archetypal project which, however, causes some problems in the run phase.
I have this interface:
#Mapper
public interface MyInterface {
public ReturnType1 method1(long myLong);
#Select("SELECT * FROM myTab WHERE id = #{myLong}")
public ReturnType2 method2(long myLong);
...
...
}
This interface uses the ibatis library (class org.apache.ibatis.annotations.Mapper);
Elsewhere in the code I have this service:
#Service
public class ExampleService {
#Autowired
private MyInterface myInterface;
...
}
where the #Service annotation is org.springframework.stereotype.Service;. Thanks to #Autowired, this service uses the interface that has #Mapper as an annotation (seen before).
However, in the run phase I get the following error:
APPLICATION FAILED TO START: Field myInterface required a bean of type MyInterface that could not be found. The injection point has the following annotations: #org.springframework.beans.factory.annotation.Autowired(required=true). Consider defining a bean of type 'MyInterface' in your configuration.
Why is this error reported to me? I am not familiar with the ibatis library... in my project I have an xml file in this path: myProject/src/main/resources/mybatis/FileMapper.xml and in the application.properties file I have this row:
mybatis.mapper-locations=classpath*:mybatis/*Mapper.xml
It seems to me that everything is configured correctly. Could you explain to me where and why I get this error?

Hello add #MapperScan
#SpringBootApplication
#MapperScan("com.demo.mappers")
public class SpringbootDemoApplication
{
public static void main(String[] args)
{
SpringApplication.run(SpringbootDemoApplication.class, args);
}
}

Getting javax.Naming.NameNotFoundException when calling WebMethod in JEE 5

I'm using JEE version 5.0.2. I'm calling a WebMethod in a #WebService annotated class. This annotated class calls a Stateless #EJB that contains the business logic (the implementation) of the WebMethod I'm calling.
My WebService class is defined as follows:
#WebService
HandlerChain(file = "MyXService_handle.xml")
public class MyXService {
#EJB(mappedName="MyXBean", beanName="MyXBean")
public MyXBean myXBean;
#WebMethod
public String sayHello(#WebParam(name="nTimes") int nTimes) {
return myXBean.sayHello(nTimes);
}
}
My EJB is defined as follows:
#Stateless(name="MyXBean", mappedName="MyXBean")
#TransactionManagement(TransactionManagementType.BEAN)
public class MyXBean {
#PersistenceContext name="persistence/my_PU", unitName="my_PU")
protected EntityManager entityManager;
public String sayHello(int nTimes) {
String s = "";
for (int i = 0; i < nTimes; i++) {
s += "Hello";
}
return s;
}
}
I'm getting the following error:
Caused by: com.sun.enterprise.InjectionException: Exception attempting to inject Unresolved Ejb-Ref com.my.domain.MyXService/myXBean#jndi: MyXBean#null#com.my.domain.MyXBean#Session#MyXBean into class com.sun.enterprise.webservice.JAXWSServlet
at com.sun.enterprise.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:387)
at com.sun.enterprise.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:206)
at com.sun.enterprise.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:117)
at com.sun.web.server.J2EEInstanceListener.handleBeforeEvent(J2EEInstanceListener.java:259)
... 31 more
Caused by: javax.naming.NameNotFoundException: MyXBean#com.my.domain.MyXBean not found
at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)
at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:188)
at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:74)
at com.sun.enterprise.naming.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:111)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:409)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.naming.NamingManagerImpl.lookup(NamingManagerImpl.java:944)
at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:173)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:407)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:287)
... 34 more
|#]
The WebService class and the EJB are exactly in the same module in the same WAR. This WAR is being deployed in a Glassfish Server version 2.1.1. I only get this warning in the deploy log (server.log):
[#|2018-12-10T22:51:59.045+0100|WARNING|sun-appserver2.1|javax.enterprise.system.tools.deployment|_ThreadID=78;_ThreadName=Thread-946;_RequestID=bf2b9b34-5240-4eca-8b4b-9d16baad7c5b;|Unresolved <ejb-link>: MyXBean|#]
I'm following the Java EE 5 specification to implement all of this, so I'm trying to do my architecture "by the book".
I already tried to implement an interface as explained in here https://docs.oracle.com/javaee/5/tutorial/doc/bnbmg.html but with no avail, the error persisted.
I have no xml configuration concerning the beans. I was expecting all to work via the annotations but I'm getting the javax.Naming.NameNotFoundException explained above.
Am I missing something? I'm available to give more details if needed.
Thank you.

You are using the ejb name and the mapped name. The usage of mapped name is vendor specific. Glassfish is using this as a "global JNDI name". Since you are using both, I don't know which one will take precedence over the other. With your example, empty #EJB and #Stateless anntoations should work.

Jersey custom Context injection

I tried implementing custom context injection just like in this answer:
#Provider
public class DaoContextProvider extends SingletonTypeInjectableProvider<Context,Bar> {
public DaoContextProvider() {
super(Bar.class, new Bar("haha"));
}
}
And here's my controller class, to witch I want to inject my context:
#Path("foo")
public class Foo {
#Context
private Bar message;
#GET
public String index() {
return String.format("%s", message );
}
}
But in response message is null.
I tried adding my context provider to singletons, as recomended:
#javax.ws.rs.ApplicationPath("webresources")
public class ApplicationConfig extends Application {
public ApplicationConfig() {
getSingletons().add(new DaoContextProvider());
}
//...
But then my artifact does not even deploy, and provides me with this error:
Artifact server:war exploded: java.io.IOException: com.sun.enterprise.admin.remote.RemoteFailureException: Error occurred during deployment: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.UnsupportedOperationException. Please see server.log for more details.
I would provide server.log, as described in exception, but I dont know where to find this log.

The set returned from getSingletons() is unmodifiable. Instead we need to override the method
#Override
public Set<Object> getSingletons() {
Set<Object> singletons = new HashSet<>();
singletons.add(new new DaoContextProvider());
return singletons;
}
Note though that a direct Application subclass is limited in functionality compared to the Jersey specific way. In Jersey, the preferred approach is to use a ResourceConfig subclass (which is actually a subclass of Application). For example (you can use PackagesResourceConfig to scan packages).
#ApplicationPath("/webresources")
public class AppConfig extends PackagesResourceConfig {
public AppConfig() {
// scans the package and sub-packages.
super("package.where.all.your.resource.and.providers.are");
getProperties().put("some properites", "to set");
getContainerRequestFilters().add(new SomeFiltersToRegister());
getProviderSingletons().add(new SomeProvidersToAdd());
// see the ResourceConfig API for more methods.
}
}
This will scan for #Path and #Provider annotated classes, so we don't need to explicitly register everything. Though some providers will need to be explicitly registered. Your particular provider doesn't need to be registered though. It i picked up in the package scan.
UPDATE
Ok since you say you are using Glassfish 4.1, the first thing you should understand is that Glassfish 4 uses Jersey 2.x. So any Jersey 1.x dependencies/jars you have, you should get rid of them. Use only Jersey 2.x dependencies, and make sure that they are only compile-time dependencies, as you do not want conflicting versions making it's way to Glassfish, that already has a version of them.
What this means is that your current implementation of the DaoContextProvider will not work. The SingletonTypeInjectableProvider is Jersey 1.x class, and the Jersey 2.x runtime will just ignore it.
In Jersey 2.x there are a few ways to configure injectable objects. One way is to create a Factory for the object. For example.
public class DaoContextProvider implements Factory<Bar> {
#Override
public Bar provide() {
return new Bar("boo hoo!");
}
#Override
public void dispose(Bar bar) {}
}
In Jersey 2.x, the API for ResourceConfig has change, and we can extend it directly. For example
#ApplicationPath("/webresources")
public class AppConfig extends ResourceConfig {
public AppConfig() {
packages("com.stackoverflow.jersey");
register(new AbstractBinder(){
#Override
protected void configure() {
bindFactory(DaoContextProvider.class)
.to(Bar.class)
.in(RequestScoped.class);
}
});
}
}
You can see the AbstractBinder. That is how we register the DaoContextProvider with the Bar class. So now Bar can be injected to your resource classes.
The only Maven dependency you need to pull everything else in, is
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.19</version>
<scope>provided</scope>
</dependency>
Notice the provided scope, so that it does not get built to the war. If you are not using Maven, then grab all the jars in the Jersey JAX-RS 2.0 RI bundle. Remember that you should make them only compile time dependencies. They should no get built into the war.
See Also:
Custom Injection and Lifecycle Management

EJB abstract remote bean

I am developing Java6 web-app (.war) deployed onto glassfish-3 server. Part of my logic, concerned with DB connections etc. is part of another project - .ear deployed along with my app. It all worked well until instead of a simple managed beans I had to create another layer of abstraction to injected logic. Maybe the code will explain it best.
My web-app:
public class OtherClass {
#EJB(name = "IClass", mappedName = "A")
private IClass iClass;
}
}
.ear deployed app:
public abstract class AbClass {...}
#Stateless(name = "IClass", mappedName = "A")
public class A extends AbClass implements IClass {...}
#Stateless(name = "IClass", mappedName = "B")
public class B extends AbClass implements IClass {...}
Common imports (another project as a maven dependency):
#Remote
public interface IClass extends Serializable {...}
However that does not work and while trying to resolve #EJB throws:
Caused by: javax.naming.NameNotFoundException: A#.com.example.IClass not found
...
Caused by: java.lang.IllegalStateException: Exception attempting to inject Remote ejb-ref name=IClass,Remote 3.x interface =com.example.IClass,ejb-link=null,lookup=,mappedName=A,jndi-name=,refType=Session into class com.example.ItherClass: Lookup failed for 'java:comp/env/IClass' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
I am aware I could work around that problem for example by creating a Factory, but I was under the impression that that approach should work.

EJB injection not working

I have 2 EJB module projects and I want from one of the projects to call a stateless no-interface bean from another project. I want to inject the bean to be called using the EJB annotation. The problem is the injection doesn't work(I use NetBeans 7.4 if that is relevant).
The stateless no-interface EJB being called:
package standalonepackage;
import javax.ejb.Stateless;
import javax.ejb.LocalBean;
#Stateless
#LocalBean
public class StandaloneBean {
private static final String message="Greetings!";
public String returnMessage(){
return message;
}
}
The interface of the bean that calls the bean above(this ejb resides in another ejb module project)
#Local
public interface ExampleBeanLocal {
public String getMessage();
}
The implementation of the interface:
#Stateless
public class ExampleBean implements ExampleBeanLocal {
#EJB
private StandaloneBean standaloneBean;
#Override
public String getMessage() {
return String.format("Me - and the second message %s", standaloneBean.returnMessage());
}
}
I also have a main class that just calls the ExampleBean getMessage method(MainClass is located in the second ejb module project):
public class MainClass {
private static ExampleBeanLocal instance = new ExampleBean();
public static void main(String[] args) {
System.out.println(instance.getMessage());
}
}
What am I missing?

First of all if you want to access your business logic as EJB then first you will need to deploy the EJB in an application server. During the deployment process the application server will create something called the JNDI name which is like a gatepass to access your business logic.
Secondly, there are two ways you can invoke an EJB.
1. Creating ContextLookup using JNDI name
2. Using Context Dependency Injection CDI (only within the same Container)
You cannot invoke an EJB using CDI from a POJO ( since it is not contained in any container and the EJB your accessing is in a different JVM ). If you want to access an EJB from a POJO you'll need to use #Remote and use the ContextLookup way of accessing an EJB, you can find more information here
http://wiki.netbeans.org/CreatingEJB3UsingNetbeansAndGlassfish

You need application server with EJB container to run this. Have a look at JBoss, Apache TomEE or something else.

you can use this way to run your jar GLASFISH_HOME/bin/appclient -client app.jar
before compiling your maven project mvn assembly:assembly
and add your main class in your pom.xml