I was thinking out load about the advanced configuration.
Let me be clear that when I post xml fragments, I am not thinking that these
should be just xml. In fact, the use of xslt is not what I want.
Everything that is xml should be directly backed by a javabean (the xml parser
just does a
Clarify what you mean by the advanced config option here please:
| But this could be worked around by allowing an advanced config option
| List beans = EJBDeployment.getBeans();
| //process beans to add config;
| EJBDeployment.setBeans(beans);
|
This convenience config topic is too
Solution:
The microcontainer accepts the notion of a deployment,
this is a collection of beans:
| public interface KernelDeployment
| {
|/**
| * Get the beans in the deployment
| *
| * @return ListBeanMetaData
| */
|List getBeans();
|
|
This can be
So, we should have each deployer defining its own AbstractKernelDeployment
subclass that programmatically generates the full deployment metadata from a
simplified description.
I'm not sure if I understand the last part. Do you mean for example, how to use
many of those AbstractKernelDeployment
That is one way to implement it.
It does have the advantage the deployers become simple and it would be easier
for other deployers to pluck out the parts they want to work on.
e.g. A hypothetical deployer that wants to post process all EJB containers
can do it more easily if it is looking for
The downside is that (in the hypothetical example) you can only override config
exposed by EJBDeployment whereas the plain BeanMetaData configs expose
everything for configuration.
But this could be worked around by allowing an advanced config option
List beans = EJBDeployment.getBeans();
Let's take the example of constructing a classloader since that was brought up
by Scott.
In plain bean metadata this looks something like the following:
| bean bean=java.net.URLClassLoader
|constructor
| parameters
| parameter type=java.net.URLsomeURL/parameter
|
You will also note that multiple beans can be constructed
so you could use the same technique to simplify more complex
(multi-bean) deployments:
| proxy-container
|interceptors.../interceptors
|target.../target
| /proxy-container
|
I see this as more important for the
