The location of the jboss-service.xml doesn't appear to make a difference.  Step-debugging through the MBean's start() method, it looks like the TCCL is set in such a way that I don't have a chance of getting at my deployment's resources.  Specifically:

public void start() throws Exception {

  // ...

  final ClassLoader loader = Thread.currentThread().getContextClassLoader();

  URL loginConfig = loader.getResource(...);

  // ...

}

Inspecting loader at this point gives:

  ModuleClassLoader for Module "ucs.jb4compat:main" from local module loader @23e8f4e1 (roots: /opt/software/sag/sag_dev/modules)

IE the TCCL is the module's ClassLoader, not that of the EAR deployment.  To the best of my knowledge, I don't have any EAR classes available at that point from which I could grab an appropriate ClassLoader.

Looking up the stack a bit, I see:

// org.jboss.as.service.AbstractService:

protected void invokeLifecycleMethod(final Method method) throws InvocationTargetException, IllegalAccessException {

        if (method != null) {

            final ClassLoader old = SecurityActions.setThreadContextClassLoader(mBeanInstance.getClass().getClassLoader());

            try {

                method.invoke(mBeanInstance);

            } finally {

                SecurityActions.resetThreadContextClassLoader(old);

            }

        }

    }

Which appears to stash the TCCL at that point and explicictly set it to the MBean's ClassLoader.  The stashed TCCL (old) at that point is "ModuleClassLoader for Module "org.jboss.as.sar:main" from local module loader @23e8f4e1 (roots: /opt/software/sag/sag_dev/modules)".

I've tried repackaging my resource (login-config.xml) inside the ear as ear//lib/config.sar//META-INF/login-config.xml as well as ear//lib/config.sar//login-config.xml, but none of the ClassLoader's I have available within the MBean's start() method are anything related to my EAR or its contents.

On a side note, I realize root-of EAR isn't expected to be in Classpath per EE spec, but I thought that contents of EAR/META-INF should be.  So in this case EAR/META-INF/login-config.xml would be equally accessible as EAR/lib/config.jar//META-INF/login-config.xml, assuming I had a ClassLoader with a view of the EAR.  Is that incorrect?  Granted the distinction is moot unless I can find an appropriate ClassLoader to pull from.

Just by way of structure, here's what I'm working with at the moment:

The EAR:

/Work/ExactlyWatt/java/dist/server/deployments $ unzip -l ExactlyWatt.ear

Archive:  ExactlyWatt.ear

  Length     Date   Time    Name

--------    ----   ----    ----

        0  09-25-12 09:33   META-INF/

      106  09-25-12 09:33   META-INF/MANIFEST.MF

        0  09-25-12 09:33   lib/

11378038  09-25-12 09:33   ExactlyWatt.war

    55168  09-25-12 09:33   ExactlyWatt_ejb.jar

...

      866  09-25-12 09:33   lib/config.jar (See below)

...

    40161  09-25-12 09:33   lib/ydoclet-runtime.jar

      568  09-25-12 09:32   META-INF/application.xml

     1137  09-21-12 15:12   META-INF/exactlywatt-ds.xml

     1050  09-24-12 15:26   META-INF/jboss-service.xml

config.jar within EAR/lib:

/Work/ExactlyWatt/java/dist/server/deployments/ear $ unzip -l lib/config.jar

Archive:  lib/config.jar

   Length     Date   Time    Name

  --------    ----   ----    ----

         0  09-25-12 09:33   META-INF/

       106  09-25-12 09:33   META-INF/MANIFEST.MF

       936  06-23-11 13:22   META-INF/login-config.xml

  --------                   -------

      1042                   3 files

EAR/META-INF/jboss-service.xml:

/Work/ExactlyWatt/java/dist/server/deployments/ear $ cat META-INF/jboss-service.xml

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

<server xmlns="urn:jboss:service:7.0"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="urn:jboss:service:7.0 http://ucmsload.courtnet.org/dtds/jb7/jboss-service_7_0.xsd">

  <!-- Note this MBean deploys & works properly.  It's accessing files on-disk in standalone/configuration rather than trying to pull from classloader.  -->

  <mbean code="ucs.jb4compat.SystemPropertiesService" name="jboss.util:type=Service,name=SystemProperties-ExactlyWatt">

    <attribute name="URLList">configuration/exactlywatt.properties</attribute>

  </mbean>

  <mbean code="ucs.jb4compat.DynamicLoginConfig" name="sample-app:service=DynamicLoginConfig,domain=ExactlyWatt">

    <!-- With or without "META-INF/" here makes no difference. -->

    <attribute name="AuthConfig">META-INF/login-config.xml</attribute>

    <depends>jboss.util:type=Service,name=SystemProperties-ExactlyWatt</depends>

  </mbean>

</server>

/Work/ExactlyWatt/java/dist/server/deployments/ear $ cat META-INF/application.xml

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

<application xmlns="http://java.sun.com/xml/ns/javaee"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://ucmsload.courtnet.org/dtds/javaee/application_6.xsd"

  version="6">

  <description>ExactlyWatt Jar Index</description>

  <display-name>ExactlyWatt</display-name>

  <module><ejb>ExactlyWatt_ejb.jar</ejb></module>

  <module>

      <web>

         <web-uri>ExactlyWatt.war</web-uri>

         <context-root>/ExactlyWatt</context-root>

       </web>

  </module>

</application>

Note this particular attempt has jboss-service.xml directly in EAR//META-INF without a SAR file to wrap it.  If I change things to put jboss-service.xml inside EAR//config.sar//META-INF and add EAR//META-INF/jboss-app.xml with a <module><service>config.sar</service></module> and application.xml with <module><java>config.sar</java></module>, it makes no difference on any of this.  I still get the module's ClassLoader for TCCL in the MBean's start() method and have no access to the EAR deployment's contents.

I have a minimal test project that reproduces this in two classes & a few XML's.  About 3KB total tarballed w/ an Ant script to build it & configured a JBoss instance.  Shall I file a JIRA ticket?

Opened:

https://issues.jboss.org/browse/AS7-5630

Thanks,

Zac