Re: RE: [JBoss-dev] current mbean structure confusing
My plans are way ahead of my time to implement any of this... some comments. 1. Don't confuse the utterly messed up and misleading current use of the classpath element and service.xml packaging with its capabilities and usefulness. There are 2 problems with the current packaging IMHO: a.the base jboss-service.jar includes every jar under the sun that I didn't explicitly remove, rather than the ones actually used in the base package, and b. No one has actually divided up the functionality of jboss into reasonable independently deployable packages. (maybe this would be an actually useful project for that debian packaging guy...???) For instance, there could be a castor-service.xml referencing the castor.jar. Loading castor classes if you aren't going to use them is silly. IMHO having the classpath element is very useful in showing what jars you actually need for certain functionality. The MBeanClassLoader solution AFAIK will not provide this documentation. I think being able to document where the classes you are using come from beats autodeploying everything in sight and hoping the classes you need are present. 2. There is definitely a problem with relying on the autodeployer: although everything may all start in the right order due to automatically computed dependencies, it doesn't look that way and is confusing. My proposed solution for this is a deployment script facility, basically a list,"deploy this, now this, now this,..." This should make it easy to construct a customized jboss by deploying the appropriate packages, including the ears etc for your application. I think this may be an easier to use and more flexible solution than the run level idea. 3. Scoping... I would like every set of deployment descriptors to be converted to a single jboss-service.xml file that explictly includes security domain/virtual host/classloader information. I think this info should be in attributes in the server element. So, for instance, for an ejb module, I would combine ejb-jar.xml, jaws.xml, and jbosscmp-jdbc.xml into a single jboss-service.xml where the module and each ejb is represented by an mbean config representing the meta data for that object. This combination is pretty easy to do with xslt, and would IMHO greatly simplify metadata loading and provide alternative "single dd" deployment descriptors. It would also provide a place to put the scoping info about which classloader to use. View: http://jboss.org/forums/thread.jsp?forum=66&thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] current mbean structure confusing
|a.the base jboss-service.jar includes every jar under the sun that |I didn't explicitly remove, rather than the ones actually used in |the base package, and including "jars" in classpath as code requirement is the initial problem, remove that. |b. No one has actually divided up the functionality of jboss into |reasonable independently deployable packages. (maybe this would be we shouldn't... the boot should be one file see my previous email |IMHO having the classpath element is very useful in showing what |jars you actually need for certain functionality. The no not as is, as is it is a stepback. put that in a comment, |MBeanClassLoader solution AFAIK will not provide this |documentation. I think being able to document where the classes it might, at least the coarse grained. MBCL-> what class-> what jar I have to look at it again to make sure. |you are using come from beats autodeploying everything in sight |and hoping the classes you need are present. no it doesn't, clearly doesn't. |2. There is definitely a problem with relying on the autodeployer: |although everything may all start in the right order due to |automatically computed dependencies, it doesn't look that way and |is confusing. My proposed solution for this is a deployment |script facility, basically a list,"deploy this, now this, now |this,..." This should make it easy to construct a customized which is what the one file achieves implictely. |jboss by deploying the appropriate packages, including the ears |etc for your application. I think this may be an easier to use |and more flexible solution than the run level idea. that could very well be. |3. Scoping... I would like every set of deployment descriptors to |be converted to a single jboss-service.xml file that explictly |includes security domain/virtual host/classloader information. I |think this info should be in attributes in the server element. |So, for instance, for an ejb module, I would combine ejb-jar.xml, |jaws.xml, and jbosscmp-jdbc.xml into a single jboss-service.xml |where the module and each ejb is represented by an mbean config |representing the meta data for that object. This combination is There we totaly agree. I think that would be very good. Although we will find that specifying the services for all the beans will be silly, combining the other files would be very good, packaging madness in the spec |pretty easy to do with xslt, and would IMHO greatly simplify |metadata loading and provide alternative "single dd" deployment |descriptors. It would also provide a place to put the scoping |info about which classloader to use. I will shoot you in the head if you do this, "give the administrator input in the class loader". You are a bit like rickard, you are a wizard in code no doubt about it and in some "ease of use" instance you are a bit of a moron :) (no offense really, I called you a rickard ;-) Ok I think I got a pretty good handle on your work, sit back bite some rope and let me refactor this, "Victor, nettoyeur" -- Nikita ca.1988 -- marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
On 2001.12.06 12:20:08 -0500 marc fleury wrote: > |a.the base jboss-service.jar includes every jar under the sun that > |I didn't explicitly remove, rather than the ones actually used in > |the base package, and > > including "jars" in classpath as code requirement is the initial problem, > remove that. > > |b. No one has actually divided up the functionality of jboss into > |reasonable independently deployable packages. (maybe this would be > > we shouldn't... the boot should be one file see my previous email > > |IMHO having the classpath element is very useful in showing what > |jars you actually need for certain functionality. The > > no not as is, as is it is a stepback. > > put that in a comment, If its a comment it will be immediately out of date and wrong. > > |MBeanClassLoader solution AFAIK will not provide this > |documentation. I think being able to document where the classes > > it might, at least the coarse grained. > > MBCL-> what class-> what jar I have to look at it again to make sure. Maybe, but only after it's successfully deployed. If the jar is missing, and you don't know what it should be, you're stuck. > > |you are using come from beats autodeploying everything in sight > |and hoping the classes you need are present. > > no it doesn't, clearly doesn't. I don't think you've demonstrated this. > > |2. There is definitely a problem with relying on the autodeployer: > |although everything may all start in the right order due to > |automatically computed dependencies, it doesn't look that way and > |is confusing. My proposed solution for this is a deployment > |script facility, basically a list,"deploy this, now this, now > |this,..." This should make it easy to construct a customized > > which is what the one file achieves implictely. > > |jboss by deploying the appropriate packages, including the ears > |etc for your application. I think this may be an easier to use > |and more flexible solution than the run level idea. > > that could very well be. > > |3. Scoping... I would like every set of deployment descriptors to > |be converted to a single jboss-service.xml file that explictly > |includes security domain/virtual host/classloader information. I > |think this info should be in attributes in the server element. > |So, for instance, for an ejb module, I would combine ejb-jar.xml, > |jaws.xml, and jbosscmp-jdbc.xml into a single jboss-service.xml > |where the module and each ejb is represented by an mbean config > |representing the meta data for that object. This combination is > > There we totaly agree. I think that would be very good. Although we will > find that specifying the services for all the beans will be silly, > combining > the other files would be very good, packaging madness in the spec > > |pretty easy to do with xslt, and would IMHO greatly simplify > |metadata loading and provide alternative "single dd" deployment > |descriptors. It would also provide a place to put the scoping > |info about which classloader to use. > > I will shoot you in the head if you do this, "give the administrator > input > in the class loader". You are a bit like rickard, you are a wizard in > code > no doubt about it and in some "ease of use" instance you are a bit of a > moron :) (no offense really, I called you a rickard ;-) How do you propose specifying which scope/ application a jar/ear/whatever is part of? All I'm saying is this needs to be specified somewhere, why not at the service element. I want it possible for it to be explicit so you can know what is happening. david > > Ok I think I got a pretty good handle on your work, sit back bite some > rope > and let me refactor this, > > "Victor, nettoyeur" > -- Nikita ca.1988 -- > > marcf > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
On 2001.12.06 14:17:46 -0500 Adam Heath wrote:
> On Thu, 6 Dec 2001, David Jencks wrote:
>
> > b. No one has actually divided up the functionality of jboss into
> reasonable
> > independently deployable packages. (maybe this would be an actually
> useful
> > project for that debian packaging guy...???)
If this sounded snide I apologize. You seem pretty good and practiced at
tracking down dependencies and I hate doing it and no one else has done
much to organize the 3.0 service.xml files;-)
For instance, there could
> be a
> > castor-service.xml referencing the castor.jar. Loading castor classes
> if
> > you aren't going to use them is silly.
>
> I have done my debian packaging on the 2.4 branch, waiting for 3.0 to
> become
> at least a beta. To split up the functionality, I created an
> /etc/jboss/conf.d/default/jboss.{conf,jcml}/ structure. Each package
> then
> installs files into one of the above 'fragment' dirs, and the
> configuration
> files in /etc/jboss/conf/default/ get rebuilt from them, when the package
> is
> installed.
>
> I keep the implicit order correct by naming the files with a leading
> number.
> This simulates a dependency chain. 3.0 does this much better.
I certainly hope so;-)))
>
> If one of the config files gets modified, then the jboss server daemon is
> automatically restarted.
>
> 3.0 eliminates the need for some of this, so I know my work will have to
> be
> redone for that. That's fine by me.
>
> Package: jboss
> Package: jboss-server
> Package: jboss-transaction
> Package: jboss-tomcat-service
> Package: jboss-client
> Package: jboss-admin
> Package: jboss-common
> Package: jnp-server
> Package: jnp-client
> Package: jbossmq
> Package: jbossmq-client
> Package: jbosssx
> Package: jbosssx-client
> Package: jboss-contrib-hsqldb
> Package: jboss-contrib-oswego
> Package: jboss-contrib-tyrex
> Package: jboss-contrib-castor
> Package: jboss-contrib
> Package: jboss-dev
> Package: jboss-docs
> Package: jboss-jdbc-postgresql
> Package: jboss-mail
>
> jboss is the package that depends on all the other ones, to give you a
> proper
> server invironment. It does not include any client only support.
>
> jboss-server is the heart of the system. It contains the actual daemon,
> with
> an init script, that starts jboss as a separate user.
>
> jboss-transaction is a separate package, as jboss-contrib-tyrex also
> provides
> the same functionality. You can only have one of these packages
> installed at
> the same time.
>
> jboss-tomcat-service depends on libtomcat-java and libjasper-java(these
> latter
> 2 debs don't exist yet, as I only patched tomcat yesterday to make them).
> The
> plan is to also make a package of jetty(which doesn't yet exist in
> debian),
> and then allow for easy integration of that as well.
>
> jboss-client depends on the other -client packages. These packages
> contain
> the *-client.jars.
>
> jboss-admin contains the untested(at least by me, I have never run it)
> -admin
> stuff.
>
> jnp-server and jboss-server can not be installed at the same time.
> jboss-server has an embedded jnpserver, while jnp-server has it
> standalone.
>
> jbossmq and jbosssx contain their respective code. The names for these
> packages may not be correct. I basically named them after the
> directories
> they occupy in cvs, and the names of their jars.
>
> jboss-contrib-* contains files that are either non-free(jboss-contrib),
> or
> files that should be a completely separate package(jboss-contrib-*).
>
> jboss-dev contains a debian packaging helper script, for those that are
> building debs for debian.
>
> jboss-docs contains the jboss documentation. It doesn't have a lot(no
> api
> docs atm). I need to flesh this out some more.
>
> jboss-jdbc-postgresql depends on postgresql.deb, and enables a
> PostgresqlDS.
> Additionally, both this package and jboss-contrib-hsqldb(which provides a
> HypersonicDS), use debian's alternative mechanism, to provide a
> DefaultDS,
> that points to either one of these(postgres is prefered over hypersonic,
> for
> no particular reason.
How do you select which one you get? This could be interesting;-) we
don't have a systematic way at this point I would say.
>
> jboss-mail depends on libactivation-java and libmail-java, and enables
> mail
> service under jboss.
This looks pretty reasonable to me as a starting point. Not all of these
are deployment units for the server.
>
> > 2. There is definitely a problem with relying on the autodeployer:
> although
> > everything may all start in the right order due to automatically
> computed
> > dependencies, it doesn't look that way and is confusing. My proposed
> > solution for this is a deployment script facility, basically a
> list,"deploy
> > this, now this, now this,..." This should make it easy to construct a
> > customized jboss by deploying the appropriate packages, including the
> ears
> > etc for your application. I think this may be an easier to use and
> more
>
Re: RE: [JBoss-dev] current mbean structure confusing
> Maybe I'm just really braindead here, but in 2.4.x, well, it's the tone that bother me, you sound like me ]:) > MBeans listed after the > AutoDeployer(implicit dependency) did not start until > the AutoDeployer > finished deploying everything. Why was this behavior > changed in 3.0? As far as I know David M was talking about making the mbeans in one file deploy and start together, I think this behavior is still useful, if it has been removed, why don't you put it back? ask david M that was a valid feature. > This is very very useful. Otherwise, mbeans > depending on EJBs and services > deployed by the AutoDeployer will have to list long > lists of MBean refs (is > this correct?) which are hard to maintain. yeah yeah we got it > Mercantec's application receives HTTP requests many > times per second by > hundreds/thousands of different clients. Jetty > should not be able to accept > HTTP requests until JBoss has completely booted up, > and this means all > AutoDeployed components. Otherwise, UI sessions > could come up with errors > in this time interval (2-3 minutes to load all our > beans), or our batched > XML-RPC requests could fail. Then code it biotch :) the fact is that being able to deploy independent services means that you almost must install/conf/start in one batch. Holding the steps in the scope of the PAGE XML being deployed is useful, Code it back, I think it took DavidM one day to code it, You supah man, go > Do you get what I'm saying here? YES, go ahead. David J, please make sure this behavior is still there when he puts it, don't remove that, even for the benefit of your dependency stuff. FUCK a little arbitrage never hurt anyone, aaarg this thread is just getting too long, too tense (although I guess I set the tone) and it is time we finish it. > maintain for a large application. Having implicit > dependencies by MBean > ordering in a file is simple and elegant and easy to > understand. Yes, yes, we agree, it is, if it was removed then bad, if it is then code it again, and flag it as "touch this and I burn your beard david" and basta. David J did relevant work, so stop bitching and fix it. David M you got 30 minutes? > specifying dependencies explicitly is very useful, > but I'm guessing is not > needed for 80% of applications. I wouldn't put down the feature, you have seen enough support here on the list for it, they are largely orthogonal (meaning there was no reason to remove it afaict) and we should really kill this thread once and for all. marcf > > Bill > > Bill > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-dev > lopment __ View: http://jboss.org/forums/thread.jsp?forum=66&thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
> Doesn't AutoDeploy = HotDeploy. You can't hot deploy > unless you autodeploy > it? Is this true? No, but I still agree with your other points, that scoping the create/configuration/init/start should follow page as a simple way to group them. marcf (No you can hot-deploy a service by undeploying the URL and redeploying, hot-deploy means the capacity to deal with new class versions dynamically) __ View: http://jboss.org/forums/thread.jsp?forum=66&thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
> > I know marc is trying to kill off this thread (it > has been going long > > enough) but I know what the story is with this one > so I thought I would > > explain (and give you a solution). I want to kill personal attacks on advanced developers of JBoss, I don't want to kill reasonable feature discussion, in fact I am working on this as we speak I am done with it. > > Sorry to be blunt, but this behavior is just plain > wrong. The AutoDeployer > is deploying something it is dependent on? Not good, > I must say, not good. > You're going to break a lot of 2.4.x applications > with this behavior. And > it is just crazy to have a circular dependency. Get off the high horsey, I solved this problem with 1- page scoping of deployment, meaning if you have N MBeans in the xml page then we create()/start() in lock step (everyone create, then everyone start). 2- do a deployment run in the autodeployer (don't wait for autodeployment but force it in the same thread that does start. > MBeans declared after the autodeployer, or with a > dependency on the > autodeployer should wait until the autodeployer has > finished deploying its > stuff. yep read the above it will be implicit in the thread doing it. > I'm going to change the code. I will commit the above marcf __ View: http://jboss.org/forums/thread.jsp?forum=66&thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
> > I'm going to change the code. > I will commit the above FYI I am done with it, turned out that as I was debugging the new invocation chain/proxy I needed this behavior of the deployer so I fixed it, I will do an "interim" commit of just the deployer logic so we are done with this, I hope this morning marcf __ View: http://jboss.org/forums/thread.jsp?forum=66&thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] current mbean structure confusing
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Monday, December 10, 2001 11:18 AM > To: [EMAIL PROTECTED] > Subject: Re: RE: [JBoss-dev] current mbean structure confusing > > > > > I know marc is trying to kill off this thread (it > > has been going long > > > enough) but I know what the story is with this one > > so I thought I would > > > explain (and give you a solution). > > I want to kill personal attacks on advanced developers of JBoss, > I don't want to kill reasonable feature discussion, in fact I am > working on this as we speak I am done with it. > I hope nobody thinks I was personally attacking anybody. I'm sorry I was combatitive. Its part of my personality. > > > > > Sorry to be blunt, but this behavior is just plain > > wrong. The AutoDeployer > > is deploying something it is dependent on? Not good, > > I must say, not good. > > You're going to break a lot of 2.4.x applications > > with this behavior. And > > it is just crazy to have a circular dependency. > > Get off the high horsey, I solved this problem with Sorry. Too lazy to be diplomatic today. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
