my point is that it will be used as an extension point which means :

- needs to be stable and supported for the life cycle of the software (which can be years). It can be extended and it should be backward compatible.

- needs to be in an independant jar that can be integrated in build system without the wsrp classes and their versionning (i.e the same jar remains compatible between jboss portal 2.6+ and 3.x, etc...)

- at the end it's better to put all api classes in the same package and place

"chris.laprun@jboss.com" wrote:
I will think about it once I get to a point where it makes sense to integrate with the rest of the Portal.
I have to admit, though, that I don't see the point of it being independent of WSRP since I don't see what else it could be used for (unless there is a registration concept in JSR 286).

I created a JIRA task targetted for alpha as it is an important concern. As it is an API we all need to review it in order to reach a consensus.

http://jira.jboss.org/jira/browse/JBPORTAL-1109

Now I see more clearly the responsibility of the registration policy. It seems that you want to encapsulate in a service how a particular producer react with respect to the registration protocol.

Here is what I see, correct me if I am wrong :

- the policy describes how a producer should behave (RegistrationMetaData)
- the policy behaves when a registration occurs

By default for now it would be injected in the producer we have. Perhaps that in the future we could support it configured per web application.

I don't think we need to expose it as an API actually. People can provide implementations. But what is sure is that we need to define how we support this with respect to the evolution of the software. I think that Alex should tell us how this is done.