One thing that I have found it necessary to build for every significant application in which I have used the MDA is a bean catalogue. By this I mean a beans.xml file that defines abstract beans for each bean class I use from the MDA, named after that class but including lazy instantiation and defining common items such as the initialize and destroy method names. This simplifies actual bean declarations, which are made from the parent bean rather than specifying a class.
I think this is enough of a common pattern to provide as part of the distribution, invoked through an import of classpath:net/shibboleth/metadata/beans.xml or the like.
It makes sense to include a fixed prefix (suggestion: mda.) in each name, so that we end up with, for example, mda.DOMResourceSourceStage.
It doesn't seem to be necessary to include all of the package hierarchy in these abstract bean names, although it might make sense to include some grouping for function. This would be the same kind of choice as we have made in IdP bean configuration files (where the prefix is shibboleth..
Environment
None
Activity
Show:
Ian Young May 2, 2017 at 9:40 AM
I have tested this with the UKf tooling, and I am going to resolve it for now as that seems to be a significant step forward by itself. Might come back to the idea of adding some more things later once others have some experience with it at this level.
Ian Young April 27, 2017 at 4:01 PM
Checked in an initial cut of this as a3e3ca99b7a22645f92d6d2def9c29c3b8338736. This version is just a set of shortcuts for the bean classes that might be used in configurations, and it does not set any properties on them. There's an accompanying test to make sure that the referenced classes exist, etc.
There are a couple of ways this could be made more useful, such as defining some more variants with derived defaults for things like namespace prefixes used in XPath. I will try plugging the first cut into things like the UKf tooling first, though to see how much of that there needs to be and how much really should be left for the individual project.
One thing that I have found it necessary to build for every significant application in which I have used the MDA is a bean catalogue. By this I mean a
beans.xmlfile that defines abstract beans for each bean class I use from the MDA, named after that class but including lazy instantiation and defining common items such as the initialize and destroy method names. This simplifies actual bean declarations, which are made from the parent bean rather than specifying a class.See for example: https://github.com/ukf/ukf-meta/blob/master/mdx/common-beans.xml
I think this is enough of a common pattern to provide as part of the distribution, invoked through an import of
classpath:net/shibboleth/metadata/beans.xmlor the like.It makes sense to include a fixed prefix (suggestion:
mda.) in each name, so that we end up with, for example,mda.DOMResourceSourceStage.It doesn't seem to be necessary to include all of the package hierarchy in these abstract bean names, although it might make sense to include some grouping for function. This would be the same kind of choice as we have made in IdP bean configuration files (where the prefix is
shibboleth..