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=66thread=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=66thread=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
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=66thread=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=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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=66thread=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 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
flexible solution than the run level idea.
Computing stuff at runtime is all nice and good, but it is a performance
hit(even if it is only
