-
1. Re: Towards a canonical server
starksm64 Sep 16, 2008 1:08 PM (in response to starksm64)There is also this related profile service ManagementView does not appear to see the conf/bootstrap.xml and conf/jboss-service.xml deployments and managed objects issue:
https://jira.jboss.org/jira/browse/JBAS-5689 -
2. Re: Towards a canonical server
dmlloyd Sep 17, 2008 1:33 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
The first hurdle is updating the build to produce a repository of jars/deployments, and then properly describing:
- the class dependency requirements for deployments
Are we going to be doing this generally by package or by module? I started doing some of my stuff by package but it seems to me that for (non-JEE) projects which have e.g. an API jar and implementation jar it might be better to have e.g. JBossRemotingAPI as a module, and have the implementation (as well as any user applications) simply depend on that.
Thoughts? -
3. Re: Towards a canonical server
starksm64 Sep 17, 2008 3:02 PM (in response to starksm64)Its going to have to be both. Java modules/osgi bundle type of packages of classes/resources should be declaring their version and dependencies. Then there are the deployments with their metadata/descriptors that would also have dependencies as well as private classes/resources with either no export, or limited export of the deployment classes.
Deployments are also what would be associated with a named profile like minimal, default, all. The standalone jars should just be part of the profile repository, either used or not depending on the named profile dependencies. -
4. Re: Towards a canonical server
starksm64 Sep 17, 2008 9:52 PM (in response to starksm64)I updated http://wiki.jboss.org/wiki/JBossMCProfileServiceBootstrap
and the first issue is that we are bootstrapping a large number of core services and jars in the org.jboss.bootstrap.microcontainer.ServerImpl by loading the bootstrap.xml and its referenced classloader.xml, aop.xml, jmx.xml, deployers.xml, bindings.xml, profile.xml.
Originally the profile service was closer to the bootstrap and the bootstrap deployments came from the profile. I guess we split this up to have more control over the order services are created. At a minimum we would need a new vfs url for the classpaths to allow the jars to come from the profile repository.
If the deployments and their order are also to be part of the profile definition, we would need to get the BootstrapMetaData from the Bootstraps, but those don't exist without loading the profile.xml. Its not a big deal for these to be manageable initially, but what is the long term plan? -
5. Re: Towards a canonical server
adrian.brock Sep 23, 2008 9:09 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
If the deployments and their order are also to be part of the profile definition, we would need to get the BootstrapMetaData from the Bootstraps, but those don't exist without loading the profile.xml. Its not a big deal for these to be manageable initially, but what is the long term plan?
The longer term plan should be to minimise the bootstrap to only what
is required to get a functional profile service.
But things have leaked into the bootstrap because of "bad" dependencies.
The splitting up of the bootstrap files is the first step in indentifying/reducing
these dependencies so they can become more normal parts of the profile.
e.g. all the JMX stuff should be in deployers rather than the bootstrap,
but then you have the problem that the @JMX advice definition is too late in the process
to expose all beans.
aop is in the bootstrap for the same reason. -
6. Re: Towards a canonical server
starksm64 Oct 30, 2008 12:11 PM (in response to starksm64)Since we are not going to get too far on this for the 5.0.0.GA, I want to continue to talk about what the server contents might look like in the canonical distribution paradigm.
The server contents would probably be something like:jboss-5.1/bin jboss-5.1/repository jboss-5.1/server/default/profile.xml jboss-5.1/server/all/profile.xml ...
The repository has deployment bundles, be they library jars or deployer contents, along with metadata about each deployment that includes things like version, capabilities and requirements. See the OSGi OBR spec http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf for an idea of capabilities/requirements.
A profile.xml should actually only be a statement of requirements that are matched up to content in the repository:<profile name="default"> <requirement>ejb3-core</requirement> <requirement>ejb3-ext</requirement> <requirement>ejb2</requirement> <requirement>ejb2</requirement> <requirement>JMS</requirement> <requirement>jmx-console.war</requirement> <requirement>ROOT.war</requirement> <requirement>JSR77 MEJB</requirement> ... </profile>
We may need to include library version range requirements as well for applications that will be added dynamically via hot deploy.