I need to use ldap connection pooling in a web application. To authenticate admin, I am using below code:
Properties props = new Properties();
System.setProperty("com.sun.jndi.ldap.connect.pool", "true");
System.setProperty("com.sun.jndi.ldap.connect.pool.maxsize", "1");
System.setProperty("com.sun.jndi.ldap.connect.pool.debug", "fine");
props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
props.put(Context.PROVIDER_URL, "ldap://localhost:10389/o=myldap");
props.put(Context.SECURITY_PRINCIPAL, "uid=admin,ou=system");//adminuser
props.put(Context.SECURITY_CREDENTIALS, "xxxxx");
InitialDirContext context = new InitialDirContext(props);
To lookup and authenticate another user, I need to change the SECURITY_PRINCIPAL and SECURITY_CREDENTIALS and then create a new context again. When I do this is a POJO, it uses connection pool but when I use this in multi user web application (I tried it with two threads), it does not use connection pool.
What workaround can be used for this?
You need to set the parameters as JVM system parameters, using -D parameters on the java invocation.
System.setProperty("com.sun.jndi.ldap.connect.pool", "true");
System.setProperty("com.sun.jndi.ldap.connect.pool.maxsize", "1");
System.setProperty("com.sun.jndi.ldap.connect.pool.debug", "fine");
Wrong properties object. You should be setting those into the 'props' object, not the system properties object.
EDIT And don't debug to true. Setting it has has the curious effect of turning pooling off.
Related
I'm trying to send a mail using javax.mail. This is my code:
Properties props = new Properties();
props.setProperty("mail.smtp.host", host);
props.setProperty("mail.smtp.port", port);
props.setProperty("mail.user", user);
props.setProperty("mail.password", password);
Session session = Session.getDefaultInstance(props);
But I get this error:
javax.mail.MessagingException: Could not connect to SMTP host: smtp.wrong.server.com, port: 25;
The funny thing is that "smtp.wrong.server.com" isn't the value that I'm passing as host.
It is like Session.getDefaultInstance(props) is returning an already created session with the wrong host name.
There isn't any other place inside my EAR where javax.mail is used (at least not in my code, maybe inside a third party dependecy?).
This behaviour only happens, of course, in PRO environment. The same EAR deployed in DEV and TEST env works fine.
Any help would be appreciated
The problem was with Session.getDefaultInstance. I should use Session.getInstance
From javadoc:
getDefaultInstance
(...)the default session is potentially available to all code executing in the same Java virtual machine(...)Subsequent calls return the Session object that was created by the first call, and ignore the passed Properties object. Use the getInstance method to get a new Session object every time the method is called.
It seams your are not using the correct key for your proerties. see Javadoc for javax.mail.Session
It is expected that the client supplies values for the properties
listed in Appendix A of the JavaMail spec (particularly
mail.store.protocol, mail.transport.protocol, mail.host, mail.user,
and mail.from) as the defaults are unlikely to work in all cases.
I'm seeing an issue where when connected to a mailbox using IMAP the infinite timeout default is causing an issue. I am having an issue getting Java Mail to recgonise IMAP properties. I verified IMAP did not seem to be using the properties by setting things like port number to the value 1, which should not work.
This is the code snippit:
Properties props = new Properties()
props.put("mail.imap.port", "1");
props.put("mail.imap.timeout", "1");
props.put("mail.imaps.connectiontimeout", "1");
Session session = Session.getInstance(props, null);
Store store = session.getStore("imaps");
store.connect(***,***,***);
If anyone knows where the problem is arising from that would great, all help is appreciated.
I believe you should be using props.setProperty(key, value) instead of using props.put(key, value). The documentation here: http://docs.oracle.com/javase/tutorial/essential/environment/properties.html warns you not to use hashTable methods
You're using the "imaps" protocol but setting properties for the "imap" protocol. Change your property names to "mail.imaps.*".
I'm looking to have my application connect to the internet through a proxy server (in order to avoid captcha). The code I am currently using is this:
Properties props = System.getProperties();
props.put("http.proxyPort", proxyPort); //proxy port
props.put("http.proxyHost", proxyHost); //proxy host
props.put("http.proxySet", "true");
This code has been unsuccesful, however. Any suggestions?
You can try the following:
SocketAddress sa = new InetSocketAddress(proxy_host_name, proxy_port_address);
Proxy proxy = new Proxy(Proxy.Type.xxx, sa);
URLConnection con = new URL(url).openConnection(proxy);
You are probably using a kind of "User Friendly Website Proxy", like http://newipnow.com or www.proxyultra.com. But you need to use a real SOCKS proxy server.
A free server, that I found, working, in a list of public Proxies:
System.setProperty("http.proxyHost", "187.115.172.82");
System.setProperty("http.proxyPort", "8181");
There is no need to set the http.proxySet property.
Pick a server from the nice list here: Hide My Ass: Proxy List
Put the parameters on the command line or use setProperty.
java -Dhttp.proxyHost=proxy.host -Dhttp.proxyPort=3128 MainClass
In order to get the Weblogic initial context to query the task database i am doing the following:
Properties h = new Properties();
h.put(Context.SECURITY_PRINCIPAL, "weblogic");
h.put(Context.PROVIDER_URL, "t3://localhost:17101");
h.put(Context.SECURITY_CREDENTIALS, "weblogic");
h.put(Context.SECURITY_AUTHENTICATION, "simple");
WLInitialContextFactory test = new WLInitialContextFactory();
test.getInitialContext(h);
Context ctx = null;
ctx = getInitialContext();
WorklistContext wliContext = WorklistContextFactory.getRemoteWorklistContext(ctx, "MyTaskApplication");
I then get the TaskQuery interface with the following code:
WorklistTaskQuery taskQuery = wliContext.getInterfaceForTaskQuery();
and to get the tasks i do:
taskQuery.getTasks(query);
where query is com.bea.wli.worklist.api.TaskQuery object.
Please note that this code is running inside the domain running the tasks.
Unfortunally i am getting the following error when i call the getTasks methods:
java.lang.SecurityException: [WLI-Worklist:493103]Access denied to resource /taskplans
/Manual:1.0. Applicable policy: Query Caller: principals=[] Method: com.bea.wli.worklist.security.WorklistSecurityManager.assertTaskAccessAllowed
It seems Weblogic is ignoring the user set on the new initial context and trying to use the one coming from the browser. It so happens that i might need to do query searchs in background workers that don't have a browser session(obviously).
Can anyone help with this?
I've found a solution for this, though it's convoluted and ugly as hell.
Since i'm making these calls through an EJB i can authenticate the call by grabbing the EJB implementation from an authenticated context like so:
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.SECURITY_PRINCIPAL,"user");
env.put(Context.PROVIDER_URL,"t3://localhost:7001");
env.put(Context.SECURITY_CREDENTIALS,"password");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
getSessionInterface(interfaceClass, new InitialContext(env));
Your best bet for this is to avoid the above example and this API all together. Just use the regular MBean Implementation which allows authentication.
Update this solution doesn't seem to be viable, it will screw up the transaction management. Will report back, but it seems if you need to create tasks outside of an authenticated context you will need to go the MBean way
Okay, so I'm moving my application over from non-SSL to SSL connections to my LDAP server. When running the application in non-SSL, connection pooling is working fine. However when I switch to SSL connection pools no longer work.
While researching here I realized that I never set the "com.sun.jndi.ldap.connect.pool.protocol" property to "plain ssl" since defaultly it is set to plain. I thought this was the problem.
When I implemented the change to include "plain ssl", it did not fix the problem and connection pools were still not being used.
Is there some other setting that I am missing?
Relevant code:
Hashtable LDAPEnvironment = new Hashtable();
LDAPEnvironment.put(Context.SECURITY_AUTHENTICATION, SECURITY_AUTHENTICATION);
LDAPEnvironment.put(Context.SECURITY_PRINCIPAL, SECURITY_PRINCIPAL);
LDAPEnvironment.put(Context.SECURITY_CREDENTIALS, SECURITY_CREDENTIALS);
LDAPEnvironment.put(Context.INITIAL_CONTEXT_FACTORY, INITIAL_CONTEXT_FACTORY);
LDAPEnvironment.put(Context.PROVIDER_URL, PROVIDER_URL );
LDAPEnvironment.put(Context.SECURITY_AUTHENTICATION, "simple");
LDAPEnvironment.put("java.naming.ldap.version", versionOfLDAP );
if (ldapProtocol != null && ldapProtocol.equalsIgnoreCase("SSL")){
LDAPEnvironment.put(Context.SECURITY_PROTOCOL,"ssl");
LDAPEnvironment.put("com.sun.jndi.ldap.connect.pool.protocol","plain ssl");
}
LDAPEnvironment.put("com.sun.jndi.ldap.connect.pool", "true");
I have found the problem. The documentation specifically states that the those properties are system properties and not environment properties. I was setting these as environment properties. :-)
If you scroll down a little, at the link you provided (scroll to "How Connections are Pooled"), you'll see the explanation to how the pooling works.
When you request a pooled connection, you will get one only if ALL the specified properties are identical. And that's a long list of properties...
I your case this is:
connection controls
host name, port number as specified in the "java.naming.provider.url" property, referral, or URL supplied to the initial context
java.naming.security.protocol property
java.naming.ldap.version property
java.naming.security.principal property
java.naming.security.credentials property
If you always use the same constants when request a connection from the connection pool, I think you should get the same pooled connection. That is, if you set the com.sun.jndi.ldap.connect.pool.* properties properly - but I didn't see that in the code you provided.
If you did set the com.sun.jndi.ldap.connect.pool.* properties to sensible values, try setting com.sun.jndi.ldap.connect.pool.debug to fine. This will help you debug.
Another option is to use a framework, or a provider that supports connection pooling. Note that the pooling provided to you by Java is rather limited. I used Spring-Ldap in the past, and it has very good support.
Hope this helps.