I have created and EJB with a remote interface:
#Stateless
public class TestSessionBean implements TestSessionRemote
{
public void businessMethod()
{
System.out.println ("***businessMethod");
}
}
I to access it from another component (e.g a servlet) running on the server via:
ic = new InitialContext();
ic.lookup("myEJB");
I am using netBeans 6.5.1 and glassfish v2.
How can I do that?
Thanks,
Ido
actually ejb3 use a default naming convention, wich i've not found a way to get around.
The name for your bean would be something like:
TestSessionBean#package.TestSessionBean
To acess your remote service you can do something like this
InitialContext ctx = new InitialContext();
ctx.lookup(interfaceClass.getSimpleName()+"#"+interfaceClass.getName());
where interfaceClass is the class of your remote interface.
do note you havent defined a remote interface(or local for that matter) for that webserver. you mightnot be able to acess theejb from another context.
As for changing the name that is actually i dont think is possible through anotations. not sure though
Related
I am trying to use Spring LDAP in one of my Spring Boot projects but I am getting an 'Address already in use' error when running multiple tests.
I have cloned locally the sample project here:
https://spring.io/guides/gs/authenticating-ldap/
...and just added the boilerplate test normally created by Spring Boot to verify that the Application Context loads correctly:
#RunWith(SpringRunner.class)
#SpringBootTest
public class MyApplicationTests {
#Test
public void contextLoads() {
}
}
If run alone, this test passes. As soon as LdapAuthenticationTests and MyApplicationTests are run together, I get the error above for the latter.
After debugging a bit, I've found out that this happens because the system tries to spawn a second instance of the embedded server.
I am sure I am missing something very stupid in the configuration.
How can I fix this problem?
I had a similar problem, and it looks like you had a static port configured (as was in my case).
According to this article:
Spring Boot starts an embedded LDAP server for each application
context. Logically, that means, it starts an embedded LDAP server for
each test class. Practically, this is not always true since Spring
Boot caches and reuses application contexts. However, you should
always expect that there is more than one LDAP server running while
executing your tests. For this reason, you may not declare a port for
your LDAP server. In this way, it will automatically uses a free port.
Otherwise, your tests will fail with “Address already in use”
Thus it might be a better idea not to define spring.ldap.embedded.port at all.
I addressed the same issue. I solved it with an additional TestExecutionListener since you can get the InMemoryDirectoryServer bean.
/**
* #author slemoine
*/
public class LdapExecutionListener implements TestExecutionListener {
#Override
public void afterTestClass(TestContext testContext) {
InMemoryDirectoryServer ldapServer = testContext.getApplicationContext().getBean(InMemoryDirectoryServer.class);
ldapServer.shutDown(true);
}
}
And on each SpringBootTest (or only once in an abstract super class)
#RunWith(SpringRunner.class)
#SpringBootTest
#TestExecutionListeners(listeners = LdapExecutionListener.class,
mergeMode = TestExecutionListeners.MergeMode.MERGE_WITH_DEFAULTS)
public class MyTestClass {
...
}
also do not forget
mergeMode = TestExecutionListeners.MergeMode.MERGE_WITH_DEFAULTS
to avoid disabling the whole #SpringBootTest auto configuration.
Okay, I think I found a solution by adding a #DirtiesContext annotation to my test classes:
#DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS)
If you are using spring embedded ldap, try to comment or remove port value from config file as below :
spring :
ldap:
embedded:
base-dn: dc=example,dc=org
credential:
username: cn=admin,dc=example,dc=org
password: admin
ldif: classpath:test-schema.ldif
# port: 12345
validation:
enabled: false
Try specifying the web environment type and the base configuration class (the one with !SpringBootApplication on it).
#RunWith(SpringRunner.class)
#SpringBootTest(
classes = MyApplication.class,
webEnvironment = RANDOM_PORT
)
public class MyApplicationTests {
#Test
public void contextLoads() {
}
}
Do this for all your test classes.
I solved this problem by adding #DirtiesContext over each test class that requires embedded ldap server. In my case (and as I feel in many others), embedded ldap server was starting up at every #SpringBootTest, since I added all spring.ldap.embedded.* properties to general application-test.properties. Therefore, when I run a bunch of tests, the problem of 'Address already in use' broke all test passing.
Steps I followed:
create an additional test profile (with corresponding named application properties file, e.g. 'application-ldaptest.properties')
move to that file all spring.ldap.embedded.* properties (with fixed port value)
over all #SpringBootTest-s that do require embedded server running up, add #ActiveProfiles("testladp") and #DirtiesContext annotations.
Hope, that helps.
We want to migrate an old application from Glassfish to TomEE. We encounter a problem about JNDI.
When I run the cmd for Glassfish server asadmin list-jndi-entries I get some JNDI entries:
java:global: com.sun.enterprise.naming.impl.TransientContext
UserTransaction: com.sun.enterprise.transaction.TransactionNamingProxy$UserTransactionProxy
com: com.sun.enterprise.naming.impl.TransientContext
OURAPPSERVER-Q2: com.ourcompany.product.OurAppServer
com.sun.enterprise.container.common.spi.util.InjectionManager: com.sun.enterprise.container.common.impl.util.InjectionManagerImpl
ejb: com.sun.enterprise.naming.impl.TransientContext
jdbc: com.sun.enterprise.naming.impl.TransientContext
AppServer: com.sun.enterprise.naming.impl.TransientContext
As you can see, there is AppServer JNDI entry. This entry is bind from our code manually.
try {
InitialContext context = new InitialContext();
context.rebind("AppServer/facede", this);
} catch (NamingException e) {
e.printStackTrace();
logger.severe("Unable to register the service facade bean, "
+ "JPOS will not be able to access services");
}
This code is not working in TomEE. I get some error like:
javax.naming.NameNotFoundException: Name [AppServer/facede] is not bound in this Context. Unable to find [AppServer].
at org.apache.naming.NamingContext.bind(NamingContext.java:899)
at org.apache.naming.NamingContext.rebind(NamingContext.java:225)
It seems like the container can't found context base on AppServer.
I am not a master of JNDI. Then I have checked some documents. The java:comp/env/ is the basic namespace. And "jdbc" for DBCTM DataSource references, "jms" for JMS connection factories, "mail" for JavaMail connection factories, "url" for URL connection factories.
We don't want to change too much on our old application code. It's not use any special features of Glassfish. I want to know how to define a JNDI in a correct way.
Is there anyone could tell me why Glassfish can use AppServer as namespace, but TomEE can't.
Tomcat (then TomEE) is not designed to change JNDI at runtime like it. Saying it simply the best is to not use this pattern but a contextual resource. Inject the resource you desire and that's this resource you change instead of JNDI (which is quite more impacting that it seems)
This is my first question in Stack Overflow so I expect it will not be too much simple. I've been looking around Internet for a good solution but by now I don't have it.
I am a very begginer to EJB, JNDI and Java EE world in general, but on the last months I've been able to do some acceptable things in this environment. Now I am focusing a problem at work and by now the solution is not as good as I would like.
The scenario is this: I have a EAR application running in Glassfih 3.1.2. I have declared EJBs within this EAR app with stateless beans offering methods through a remote Interface.
This is my Remote Bean running in a server called server1, for example
package com.booreg;
import javax.ejb.LocalBean;
import javax.ejb.Stateless;
import com.booreg.IMyRemoteBean;
#Stateless
#LocalBean
public class MyRemoteBean implements IMyRemoteBean
{
#Override
public String helloWorld()
{
return "Hi what's up boy";
}
}
This is the interface for it
package com.booreg;
import javax.ejb.Remote;
#Remote
public interface IMyRemoteBean
{
public String helloWorld();
}
Then I have a second EAR app that must run imperatively on another server, called server2. The second APP is using JSF and Managed Beans. We have a Managed Bean acting as a remote client of MyRemoteBeanRemote, as this:
package com.nucleus;
import javax.ejb.EJB;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
import com.booreg.IMyRemoteBean;
#ManagedBean
#ViewScoped
public class MyManagedBean
{
#EJB( name="TheRef") IMyRemoteBean myRemoteBean;
public String getPhrase() { return myRemoteBean.helloWorld(); }
}
I've arrived to the point that this works declaring an ejb-ref inside WEB-INF/sun-web.xml file in my web project.
<ejb-ref>
<ejb-ref-name>TheRef</ejb-ref-name>
<jndi-name>corbaname:iiop:server1:3700#java:global/booreg/booreg.ejb/MyRemoteBean!com.booreg.IMyRemoteBean</jndi-name>
</ejb-ref>
I understand that with this sun-web.xml file the jndi-name makes the second app to know where to locate the ejb implementation located at first app. But here I have some questions:
It's necessary to declare one ejb-ref entry for each EJB interface I have in my project ?
How can I avoid making a static reference to server/port (server1:3700 during development) inside sun-web.xml ? When this will go into production I will have to change manually the sever name for each ?? This sounds bizarre. Can I use some kind of variable at server side to specify server/port ?
I expect I have explained myself well enough.
Many thanks
Update: finally, thanks to this link I see that is possible to make references to the ejb server (server1) creating a jndi.properties file inside my classpath. This file should contain lines like this.
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=com.sun.enterprise.naming
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
org.omg.CORBA.ORBInitialHost=server1
org.omg.CORBA.ORBInitialPort=3700
But I am still facing problems. When deploying the application appear the next exception at server1 an I can't deploy the application.
ADVERTENCIA: IOP00100006: Class com.sun.jersey.server.impl.cdi.CDIExtension is not Serializable
org.omg.CORBA.BAD_PARAM: ADVERTENCIA: IOP00100006: Class com.sun.jersey.server.impl.cdi.CDIExtension is not Serializable vmcid: SUN minor code: 6 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy117.notSerializable(Unknown Source)
at com.sun.corba.ee.impl.orbutil.ORBUtility.throwNotSerializableForCorba(ORBUtility.java:783)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_abstract_interface(CDROutputStream_1_0.java:697)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_abstract_interface(CDROutputObject.java:545)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAbstractObject(Util.java:493)
...
Anybody has any idea ?
#dgisbert
In the last comment you mentioned , that one server is a public and other one is Internal Server of your enterprise. Well calling the Application layer from a public server is not a best practise. It means you are directly giving access to your critical business layer. I would suggest rather to have a Web Service Layer on top of your EJB calls so every call from Public site has to come through WebServer -> App Server. This way you can higly reduce the risk of attacks
I made a small example using weblogic 10.3.6 and EJB 3.0. Define SimpleService class, define weblogic-ejb-jar.xml in order to map SimpleService class to JNDI name, pack it as EJB component in EAR file and deploy on server. Deployment is successful and I can see ejb bean with name SimpleServiceBean. After that using standalone application connect to webloigc server through InitialContext with all necessary environment attributes I try to lookup that bean. I assume that it will be available under name ejb/SimpleService but can't found it under that name and only after I was looking through a JNDI tree name I found out that it available under name SimpleService#ds/base/ejb/SimpleService. Help me to understand what is going on? How should I configure ejb bean in order that it will be available under ejb/SimpleService as it described in the official weblogic manual? Or maybe it's a correct JNDI name for the EJB bean?
My classes and configs are:
ds.base.ejb.SimpleServiceBean:
#Stateless(mappedName = "ServiceBean")
#TransactionAttribute(NEVER)
#ExcludeDefaultInterceptors
#Remote(SimpleService.class)
public class SimpleServiceBean implements SimpleService {
...
}
weblogic-ejb-jar.xml
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>ServiceBean</ejb-name>
<jndi-name>ejb/ServiceBean</jndi-name>
<enable-call-by-reference>True</enable-call-by-reference>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
application.xml:
<application>
<display-name>web-app-ear</display-name>
<module>
<ejb>app-ejb-1.0-SNAPSHOT.jar</ejb>
</module>
</application>
Then try to get it from standalone:
InitialContext context = new InitialContext(env);
SimpleService simpleService = (SimpleService)
context.lookup("SimpleService#ds/base/ejb/SimpleService");
assert simpleService != null
there is a good FaQ about the global portal JNDI names on glassfish.org http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#SessionBeanGlobalJNDINameAssignment
It is best practise NOT to assign a jndi name but rely on the ones defined since EE 5 (e.g. SimpleService#ds/base/ejb/SimpleService)
If you add the jndi-name configuration to your weblogic-ejb-jar.xml you could actually make it available as ejb/ServiceBean but you also have to define it "old school" style in ejb-jar.xml. More on the weblogic-ejb-jar.xml can be found http://docs.oracle.com/cd/E23943_01/web.1111/e13719/ejb_jar_ref.htm
There is also a good overview about the dd in the orcl docs.
http://docs.oracle.com/cd/E23943_01/web.1111/e13719/understanding.htm#EJBPG129
Assuming, that you are working with 10.3.x server version ...
Use this.
#Stateless(mappedName="UserFacade")
public class UserFacadeImpl {
//......
}
Properties p=new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
p.put(Context.PROVIDER_URL,"t3://localhost:7001");
InitialContext ctx=new InitialContext(p);
userFacade=(UserFacade)ctx.lookup("UserFacade#com.webservices.facade.UserFacade");
hope it helps.
I have a Glassfish v2.1.1 cluster setup. I deployed an EAR file consisting a single stateless bean to stand alone server. It has an IIOP port 3752.
My client application which will be communicating with this bean is deployed on cluster. When i lookup bean's name, i get NameNotFoundException. Code looks as below:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");
props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
if (logger.isDebugEnabled()) {
logger.debug("Looking for bean from location : " + PropertiesService.instance().getSchedulerOrbHost() + ":"
+ PropertiesService.instance().getSchedulerOrbPort());
}
props.setProperty("org.omg.CORBA.ORBInitialHost", PropertiesService.instance().getSchedulerOrbHost());
props.setProperty("org.omg.CORBA.ORBInitialPort", PropertiesService.instance().getSchedulerOrbPort());
InitialContext context = null;
try {
context = new InitialContext(props);
} catch (NamingException e) {
e.printStackTrace();
}
String beanName = "test.OperationControllerRemote";
OperationControllerRemote remote = (OperationControllerRemote) context.lookup(beanName);
Note that i checked JNDI tree and name "test.OperationControllerRemote" is there.
Any opinions please?
Here are the ways I have got it to work with a GF 2.1.1 cluster and a Swing client. I'm currently going with the Standalone option because of client launch speed, but the ACC might work for you.
Standalone
The way you're doing it is considered standalone.
http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB
http://blogs.oracle.com/dadelhardt/entry/standalone_iiop_clients_with_glassfish
ACC
Another way to approach this is to launch the client with the ACC. This means packaging the client code into the ear as an Application Client and either launching using the JNLP method or manually installing a bundled ACC (mini glassfish really) on client machines. In GF 2.1, either way works ok, but both are pretty fat and JNLP method can make startup times a bit longer. Supposedly in GF 3.1 they've reworked the ACC and it starts up faster. Something that may not be obvious is that with the ACC you get the list of servers in the cluster provided automatically at client startup.
http://blogs.oracle.com/theaquarium/entry/java_ee_clients_with_or
http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beakv.html#scrolltoc
http://download.oracle.com/docs/cd/E18930_01/html/821-2418/gkusn.html
Lookups
Either of the above ways provides RMI/CORBA failover and load balancing for the client.
Either way, when you have the right dependencies on your classpath and the com.sun.appserv.iiop.endpoints system property set (like node1:33700,node2:33701), you'll only need the no-args InitialContext because Glassfish's stuff autoregisters their connection properties, etc as described in the first link:
new InitialContext()
And lookups will work. For my remote session beans (EJB 3.0) I typically do it like:
#Stateless(mappedName="FooBean")
public class FooBean implements FooBeanRemote {}
#Remote
public interface FooBeanRemote {}
then in client code:
FooBeanRemote foo = (FooBeanRemote) ctx.lookup("FooBean");