'Address already in use' when running tests using Spring LDAP embedded server - testing

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.

Related

Error creating bean named `conversionServicePostProcessor` when using spring-boot-admin-server

I was trying to enable Spring boot admin server for my application. The default settings work perfectly fine but when I attempt to enable security, I am getting following error:
APPLICATION FAILED TO START
Description:
The bean 'conversionServicePostProcessor', defined in class path
resource
[org/springframework/security/config/annotation/web/configuration/WebSecurityConfiguration.class],
could not be registered. A bean with that name has already been
defined in class path resource
[org/springframework/security/config/annotation/web/reactive/WebFluxSecurityConfiguration.class]
and overriding is disabled.
Action:
Consider renaming one of the beans or enabling overriding by setting
spring.main.allow-bean-definition-overriding=true
Process finished with exit code 1
I am using the latest SNAPSHOT version of spring-boot-admin-starter-server (2.2.0-SNAPSHOT). Here is my security configuration:
#EnableAdminServer
#EnableWebFluxSecurity
#Configuration(proxyBeanMethods = false)
class AdminServerSecurityConfigurations(val adminServerProperties: AdminServerProperties) {
#Bean
fun adminServerSecurityWebFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain = http
// #formatter:off
.authorizeExchange()
.pathMatchers("${adminServerProperties.contextPath}/assets/**").permitAll()
.pathMatchers("${adminServerProperties.contextPath}/login").permitAll()
.anyExchange().authenticated().and()
.formLogin().loginPage("${adminServerProperties.contextPath}/login").and()
.logout().logoutUrl("${adminServerProperties.contextPath}/logout").and()
.httpBasic().and()
// #formatter:on
.csrf().disable()
.build()
#Bean
fun notifyLogger(instanceRepository: InstanceRepository) = LoggingNotifier(instanceRepository)
}
I found a pull request to update the documentation: https://github.com/spring-projects/spring-boot/issues/14069
For Reactive WebSockets,
{spring-reference}web-reactive.html#webflux-websocket[Spring WebFlux] offers rich support,
which is accessible through the spring-boot-starter-webflux module.
See the spring-boot-sample-websocket-reactive sample project to see how WebSockets may
be implemented using Spring WebFlux.
it turns out that using webflux and websocket leads to conflicts.
also in this pull request was denied in the resolution of the conflict
https://github.com/spring-projects/spring-boot/issues/14810
for reactive websocket see this sample https://www.baeldung.com/spring-5-reactive-websockets
I had the same issue and was able solve it by adding
spring.main.allow-bean-definition-overriding=true
to my application.properties.
Sounds like a workaround and it was also only necessary if I deployed it as WAR -- as a standalone application the exception never occured.
I also faced this error, after Reimport All Mavne Projects(Intellij IDE) it works fine for me. Here my detailed input on this issue here

"Authentication not supported": jgit error when trying to clone tfs hosted git repo

