10 Replies Latest reply: Mar 16, 2010 10:39 AM by David Lloyd RSS

Weird dependency error

Ales Justin Master
With the latest MC update I get weird dependency error:

DEPLOYMENTS IN ERROR:
  Deployment "ShortTasksThreadFactory" is in error due to the following reason(s): ** NOT FOUND Depends on 'ShortTasksThreadFactory' **
  Deployment "SystemThreadGroup" is in error due to the following reason(s): ** NOT FOUND Depends on 'SystemThreadGroup' **

which comes from thread-pool-jboss-beans.xml

   <threads xmlns="urn:jboss:threads:2.0">

      <!-- The system thread group for all JBoss threads. -->
      <thread-group name="SystemThreadGroup" group-name="System Threads" daemon="true"/>

      <!-- A simple direct executor which is always available for use. -->
      <direct-executor name="DirectExecutor"/>

      <!--
        ~ This thread pool is for SHORT-RUNNING tasks that block very little or not at all.  Long-running
        ~ tasks submitted to this pool may cause starvation and extended blocking.
        -->
      <thread-group name="ShortTasksThreadGroup" group-name="Short Tasks Threads">
         <parent-thread-group name="SystemThreadGroup"/>
      </thread-group>

      <thread-factory name="ShortTasksThreadFactory">
         <thread-group name="ShortTasksThreadGroup"/>
      </thread-factory>

looking at ThreadsHelper

    static void addMetaData(final List<BeanMetaData> beanMetaDataList, final ThreadGroupMetaData metaData) {
        final String name = metaData.getName();
        final BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(name, ThreadGroup.class.getName());
        final RefMetaData parentRef = metaData.getParentThreadGroup();
        if (parentRef != null) {
            builder.addConstructorParameter(ThreadGroup.class.getName(), builder.createInject(parentRef.getName()));
        }
        final String groupName = metaData.getGroupName();
        builder.addConstructorParameter(String.class.getName(), builder.createValue(groupName != null ? groupName : name));
        if (metaData.isDaemon() != null) {
            builder.addPropertyMetaData("daemon", builder.createValue(metaData.isDaemon()));
        }
        final Integer maxPriorityMeta = metaData.getMaxPriority();
        if (maxPriorityMeta != null) {
            builder.addPropertyMetaData("maxPriority", builder.createValue(maxPriorityMeta));
        }
        builder.ignoreCreate();
        builder.ignoreStart();
        builder.setStop("interrupt");
        builder.ignoreDestroy();
        beanMetaDataList.add(builder.getBeanMetaData());
    }

I don't see where SystemThreadGroup could get any ("self") dependency.

Could this be to new circular dependency handling?

  • 1. Re: Weird dependency error
    Ales Justin Master
    Attaching the AS_trunk patch with MC updates.
  • 2. Re: Weird dependency error
    David Lloyd Master
    Back when I first did the error message cleanup, I noticed that some of the error messages were a bit odd... it might not be a circular dependency.  It might just be an oddity of the error message formatting.
  • 3. Re: Weird dependency error
    Ales Justin Master
    Back when I first did the error message cleanup, I noticed that some of the error messages were a bit odd... it might not be a circular dependency.  It might just be an oddity of the error message formatting.

    It's actually not oddity of the message, although better info should definitely help -- I need to think about this one.

     

    But I did manage to find the true culprit -- it's XB.

    The latest 2.2.0.Beta5 eats the elements in threads-pool-jboss-beans.xml, hence the groups list is half full,

    eventually resulting in missing beans -- which is what the error is actually trying to explain with "NOT FOUND". :-)

     

    It was easy to reproduce this in my MC demos:

    * http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trunk/threads/

  • 4. Re: Weird dependency error
    Ales Justin Master

    But I did manage to find the true culprit -- it's XB.

    -Dxb.builder.repeatableParticleHandlers=false is a workaround

  • 5. Re: Weird dependency error
    Alexey Loubyansky Master

    To elaborate on what's going on.

     

    The property above controls how collection values are populated and set. With the repeatable handlers enabled, collections are first completely filled in and then set on the property. With repeatable handlers disabled, the items are added directly to the property, i.e. myBean.getMyCollection().add(item).

     

    Now what's going in the given case. ThreadsMetaData is bound to a type with model group all and which also contains elements with maxOccurs="unbounded", which is forbidden by the xsd spec.

    So, the binding has to be fixed and the only option here is unordered sequence. But even then, by the original idea, unordered sequence should mean that its particles can appear in no specific order but it doesn't mean that elements with maxOccurs="unbounded" may be spread and mixed with other content, i.e. they are still expected to appear one after the other. Anyway, I'm not gonna enforce that now.

     

    What I'm gonna do is:

    - binding repeatable elements into model group all  should fail https://jira.jboss.org/jira/browse/JBXB-242

    - and don't use repeatable handlers inside unordered sequences

     

    But this alone won't be enough to remove the property. ThreadsMetaData has to be fixed as well.

  • 6. Re: Weird dependency error
    David Lloyd Master

    alex.loubyansky@jboss.com wrote:

     

    Now what's going in the given case. ThreadsMetaData is bound to a type with model group all and which also contains elements with maxOccurs="unbounded", which is forbidden by the xsd spec.

    So, the binding has to be fixed and the only option here is unordered sequence.

    To put it in terms that we JAXB-haters can understand: if you want an unbounded choice, you can't have separate collections for each possible child element because then the marshaller (which we don't presently use) can't possibly reconstitute the elements in the same order from your object model.  You're basically stuck with having a List of Objects.  Hooray.

     

    Of course at this stage we're not in much better shape than if we'd just used DOM in the first place.

  • 7. Re: Weird dependency error
    Jason Greene Master

    david.lloyd@jboss.com wrote:

     

    alex.loubyansky@jboss.com wrote:

     

    Now what's going in the given case. ThreadsMetaData is bound to a type with model group all and which also contains elements with maxOccurs="unbounded", which is forbidden by the xsd spec.

    So, the binding has to be fixed and the only option here is unordered sequence.

    To put it in terms that we JAXB-haters can understand: if you want an unbounded choice, you can't have separate collections for each possible child element because then the marshaller (which we don't presently use) can't possibly reconstitute the elements in the same order from your object model.  You're basically stuck with having a List of Objects.  Hooray.

     

    Of course at this stage we're not in much better shape than if we'd just used DOM in the first place.

     

    Note that schema 1.1 fixes this spec deficiency.

  • 8. Re: Weird dependency error
    David Lloyd Master

    Just to confirm, running "xjc" on the threads schema unsurprisingly yields classes consisting mainly of "List<Object>" and "List<JAXBElement<?>>" and so on.

     

    Why are we using JAXB again? 

  • 9. Re: Weird dependency error
    Alexey Loubyansky Master

    Use unordered sequences for this. Don't they solve your problem?

    But if you are using spec constructs then you are expected to comply with the spec.

  • 10. Re: Weird dependency error
    David Lloyd Master

    Translation: use @JBossXmlModelGroup(kind=JBossXmlConstants.MODEL_GROUP_UNORDERED_SEQUENCE) !

     

    I think I will.  Still means another release of two to four components though, so give me a few days.