I need help in making a call to EJB remote interface from Spring.
I have a legacy EJB deployed in my JBoss.
Ejb-jar.xml islisted below.
<session>
<display-name>ServiceBean</display-name>
<ejb-name>ServiceBean</ejb-name>
<home>com.ejbproject.ejb.ServiceHome</home>
<remote>com.ejbproject.ejb.Service</remote>
<ejb-class>com.ejbproject.ejb.impl.ServiceBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
I have a web application which uses Spring.The spring application context contains the following entry:
<jee:remote-slsb id="myServiceBean"
jndi-name="ejb/ServiceBean"
business-interface="com.myproject.account.ejb.ServiceBean"
resource-ref='true'></jee:remote-slsb>
I created the business interface ServiceBean in web project and added all methods defined in remote interface define in ejb-jar.xml.
The web application is deployed in the same JBoss server.
But when I try to deploy I am getting a naming exception 'ServiceBean' not bound. Do I have to add environment entries in web.xml to access the EJB (even if both the EJB and web application are deployed in same JBoss)?
First of all, check real jndi-name of your ejb component, usually application server print some information about it in the log files.
Then try to define slsb like this
<jee:remote-slsb
id="taskStarter"
jndi-name="ejb/TaskStarterBean#ru.TaskStarterRemote"
business-interface="ru.TaskStarter"
lookup-home-on-startup="false"
/>
I show my realization of this structure:
#Remote(TaskStarterRemote.class)
#Local(TaskStarterLocal.class)
#Stateless
public class TaskStarterBean implements TaskStarter
#Remote
public interface TaskStarterRemote extends TaskStarter
public interface TaskStarter
Related
I'm building my project with Spring Boot and when uploading to Tomcat as a .war it was throwing errors.
In any case what fixed it is to change
public class Application implements AppShellConfigurator {
to
public class Application extends SpringBootServletInitializer implements AppShellConfigurator {
I've used a sampler from start.vaadin.com v22 to build upon which came by default with the
Application implements AppShellConfigurator
Like this it was running fine inside Intellij with the embedded Tomcat but when deploying to a standalone/external one , I had to change that to the latter.
Is that required ? if yes then the docs should be updated because at
https://vaadin.com/docs/v22/flow/production/production-build
there's no mention of it.
As M. Deinum said this is related to Spring Boot.
Usually you run the Spring Boot Application as an executable JAR. But If you want to run it as a WAR inside a Tomcat you have to use SpringBootServletInitializer.
The first step in producing a deployable war file is to provide a
SpringBootServletInitializer subclass and override its configure
method. Doing so makes use of Spring Framework’s servlet 3.0 support
and lets you configure your application when it is launched by the
servlet container. Typically, you should update your application’s
main class to extend SpringBootServletInitializer...
Source: https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.traditional-deployment
I have an existing web application developed with JSF 2.0 for the view layer and Spring 3 for data access, service and security layers. Then I tried to create the mobile application so I used a Spring #controller class to listen on ws requests but the problem is that when I insert data by mobile application and web application a duplicated entry exception was thrown. It seems to me that Spring create two instances of my Dao in different application contexts one for my managed beans and other one for controller.
NB: I use criteria for data base querys
Can some one help me ?
Finally, i can use a spring controller with jsf web application. i created a applicationContext.xml file then i moved all my beans into it and i conserve my servlet.xml file but with no beans inside, that's will create one root webapp context, by consequence hibernate will create one session for the managed beans and the controller
Difference between applicationContext.xml and spring-servlet.xml in Spring
I am trying to deploy an application that was originally developed for OC4J. It was compliled under JDK 1.5 and ran on OC4J R3.
I deployed it to Weblogic 11g (10.3.6) and got the following error:
Exception preparing module: EJBModule(XXX-ejb-1.0.jar) Unable to deploy EJB: XXX-ejb-1.0.jar from XXX-ejb-1.0.jar: In EJB XXXXXXXXXX, both the remote home and remote component interface must be specified. Currently, only one of them is specified.
Substituted for missing class In EJB XXXXXXXXX, both the remote home and remote component interface must be specified. Currently, only one of them is specified. -
It is referring to an EJB 3.0 as defined in the ejb-jar.xml ejb-jar version="3.0" and afaik this seems to be an EJB 2.1 error because EJB 3 doesn't require both remote and home interfaces. The EJB is a Stateless Session bean that uses Spring 2.5.6 DI and doesn't use annotations, rather the ejb-jar.xml deployment descriptor.
public class myEJBImpl extends AbstractStatelessSessionBean
implements myEJB {
#Override
// Use Spring DI
protected void onEjbCreate() throws CreateException {
xxxDAO = xxx;
}
I have a top-down JAX-WS webservice generated in RAD 8.5 for Websphere 8.5.
I would like to use ServletContextListener to initialise the log4j set-up for the webservice app deployed on websphere.
I created a listener that implements ServletContextListener and ServletContextAttributeListener and added #WebListener annotation to the class ( instead of putting it in web.xml ) but that does not get invoked when I start the webservice application.
According to this link
A WEB-INF/web.xml file. The web.xml does not contain servlet or
servlet-mapping elements. The WebSphere Application Server runtime
defines them dynamically as the module is loaded.
What do I need to do to so that my log4j set-up in initialised or in other words to make sure that the listener is invoked?
I'm new to OSGI and currently trying to use it to create modular web application. Web application itself is created using Vaadin 6.
I following this WIKI article at Vaadin web site: Creating Modular Vaadin application with OSGI
Steps I've did so far:
- created OSGI bundle for module service (simple service which tracks other osgi modules a.k.a. plugins) and deployed it to jboss.
- created vaadin application, just a stub.
OSGI service supposed to be injected to Servlet class, like:
#WebServlet(urlPatterns="/*")
public static class Servlet extends AbstractApplicationServlet {
#Resource(mappedName="vaadin-moduleService")
ModuleService moduleService;
#Override
protected Class<? extends Application> getApplicationClass() {
return ModuleDemoApp.class;
}
#Override
protected Application getNewApplication(HttpServletRequest request) throws ServletException {
return new ModuleDemoApp(moduleService);
}
}
Now the question - how this service can be injected here? Currently I'm just getting NULL pointer, so DI doesn't work. From article referred above:
Note, that the servlet has a moduleService field annotated with the
#Resource annotation. One of the interesting features of GlassFish 3
is that it is possible to inject references to OSGi services into all
container managed Java beans, even though they are not actually
running in the OSGi container themselves. Thus, in this case, GlassFish
will find the module service we define in the previous section and inject it.
According to this Glassfish will do all the magic internally and automatically. Anyone aware of how to get it done using JBoss7?
Unfortunately didn't find any good (for newbie) explanation on how anything running inside of OSGI container can be referenced outside of it... Suppose that converting of the web application itself to OSGI bundle is not required to acomplish what I need. Is this true?
Thanks a lot.
The documentation states that the JavaEE component can get the BundleContext injected as a #Resource. If that works, then you can track your module service through a ServiceTracker.
I saw another example of using Vaadin together with OSGi here.