I spent some time in attempts to understand Embeddable Enterprise Bean Applications and still need some clarifications. Assume I need Junit to test EJB application.
So I have assumptions what should happened, please help me figure out correct answer:
Junit is entrypoint and it deploys EJB application to server? So that EJB and Jboss are "embedded" into tests.
Junit and 'EJB' application are two separate JVM processes and they somehow communicate by jndi names or something(I don't use remote EJB).
Real server(JBoss) never used and EJBContainer is just kind of Mock.
Something else.
Edited:
I found an example:
Could you please comment on this code:
#Test
public void test() throws Exception {
String jbossHomeDir = "E:\\dev_station\\java_station\\Serveurs\\jboss-as-7.1.1.Final";
System.setProperty("jboss.home.dir", jbossHomeDir);
StandaloneServer server = EmbeddedServerFactory.create(new File(
jbossHomeDir), System.getProperties(), System.getenv(),
"org.jboss.logmanager");
server.start();
server.deploy(new File("target/classes"));
Context namingContext = server.getContext();
}
The Java EE 6 Tutorial (that first link in the question) says that
The embedded container, the enterprise bean components, and the client all are executed in the same virtual machine using the same classpath.
That is, the JUnit test ("client"), the embedded container (implemented by JBoss Wildfly, Glassfish, etc.), and the Java EE application components (EJBs, etc.) all run in the same JVM instance (the same process).
Nothing is mocked. Container services (transactions, injection, etc.) are provided by an actual Java EE server implementation.
So, the correct alternative between those four listed in the question is number 1.
Related
Spring has a class called LocalEntityManagerFactoryBean. Why is this class called "Local"? In what meaning is it local? Is there some RemoteEntityManagerFactoryBean class in Spring as well?
I dont have an authoritative source, however I'm pretty sure that it is "Local" in that it is local to the spring application context used by the application.
Spring doesn't provide a Remote EMF, however other components such as application servers will. For instance JBoss AS (an open source J2EE app server) can manage JPA EMF's and will make it available to your application at runtime, eg over JNDI, refer to the JBoss docs
I would be very much thankful to clear me some question about this new EJB3.0 and above version:
1) if suppose I need ejbCreate, ejbActivate and all other events so how can I get it from the new EJB3.0 and above ver.
2) I always have problem to find particular xml file to alocate a JNDI name according to variety of Application Servers so is there any way that I can give JNDI name without xml file and can also be use a portable name that in every Application Server it can be findable of EJB deployed on app server remotely
3)Can any buddy tell me, i have hosting plan of Java/Linux which supports
i) Tomcat - 5.5.xSupport
ii)JDK - 1.6.x Support
iii)JSP/servlet - 2.0 Support
can it be possible that EJB 3.1 be deployed because some where i have got that tomcat is not able to deploy EJB so please give me some advice help...
Thank You...!!!
please Help me...!!!
1) if suppose i need ejbCreate, ejbActivate and all other events so
how can i get it from the new EJB3.0 and above ver.
In EJB 3 and above, the EJB lifecycle is handled through life cycle annotations, such as: #PostConstruct and #PreDestroy.
2) i always have problem to find perticular xml file to alocate a JNDI
name according to variety of Application Servers so is there any way
that i can give JNDI name without xml file and can also be use a
portable name that in every Application Server it can be findable of
EJB deployed on app server remotly
The #Stateless and #Stateful annotations have two attributes that might solve this issue (name and mappedName). Yet
The mapped name is product-dependent and often installation-dependent.
Hope it helps you.
1) ejbCreate, ejbActivate etc. are related to EJB 2.x, if you need similar functionality in EJB 3.x, you should decorate your methods with annotations #PostActivate, #PrePassivate etc. Method signature should follow certain rules, example for #PostActivate:
The method annotated with #PostActivate must follow these
requirements:
The return type of the method must be void.
The method must not throw a checked exception.
The method may be public, protected, package private or private.
The method must not be static.
The method must not be final.
This annotation does not have any attributes.
2) It seems that you're referring to name and mappedName attributes of #Stateless and #Stateful annotations. For more details see official documentation. From my experience mappedName is better, but it's application-server-specific, e.g. on Glassfish it works perfectly. Example:
#Stateless(mappedName="ejb/myBean")
public class MyFirstBean {
..
}
Since no one answered Question 3 ..
3)Can any buddy tell me, i have hosting plan of Java/Linux which supports i) Tomcat - > 5.5.xSupport ii)JDK - 1.6.x Support iii)JSP/servlet - 2.0 Support
No, you are going to need a server that supports Java EE. Read How to deploy EJB based application on Tomcat
Assume the follwing method:
Test getTest()
{
Properties props = new Properties();
props.put(javax.naming.Context.SECURITY_PRINCIPAL, "OtherUser");
props.put(javax.naming.Context.SECURITY_CREDENTIALS, "OtherPassword");
InitialContext ic = new InitialContext(props);
return (TestHome)PortableRemoteObject.narrow(ic.lookup("ejb/Test"),
TestHome.class).create();
}
If this method (in an EJB) is called from a client using user "MyUser" I'd like it to return an EJB with a different caller principal. Calls to Test made by the client would then be noted as being from "OtherUser". i.e. I have programmactially changed a client's caller principal for a given EJB.
However, I find no text on this in the Java EE specs and although it works on our current Java EE app-server (Sybase EAS 4.1), I'd like to ask you if this is a Java EE standard approach or not.
A standard way of handling login/logoff is JAAS. I don't know if it's fair to say that it is the standard, but it's supported by the Java EE servers I've worked with so far (JBoss, Websphere), and apparently also by Sybase EAS.
JBoss, for instance, comes with several predefined login modules for Database and LDAP and whatnot, that you just have to declaratively configure for your application. However, you are also completely free to write your own login module by implementing the respective interface (javax.security.auth.spi.LoginModule).
Take a look at the JAAS Reference Guide.
About your code snippet: I don't know if that'll work on other app servers. This is EJB 1.1, and thus really, really old stuff. You should definitely look at EJB 3.1 and consider modernizing your application anyway.
If I get this right this should link a username to an EJB across more than one methodcall, which in my opinion is a state. I guess the standard for this would be to create a Stateful SessionBean with a setUser(String name) method. In a stateless bean you would have to pass the userName (or properties object) on each methodcall.
I have deployed an enterprise app in an EAR and a standalone web app in WAR (out side of the EAR) to the same Java EE server.
Question is can I access the local interface of the session bean in the EAR from the standalone WAR? if so can I use dependency injection (DI)?
Section 3.2.2 of the EJB 3.1 specification explicitly states that this is not portable:
Access to an enterprise bean through
the local client view is only required
to be supported for local clients
packaged within the same application
as the enterprise bean that provides
the local client view. Compliant
implementations of this specification
may optionally support access to the
local client view of an enterprise
bean from a local client packaged in a
different application. The
configuration requirements for
inter-application access to the local
client view are vendor-specific and
are outside the scope of this
specification. Applications relying on
inter-application access to the local
client view are non-portable.
In general, the solution will require at a minimum:
Some mechanism for allowing both the EAR and WAR class loaders to have visibility to the same interface class.
Some mechanism for looking up a local interface from another application. For example, java:global.
The answer anyway to both your questions is yes.
Since both the ear and war are in the same JVM, a local interface can be used. To get an instance of the session bean, you would use the global JNDI name of said bean to do either a JNDI lookup or use with the mappedName property on the #EJB annotation. Those names are standardized via the following pattern:
java:global[/<app-name>]/<module-name>/<bean-name>[!<fully-qualified-interface-name>]
Lookup would thus be if the name of your ear is my_app, your bean is MyBean.java and its local interface is com.foo.SomeBeanLocal:
InitialContext ctx = InitialContext();
SomeBeanLocal someBean = (SomeBeanLocal) ctx.lookup("java:global/my_ear/SomeBean/com.foo.SomeBeanLocal");
Injection would be:
public SomeManagedClass {
#EJB(mappedName="java:global/my_ear/SomeBean/com.foo.SomeBeanLocal")
SomeBeanLocal someBean;
}
There are two catches however:
Non-standard naming
Older Java EE implementations (e.g. JBoss AS 5.1, Glassfish 2, Websphere) used their own naming pattern. E.g. JBoss AS 5.x would use:
<app-name>/<bean-name>/local|global
E.g. with the same names as the previous example, the global JNDI name of that bean in JBoss AS 5.1 would be:
my_app/MyBean/local
As said, other old application servers might use other names.
Startup-order
Especially with injection you have to assure somehow that the application you want to inject from has been started before the application you want to inject into. I.e. in your case that the EAR has been started before the standalone WAR. There are no standard mechanisms for this. You might be just lucky that it happens to be in the right order for you. This order might be influenced by time-stamps, alphabetical order of application names, or something else entirely.
JBoss AS for example uses <depends> tags in many of its proprietary configuration files, which is perfectly suited for this although it can be hard to find out what exactly you need to depend on (the syntax can be very cryptic).
I'm trying to inject a EJB within my RESTful Service (RESTEasy) via Annotations.
public class MyServelet implements MyServeletInterface {
...
#EJB
MyBean mybean;
...
}
Unfortunately there is no compilation or AS error, the variable "mybean" is just null and I get a NullPointerException when I try to use it.
What I'm doing wrong?
Here are some side-informations about my architecture:
JBoss 4.2.2.GA
Java version: 1.5.0_17
local MDB-Project
remote EJB-Project
WAR Project with the RESTful Service which uses the remote EJB and sends messages to the local MDB-Project
Thanks in advance!
br
Dominik
p.s: everything is working fine when I use normal context lookup.
I had a similar problem (though without #Remote beans). The way it worked for me - sample application is here: https://github.com/kubamarchwicki/rest-app/ (this works: https://github.com/kubamarchwicki/rest-app/blob/master/service-webapp/src/main/webapp/WEB-INF/web.xml#L9)
The crack with context lookup is that the name changes with a change of the ear name. If you fancy things like versions, it makes the whole thing hard to trace or forces you to hardcode ear name somewhere in the code.
Just a few cents to an old discussion ;-)
This is not exactly my forte, so maybe I am way off... but, can you do EJB stuff in a WAR? I was under the impression you needed to do EJB work in an EAR.
JBoss 4.2.2.GA is not a fully compliant Java EE 5 server, it does not support EJB references injection in servlets or application clients, only in the EJB layer. Use JBoss 5 for that (or perform a lookup).
JBoss 4.2.2.GA supports only Servlet 2.4. There is no support of DI on Servlet 2.4. Hence you always get 'null' for myBean variable. As suggested, please migrate to JBoss 5.0 which supports Servlet 2.5 which makes use of Java 5 features like annotations.