-
15. Re: Repository prototype discussion
Yes, I don't yet have a clear picture on this (in terms of api/linkage).
The profile/policy/metadata implementations are mixed together
but performing different functions.
The profile is more about what is deployed (including policy).
The policy is more about static configuration options, overrides and retrieval strategy.
The metadata is the runtime model with layers.
i.e.
The profile will know which version of policy to deploy.
The policy will know how to populate/retrieve the metadata model.
For now I am just addressing what I took for your question about a good pattern
for applying external configuration to bean configuration (where this is implementation
detail that the user shouldn't really see/change).
e.g. in the example you gave originally, this could have used direct
access to repository<bean name="DefaultPartition" class="org.jboss.clustering.ClusterPartition"> <property name="MulticastAddress"><repository level="Server" name="jboss.server.udp.address"/></property> </bean>
But that means the bean metadata layer needs to understand all the different
policy retrieval strategies.
Alternatively, we could make the assumption that it will always be accessed
via the metadata layer and that this is populated through the policy.
The implementation choices are unclear to me at the moment.
The only thing that is clear to me, is that we want average users/administrators
to be dealing with something like the policy deployment (whether it is xml or GUI)
and not with the implementation details you posted originally. :-) -
16. Re: Repository prototype discussion
The policy and metadata loaders are almost certainly trying to do the same thing,
though not necessarily the same way.
I haven't groked the metadata loader stuff yet. :-) -
17. Re: Repository prototype discussion
The (unused in current implementation) MetaDataLoader notion was about lazily picking up metadata from external stores as well as resynching with runtime changes. It is not a well formed concept because it does heavily intersect with the policy notion and the policy is not a property of the metadata repository.
So one possible api mapping involves profile -- policy -- repository with the policy defining the MetaDataLoaders for a set of repository bindings. -
18. Re: Repository prototype discussion
Are there some tests for this somewhere demonstrating how it is used?
-
19. Re: Repository prototype discussion
Never mind, I found some in the zip attached to the wiki page
-
20. Re: Repository prototype discussion
Those should have been added to the container tests. I have done this under the org.jboss.test.repository.test package in container/src/tests.
-
21. Re: Repository prototype discussion
I've committed the infrastructure for the scoped metadata
that I've been working on.
It can be found in the container project under org.jboss.metadata
the tests are in org.jboss.test.metadata
The part that is missing is the scopes
and how these get integrated into
1) The repository
2) AOP (via the Microcontainer integration)
The scopes will also have support for AOP Domains
and eventually scoped microcontainer kernels.
I'll start a different thread for an issue about the caching.