12 Replies Latest reply on Nov 25, 2009 4:02 AM by starksm64

    Getting rid of conf/jboss-service.xml

    starksm64

      https://jira.jboss.org/jira/browse/JBAS-4814

      I have the server booting with a conf/jboss-service.xml just including the Log4jService, and all other services moved to a deploy/legacy-conf-service.xml.

      The only change needed for this was to move the injection of the security mgr service out of the deployer into the deploy/jbossweb.sar. Serveral smoke tests are failing due to jndi issues though, so still need to look into that.

        • 1. Re: Getting rid of conf/jboss-service.xml
          starksm64

          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' **}
          


          This should be an optional dependency from the ejb container. I'll restore it for now.


          • 2. Re: Getting rid of conf/jboss-service.xml
            starksm64

            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
            

            I fixed this as JBAS-5997, and now all of the smoke tests are passing. We need to talk about what legacy services are needed, if they should be moved to a separate beans/service.xml, etc.

            <?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>
            


            • 3. Re: Getting rid of conf/jboss-service.xml
              starksm64

              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.

              • 4. Re: Getting rid of conf/jboss-service.xml
                wolfc

                While working on RELOADED-9 (JavaEE 6 JNDI namespaces) I've made the initialization of java:comp optional in NamingBeanImpl (JBNAME-37).
                Now I'm bringing this to AS, but whatever happened to naming-jboss-beans.xml?
                The naming service is still in jboss-service.xml. Are we going to keep it that way, or is this going to be expedited?

                • 5. Re: Getting rid of conf/jboss-service.xml
                  emuckenhuber

                   

                  "wolfc" wrote:
                  While working on RELOADED-9 (JavaEE 6 JNDI namespaces) I've made the initialization of java:comp optional in NamingBeanImpl (JBNAME-37).
                  Now I'm bringing this to AS, but whatever happened to naming-jboss-beans.xml?
                  The naming service is still in jboss-service.xml. Are we going to keep it that way, or is this going to be expedited?


                  The change has been rolled back, as there were too many regressions. However for AS6 the plan is to get rid of jboss-service.xml, but i can't tell you in which timeframe :)

                  • 6. Re: Getting rid of conf/jboss-service.xml
                    starksm64

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

                    • 7. Re: Getting rid of conf/jboss-service.xml
                      starksm64

                      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.

                      • 8. Re: Getting rid of conf/jboss-service.xml
                        wolfc

                        The component I want to use for installing java:comp is here: http://anonsvn.jboss.org/repos/jbossas/projects/reloaded/trunk/naming/src/main/java/org/jboss/reloaded/naming/service/NameSpaces.java

                        When this is properly integrated I want to expand it to install java:module & java:app as well.

                        https://jira.jboss.org/jira/browse/RELOADED-9

                        • 9. Re: Getting rid of conf/jboss-service.xml
                          starksm64

                          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.

                          • 10. Re: Getting rid of conf/jboss-service.xml
                            starksm64

                            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.

                            • 11. Re: Getting rid of conf/jboss-service.xml
                              shelly.mcgowan

                              With these changes, the 'standard' and 'web' configs fail to boot. The conf/jboss-service.xml files for these configs contains more than what's defined in https://jira.jboss.org/jira/browse/JBAS-7469. 'default' and 'all' configs start fine.
                              The standard config fails to boot with:

                              2009-11-19 12:14:23,281 INFO [org.jboss.system.server.profileservice.ProfileServiceBootstrap] (Thread-2) Loading profile: ProfileKey@1f1ad4a[domain=default, server=default, name=standard]
                              2009-11-19 12:14:23,281 DEBUG [org.jboss.system.server.profileservice.repository.AbstractProfileService] (Thread-2) Activating profile: NoopProfile@c7bf90{key = ProfileKey@1f1ad4a[domain=default, server=default, name=standard]}
                              2009-11-19 12:14:23,317 ERROR [org.jboss.system.server.profileservice.ProfileServiceBootstrap] (Thread-2) Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
                              
                              DEPLOYMENTS MISSING DEPENDENCIES:
                               Deployment "NamingService" is missing the following dependencies:
                               Dependency "RemoteNamingBean" (should be in state "Configured", but is actually in state "**ERROR**")
                               Deployment "jboss.jmx:alias=jmx/rmi/RMIAdaptor" is missing the following dependencies:
                               Dependency "jboss:service=Naming" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss:service=Naming' **")
                               Deployment "jboss.jmx:name=Invoker,protocol=jrmp,service=proxyFactory,type=adaptor" is missing the following dependencies:
                               Dependency "jboss:service=Naming" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss:service=Naming' **")
                               Deployment "jboss.jmx:name=MBeanProxyRemote,protocol=jrmp,type=adaptor" is missing the following dependencies:
                               Dependency "jboss.jmx:name=Invoker,protocol=jrmp,service=proxyFactory,type=adaptor" (should be in state "Create", but is actually in state "Configured")
                               Deployment "jboss:service=CorbaNaming" is missing the following dependencies:
                               Dependency "jboss:service=Naming" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss:service=Naming' **")
                               Deployment "jboss:service=KeyGeneratorFactory,type=UUID" is missing the following dependencies:
                               Dependency "jboss:service=Naming" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss:service=Naming' **")
                               Deployment "jboss:service=Mail" is missing the following dependencies:
                               Dependency "jboss:service=Naming" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss:service=Naming' **")
                               Deployment "jboss:service=NamingProviderURLWriter" is missing the following dependencies:
                               Dependency "jboss:service=Naming" (should be in state "Configured", but is actually in state "** NOT FOUND Depends on 'jboss:service=Naming' **")
                               Dependency "jboss:service=Naming" (should be in state "Configured", but is actually in state "** NOT FOUND Depends on 'jboss:service=Naming' **")
                               Deployment "jboss:service=invoker,type=iiop" is missing the following dependencies:
                               Dependency "jboss:service=Naming" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss:service=Naming' **")
                              
                              DEPLOYMENTS IN ERROR:
                               Deployment "jboss:service=Naming" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss:service=Naming' **
                               Deployment "JndiViewBean" is in error due to the following reason(s): javax.management.InstanceAlreadyExistsException: jboss:service=JNDIView already registered.
                               Deployment "RemoteNamingBean" is in error due to the following reason(s): javax.management.InstanceAlreadyExistsException: jboss:service=Naming already registered., **ERROR**
                              


                              and the web config:
                              13:59:01,245 INFO [ProfileServiceBootstrap] Loading profile: ProfileKey@1ff8de3[domain=default, server=default, name=web]
                              13:59:01,245 DEBUG [AbstractProfileService] Activating profile: NoopProfile@17ccb2f{key = ProfileKey@1ff8de3[domain=default, server=default, name=web]}
                              13:59:01,248 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
                              
                              DEPLOYMENTS MISSING DEPENDENCIES:
                               Deployment "WebServer" is missing the following dependencies:
                               Dependency "jboss.security:service=JaasSecurityManager" (should be in state "Configured", but is actually in state "** NOT FOUND Depends on 'jboss.security:service=JaasSecurityManager' **")
                               Deployment "jboss.jca:name=DefaultDS,service=DataSourceBinding" is missing the following dependencies:
                               Dependency "jboss.jca:name=DefaultDS,service=LocalTxCM" (should be in state "Create", but is actually in state "Configured")
                               Deployment "jboss.jca:name=DefaultDS,service=LocalTxCM" is missing the following dependencies:
                               Dependency "jboss.security:service=JaasSecurityManager" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss.security:service=JaasSecurityManager' **")
                               Deployment "jboss.jdbc:datasource=DefaultDS,service=metadata" is missing the following dependencies:
                               Dependency "jboss.jdbc:service=metadata" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss.jdbc:service=metadata' **")
                               Deployment "jboss.web.deployment:war=/ROOT" is missing the following dependencies:
                               Dependency "jboss.web:service=WebServer" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss.web:service=WebServer' **")
                               Deployment "jboss.web.deployment:war=/invoker" is missing the following dependencies:
                               Dependency "jboss.web:service=WebServer" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss.web:service=WebServer' **")
                               Deployment "jboss.web.deployment:war=/jmx-console" is missing the following dependencies:
                               Dependency "jboss.web:service=WebServer" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss.web:service=WebServer' **")
                              
                              DEPLOYMENTS IN ERROR:
                               Deployment "jboss.security:service=JaasSecurityManager" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss.security:service=JaasSecurityManager' **
                               Deployment "jboss.jdbc:service=metadata" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss.jdbc:service=metadata' **
                               Deployment "jboss.web:service=WebServer" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss.web:service=WebServer' **
                              
                              


                              Another issue seen is that minimal fails to shutdown as part of the jboss-minimal-tests target but that may require changes. Is there still work being done for these configs?

                              • 12. Re: Getting rid of conf/jboss-service.xml
                                starksm64

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