When I try to clone a tfs hosted git repo http://tfstta.com:8080/tfs/DefaultCollection/_git/SampleTFSGit from my linux machine, I face the Authentication not supported error:
org.eclipse.jgit.api.errors.TransportException: http://:#tfstta.int.thomson.com:8080/tfs/DefaultCollection/_git/SampleTFSGit.git: authentication not supported*
Enabling basic authentication/alternate credentials does not seem to be an option.
Could someone please tell me a work around for this? I would be very grateful!
Goto Eclipse Menu
Window -> Preferences -> Team -> Git -> right side panel update time to 3000. `Connection timeout (seconds): 3000. Click on Apply and Close button. Clone again it will solve your problem.
This issue happens because JGit doesn't fully support NTLM, and instead of falling back to Basic auth or something else, it will stop right there.
Usually TFS answers failed authentication with multiple WWW-Authenticate headers. What happens here is that there is a bug in JGit's org.eclipse.jgit.transport.http.apache.HttpClientConnection, that will take into consideration only the last of the WWW-Authenticate headers, making it give up before even trying other connection types.
What I suggest is use your own implementation of org.eclipse.jgit.transport.http.HttpConnection, implementing like this:
#Override
public Map<String, List<String>> getHeaderFields() {
Map<String, List<String>> ret = new HashMap<>();
for (Header hdr : resp.getAllHeaders()) {
List<String> list;
if(ret.containsKey(hdr.getName())) list = ret.get(hdr.getName());
else { list = new LinkedList<>(); ret.put(hdr.getName(), list); }
for (HeaderElement hdrElem : hdr.getElements())
list.add(hdrElem.toString());
}
return ret;
}
Or if you are lazy (like me), you can just switch to org.eclipse.jgit.transport.http.JDKHttpConnection and be happy because it uses native Java connection underneath, that works correctly.
If you are trying to use Spring Cloud Config Server with a TFS Git Repository, my choice is just to implement your own ConfigurableHttpConnectionFactory
/**
* This will use native Java connections, instead of crappy ecplise implementation.
* There will be no management of implementation though. I cannot assure
*/
public class SpringJDKConnectionFactory extends JDKHttpConnectionFactory implements ConfigurableHttpConnectionFactory {
#Override
public void addConfiguration(MultipleJGitEnvironmentProperties environmentProperties) {
}
}
And have a configuration loading over the Spring's default:
#Configuration
public class JGitConnectionFactoryConfiguration {
#Bean
#Primary
public ConfigurableHttpConnectionFactory configurableHttpConnectionFactory() {
return new SpringJDKConnectionFactory();
}
}
But beware, TFS will probably not like Basic auth with direct passwords. So create a "Personal Access Token" in TFS, and use that as a password instead.
Simple sample code:
public static void main(String[] args) throws GitAPIException, IOException {
CloneCommand cmd;
String url = "http://tfs-url.com/Git-Repo";
File file = new File("build/git_test");
if(file.exists())
FileUtils.delete(file,FileUtils.RECURSIVE);
cmd = new CloneCommand();
cmd.setDirectory(file);
cmd.setURI(url);
//#use Personal access tokens as basic auth only accepts these
cmd.setCredentialsProvider(new UsernamePasswordCredentialsProvider("UserAccount","personalaccesstoken"));
ConfigurableHttpConnectionFactory cf = new SpringJDKConnectionFactory();
HttpTransport.setConnectionFactory(cf);
Git git = cmd.call();
}
You might want to try https://www.visualstudio.com/en-us/products/team-explorer-everywhere-vs.aspx since it is Microsoft's cross-platform TFS command-line. The code is posted on GitHub if you want to try and patch the authentication helpers back to jGit.
I would recommend you to upgrade your TFS server to the latest Update 3 and then use SSH Authentication for Git Repository.
SSH Support for Git Repos
With TFS 2015 Update 3, you can now connect to any Team Foundation
Server Git repo using an SSH key. This is very helpful if you develop
on Linux or Mac. Just upload your personal SSH key and you're ready to
go.
I have faced this issue with a new pc (configured by someone else). Fixed error with reinstalling JDK and running eclipse with it.
I used a bad approach but for initial work, it's fine for me.
In my case, I switched Project visibility on gitlab from private to public. Go to Gitab -> <your project> -> Settings -> General -> Visibility, project features, permissions -> switch to Public
In application.properties I added only spring.cloud.config.server.git.uri without authentication properties and also at the end of the gitlab uri added .git
http://gitlab.com/<your-repo-name>.git
I don't recommend this approach for people who work tasks for the company.
When you use command below, you'll be prompted to enter the username and password.
git-clone http://:#tfstta.int.thomson.com:8080/tfs/DefaultCollection/_git/SampleTFSGit
In my test, when send the command, you'll be prompted a Windows Security. It's not needed to use basic authentication/alternate credentials, simply type domaine\username and the password will connect to TFS.

Easy way to access to a remote ejb located in another server

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

EJB lookup problem

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");

giving an EJB a JNDI

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