I have been planning for a long time and hope to be able to work on very
soon another major change to deployment.
My plan is to divide deployment up into:
1. add all the classes to the classloader
2. Transform all the dd's into mbean configuration (using xslt mostly)
3. Deploy the resulting mbean configurations.
For instance in step 2, ejb-jar.xml, jboss.xml, and jbosscmp-jdbc.xml all
get transformed into what are basically Container mbean configurations.
Lets work together to see how these ideas fit.
Also I think DeploymentInfo should be an mbean, so the subdeployers don't
need to keep track of them, the MBeanServer will.
I'm not entirely sure what you mean by the subdeployer's lifecycle. If you
mbean the sequence of init, create, start calls, note that these are not
done all at once per package, but each step is run through every subpackage
before the next is started. Keeping the functionality in MainDeployer
prevents a rogue SubDeployer from failing to deploy subpackages. Perhaps,
however, allowing this would be a good idea.
So is your idea that the only thing the MainDeployer is really does is find
the deployer for each package and subpackage, and once found the deployers
themselves do all the work including calling subpackage deployers? It
would work, I don't have an opinion yet on if it is a good idea.
Thanks
david jencks
On 2002.04.14 17:16:03 -0400 Larry Sanderson wrote:
> I have been working with the deployers for the last week or so, and I
> have been thinking about some design changes that would help clean it up.
>
> I see two major problems with the current usage: 1) MainDeployer is a
> bootstrapped class, with no way to provide an alternate implementation,
> 2) All SubDeployers rely on a concrete implementation of deployer:
> MainDeployer,
>
> The first problem is easy to fix: provide a System-Property style
> configuration for an alternate bootstrapped deployer.
>
> The second problem is not so easy. I propose that we give more control
> to the SubDeployers, and simplify the bootstrap deployer. I propose that
> we move all life-cycle management of SubDeployers to the particular
> implementations of SubDeployer. This eliminates the need for the
> bootstrapped deployer to manage each SubDeployer's life cycle. Further,
> the bootstrapped deployer no longer has to manage DeploymentInfo objects
> - this job has been passed down to the SubDeployer as well. This allows
> each SubDeployer to create their own implementations of DeploymentInfo.
> Finally, DeploymentInfo needs to be cleaned up - it has become a
> repository for disparate, and often unnecessary information. Since
> SubDeployers are now allowed to create their own implementations, all but
> the most common attributes can be removed.
>
> Here are my thoughts for the public class structure:
>
> [code]
> public interface SubDeployer
> {
> boolean accepts(URL url);
> boolean deploy(URL url);
> boolean unDeploy(URL url);
> boolean isDeployed(URL url);
> DeploymentInfo getDeploymentInfo(URL url);
> }
>
> public interface Deployer extends SubDeployer
> {
> SubDeployer getSubDeployer(URL url);
> void addDeployer(SubDeployer deployer);
> void removeDeployer(SubDeployer deployer);
> }
>
> public class DeploymentInfo
> {
> // General cleanup
>
> // make members private with accessors / mutators
>
> // remove "SubDeployment" specific attributes
> // (webContext,manifest,document metaData,etc...)
> // These can be provided with subDeployment specific
> // subclasses.
> }
> [/code]
>
>
> Let me know if you have any comments. I would like to get started on
> this soon.
>
> Thanks
>
> -Larry
>
> _________________________________________________________
> View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=12917
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
