Issue tracking

Ubuntu-12.04.1-server-amd64

The following error occurs during regression test with REST enabled:

This exception occurs on Ubuntu 12.04 64 bit server and symas-openldap-silver.64_2.4.34-1_amd64.deb.

[FC-2] Error adding inheritance Created: 21/Apr/13 Updated: 30/Apr/13 Due: 28/Apr/13 Resolved: 30/Apr/13

When adding inheritance relationships between roles, get this error. It appears to happen when a role is assigned to a user beforehand:

java
java Enter child role name:
csr
java Enter parent role name:
employee
java 2013-04-21 17:28:59,889 (INFO ) us.jts.fortress.rbac.RoleUtil.loadGraph initializing ROLE context Client123
java ConnectionPool (Sun Apr 21 17:28:59 CDT 2013) : adding a connection to pool...
java 2013-04-21 17:28:59,980 (ERROR) us.jts.fortress.AdminMgrConsole.addRoleInheritance caught SecurityException rc=5003, msg=us.jts.fortress.rbac.RoleDAO.update name CSR caught LDAPException=20 msg=modify/add: roleOccupant: value #0 already exists
java us.jts.fortress.UpdateException: us.jts.fortress.rbac.RoleDAO.update name CSR caught LDAPException=20 msg=modify/add: roleOccupant: value #0 already exists
java at us.jts.fortress.rbac.RoleDAO.update(RoleDAO.java:193)
java at us.jts.fortress.rbac.RoleP.update(RoleP.java:132)
java at us.jts.fortress.rbac.AdminMgrImpl.addInheritance(AdminMgrImpl.java:1002)
java at us.jts.fortress.AdminMgrConsole.addRoleInheritance(AdminMgrConsole.java:160)
java at us.jts.fortress.ProcessMenuCommand.processAdminFunction(ProcessMenuCommand.java:418)
java at us.jts.fortress.ProcessMenuCommand.processRbacControl(ProcessMenuCommand.java:73)
java at us.jts.fortress.FortressConsole.main(FortressConsole.java:28)
java at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
java at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
java at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java at java.lang.reflect.Method.invoke(Method.java:601)
java at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
java at java.lang.Thread.run(Thread.java:722)
java Caused by: LDAPException(resultCode=20 (attribute or value exists), errorMessage='modify/add: roleOccupant: value #0 already exists')
java at com.unboundid.ldap.sdk.migrate.ldapjdk.LDAPConnection.modify(LDAPConnection.java:1137)
java at com.unboundid.ldap.sdk.migrate.ldapjdk.LDAPConnection.modify(LDAPConnection.java:1154)
java at us.jts.fortress.ldap.DataProvider.modify(DataProvider.java:204)
java at us.jts.fortress.rbac.RoleDAO.update(RoleDAO.java:187)
java ... 12 more

[FC-3] Enhance Role Assignment Func Created: 30/Apr/13 Updated: 30/Apr/13 Due: 10/May/13

Linux Dev

Measure/repair role assignment funcs to optimize for role occupants.

Measure/repair role assignment funcs to optimize for role occupants.

Support apacheds

test case fails:

deleteRoles("DEL-RLS ROLES_TR5_HIER", RoleTestData.ROLES_TR5_HIER);

role oamT5ROLE2 has oamT5Role1 as child and fails on delete. The previous test run removed oamT5Role1 so this error condition should not happen.

Need to figure out why this happens on ApacheDS and not OpenLDAP.

The updateRole function may modify parent attribute on role entity. This has the opportunity to circumvent role SSD policy constraint. Perform SSD constraint checks if addition role parent is added.

During test-full target (with teardown) on apacheds receive this error:

junit Testcase: testCreateSession took 0.019 sec
junit FAILED
junit us.jts.fortress.rbac.UserDAO.checkPassword userId jtsUser2 caught LDAPException=53 msg=ERR_732 Cannot process a Request while binding
junit junit.framework.AssertionFailedError: us.jts.fortress.rbac.UserDAO.checkPassword userId jtsUser2 caught LDAPException=53 msg=ERR_732 Cannot process a Request while binding
junit at us.jts.fortress.rbac.AccessMgrImplTest.createSessions(AccessMgrImplTest.java:331)
junit at us.jts.fortress.rbac.AccessMgrImplTest.testCreateSession(AccessMgrImplTest.java:281)
junit

