The issue I am currently experiencing is that my entityManager fails to be injected during the execution of a web application deployed within an ear.
The ear is setup as follows:
/META-INF -application.xml (EJBJar +
WAR)
-MANIFEST.MF
-weblogic-application.xml (currently just the default one that eclipse
generates)
/APP-INF
-lib
-EJBClientJar (interfaces + pojos)
-other jars
-classes
EJBJar
/META-INF
-persistence.xml
/src
-Annotated classes
WAR
-Service classes
Classes are as follows:
DAO inside EJBJar
#Stateless(mappedName="AwesomeBean")
public class Awesome implements AwesomeRemote //AwesomeRemote in EJBClientJar
{
#PersistenceContext
EntityManager em;
}
public class AwesomeService //Inside WAR
{
AwesomeRemote = context.lookup (Awesome.path.to.AwesomeRemote) //Is found
}
The call stack is like this:
War -> EJBClientJar -> EJBJar
On the EJB jar the entity manager is null. Question being how do I ensure that the PersistenceContext gets injected? The JNDI lookup succeeds on the AwesomeRemote Interface. The Interface has no annotations on it.
It's probably due to the fact that you try to inject on POJO class, not on managed component. Could you try to mark it as #Stateless and public and check whether it works?
For simple testing you can also add #WebService annotation and invoke your bean with SoapUI for example.
You should read about "packaging" part of ejb specifications.
This structure should be sufficient and work:
/
/lib
EJBClientJar (interfaces + pojos)
/META-INF
persistence.xml
application.xml
EJBJar.jar
WAR.war
As some formatting was lost, I'm not sure about what wasn't right in yours.
If this still doesn't work, try removing the only tricky part from above: put all classes from EJBClientJar in root. You the just have the most simple EAR packaging possible, it just will work.
Also, if you don't use your session bean outside a web application, you could use #Local instead of #Remote .
Related
We got Java EE 7 project with the following structure:
app.ear
META-INF
application.xml
lib
framework.jar
webapp.war
core.jar
Framework.jar is our framework that uses some kind of command pattern.
This is how it works. Each command has it's own ejb attached to it that does all the business logic. This command ejb extends CommandEJB class that have an execute method.
For example, this is an example of a command ejb:
public class cmdCreateBookEJB<T extends cmdCreateBook> extends CommandEJB<T> {
#Override
public void execute() {
//do something
}
}
And in our framework, we also have CommandExecutorEJB that sets the appropriate ejb for the command and execute it.
Example:
CmdCreateBook cmdCreateBook = new cmdCreateBook();
cmdCreateBook.setEjb(cmdCreateBookEJB.class.getSimpleName());
commandExecutorEJB.execute(cmdCreateBook);
The problem is our framework, specifically CommandExecutorEJB(that is packed in framework.jar inside lib folder) needs to know about ejb's from core.jar, so it can handle the command. What actually happens in the framework is that the the specific command ejb(cmdCreateBookEJB) in my example is cast to CommandEJB and then it's execute method is called.
The question is how to make the framework know about command ejbs.
I know that one option is to specify am env-entry in ejb-jar.xml with the core jar module name, and then use #Resource in commandExecutorEJB to find the entry, and then use the JNDI lookup to find the resource that would be cast to CommandBean.
But, I would like not to use ejb-jar.xml as we're using ejb 3.2 and ejb-jar.xml isn't necessary anymore.
EDIT:
To better explain here is how the jndi lookup string would look like for my example: java:app/core.jar/cmdCreateBookEJB
Because framework isn't and shouldn't be aware of the core.jar(The name core.jar name is just an example, someone could name it BookStoreCore.jar), I somehow need to pass module name(in my example core.jar), so that the framework know where to look for classes to find a specific command EJB, in my example cmdCreateBookEJB.
I know that I can use an env-var in ejb-jar.xml to pass module name to the framework. Here's an example:
<session>
<ejb-name>CommandExecutorEJB</ejb-name>
<ejb-class>com.mypackage.CommandExecutorEJB</ejb-class>
<session-type>Stateless</session-type>
<env-entry>
<env-entry-name>com.mypackage.CommandExecutorEJB/moduleName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>core</env-entry-value>
</env-entry>
</session>
But, I would love to eliminate ejb-jar.xml from our project setup
You're using Java EE 7.
You can completely avoid class visibility problems by putting everything in your WAR file. core.jar and framework.jar can both be added to your WEB-INF/lib directory.
You can then directly inject EJBs where ever they're needed.
I have a very simple Spring JPA Repository which is packed into a JAR and stored in the local maven repository.
I can use the JPA Repository in my Unit-Tests and in a little Main-Test-Routine. It gets #Autowired without any problem.
Here is the definition of my JPA-Repository:
public interface TestRepo extends CrudRepository<Seminar , Integer > {
List<Seminar> findAll();
}
And in the applicationContext.xml of the JAR:
<jpa:repositories base-package="de.dmsb.my.core"
entity-manager-factory-ref="entityManagerFactory"
transaction-manager-ref="transactionManager">
</jpa:repositories>
There a also some other Services defined in this JAR too which can be used in the JAR and in the WAR, which includes the JAR as a dependency with maven.
But as soon as a try to #Autowire the the JPA-Repository:
#Autowired
TestRepo testRepo;
I get an runtime error that there is no suitable bean defined. Other beans work - but as soon as it comes to JPA-Repositories it doesn't work.
I mean of course you cannot #Autowire a interface - and in the WAR there is not JPA-Repository bean in the ApplicationContext when I debug it - all the other beans from the JAR are there.
Any idea what the problem might be?
I have an EJB with some JPA logic that I use in my java EE projects.
Instead of copying the class in every project I'm trying to put it in a separate jar, so I have this structure:
Java EE project with EJB and WAR projects in it
JPALogic: JAR project with JPALogic class in it
RemoteServices: JAR project with beans interfaces
Services: EJB project with beans, including JPALogic and RemoteServices as libraries
Frontend: WAR project with frontend, including RemoteServices as library.
JPALogic is used only in the EJB project and there's no reference to it in other parts of the Java EE app. In JPALogic library I've my JPALogic bean:
#Stateless
#LocalBean
public class JPALogic {
#Resource
private EJBContext ejbContext;
#Inject #ShardedPersistenceContext
private EntityManager em;
public JPALogic() {
}
[...lots of methods...]
}
It works perfect if JPALogic code is directly in the EJB project, but when I put it in the external library deployment become very unstable (netbeans 8 + glassfish 4) and almost every deploy fail with this error:
Exception while deploying the app [app] : Cannot resolve reference [Remote ejb-ref name=com.my.autenticacion.services.AutRolBackendServices/jpa,Remote 3.x interface =com.my.infraestructura.jpa.JPALogic,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session] because there are [2] ejbs in the application with interface com.my.infraestructura.jpa.JPALogic.
I've search but it seems this kind of error appear when an interface have more than one implementation, and this is not the case: there's only one bean named "JPALogic" and, inspecting the ear, JPALogic.jar appear one time only.
I'm doing something wrong?
If you jar contains EJB annotations (#Singleton, #Stateless, #Stateful component-defining annotations), its not a simple jar, but an ejb-jar, and should be packaged as a module.
Solution:
You should reference the JPALogic.jar in application.xml as an EJB module.
You can also add a "Class-Path: JPALogic.jar" in the META-INF/MANIFEST.MF of the referencing modules to garantee visibility. It could be visibile, depending on the container.
Like this:
application.EAR
META-INF/application.xml
(must have a reference to the JPALogic.jar EJB module)
JPALogic.jar (EJB-JAR)
remoteservices.jar
services.jar
META-INF/MANITESF.MF Class-Path: JPALogic.jar
remoteservices.jar
frontend.war
For a more details, refer to the JAVA EE 6 specification, chapter EE.8:
EE.8.3.2 EJB Container Class Loading Requirements
EE.8.5.2 Deploying a Java EE Application
I have Tomcat 7.0.47 and I'm hosting a REST Easy JAXRS service. The service uses two external JARs, one that has a base repository interface and default implementation and one that creates a concrete repository derived from the base (i.e. these two JARs have a dependency).
The service works, i.e. I can send a request and get back data from the database.
Now what I'm trying to do is get the repository injected into the REST service, to do this I've changed the REST code to look like
#Path("/country")
public class CountryService {
#Inject
ICountriesRepository repository;
#GET
#Produces({"application/json", "application/xml"})
public List<Country> getCountries() throws NamingException, SQLException {
return repository.getCountries();
}
}
I've added a beans.xml file to the web application's WAR file (it's in the META-INF directory) and I've added beans.xml to both the JARS.
When I deploy the app I see the following message:
INFO: Adding scanned resource: com.mantiso.cricket.service.CountryService
but I don't see similar messages for the repository class in the JAR.
The JAR is deployed; the beans.xml file is in the JAR's META-INF directory; I've tried adding #ManagedBean to the repository class.
I'm sure I'm missing something simple, but lots of searching has turned up not a lot.
This is Tomcat 7.0.47; Weld 2.1.0; RESTEasy 3.0.5
What else should I try?
And the answer is: The beans.xml file for the web app must be in the WEB-INF directory. If it's in the META-INF directory then it's not parsed.
Although, this did appear to work OK when I tried injecting into a servlet
I am using Glassfish 4. And I have an EAR which has a WAR and a JAR (with the EJBs).
I want to call the EJBs from my WAR but am not really sure if I need to use Local or Remote interfaces.
Inside my JAR, my Bean looks like this :
#Stateless
public class Test implements TestLocal {
#Override
public void testing() {
}
}
And my local :
#Local
public interface TestLocal {
void testing();
}
Inside my WAR I have a web service and it looks like this :
#WebService(serviceName = "TestWS")
public class TestWS {
private #EJB TestLocal testBean;
#WebMethod(operationName = "test")
public String test() {
testBean.test();
}
}
Both of these are packaged into an EAR.
When I call my WebService method I get an AccessLocalException :
Warnung: javax.ejb.AccessLocalException: Client not authorized for
this invocation at
com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1895)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
Firstly :
Is this the correct way to call the EJB. Can a WAR inside an EAR use Local interfaces from an included JAR?
If so then does anyone know what I am doing wrong? Do I need to setup some kind of security configuration?
To look up a remote EJB, it must have a remote interface exposed. Include that remote interface into your war.
The GlassFish documentation has an entry for this error:
javax.ejb.AccessLocalException: Client Not Authorized Error
Description
Role-mapping information is available in Sun-specific XML (for example, sun-ejb-jar.xml), and authentication is okay, but the following error message is displayed:
[...INFO|sun-appserver-pe8.0|javax.enterprise.system.container.ejb|...|
javax.ejb.AccessLocalException: Client not authorized for this invocation.
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:...
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(...)
Solution
Check whether the EJB module (.jar) or web module (.war) is packaged in an application (.ear) and does not have role-mapping information in application level, Sun-specific, sun-application.xml. For any application (.ear), security role-mapping information must be specified in sun-application.xml. It is acceptable to have both module-level XML and application-level XML.
#Remote is usefull if you deploy separately your jar which contain your EJBs on a different server, for example.
There, war and jar are in the same ear so you just have to use the Local annotation.
Tips : since EJB 3.1 interfaces are not required, you can use #LocalBean directly on your "Test" class and remove the TestLocal interface.
To call a ejb method into a class which is your war, you firstly have to create a link between war and jar. Being in the same ear is not enough.
If you use Maven, you can simply add the jar reference into your dependencies in the pom of your war.