-
1. Re: Convenience or use case configurations
adrian.brock Jan 24, 2005 10:51 PM (in response to 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. -
2. Re: Convenience or use case configurations
adrian.brock Jan 24, 2005 10:56 PM (in response to 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"/>
-
3. Re: Convenience or use case configurations
adrian.brock Jan 24, 2005 11:00 PM (in response to 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
aList getBeans()
and let the kernel takeover to resolve dependencies,
construct containers and do all the other goodness in the correct order. -
4. Re: Convenience or use case configurations
dimitris Jan 25, 2005 11:51 AM (in response to adrian.brock)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? -
5. Re: Convenience or use case configurations
adrian.brock Jan 25, 2005 1:37 PM (in response to 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. -
6. Re: Convenience or use case configurations
adrian.brock Jan 25, 2005 1:42 PM (in response to 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. -
7. Re: Convenience or use case configurations
starksm64 Jan 30, 2005 4:19 PM (in response to adrian.brock)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. -
8. Re: Convenience or use case configurations
adrian.brock Jan 31, 2005 10:56 AM (in response to 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.