ALL inbound data must be encoded safe text before persisted.

The UserDAO createUser and updateUpdate user methods throw npe when user entity contains a null value in password field.

Change quickstart package's 'builder' target to pull fortress source from maven. Do not include source in quickstart archive.

fix this method to detect when any of the constraint attributes changes. Currently it will only trigger if all of the attributes are not null.

public boolean isTemporalSet()

Add OPENLDAP_POLICY_SUBENTRY to the result set for user search

Add inetorgperson attributes bldg, dept and room to user

final User create(User entity)
{
add flag here:
if (VUtil.isNotNullOrEmpty(entity.getPwPolicy()))

During deletion to fortress permission object:
ftObjNm=TOB4_8,ou=Permissions,ou=RBAC,dc=jts,dc=us

PermDAO.delete

This error in debug level slapd.logs, excerpt below, full log attached:

51a66b8d => index_entry_del( 911, "ftObjNm=TOB4_8,ou=Permissions,ou=RBAC,dc=jts,dc=us" )

51a66b8d mdb_idl_delete_keys: 38f 00000000
51a66b8d mdb_idl_delete_keys: 38f 0096defd
51a66b8d mdb_idl_delete_keys: 38f 3d1dea68
51a66b8d mdb_idl_delete_keys: 38f 76324484
51a66b8d mdb_idl_delete_keys: 38f 29c95ac5
51a66b8d mdb_idl_delete_keys: 38f 0e1b3d46
51a66b8d mdb_idl_delete_keys: 38f 1ccd25c5
51a66b8d <= index_entry_del( 911, "ftObjNm=TOB4_8,ou=Permissions,ou=RBAC,dc=jts,dc=us" ) success
51a66b8d <=- mdb_delete: id2entry failed: MDB_PAGE_FULL: Internal error - page has no more space (-30786)
51a66b8d send_ldap_result: conn=1000 op=3820 p=3
51a66b8d send_ldap_result: err=80 matched="" text="entry delete failed"
51a66b8d slap_queue_csn: queing 0x3bb8e308 20130529205645.303808Z#000000#000#000000
51a66b8d ==> mdb_add: reqStart=20130529205645.000000Z,cn=log
51a66b8d oc_check_required entry (reqStart=20130529205645.000000Z,cn=log), objectClass "auditDelete"
51a66b8d oc_check_allowed type "objectClass"
51a66b8d oc_check_allowed type "structuralObjectClass"
51a66b8d oc_check_allowed type "reqStart"
51a66b8d oc_check_allowed type "reqEnd"
51a66b8d oc_check_allowed type "reqType"
51a66b8d oc_check_allowed type "reqSession"
51a66b8d oc_check_allowed type "reqAuthzID"
51a66b8d oc_check_allowed type "reqDN"
51a66b8d oc_check_allowed type "reqMessage"
51a66b8d oc_check_allowed type "reqResult"
51a66b8d oc_check_allowed type "reqEntryUUID"
51a66b8d mdb_dn2entry("reqStart=20130529205645Z,cn=log")
51a66b8d => mdb_dn2id("reqStart=20130529205645Z,cn=log")
51a66b8d <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798)
51a66b8d => mdb_entry_decode:
51a66b8d <= mdb_entry_decode
51a66b8d => access_allowed: add access to "cn=log" "children" requested
51a66b8d <= root access granted
51a66b8d => access_allowed: add access granted by manage(=mwrscxd)
51a66b8d => access_allowed: add access to "reqStart=20130529205645.000000Z,cn=log" "entry" requested
51a66b8d <= root access granted
51a66b8d => access_allowed: add access granted by manage(=mwrscxd)
51a66b8d => mdb_dn2id_add 0x4eba: "reqStart=20130529205645Z,cn=log"
51a66b8d <= mdb_dn2id_add 0x4eba: 0
51a66b8d => index_entry_add( 20154, "reqStart=20130529205645.000000Z,cn=log" )
51a66b8d mdb_idl_insert_keys: 4eba b5c866dc
51a66b8d mdb_idl_insert_keys: 4eba
51a66b8d mdb_idl_insert_keys: 4eba 86ee7ec7
51a66b8d mdb_idl_insert_keys: 4eba 7990d2ba
51a66b8d <= index_entry_add( 20154, "reqStart=20130529205645.000000Z,cn=log" ) success
51a66b8d => mdb_entry_encode(0x00004eba): reqStart=20130529205645.000000Z,cn=log
51a66b8d <= mdb_entry_encode(0x00004eba): reqStart=20130529205645.000000Z,cn=log
51a66b8d mdb_add: added id=00004eba dn="reqStart=20130529205645.000000Z,cn=log"
51a66b8d send_ldap_result: conn=1000 op=3820 p=3
51a66b8d send_ldap_result: err=0 matched="" text=""
51a66b8d slap_graduate_commit_csn: removing 0x89e6d50 20130529205645.303808Z#000000#000#000000
51a66b8d send_ldap_response: msgid=3821 tag=107 err=80
ber_flush2: 34 bytes to sd 14
0000: 30 20 02 02 0e ed 6b 1a 0a 01 50 04 00 04 13 65 0 ....k...P....e
0010: 6e 74 72 79 20 64 65 6c 65 74 65 20 66 61 69 6c ntry delete fail
0020: 65 64 ed
ldap_write: want=34, written=34
0000: 30 20 02 02 0e ed 6b 1a 0a 01 50 04 00 04 13 65 0 ....k...P....e
0010: 6e 74 72 79 20 64 65 6c 65 74 65 20 66 61 69 6c ntry delete fail
0020: 65 64 ed
51a66b8d conn=1000 op=3820 RESULT tag=107 err=80 text=entry delete failed
51a66b8d slap_graduate_commit_csn: removing 0x8a07120 20130529205645.303808Z#000000#000#000000
51a66c46 daemon: epoll: listen=7 active_threads=0 tvp=zero

