Off the record

Let's say you are a programmer.
Let's say you are aware of the traps a big IT project can fall into, and you decide to adopt a test driven approach.
On the next day, you find out that this huge (900 md) part of the code that is done by this other contractor will not be delivered until 2009, and of course you need this part to test your code...Treat yourself and build a mock object that will simulate the behaviour of the missing part of the code !

Wikipedia says you normally need this (these) mock object because this damn contractor code :

• produces non-deterministic results like current time or current temperature
• has states that are difficult to create or reproduce (e.g. a network error);
• is slow (e.g. a complete database, which would have to be initialized before the test); (You don't run a test that is slo 100 times a day...especially if you have 100 tests like this one )
• does not yet exist or may change behavior;
• would have to include information and methods exclusively for testing purposes (and not for its actual task).

A proper conception of your mock object will be the following :
Upon a commonly agreed interface with the ... contractor :

1. he builds his code
2. you call the interface to interact with his object
3. you buil a mockup implementing the interface, who will act in the same way as the other guy's code
4. you deliver !

Ok, but a test class can do the job, why would i want a mockup?
Probably in the cases where you interact with some objects that are complex to mimic (you do not want to build them in messy test cases), when these objects are slow to build, or cost time to calculate (remember a big project usually involves a suite of hundreds of test, and the suite needs to be run fast...), when you need to test states like DB is down, but you do not want to stop the db to run your test

Where is this damn script supposed to create a database and a user with all the rights on it? Well here, it should work with almost all the db you use for dev purposes (Oracle, MySQL, HSQL...) :

create database myDB;
grant all on myDB.* to 'myUser'@'localhost' identified by 'myUser' with grant option;
grant all on myDB.* to 'myUser'@'localhost.localdomain' identified by 'myUser' with grant option;

The object ProfileFactory delivers user profiles based on the user name and the group name, however, the group seems to be optional so far...
From there, you can access all the LDAP properties (permitted by the login/pass provided by Weblogic...) !
For instance, if we want the userTown field, "request" being a HttpServletRequest Object :

ProfileWrapper p = ProfileFactory.getProfile(request.getRemoteUser(), null);
p.getProperty("LDAP_RepositoryName_In_BEA", "userTown");

That's it.
Nota, from version 9.2 on, an entry point to the user segments is provided in the API !