MyProxy server segfaulting

Setting up a new MyProxy (v3.9 12 Jun 2007 PAM OCSP) from VDT 1.8.1 I ran across an annoying segfault issue when running the server to run as a CA, in debug mode.

# myproxy-server -dmax_proxy_lifetime: 43200 seconds
PAM enabled, policy requiredCA enabledmax certificate lifetime: 43200 seconds
using storage directory /var/myproxy
Starting myproxy-server on localhost:7512...
Connection from 127.0.0.1
using trusted certificates directory /opt/vdt/globus/TRUSTED_CA
Authenticated client <anonymous>
applying trusted_retrievers policy
trusted retrievers policy matched
applying authorized_retrievers policy
applying authorized_renewers policy
Program received signal SIGSEGV, Segmentation fault.

Note, the client can connect and only fails once the client responds with their credentials. Using GDB I got the stack trace of the issue:

#0  0x008f3950 in strip_newlines (string=0x901d13 "unknown error\n")    at myproxy_log.c:72
#1  0x008f3a95 in myproxy_log_verror () at myproxy_log.c:141
#2  0x0804ca27 in myproxy_authorize_accept (context=0x9fcc020,     attrs=0x9fcc008, client_request=0x9fd70c0, client=0xbfd892e0)    at myproxy_server.c:1445
#3  0x0804ae5a in handle_client (attrs=0x9fcc008, context=0x9fcc020)    at myproxy_server.c:465
#4  0x0804a932 in main (argc=2, argv=0xbfd897e4) at myproxy_server.c:308

Noting that the exception is in the myproxy_log_verror method, and looking at the myproxy code I found this method is only activated when in debug mode. So, assuming all my config was good I ran the myproxy-server proper and all was good.

Some thoughts on a dynamic (lazy) data access layer for web services

The problem I’ve been address in my most recent work block has been to develop an interface to a relational data store which can be used either as a local DB, or via webservices. The concept is quite straight forward, we want CRUD operations on a set of data objects. The schema is fairly straight forward too, with a core hierarchy of elements with a few enumerated lists. As well as a few cuts across the hierarchy.

We want to use this with webservices, as well wanting to be able to serialise to an XML document, so we layed out the schema in XSD, and applied HyperJAXB3 to is using a JAXB annotations document. Other than a few tweaks to the HJ3 code to add in some extra features we needed, everything this far is vanilla.

We then laid out a generic DAO interface, and implemented a JPA and webservices client. The webservices server actually just wraps the JPA client with a security layer.

All is well so far, with the base functionality passing all the unit tests. But, this is a fairly clumsy, class by class CRUD interface. With JPA/Hibernate you can lazily fetch parents and children of an object, and replicating this functionality would be really useful. But the webservices link really kills things.

One approach we tried was to override the getter methods on the beans to allow dynamic retrieval of data if the stored attribute is null. But we needed the webservices client to create these new (extended) beans. This is actually harder than it sounds, as CXF w/ JAXB does not allow you to replace the context factory. (see https://jax-ws.dev.java.net/issues/show_bug.cgi?id=282 )

We also tried writing our own proxies, with some success. But we ran into troubles when proxying single elements (as opposed to lists) as you loose the annotations which CXF and JPA require.

The obvious answer, which I haven’t mentioned yet is to put this logic in the getters proper. This would be nice, but because we are generating the classes from a schema we don’t want to change the generated code. There are many reasons, none less than because the schema is evolving and it hurts to merge changes. We attempted to write our own JAXB plugin to change the methods which were already generated, but XJC/the-java-code-model do not allow you to remove code from a method, only append to it. Similarly, you can’t get the annotations on a method, nor modify existing annotations. This is a huge problem for us, as it would save us having to modify the JAXB plugins which create this code, rather we could simply apply our changes to the produced code.

Perhaps there is a way around this, but it certainly isn’t obvious, or indexed by Google.

The closing remarks are these. With a bit of backfilling JAXB/XJC will be an immensely powerful tool, able to develop a wide range of data models. (I’m working on the tickets now). Dynamic getter access to attributes via web services would be nice, but it is too much hard work really, and if it is required then creating a second set of domain objects is your only real hope, IMHO. When this project wraps up I’ll release the code here so we can all think about how this approach really faired.