junit 2013-05-29 17:51:18,449 (INFO ) DEL-RLS-TR6-DESC
junit 2013-05-29 17:51:18,480 (ERROR) us.jts.fortress.rbac.AdminMgrImplTest.delRoleDescendant caught SecurityException rc=5004, msg=us.jts.fortress.rbac.RoleDAO.remove role name=oamT6C4B2A1 LDAPException=32 msg=no such object
junit us.jts.fortress.RemoveException: us.jts.fortress.rbac.RoleDAO.remove role name=oamT6C4B2A1 LDAPException=32 msg=no such object
junit at us.jts.fortress.rbac.RoleDAO.remove(RoleDAO.java:316)
junit at us.jts.fortress.rbac.RoleP.delete(RoleP.java:246)
junit at us.jts.fortress.rbac.AdminMgrImpl.deleteRole(AdminMgrImpl.java:434)
junit at us.jts.fortress.rbac.AdminMgrImplTest.delRoleDescendant(AdminMgrImplTest.java:670)
junit at us.jts.fortress.rbac.AdminMgrImplTest.testDelRoleDescendant(AdminMgrImplTest.java:603)
junit at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
junit at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
junit at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
junit at java.lang.reflect.Method.invoke(Method.java:601)
junit at junit.framework.TestCase.runTest(TestCase.java:168)
junit at junit.framework.TestCase.runBare(TestCase.java:134)
junit at junit.framework.TestResult$1.protect(TestResult.java:110)
junit at junit.framework.TestResult.runProtected(TestResult.java:128)
junit at junit.framework.TestResult.run(TestResult.java:113)
junit at junit.framework.TestCase.run(TestCase.java:124)
junit at junit.framework.TestSuite.runTest(TestSuite.java:243)
junit at junit.framework.TestSuite.run(TestSuite.java:238)
junit at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
junit at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
junit at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906)
junit Caused by: LDAPException(resultCode=32 (no such object), errorMessage='no such object', matchedDN='ou=Roles,ou=RBAC,dc=jts,dc=us')
junit at com.unboundid.ldap.sdk.migrate.ldapjdk.LDAPConnection.modify(LDAPConnection.java:1137)
junit at com.unboundid.ldap.sdk.migrate.ldapjdk.LDAPConnection.modify(LDAPConnection.java:1154)
junit at us.jts.fortress.ldap.DataProvider.modify(DataProvider.java:188)
junit at us.jts.fortress.ldap.DataProvider.delete(DataProvider.java:235)
junit at us.jts.fortress.rbac.RoleDAO.remove(RoleDAO.java:311)
junit ... 19 more
junit 2013-05-29 17:51:18,483 (INFO ) DEL-RLS-TR6-ASC
junit 2013-05-29 17:51:18,487 (ERROR) us.jts.fortress.rbac.AdminMgrImplTest.delRoleAscendant caught SecurityException rc=5060, msg=us.jts.fortress.rbac.HierUtil.validateRelationship child oamT7D2C1B1A1 does not have parent oamT7C2B1A1
junit us.jts.fortress.ValidationException: us.jts.fortress.rbac.HierUtil.validateRelationship child oamT7D2C1B1A1 does not have parent oamT7C2B1A1
junit at us.jts.fortress.rbac.HierUtil.validateRelationship(HierUtil.java:127)
junit at us.jts.fortress.rbac.RoleUtil.validateRelationship(RoleUtil.java:245)
junit at us.jts.fortress.rbac.AdminMgrImpl.deleteInheritance(AdminMgrImpl.java:1046)
junit at us.jts.fortress.rbac.AdminMgrImplTest.delRoleAscendant(AdminMgrImplTest.java:764)
junit at us.jts.fortress.rbac.AdminMgrImplTest.testDelRoleAscendant(AdminMgrImplTest.java:741)
junit at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
junit at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
junit at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
junit at java.lang.reflect.Method.invoke(Method.java:601)
junit at junit.framework.TestCase.runTest(TestCase.java:168)
junit at junit.framework.TestCase.runBare(TestCase.java:134)
junit at junit.framework.TestResult$1.protect(TestResult.java:110)
junit at junit.framework.TestResult.runProtected(TestResult.java:128)
junit at junit.framework.TestResult.run(TestResult.java:113)
junit at junit.framework.TestCase.run(TestCase.java:124)
junit at junit.framework.TestSuite.runTest(TestSuite.java:243)
junit at junit.framework.TestSuite.run(TestSuite.java:238)
junit at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
junit at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
junit at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906)
junit 2013-05-29 17:51:18,487 (INFO ) DEL-RLS TR1
junit 2013-05-29 17:51:18,502 (INFO ) DEL-RLS TR2
junit 2013-05-29 17:51:18,516 (INFO ) DEL-RLS TR3
junit 2013-05-29 17:51:18,771 (INFO ) DEL-RLS TR4
junit 2013-05-29 17:51:18,799 (INFO ) DEL-RLS ROLES_TR5_HIER
junit 2013-05-29 17:51:18,818 (INFO ) DEL-RLS ROLES_TR5B
junit 2013-05-29 17:51:18,852 (INFO ) DEL-RLS ROLES_TR8_SSD
junit 2013-05-29 17:51:18,919 (INFO ) DEL-RLS ROLES_TR9_SSD
^Csmckinn@smckinnlt-lr02:~/GIT/fortressDev/openldap-fortress-core$ sudo ./build.sh init-slapd
Buildfile: /home/smckinn/GIT/fortressDev/openldap-fortress-core/build.xml

