Bugs in 4.1 and progress to 4.2

[Steve Fisher]

Hi,

Shelly has reported a bug and a fix for 4.1 where the JMS buffers fill up because of failure to close things properly. The fix is to add "connection.close();" to the following two files.

     exposed/src/main/java/org/icatproject/exposed/interceptor/LogoutInterceptor.java

     user-ldap/src/main/java/org/icatproject/userldap/facility/LoginInterceptor.java

If it is desired I will produce a 4.1.2 with this correction. Please tell me if you want this. It is only a problem (I think)  with a high rate of ICAT calls.

I have been investigating the poor performance of the "get" and "search" calls. It is caused by unexpected behaviour of EclipseLink. They have added functionality which is not present in hibernate to do lazy evaluations outside of a transaction and even when the persistence context has been cleared and all entities detached. The result of this was that the handling of the INCLUDE mechanism was very inefficient leading to many queries for things which had not been requested. I have found no way to turn this behavior off, so I plan to copy the data structure to be output before allowing the copy to be handled by JAX-WS. I have tried it for one entity type and found that it solves the problem. If anybody knows of a way to really detach the entities I would be very pleased to hear about it otherwise I may write a "pruned" operation for each entity which returns a new object with the desired contents and which  recurses down to copy everything that is needed. An alternative which would be more robust (as there is no opportunity to miss an attribute) but probably slower would be to use reflection. I might get the best of both worlds by writing a code generator to generate the code for each entity type. This is a very significant performance problem - perhaps a factor of five, however as it is "only" performance I propose to release a 4.2 sooner than expected with just the performance enhancement and the decoupled authentication mechanism. Shelly's bug will vanish as the offending authn code has gone.

I have another issue where I am looking for advice. Currently icat has a top level module  with component modules in sub-directories, each with its own pom. This structure means that all components get the same version number (mainly because of SVN tagging of the top level module)  which gets increased though nothing has changed. Do people have any experience of using maven this way - or better suggestions.

Steve

[Steve Fisher]

I would like to release 4.2 ASAP as the performance improvements are significant. However I want to be sure that I make the change to produce the authentication plugins correctly - the login call has changed to accommodate multiple plug-ins requiring different parameters. The login call now takes a string identifying the chosen authentication plugin and a map of credentials. For the username/password case the map can be expected to have two entries with keys of "username" and "password". This is indeed the case for the two authentication methods provided so far “db” and “ldap” - where “db” is simply a database lookup.

The first question is how to pass in the map. If I declare the map to be a java.util.Map then for this to be deployable you need an uptodate copy of jax-ws such as the one with the latest glassfish. With older versions you get a message saying that interfaces are not supported. This would be OK except that it is clearly not true as List is also an interface. The map is represented as a sequence of types where each type is a sequence of key and value. It works fine from python.

A possible alternative would be to use a JSON representation of the map - which is clearly good for python people or to use a syntax such: /username:fred/password:bill where the first character in the string defines the separator. However my preference is to leave this declared as a Map which I think is the cleanest.

The other issue is how to name and identify the authn plugins. I think the full class name should be treated as the canonical name. Assuming that people are following the normal rules for naming classes (i.e. starting with a reversed domain name that you “own”) then uniqueness of these names can be guaranteed. However I don’t think that users should be expected to type such a long name whenever they wish to select an authn method. My preference is to allow the ICAT deployer to define a short name which would appear in a configuration file along with the JNDI string to find the authenticator which may be deployed remotely. This would look something like:

authn.list = db, ldap
authn.dp.jndi = java:global … # full jndi name of db authenticator
authn.ldap.jndi = java:global … # full jndi name of ldap authenticator

Comments please - ASAP.

Steve 

[tom.g...@stfc.ac.uk]

Hi Steve,

 

I’ve been trying out the latest version (r2056) and what you have there seems to work well enough for me.

 

Best Regards,

Tom

--
http://groups.google.com/group/icat-developers

--
Scanned by iCritical.