Convenience or use case configurations

[adrian.brock]

I'd better outline the idea of "convenience" or use case configurations.

The problem:
Although the jboss microcontainer metadata is very flexible and basically
will allow you configure anything you like that could be done through
java programming and much more, it is very verbose.
In many use cases, a lot of the configuration remains the same with only
a few parameters changing.

[adrian.brock]

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.URL">someURL</parameter>
 </parameters>
 </constructor>
</bean>

which will become pretty tedious for more complicated constructs.

[adrian.brock]

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 List<BeanMetaData>
 */
 List getBeans();

This can be used to "generate" the bean metadata from a few parameters.

In the example above it would be something like:

public class URLClassLoaderDeployment extends AbstractDeployment
{
 /** with getters and setters */
 private URL url;

 public List getBeans()
 {
 // Generate the bean metadata here
 }
}

So the xml might look something like:

<urlclassloader url="whatever"/>

[adrian.brock]

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 deployers where we should be able to
parse the more complex j2ee deployment descriptors and turn them into
a

List getBeans()

and let the kernel takeover to resolve dependencies,
construct containers and do all the other goodness in the correct order.

[dimitris]

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 subclasses in order to produce deployment metadata from a combined larger xml definition, that may contain information for different deployers?

[adrian.brock]

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 "metadata instanceof EJBDeployment" rather than a
BeanMetaData with an open ended set of possibities like
bean="StatelessContainer" or bean="CMPContainer"

I don't understsand your second question.

[adrian.brock]

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();
//process beans to add config;
EJBDeployment.setBeans(beans);

Although that is probably too simplistic to scale across multiple separation of concerns
and would be brittle to internal changes within the EJB metadata model.

[starksm64]

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 wide open to grok effectively because its mixing several different layers. Its a variation of the *-ds.xml vs the underlying jboss-service.xml mbeans for the datasource layer, and as such its really intersecting with the admin ui layer. Turing around and discussing how this impacts the type interfaces showing up at the object based kernel metamodel is making a huge leap without any usecases to justify it.

Due to the historical tight coupling of xml configuration views with xml parsing showing up in the codebase, I want to be clear that when we discuss configuration using xml fragments that this implies the existence of a jbossxb layer which is handling the actual xml to object transformation. As such, a convience configuration further impiles another layer on top of the jbossxb layer. The layer could just be an xml transformation to the full schema, or it could be another namespace that maps to jbossxb factories that extend the full schema factories.

[adrian.brock]

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 direct translation).

The pseudo xml representation I am using in these posts is just easier to get the ideas
across than posting javabean code.

The idea is the same as the -ds.xml but it is done in code not xslt.