09:15:48 AM emmanuel lecharny: I may have a few q regarding the update methods
09:16:08 AM emmanuel lecharny: it seems that you remove an Attribute before adding some new values
09:18:43 AM emmanuel lecharny: something like :
09:18:44 AM emmanuel lecharny: LDAPModification(type=replace, attr=ftRoles, values={}),
LDAPModification(type=add, attr=ftRoles, values=

)] should be enough

09:46:27 AM smckinney: yes agreed. wondering why I did not do that to begin with...
09:47:28 AM smckinney: will create an issue to take another look at it.

It would be very comfy to have toString() methods added to the base classes, especially for debugging and logging purpose.

Add name to ehcache as Emmanuel specifies via the fortress list server:

yesterday, I spent a couple of hours trying to understand why I get a
failure in the tests. I finally found the pb : the EhCache CacheManager
is initialized using a factory, and the configuration file does not have
a name, which leads the cache to be a singleton. If you are embedding
fortress into another application using EhCache, or if Fortress embed an
application using EhCache, it's very likely that you face some issue if
this cache is also a singleton.

Bottom line, I added a name="fortress" in the ehcache.xml file, and this
solved my pb :

<?xml version="1.0" encoding="UTF-8"?>

<!--
Fortress CacheManager Configuration
==========================
This ehcache.xml corresponds to a single CacheManager.
-->
<ehcache name="fortress"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

