This was due to also removing the org.jboss.web.WebService dyn class loading service:

18:22:16,979 WARN [HDScanner] Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}

jboss.j2ee:module="cts.jar",service=EjbModule
 -> jboss:service=WebService{Create:** NOT FOUND Depends on 'jboss:service=WebService' **}

The tests are working against the default config after that change, but still fail against all due to an iiop-service.xml naming dependnecy failure:

*** CONTEXTS IN ERROR: Name -> Error

vfsfile:/Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.GA/server/all/deploy/iiop-service.xml -> java.net.SocketTimeoutException: Receive timed out

<?xml version="1.0" encoding="UTF-8"?>

<!-- $Id: jboss-service.xml 77499 2008-08-26 18:38:57Z dimitris@jboss.org $ -->

<!-- ===================================================================== -->
<!-- JBoss Server Configuration -->
<!-- ===================================================================== -->

<server>

 <!-- Load all jars from the JBOSS_DIST/server/<config>/lib directory. This
 can be restricted to specific jars by specifying them in the archives
 attribute.
 -->
 <classpath codebase="${jboss.server.lib.url:lib}" archives="*"/>

 <!-- ==================================================================== -->
 <!-- Main Deployer -->
 <!-- ==================================================================== -->
 <mbean code="org.jboss.deployment.MainDeployer"
 name="jboss.system:service=MainDeployer">
 <!-- This is used to delegate the deployment handling -->
 <attribute name="KernelMainDeployer"><inject bean="MainDeployer" /></attribute>
 <!-- This is used to validate incomplete deployments -->
 <attribute name="Controller"><inject bean="jboss.kernel:service=Kernel" property="controller"/></attribute>
 </mbean>

 <!-- ==================================================================== -->
 <!-- SAR Deployer -->
 <!-- ==================================================================== -->
 <mbean code="org.jboss.deployment.SARDeployer"
 name="jboss.system:service=ServiceDeployer">
 <depends>jboss.system:service=MainDeployer</depends>
 </mbean>

 <!-- ==================================================================== -->
 <!-- XMBean Persistence -->
 <!-- ==================================================================== -->
 <mbean code="org.jboss.system.pm.AttributePersistenceService"
 name="jboss:service=AttributePersistenceService"
 xmbean-dd="resource:xmdesc/AttributePersistenceService-xmbean.xml">
 <!-- the AttributePersistenceService is persistent, itself -->

 <!--
 <attribute name="AttributePersistenceManagerClass">org.jboss.system.pm.XMLAttributePersistenceManager</attribute>
 <attribute name="AttributePersistenceManagerConfig">
 <data-directory>data/xmbean-attrs</data-directory>
 </attribute>
 <attribute name="ApmDestroyOnServiceStop">false</attribute>
 <attribute name="VersionTag"></attribute>
 -->
 </mbean>

 <!-- A Thread pool service -->
 <mbean code="org.jboss.util.threadpool.BasicThreadPool"
 name="jboss.system:service=ThreadPool">
 <attribute name="Name">JBoss System Threads</attribute>
 <attribute name="ThreadGroupName">System Threads</attribute>
 <!-- How long a thread will live without any tasks in MS -->
 <attribute name="KeepAliveTime">60000</attribute>
 <!-- The max number of threads in the pool -->
 <attribute name="MaximumPoolSize">10</attribute>
 <!-- The max number of tasks before the queue is full -->
 <attribute name="MaximumQueueSize">1000</attribute>
 <!-- The behavior of the pool when a task is added and the queue is full.
 abort - a RuntimeException is thrown
 run - the calling thread executes the task
 wait - the calling thread blocks until the queue has room
 discard - the task is silently discarded without being run
 discardOldest - check to see if a task is about to complete and enque
 the new task if possible, else run the task in the calling thread
 -->
 <attribute name="BlockingMode">run</attribute>
 </mbean>


 <!-- ==================================================================== -->
 <!-- JBoss RMI Classloader - only install when available -->
 <!-- ==================================================================== -->
 <mbean code="org.jboss.util.property.jmx.SystemPropertyClassValue"
 name="jboss.rmi:type=RMIClassLoader">
 <attribute name="Property">java.rmi.server.RMIClassLoaderSpi</attribute>
 <attribute name="ClassName">org.jboss.system.JBossRMIClassLoader</attribute>
 </mbean>

 <!-- ==================================================================== -->
 <!-- JNDI -->
 <!-- ==================================================================== -->

 <!-- A simple mbean wrapper around the jndi Naming object. This
 only handles an in memory instance. The NamingService uses this
 as the JNDI store and exposes it remotely.
 -->
 <mbean code="org.jnp.server.NamingBeanImpl"
 name="jboss:service=NamingBeanImpl"
 xmbean-dd="resource:xmdesc/NamingBean-xmbean.xml">
 </mbean>

 <mbean code="org.jboss.naming.NamingService"
 name="jboss:service=Naming"
 xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
 <!-- The call by value mode. true if all lookups are unmarshalled using
 the caller's TCL, false if in VM lookups return the value by reference.
 -->
 <attribute name="CallByValue">false</attribute>

 <!-- The listening port for the bootstrap JNP service. Set this to -1
 to run the NamingService without the JNP invoker listening port.
 -->
 <attribute name="Port">
 <value-factory bean="ServiceBindingManager" method="getIntBinding">
 <parameter>jboss:service=Naming</parameter>
 <parameter>Port</parameter>
 </value-factory>
 </attribute>

 <!-- The bootstrap JNP server bind address. This also sets the default
 RMI service bind address. Empty == all addresses
 -->
 <attribute name="BindAddress">${jboss.bind.address}</attribute>
 <!-- The port of the RMI naming service, 0 == anonymous -->
 <attribute name="RmiPort">
 <value-factory bean="ServiceBindingManager" method="getIntBinding">
 <parameter>jboss:service=Naming</parameter>
 <parameter>RmiPort</parameter>
 </value-factory>
 </attribute>
 <!-- The RMI service bind address. Empty == all addresses
 -->
 <attribute name="RmiBindAddress">${jboss.bind.address}</attribute>
 <!-- The thread pool service used to control the bootstrap lookups -->
 <depends optional-attribute-name="LookupPool"
 proxy-type="attribute">jboss.system:service=ThreadPool</depends>
 <!-- An example of using the unifed invoker as the transport.
 <depends optional-attribute-name="InvokerProxyFactory"
 proxy-type="attribute">jboss:service=proxyFactory,type=unified,target=Naming</depends>
 -->
 <depends optional-attribute-name="Naming"
 proxy-type="attribute">jboss:service=NamingBeanImpl</depends>
 </mbean>

 <mbean code="org.jboss.naming.JNDIView"
 name="jboss:service=JNDIView"
 xmbean-dd="resource:xmdesc/JNDIView-xmbean.xml">
 <!-- The HANamingService service name -->
 <attribute name="HANamingService">jboss:service=HAJNDI</attribute>
 </mbean>

 <!-- ==================================================================== -->
 <!-- Security -->
 <!-- ==================================================================== -->

 <!-- JAAS security manager and realm mapping -->
 <mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
 name="jboss.security:service=JaasSecurityManager">
 <!-- A flag which indicates whether the SecurityAssociation server mode
 is set on service creation. This is true by default since the
 SecurityAssociation should be thread local for multi-threaded server
 operation.
 -->
 <attribute name="ServerMode">true</attribute>
 <attribute name="SecurityManagerClassName">org.jboss.security.plugins.JaasSecurityManager</attribute>
 <attribute name="DefaultUnauthenticatedPrincipal">anonymous</attribute>
 <!-- DefaultCacheTimeout: Specifies the default timed cache policy timeout
 in seconds.
 If you want to disable caching of security credentials, set this to 0 to
 force authentication to occur every time. This has no affect if the
 AuthenticationCacheJndiName has been changed from the default value.
 -->
 <attribute name="DefaultCacheTimeout">1800</attribute>
 <!-- DefaultCacheResolution: Specifies the default timed cache policy
 resolution in seconds. This controls the interval at which the cache
 current timestamp is updated and should be less than the DefaultCacheTimeout
 in order for the timeout to be meaningful. This has no affect if the
 AuthenticationCacheJndiName has been changed from the default value.
 -->
 <attribute name="DefaultCacheResolution">60</attribute>
 <!-- DeepCopySubjectMode: This set the copy mode of subjects done by the
 security managers to be deep copies that makes copies of the subject
 principals and credentials if they are cloneable. It should be set to
 true if subject include mutable content that can be corrupted when
 multiple threads have the same identity and cache flushes/logout clearing
 the subject in one thread results in subject references affecting other
 threads.
 -->
 <attribute name="DeepCopySubjectMode">false</attribute>
 </mbean>

 <!-- ==================================================================== -->
 <!-- Remoting services -->
 <!-- ==================================================================== -->

 <!-- For detailed description of all these configuration attributes, please see the -->
 <!-- JBoss Remoting User's Guide or wiki (http://www.jboss.org/wiki/Wiki.jsp?page=Remoting_configuration) -->

 <!-- The NetworkRegistry contains all the local and remote -->
 <!-- servers that it recognizes. The remote ones registered -->
 <!-- are dependant on the detectors running and which domains -->
 <!-- they are configured to identify. -->
 <mbean code="org.jboss.remoting.network.NetworkRegistry"
 name="jboss.remoting:service=NetworkRegistry"/>

 <!-- The Connector is the core component of the remoting server service. -->
 <!-- It binds the remoting invoker (transport protocol, callback configuration, -->
 <!-- data marshalling, etc.) with the invocation handlers. -->
 <mbean code="org.jboss.remoting.transport.Connector"
 name="jboss.remoting:service=Connector,transport=socket"
 display-name="Socket transport Connector">

 <!-- Can either just specify the InvokerLocator attribute and not the invoker element in the -->
 <!-- Configuration attribute, or do the full invoker configuration in the in invoker element -->
 <!-- of the Configuration attribute. -->

 <!-- Remember that if you do use more than one param on the uri, will have to include as a CDATA, -->
 <!-- otherwise, parser will complain. -->
 <!--
 <attribute name="InvokerLocator">
 <value-factory bean="ServiceBindingManager" method="getStringBinding">
 <parameter>jboss.remoting:service=Connector,transport=socket</parameter>
 <parameter><![CDATA[socket://${host}:${port}/?datatype=invocation]]></parameter>
 </value-factory>
 </attribute>
 -->

 <attribute name="Configuration">
 <!-- Using the following <invoker> element instead of the InvokerLocator above because specific attributes needed. -->
 <!-- If wanted to use any of the parameters below, can just add them as parameters to the url above if wanted use the InvokerLocator attribute. -->

 <value-factory bean="ServiceBindingManager" method="getElementBinding">
 <parameter>jboss.remoting:service=Connector,transport=socket</parameter>
 <parameter><![CDATA[
 <config>
 <!-- Other than transport type and handler, none of these configurations are required (will just use defaults). -->
 <invoker transport="socket">
 <attribute name="dataType" isParam="true">invocation</attribute>
 <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute>
 <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute>
 <!-- This will be port on which the marshall loader port runs on. -->
 <!-- <attribute name="loaderport" isParam="true">4447</attribute> -->
 <!-- The following are specific to socket invoker -->
 <!-- <attribute name="numAcceptThreads">1</attribute>-->
 <!-- <attribute name="maxPoolSize">303</attribute>-->
 <!-- <attribute name="clientMaxPoolSize" isParam="true">304</attribute>-->
 <!-- <attribute name="timeout" isParam="true">600000</attribute>-->
 <attribute name="serverBindAddress">${host}</attribute>
 <attribute name="serverBindPort">${port}</attribute>
 <!-- <attribute name="clientConnectAddress">216.23.33.2</attribute> -->
 <!-- <attribute name="clientConnectPort">7777</attribute> -->
 <attribute name="enableTcpNoDelay" isParam="true">true</attribute>
 <!-- <attribute name="backlog">200</attribute>-->
 <!-- The following is for callback configuration and is independant of invoker type -->
 <!-- <attribute name="callbackMemCeiling">30</attribute>-->
 <!-- indicates callback store by fully qualified class name -->
 <!-- <attribute name="callbackStore">org.jboss.remoting.CallbackStore</attribute>-->
 <!-- indicates callback store by object name -->
 <!-- <attribute name="callbackStore">jboss.remoting:service=CallbackStore,type=Serializable</attribute> -->
 <!-- config params for callback store. if were declaring callback store via object name, -->
 <!-- could have specified these config params there. -->
 <!-- StoreFilePath indicates to which directory to write the callback objects. -->
 <!-- The default value is the property value of 'jboss.server.data.dir' and if this is not set, -->
 <!-- then will be 'data'. Will then append 'remoting' and the callback client's session id. -->
 <!-- An example would be 'data\remoting\5c4o05l-9jijyx-e5b6xyph-1-e5b6xyph-2'. -->
 <!-- <attribute name="StoreFilePath">callback</attribute>-->
 <!-- StoreFileSuffix indicates the file suffix to use for the callback objects written to disk. -->
 <!-- The default value for file suffix is 'ser'. -->
 <!-- <attribute name="StoreFileSuffix">cst</attribute>-->
 </invoker>

 <!-- At least one handler is required by the connector. If have more than one, must decalre -->
 <!-- different subsystem values. Otherwise, all invocations will be routed to the only one -->
 <!-- that is declared. -->
 <handlers>
 <!-- The JSR88 deployment service StreamingTarget handler -->
 <handler subsystem="JSR88">org.jboss.deployment.remoting.DeployHandler</handler>
 </handlers>
 </config>
 ]]>
 </parameter>
 </value-factory>
 </attribute>
 <depends>jboss.remoting:service=NetworkRegistry</depends>
 </mbean>


 <!-- <mbean code="org.jboss.remoting.detection.jndi.JNDIDetector"-->
 <!-- name="jboss.remoting:service=Detector,transport=jndi">-->
 <!-- host to which the detector will connect to for the JNDI server. -->
 <!-- <attribute name="Host">localhost</attribute>-->
 <!-- port to which detector will connect to for the JNDI server. -->
 <!-- <attribute name="Port">5555</attribute>-->
 <!-- context factory string used when connecting to the JNDI server. -->
 <!-- The default is org.jnp.interfaces.NamingContextFactory. -->
 <!-- <attribute name="ContextFactory">org.acme.NamingContextFactory</attribute> -->
 <!-- url package string to use when connecting to the JNDI server. -->
 <!-- The default is org.jboss.naming:org.jnp.interfaces. -->
 <!-- <attribute name="URLPackage">org.acme.naming</attribute> -->
 <!-- Sets the number of detection iterations before manually pinging -->
 <!-- remote server to make sure still alive. This is needed since remote server -->
 <!-- could crash and yet still have an entry in the JNDI server, -->
 <!-- thus making it appear that it is still there. The default value is 5. -->
 <!-- <attribute name="CleanDetectionNumber">20</attribute>-->

 <!-- Specifies the domains in which the detector will recognize -->
 <!-- detections. If servers are not configured to be in these -->
 <!-- domains, they will not be added to NetworkRegistry. -->
 <!-- <attribute name="Configuration">-->
 <!-- <domains>-->
 <!-- <domain>roxanne</domain>-->
 <!-- <domain>sparky</domain>-->
 <!-- </domains>-->
 <!-- </attribute>-->
 <!-- </mbean>-->

 <!-- ==================================================================== -->
 <!-- Monitoring and Management -->
 <!-- ==================================================================== -->

 <!-- Uncomment to enable JMX monitoring of the bean cache
 <mbean code="org.jboss.monitor.BeanCacheMonitor"
 name="jboss.monitor:name=BeanCacheMonitor"/>
 -->

 <!-- Uncomment to enable JMX monitoring of the entity bean locking
 <mbean code="org.jboss.monitor.EntityLockMonitor"
 name="jboss.monitor:name=EntityLockMonitor"/>
 -->

 <!-- ==================================================================== -->
 <!-- An MBean that is a registry for JDBC type-mapping metadata -->
 <!-- ==================================================================== -->

 <mbean code="org.jboss.ejb.plugins.cmp.jdbc.metadata.MetaDataLibrary"
 name="jboss.jdbc:service=metadata"/>

</server>

I have this working with the naming beans in a naming-jboss-beans.xml and the legacy-conf-service.xml. I'm looking through the current https://svn.jboss.org/repos/jbossas/projects/docs/community/5/Installation_And_Getting_Started_Guide/ and we have a lot to update if we are going to restructure conf, possibly including moving out some of the bootstrap beans files as well.

I want to focus on this again to get the conf/jboss-service.xml removed from trunk asap.

As an extension to the JBNAME-37 change, setup of the java:comp env really should be a separate bean because creation of the InitialContext to create the java:comp binding can depend on a bean which implements InitialContextFactory or otherwise creates the IntitialContext that should be used. Carlo already alludes to this in JBNAME-37.

So, I want to remove the java:comp creation from the NamingBeanImpl and just have a simple bean(s) provide this binding.

I have the naming service, and in fact all services moved out of the conf/jboss-service.xml, but I see DML is working on this as issue JBAS-6948. Once I clarify what his status is I can figure out how to commit the changes to trunk.

I just commited the initial change where all services have been moved out of conf/jboss-service.xml as the smoke-tests are passing. This bootstrap descriptor is still needed for the bootstrap class loader. To completely remove conf/jboss-service.xml, the bootstrap class loader configuration also needs to be moved into the profile. JBAS-7469 is tracking this and I'll start a separate thread on that.

The services in conf/jboss-service.xml have been moved into:

deployers/core-naming-jboss-beans.xml - the basic bean and remote access bean
deploy/naming-jboss-beans.xml - legacy mbean wrapper and jndi view (which needs updating)
deploy/legacy-conf-service.xml

I think there is more work to make the naming service more usable as a mcbean such as moving the remoting piece from deployers/core-naming-jboss-beans.xml to deploy/naming-jboss-beans.xml and making better use of the remoting v3 for the remoting proxy. I'm going to look at what the requirements from the embedded usecases were before doing anything along these lines.

Both standard and web are now booting. The conf/jboss-service.xml has been stripped down to just the class loading in these profiles.