A couple of requests

[immanuel]

Hello, I'm completing the integration of acegi into an existing application, and I was wondering what is the best way to propagate custom information with the SecureContext into the current thread. What I've done is subclass the context with a custom class and use that class into HttpSessionContextIntegrationFilter: I then complete it with custom data after validation and upon further use in the application. A couple of questions/requests:
1) would it be possible to make the http session attribute key for the secure context configurable? Currently the value is fixed to ACEGI_SECURITY_CONTEXT
2) currently the secure context instance is created into the HttpSessionContextIntegrationFilter.generateNewCon text: this is public and as such it is easily subclassable. What I'd like to do instead is extract a ioc-configured prototype from spring context using a lookup-method. The problem is that acegi's jar are signed, and this seem to be incompatible with the use of aop-features based on subclassing such as this one: the app explodes with the error "signer information does not match signer information of other classes in the same package". Does this mean I can't use this unless I build acegi by myself and produce non-signed jars?

[Ben Alex]

I have no problem with making the attribute name configurable. Although I'm not sure how often it would be customised...

The signed JAR issue is more difficult and I can't offer any suggestions on that front short of re-jaring. Alternatively, we could easily make the generateNewContext() method as part of an interface such that custom implementations could be offered.

Please note current CVS has extensively refactored the context handling approach. You might like to take a look. If you wish to submit a patch for HttpSessionContextIntegrationFilter, please feel free.

[immanuel]

I have no problem with making the attribute name configurable. Although I'm not sure how often it would be customised...

Well, this is simply because we have legacy struts bean tags that extract "our" custom secure context bean from the session (i.e.: the object that performed the same role as securecontext and that has been refactored in order to implement the acegi interface) and use it in order to access a couple of custom properties. I prefer providing my own name than having to use ACEGI_SECURITY_CONTEXT.

The signed JAR issue is more difficult and I can't offer any suggestions on that front short of re-jaring. Alternatively, we could easily make the generateNewContext() method as part of an interface such that custom implementations could be offered.

Well, for now I have re-jarred the classes and used the lookup-method approach: I believe that moving that method in an interface is not really needed, since one could subclass and override it: at the end having to subclass and change the name of the class used in the filter is even less work than having to specify another bean and set it as a "contextGenerator" property.

Please note current CVS has extensively refactored the context handling approach. You might like to take a look. If you wish to submit a patch for HttpSessionContextIntegrationFilter, please feel free.

Ok, I'll take a look.