Another from Emmanuel:

>
> On 05/25/2013 04:24 PM, Emmanuel Lecharny wrote:
>> 2) It would be better to get the connection immediately before using it,
>> and to release it as soon as you are done with it. For instance, the
>> connection could be get just before calling the dataProvider and
>> released just after. Not really a huge improvment, but assuming that
>> you may have thousands of requests per second, this may become an
>> issue.
>>
>
> The current pattern followed in the Fortress DAO's is as follows:
>
> // inside any DAO method:
> try
>

> catch (LDAPException e)
>

> finally
>

>
> This change you are suggesting is to delay opening the connection
> until the beginning of step 3?
Yes. Basically :

try
{
1. build up the ldap attribute set or search filter
2. getAdminConnection();
3. perform the ldap operation

Now, it's questionable if the connection should be grab in (2) instead
in the method that performs the operation. The only rationnal I see is
for a non-admin connection to be used, but this is not the case in teh
DAO, AFAICS.

There are some cases where we would like to clear all or one single cache. For instance, when running atomic tests, teh cache should be cleared before the test, or after the test.

Currently, this is not possible.

The CUtil.setConstraint utility is not correctly processing the multi attribute string input. Modify string parsing to allow for empty subattributes within constraint data struct.

the pw policy subentry is stored in ldap as a DN. This creates problems with the client on inquiries. Strip the rDn from the dn and set that value in pwpolicy attribute on user entity during retrieval.

Fortress role assignments effect both user and role entities. The UserDAO only changes user entity and does not update role. This leaves role assignment in inconsistent state. Remove capability to assign roles from add/update user and only allow in assignuser.

cleanup test data

rename constant for user system policy violation.

Commander need ability to search SDSets by name.

add jpeg photo to userdao

needed for commander

add Apache DS regression junit test suite

bump up heap allocation to 1024M

add counter to lower level fortress dao utils to measure the numbers of the various ldap ops - add, mod, delete, search, etc

The idea is to abstract the lib from the logger used by the application that embeds Fortress.

It's convenient when debugging to have the classes to implement toString()

Break fortress modules in rbac package into separate packages.

Break fortress core into multiple jars. One for CLI, Ant, Rest, etc

This task is to determine how to convert the Fortress Config component to not be a singleton.

Convert the build and packaging tasks to use Maven rather than Ant. Use maven for releasing source code from GIT. Automatic publish artifacts using Maven.

Convert the Fortress ldap connections to be over network or to use local mode.

Use Apache LDAP API for fortress. Daotutil should provide abstraction layer to use unbound or apache.

Use annotations for OpenLDAP junit tests. Break the tests into standalone mode. Follow the apacheds model.

fortress to use junit 4.11

release 27

Currently, the various Mgr factories are creating instances for Mgr depending on the type of access we want (basically, direct access or via REST).

We can imagine that we may have more kind of access in the future (remote, SOAP yukkk, ... )

But in any case, I think we can simplify the way we create instances :

accessClassName = AccessMgrImpl.class.getName();
AccessMgr accessMgr =
(AccessMgr)ClassUtil.createInstance(accessClassName);

could be written :

AccessMgr accessMgr = new AccessMgrImpl();

We know everything about the class, and we don't even have to pull a constructor FQCN from the configuration, the only thing is that we will create a new instance depending on some configuration parameter.

(this is of course when the config does not provide the class name to instanciate)

I also have some concern about the fact that we may want to mix REST and other kind of access. Atm, either we have a REST access, or not, but it's global and can't be changed, as the IS_EST flag is static and final. Each context might access the Mgr in different ways (at least, this is my understanding, even if I'm pushing it a bit too far).

Does it sound reasonnable ?

fix this code in UserDAO:

final User update( User entity )

if ( VUtil.isNotNullOrEmpty( entity.getEmployeeType() ) )

Currently, all the fortress configuration is done though a configuration file.

It would be very convenient to be able to configure Fortress without depending on a configuration file.

these methods:
private void loadUserRoles( List<UserRole> list, LDAPModificationSet mods )
private void loadUserAdminRoles( List<UserAdminRole> list, LDAPModificationSet mods )

need this added:

if ( attr != null )

}
}

