7 Replies Latest reply on Jan 30, 2008 11:07 AM by dmlloyd

Remoting 3 deployers

dmlloyd Jan 29, 2008 10:13 AM

I'm working on creating deployers for Remoting 3. The design I'm thinking of will allow deployment and/or configuration of:

* Endpoints
* Protocol support modules
* Protocol server instances
* Server interceptor modules
* Service instances
* Remote endpoint connections

Each of these items should be individually deployable, but it should also be possible to deploy multiple units at once (the individual configurations are fairly simple at this point, and it would be silly to require the user to write 10 4-line XML files just to get a basic deployment running). I believe that it is most appropriate to express each of these items as a simple XML configuration.

So my first question is, what is the most appropriate way to approach this deployer? And, is it better to make a separate deployer for each type, or to have one deployer that covers everything?

Finally, is it better to use JAXPDeployer/JAXBDeployer(s) or is there a more preferred way to deploy using an XML configuration? It seems like every deployer in the AS codebase does something a bit different, and I've been unable to find a good example of what a deployer ought to look like.

Thanks.

1. Re: Remoting 3 deployers

alesj Jan 29, 2008 1:00 PM (in response to dmlloyd)

"david.lloyd@jboss.com" wrote:
And, is it better to make a separate deployer for each type, or to have one deployer that covers everything?

I would go with separate deployer for each type.
Since that was our intention with the aspect deployers.
To have small fine grained easily changeable components.

Perhaps follow this discussion between runtime and deployment process architecture:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124055#4124055

"david.lloyd@jboss.com" wrote:

Finally, is it better to use JAXPDeployer/JAXBDeployer(s) or is there a more preferred way to deploy using an XML configuration?

I would go with the new thing that we will introduce:
- http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/container/src/main/org/jboss/javabean/plugins/jaxb/
- http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/container/src/tests/org/jboss/test/xb/builder/

We already have MC bean metadata annotated, just need to switch the current BeanDeployer to use this jbossxb-builder.
Actions
2. Re: Remoting 3 deployers

dmlloyd Jan 29, 2008 2:04 PM (in response to dmlloyd)
So what would the configuration actually look like then?

I wanted something like:
<endpoint> <name>DavesEndpoint</name> </endpoint>

or even:
<endpoint name="DavesEndpoint"/>

...to deploy a simple endpoint. From the look of the JAXB annotations, it looks like I'd have to make the user do something like this:

<javabean class="org.jboss.remoting.deployer.EndpointBean"> <property name="name">DavesEndpoint</property> </javabean>

Am I totally misunderstanding this?
Actions
3. Re: Remoting 3 deployers

alesj Jan 29, 2008 6:51 PM (in response to dmlloyd)

"david.lloyd@jboss.com" wrote:
Am I totally misunderstanding this?

Almost. :-)

The idea with jbossxb-builder is to create your own configuration on top of metadata.
What ever suits you best, like your simple example with endpoint.

All you need to do is make sure your top element metadata handler implements/produces either BeanMetaData or KernelDeployment.
Which will be later picked up by existing MC deployers.
Actions
4. Re: Remoting 3 deployers

starksm64 Jan 29, 2008 8:38 PM (in response to dmlloyd)

You really should start from your metadata view and pojos with their plugins described as javabean setters that will map to dependency injections.

A parsing deployer translates whatever xml view of your metadata you want into the metadata, and another deployer translates this into KernelDeployment/BeanMetaData or ServiceDeployment/ServiceMetaData descriptions of the runtime components that should be created. This includes dependencies between the components and other services they rely on.

The ServiceDeployment/ServiceMetaData is the simplest because its a simple mbean. However, it does not integrate well with aop, has other limitations, and its not the best deployer to look at as it keeps the service.xml dom element around and implements its own component model.

One of the examples that should come out of the jbw talk Ales and I are doing is an example of a parsing deployer that produces some metadata from a custom xml/jaxb model, a AbstractComponentDeployer/AbstractSimpleRealDeployer pair that translates this into KernelDeployment/BeanMetaData for wiring by the mc deployers.
Actions
5. Re: Remoting 3 deployers

dmlloyd Jan 30, 2008 9:14 AM (in response to dmlloyd)

OK, now I understand, I think. I'll give this a shot today and see if it works.

Looking at the AS source, it seems that almost all the deployers are currently using ServiceDeployment/ServiceMetaData at the moment. Does this mean that we're going to make a move towards the KernelDeployment method instead?

I was hoping to have this at least somewhat working by JBW - we'll see what happens.
Actions
6. Re: Remoting 3 deployers

alesj Jan 30, 2008 10:09 AM (in response to dmlloyd)

"david.lloyd@jboss.com" wrote:

Looking at the AS source, it seems that almost all the deployers are currently using ServiceDeployment/ServiceMetaData at the moment. Does this mean that we're going to make a move towards the KernelDeployment method instead?

That's because they are mostly ports from MBeans.
So it's easier/quicker for them to use ServiceMetaData.

But for new things, I would definitely recommend KernelDeployment/BeanMetaData.

If you have any issues, let me know.
Here or on the MC user forum.
Actions
7. Re: Remoting 3 deployers

dmlloyd Jan 30, 2008 11:07 AM (in response to dmlloyd)

"alesj" wrote:
But for new things, I would definitely recommend KernelDeployment/BeanMetaData.

OK, that's what I'm going with then.

"alesj" wrote:
If you have any issues, let me know.
Here or on the MC user forum.

Hint taken. :-)
Actions

Go to original post