I have to migrate a software project from Websphere Application Server v8 (WAS8) to Webphere Liberty Base v17 (WL17) and ran into troubles with the EJB's. E.g. there is the following EJB:
#Stateless
#Local(MyUserServiceLocal.class)
public class MyUserServiceBean implements MyUserServiceLocal {
#EJB
private OtherServiceLocal otherServiceLocal;
#Resource
private SessionContext context;
public MyUserServiceBean() {
}
public String getUserEmail() {...}
public String getUserDataId() throws ServiceException {...}
...
}
With the corresponding local interface:
#Local
public interface MyUserServiceLocal {
public String getUserEmail();
public String getUserDataId() throws ServiceException;
...
}
There are a lot more EJB's following a similar implementation scheme.
The project builds fine, all facets in all Eclipse projects are set correctly and maven creates a fresh and deployble EAR file. But when I visit the applications default page the following nested exception is thrown: The MyUserServiceBean bean class for the MyApplication#MyUserServiceEjb.jar#MyUserServiceBean bean does not have a public constructor that does not take parameters.
I currently can not imagine why this exception is thrown by WL17. The feature configuration of my WL looks like this:
<featureManager>
<feature>appSecurity-2.0</feature>
<feature>cdi-1.2</feature>
<feature>distributedMap-1.0</feature>
<feature>ejbLite-3.2</feature>
<feature>ejb-3.2</feature>
<feature>jacc-1.5</feature>
<feature>jaxrs-2.0</feature>
<feature>jaxws-2.2</feature>
<feature>jca-1.7</feature>
<feature>jdbc-4.1</feature>
<feature>jndi-1.0</feature>
<feature>jpa-2.1</feature>
<feature>jsf-2.2</feature>
<feature>jsp-2.3</feature>
<feature>ldapRegistry-3.0</feature>
<feature>mdb-3.2</feature>
<feature>servlet-3.1</feature>
<feature>ssl-1.0</feature>
<feature>webCache-1.0</feature>
<feature>wmqJmsClient-2.0</feature>
</featureManager>
I is the same when I do not load the mdb or the ejb feature. Is there any idea how to solve this problem? I have googled a lot and reade half of the internet but didn't get an answer or an idea how to solve this problem.
I found the problem of the EJB. One of the interface methods was declared to throw a javax.xml.rpc.ServiceException. I do not understand why this should be a problem, but after removing the throws declaration in the interface and the implementation class WL 17 was able to initialize the bean correctly.
Related
I'm using Eclipse with Glassfish for my first steps in Java EE. I've created three eclipse projects (JPA project, EJB project, Web project). I've created a local EJB bean TestBean with a local interface TestBeanLocal:
#Stateless
#LocalBean
class TestBean implements TestBeanLocal {
#Override
public void doSomething(List<JPAEntity> myEntities) {
for(JPAEntity a : myEntities) {
}
}
}
and a ManagedBean that uses the EJB:
#MangagedBean
public class MyBean {
#EJB
private TestBeanLocal testBean;
#PostConstruct
private void init() {
//load JPAEntity from Database
List<JPAEntity> myEntities = ....
testBean.doSomething(myEntities);
}
}
My problem is that I get a ClassCastException at the for loop in the TestBean.
java.lang.ClassCastException: us.mypackage.jpa.JPAEntity cannot be cast to us.mypackage.jpa.JPAEntity
I found another stackoverflow question that says that this error message is because of two different classloaders. How can I fix this? Can I tell EJB to use the same classloader that my webproject uses?
It seems that the entity jar is located in both war and ear
Try to remove the entity jar from the war library
War should see the ear libraries file
HTH
we are upgrading our web application to Oracle WebLogic 12c with EJB 3.x, and we got an issue.
This is the scenario...
We have a simple EJBs that we are going to call MyService, defined with its bean and local/remote interfaces defined by the EJB 3.x annotations.
Here is a pseudo code of the scenario:
class MyListener implements ServletContextListener {
#EJB private MyService myService;
public void contextInitialized(ServletContextEvent arg0) {
// Here myService is correctly instantiated, so we do something...
}
}
Now we have to move the contextInitialized method logic inside an utility class, so the new scenario will be:
class MyUtility {
#EJB private MyService myService;
public void doSomething() {
// Here myService is NULL!!!!!
}
}
class MyListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent arg0) {
new MyUtility().doSomething();
}
}
I have read a lot of documentation about that problem, and I discovered that only some kind of classes are scanned by the Application Server to resolve the injected EJBs ( Java EE 6, 5, 7 | List of managed beans or classes: EJBs , JSF beans and ..? ).
Is there a workaround to force the scanning of a custom class like mine with WebLogic?
Thank you very much.
There is an option to wrap you Injection into a CDI-Component and to use this one in your code. CDI has the capability to work in standalone java, as soon as you configured it well.
Another helpful option can be the fact, that CDI supports EJB-injection too (in some usecases):
CDI.current().select(MyService.class).get();
BUT: EJBs has their own Transaction-Management. So I would prefer the wrapping into a cdi-component to get more controll in it.
I am trying to build an application ear file with the following structure:
app.ear
--> lib
-- app-domain.jar
-- app-api.jar
-- app-common.jar
...
--> META-INF
-- application.xml
-- glassfish-application.xml
-- MANIFEST.MF
-- app-ejb.jar
-- app-rs.war
The app-api.jar file contains my remote interfaces like
#Remote
public interface LanguageService {
/**
* #return all languages known to the system
*/
List<Language> loadLanguages();
The implementation is contained in the app-ejb.jar file and looks like this:
#Stateless
#Remote(LanguageService.class)
#Path("/language")
public class LanguageServiceImpl extends ValidatingService implements LanguageService {
#PersistenceContext(unitName = "kcalculator")
EntityManager em;
#GET
#Produces("application/json")
#Override
public List<Language> loadLanguages() {
CriteriaQuery<Language> query = createLoadLanguageQuery();
return em.createQuery(query).getResultList();
}
And finally I want to provide this as an JAX-RS web service and thus have my implementation of the javax.rs.Application class in the app-rs.war file, which looks like this:
#ApplicationPath("/resources")
public class MyApplication extends Application {
#Override
public Set<Class<?>> getClasses() {
Set<Class<?>> s = new HashSet<Class<?>>();
s.add(LanguageServiceImpl.class);
return s;
}
This deploys without any problem, the application class is also detected. However, when i finally access the web service an internal server error occurs due to a NPE.
The LanguageServiceImpl cannot be looked up, the log contains the following entry:
Caused by: javax.naming.NameNotFoundException: No object bound to name java:module/LanguageServiceImpl!com.kcalculator.ejb.LanguageServiceImpl
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:741)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:167)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
... 63 more
Hence the file is considered a Pojo, and so the reference to the entity manager is not initialized, which finally results in the Nullpointer exception.
I am kinda stuck, as annotating the bean class and giving it a mapped name is not working. Putting my application class into the ejb.jar file does not solve the problem either.
Can anyone point out what i am missing here?
Additional comment:
What I found out in the meantime: If I add a stateless session bean to my app-rs.war file and register it in MyApplication, it works without any problem. There injecting the LanguageService works, too. So it seems the problem is related to the fact that the service implementing bean class is located in another artifact.
The problem could be that you have an EJB with a remote interface.
JAX-RS 1.1 states in 6.2 that JAX-RS annotations only need to be supported on no-interface beans and local interfaces:
JAX-RS annotations MAY be applied to a bean’s local interface or directly to a no-interface bean.
As indicated in one of the previous comments, a working solution was found by moving the session beans to the web archive as well. Thus the separation between the ejb .jar file and the disclosing web service containing project is gone, however it seems rational to have the services in the artifact that is also supposed to provide the web services.
Thanks for the hints, however it is still not clear to me (according to the specification) why the initially described approach should not be feasible (but i realized it isn't...).
I try to deploy a jboss5 bean project bundle on a jboss7 server. An other developer already made some changes that the code can work on jboss7, like to place a jboss-deployment-structure.xml into the project.
I created two beans, one in project A (BeanA) and one in project B (BeanB).
BeanA has to lookup for BeanB. I always get "No EJB found with interface of type 'de.foo.soa.foobar.al.BeanB' for binding de.foo.soa.foobar.ba.ProjectB/BeanB.
Bean B:
import javax.ejb.Stateless;
import javax.ejb.LocalBean;
#Stateless
#LocalBean
public class NumSrvLocalBean {
public String testNumSrv() {
return "numsrv works";
}
}
Bean A does:
#EJB private NumSrvLocalBean numSrvLocalBean;
private String numSrvLocalBean_path = "java:module/NumSrvLocalBean!de.foo.soa.foobar.al.NumSrvLocalBean";
ctx = new InitialContext();
numSrvLocalBean = (NumSrvLocalBean) ctx.lookup(numSrvLocalBean_path);
I also added the right dependency to the jboss-deployment-structure.xml:
<module name="deployment.ProjectB.jar" export="true"/>
So evertything is fine for my understanding but I always get this exception. I created my own project, lets call it project X. There I can lookup for any Bean I want to from all other projects (about 15). I cant inject in project A any bean outside from project A. But I can inject beans inside the project. So there must be something that blocks the beans inside the project.
I've got this files in project A:
jboss.xml
jboss-deployment-structure.xml
MANIFEST.MF (standard, not filled)
persistence.xml
seam.properties
ProjectA.properties (contains an wsdlUrl because this project was also configured as XML-RPC project)
I look forward four your ideas,
greetings.
I solved this problem by using EJB(mappedName="java:global/....").
I already tried EJB(mappedName=className.JNDI_NAME) but this didnt worked. We used Interfaces in JBoss 5, where we defined the JNDI name like
#Local
public interface ClassNameLocal extends ClassNameInterface {
/** Name im JNDI (Java Naming and Directory Interface) */
public final static String JNDI_NAME = "foo/bar/and/so/on/ClassName/local";
}
This seems not to work anymore. I needed to use the full path.
I have #Local interface
#Local
public interface IRepo
{
and two realisation, but only 1 bean realisation
#Stateless(name = "RepoBean")
public class RepoBean implements IRepo
{
second
public class SimpleRepo implements ILogRepositoryIRepo
{
and inject it ti my Web service using
#EJB(name = "RepoBean")
private IRepo repository;
And it's works well on jboss and on WebLogic. But on GlassFish 3.1.1 I get Error (while deploying)
Cannot resolve reference Local ejb-ref name=RepoBean,Local 3.x interface =com.company.IRepo,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session because there are 2 ejbs in the application with interface com.company.IRepo.
But I have only 1 ejb realisation.
Any ideas? May be I can use some deployment-desriptor or something else.
EJB 3.0, Java EE 5
I really didn't understand what you're trying to do, but if you have two beans that implement the same business interface, you'll have to use the 'beanName' attribute as follows:
#EJB(beanName = "RepoBean")
private IRepo repository;
-- UPDATE
Look at this: java.net/node/702013. There is a bug issue to this problem: java.net/jira/browse/GLASSFISH-11684
Seems like this only occurs with EJB-in-WAR packaging. In ejb jar doesn't happen.
Well, Glassfish is more right than JBoss and WebLogic, Business-Bean-Classes should all have their own EJB-Local-Interface.
I Guess WL or JBoss will give you a warning instead of an error.