Do not update roleOccupants attribute in RoleDAO.update method

We are currently testing the API though the existing managers. It would be good to also test the DAO themselves, as we may have different implementations.

We currently have one single implementation for the DAOs, using the UnboundID API. It would be interesting to have a way to instanciate some other implementation (like one using the Apache LDAP API, or a relational database)

flip switch in build.properties to 2.4.35-2

The PermDAO updatePerm incorrectly process administrative roles. For example it validates against the non admin role tree and causes this exception when roles is non-null:

SecurityException=us.jts.fortress.FinderException: getRole Obj COULD NOT FIND ENTRY for dn cn=oamAdmin8,ou=Roles,ou=RBAC,dc=jts,dc=us

The function should throw a checked security exceptoin

DelAccessMgr needs sessionPermissions method

Add load script for delegated policy. Change fortress junit test to work if delegated policy is loaded beforehand.

correctly map user displayName to displayName in fortress

implement this method:

Caused by: java.lang.UnsupportedOperationException
at us.jts.fortress.rest.DelAccessMgrRestImpl.sessionPermissions(DelAccessMgrRestImpl.java:384)

during the role activation step the user role selection is improperly loaded into the session.

add the ability to set user properties in ant:

<user ... userProps="fortressdemo1:ROLE_TEST1"/>

convert load scripts to use global classpath set in the build.xml rather than from local properties in the ant build file.

Minor bug fixes and improvements in configuration of apache ldap api usage.

Add windows support for commander and enmasse demos

The two improvements made:

1. minor bug fixes to enable the apache ldap api to work correctly

2. tweaks to enable win platform support on enmasse & commander demo web applications

add switch to allow xml load utility to be attached by remote debugger

For now make the jpegphoto transient so that enmasse doesn't try to xml serialize.

remove local.mode from the resolve target.

remove 'none', 'all' and any other values from constraints. Use empty value to indicate that constraint is not enforced.

Add the thread id to log4j messages. Add the tenant id to log statements in junit output.

The addActiveRole method is not checking time/date constraints on roles being activated into session.

When user-role constraint data is being converted from raw (as stored in ldap) to entity format it is not handling empty params correctly. Change the way the string is being parsed in order to handle empty values.

Add new ant & bash scripts to kick off multi-tenant batch test/demo.

The connection pool fortress uses ConnectionPool class from Mozilla java ldap sdk. The code performs a bind on connections that are being put back in the pool (ostensibly to clear the previous credentials). This creates unnecessary extra bind during user authentication flow.

Change the ConnectionPool class to not bind before returning to pool

Add jpeg photo to ant load utility.

change error mapping on bind to use

/**

• The User bind operation failed on server.
  */
  public final static int USER_BIND_FAILED = 1037;