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 done at startup). The booting of jboss might be
> better
> if it had a static boot order, and then the auto deploy was enabled after
> all
> of the base jboss started.
>
> The individual service elements could still store their dependencies,
> there
> would just be an external script/program that would order them into a
> static
> boot sequence.
I would prefer to keep all the dependency checking on and have a script
that makes it redundant.
>
> After all, I have read over and over in various docs that a production
> server
> should not have autodeploy of jars, wars, and ears(because of the
> additional
> load), and only development systems should have this functionality
> enabled.
I agree.
david jencks
>
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
