Re: [JBoss-dev] should J2eeDeployer extend DeployerMBeanSupport?
On 2001.12.10 18:42:23 -0500 Jason Dillon wrote: > > Universal deployer is asked to deploy a package. > > =) > > > It starts by unpacking all the nested jars (recursively) and locating > all > > the deployment descriptors (this functionality is pretty much in > > DeployerMBeanSupport today). (there may be some needs to ignore some > dd's, > > per j2ee spec. I'm still looking) > > > > It then collects related deployment descriptors (such as ejb-jar.xml, > > jboss.xml, and jbosscmp.xml) and uses xslt to combine them into one > jboss > > specific dd that includes all relevant info (this may include expanding > > defaults to be present wherever they are used). (I've prototyped this, > its > > pretty easy. The ability to deploy from such a single dd has been > > requested). > > Would this allow users to override specific parts of an ejb config > perhaps? > Say to just set (or unset) the default RMI port, or up the number of > threads > that a MDB is allocated? > > > One of the features of the combined dd is that everything is an mbean > > configuration. Therefore, there are no more standalone "deployer" > mbeans. > > Instead, an mbean that represents the deployed unit is created, and is > > responsible for interpreting the dd xml itself. As a side effect, > Andreas > > gets appropriately named mbeans for each deployment unit, that can > create > > his jsr-77 mbeans to proxy themselves. > > Will these beans have controls to allow them to be undeployed or changed > at > runtime too? > > How will new deployment types be handled? How does the universal > deployer > know what type of deployer mbean to create for the requested deployment > unit? What I was thinking of was actually to use xslt to transform all dd's into our mbean config language, and use ServiceDeployer to deploy the resulting file. The "deployment" mbeans are than pretty much like any other mbean to the core system. If you think of something else that needs deploying, you just write a deployment mbean for it and possibly some xslt scripts to get the dd into a canonical form. david jencks > > Sounds like you might need a DeployerFactory, which despenses Deployers > for > the UniveralDeployer. Or I guess the UD could also be a DF... > > If the new deployer concept will also manage the state and configuration > of > the deployment, perhaps it should be renamed for clarity? > > --jason > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] should J2eeDeployer extend DeployerMBeanSupport?
> Universal deployer is asked to deploy a package. =) > It starts by unpacking all the nested jars (recursively) and locating all > the deployment descriptors (this functionality is pretty much in > DeployerMBeanSupport today). (there may be some needs to ignore some dd's, > per j2ee spec. I'm still looking) > > It then collects related deployment descriptors (such as ejb-jar.xml, > jboss.xml, and jbosscmp.xml) and uses xslt to combine them into one jboss > specific dd that includes all relevant info (this may include expanding > defaults to be present wherever they are used). (I've prototyped this, its > pretty easy. The ability to deploy from such a single dd has been > requested). Would this allow users to override specific parts of an ejb config perhaps? Say to just set (or unset) the default RMI port, or up the number of threads that a MDB is allocated? > One of the features of the combined dd is that everything is an mbean > configuration. Therefore, there are no more standalone "deployer" mbeans. > Instead, an mbean that represents the deployed unit is created, and is > responsible for interpreting the dd xml itself. As a side effect, Andreas > gets appropriately named mbeans for each deployment unit, that can create > his jsr-77 mbeans to proxy themselves. Will these beans have controls to allow them to be undeployed or changed at runtime too? How will new deployment types be handled? How does the universal deployer know what type of deployer mbean to create for the requested deployment unit? Sounds like you might need a DeployerFactory, which despenses Deployers for the UniveralDeployer. Or I guess the UD could also be a DF... If the new deployer concept will also manage the state and configuration of the deployment, perhaps it should be renamed for clarity? --jason > Note that the ConnectionFactoryLoader is kind of like this already -- it > can be thought of an mbean that represents the deployment of a > ConnectionFactory. The RARDeployement is similar, but is not yet > self-deploying: it is created by the (now almost empty) RARDeployer MBean. > > Any thoughts? > > david jencks > > > > On 2001.12.10 16:19:46 -0500 Jason Dillon wrote: > > Any chance this overhaul will introduce a single entry point to > > deploy/undeploy? By that I mean that it will have a collection of > > mappings from url regex or something to the JMX object name of the actual > > deployer that can handle those deployments. Then all other components > > will use that deployer controller. > > > > I was looking to trim down the logging that is done for deploy/undeploy, > > which I did some, but it is difficult since different components use > > different deployers to get the job done. > > > > It would be nice if there one a single place which would have the > > authority to say if something was deployed or undeployed. > > > > I was thinking a simple MBean which took a regex and an object name, then > > simply proxied requests to the appropriate MBean as they came in > > nothing too fancy, or rather heavy. > > > > --jason > > > > __ > > View this jboss-dev thread in the online forums: > > http://jboss.org/forums/thread.jsp?forum=66&thread=5265 > > > > ___ > > 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 > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] should J2eeDeployer extend DeployerMBeanSupport?
Maybe I can get some feedback on whether I am biting off too mcuh at once here... The kind of mapping you describe is implictly in what I'm thinking of. My idea is: Universal deployer is asked to deploy a package. It starts by unpacking all the nested jars (recursively) and locating all the deployment descriptors (this functionality is pretty much in DeployerMBeanSupport today). (there may be some needs to ignore some dd's, per j2ee spec. I'm still looking) It then collects related deployment descriptors (such as ejb-jar.xml, jboss.xml, and jbosscmp.xml) and uses xslt to combine them into one jboss specific dd that includes all relevant info (this may include expanding defaults to be present wherever they are used). (I've prototyped this, its pretty easy. The ability to deploy from such a single dd has been requested). By now, the deployer should know which scope the classes are going into (base jboss or a particular application). It creates a jboss URLClassLoader from the list of unpacked packages, and adds it to the appropriate scope/ServiceLibraries. One of the features of the combined dd is that everything is an mbean configuration. Therefore, there are no more standalone "deployer" mbeans. Instead, an mbean that represents the deployed unit is created, and is responsible for interpreting the dd xml itself. As a side effect, Andreas gets appropriately named mbeans for each deployment unit, that can create his jsr-77 mbeans to proxy themselves. Note that the ConnectionFactoryLoader is kind of like this already -- it can be thought of an mbean that represents the deployment of a ConnectionFactory. The RARDeployement is similar, but is not yet self-deploying: it is created by the (now almost empty) RARDeployer MBean. Any thoughts? david jencks On 2001.12.10 16:19:46 -0500 Jason Dillon wrote: > Any chance this overhaul will introduce a single entry point to > deploy/undeploy? By that I mean that it will have a collection of > mappings from url regex or something to the JMX object name of the actual > deployer that can handle those deployments. Then all other components > will use that deployer controller. > > I was looking to trim down the logging that is done for deploy/undeploy, > which I did some, but it is difficult since different components use > different deployers to get the job done. > > It would be nice if there one a single place which would have the > authority to say if something was deployed or undeployed. > > I was thinking a simple MBean which took a regex and an object name, then > simply proxied requests to the appropriate MBean as they came in > nothing too fancy, or rather heavy. > > --jason > > __ > View this jboss-dev thread in the online forums: > http://jboss.org/forums/thread.jsp?forum=66&thread=5265 > > ___ > 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
Re: [JBoss-dev] should J2eeDeployer extend DeployerMBeanSupport?
Any chance this overhaul will introduce a single entry point to deploy/undeploy? By that I mean that it will have a collection of mappings from url regex or something to the JMX object name of the actual deployer that can handle those deployments. Then all other components will use that deployer controller. I was looking to trim down the logging that is done for deploy/undeploy, which I did some, but it is difficult since different components use different deployers to get the job done. It would be nice if there one a single place which would have the authority to say if something was deployed or undeployed. I was thinking a simple MBean which took a regex and an object name, then simply proxied requests to the appropriate MBean as they came in nothing too fancy, or rather heavy. --jason __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66&thread=5265 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] should J2eeDeployer extend DeployerMBeanSupport?
I've been working on a pretty major overhaul of all the deployers, but it is taking far longer than I expected. If as an interim measure you want to change j2ee deployer to extend DeployerMBeanSupport I think that is fine. david jencks On 2001.12.09 02:16:32 -0500 Jason Dillon wrote: > Looks like it should, but I don't know if there is a reason it does not. > > The logic to find the temp directory is messed up, which is why it is > using > the deploy/* directory. > > I am going to fix that, but if there isn't any reason for it not to > extend > DeployerMBeanSupport, it probably should. > > --jason > > > ___ > 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
[JBoss-dev] should J2eeDeployer extend DeployerMBeanSupport?
Looks like it should, but I don't know if there is a reason it does not. The logic to find the temp directory is messed up, which is why it is using the deploy/* directory. I am going to fix that, but if there isn't any reason for it not to extend DeployerMBeanSupport, it probably should. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
