简体   繁体   中英

Eclipse cannot resolve composite component attribute of abstract class type

The code seems to work even though Eclipse is marking the line #{cc.attrs.bolt.spec.size} in the bolt_component.xhtml as the property cannot be resolved for spec.size

bolt_component.xhtml

<composite:attribute name="bolt" type="model.bolts.Bolt" />
#{cc.attrs.bolt.spec.size}

my abstract class

public abstract class Bolt implements Serializable {
protected BoltSpec spec;
    I have setSpec()
    but not a getSpec()

and the concrete class

public class BoltHexHead extends Bolt implements Serializable {

private static final long serialVersionUID = 1L;
private BoltSpecHexHead spec;

public BoltSpecHexHead getSpec() {
    return spec;
}
public void setSpec(BoltSpecHexHead spec) {
    this.spec = spec;
    super.setSpec(spec);
}

I realize why Eclipse is flagging because I don't have a getSpec() but when I add getSpec in Bolt I get a null pointer in my controller which uses the HexHeadBolt .getSpec() turns out to be null when it should not be.

if (analysisHexHeadWithNutOperational.getBolt().getSpec().getSize() == null) {

I've tried multitude of combinations of getters setters private protected, etc...

Is the flagging by Eclipse a bug? Or do I have my inheritance set up incorrectly I'm using Luna

EDIT

added screenshot showing even with cleaner DRY code, using parameterized property, Eclipses still flags "size" cannot be resolved, but only in the custom component 在此处输入图片说明

EDIT2

by adding spec to cc interface I can get Eclipse to stop flagging

faclet

<stk:bolt_component boltTypes="#{data.hexHeadBoltTypes}"
         bolt="#{hex_head_nut_operational.boltAnalysis.bolt}"
         spec="#{hex_head_nut_operational.boltAnalysis.bolt.spec}" />

cc

composite:interface>
    <composite:attribute name="boltTypes" /> 
    <composite:attribute name="bolt" />
    <composite:attribute name="spec" />

I gather you're having trouble figuring out how to use an abstract bolt with a generic abstract bolt spec. In a good abstract class with common properties (and getters/setters) it should not have been necessary to repeat the getter/setter in every subclass and delegate to super . The mistake in your getSpec() attempt was likely that you didn't delegate to super . Moreover, the in subclass repeated spec property is unnecessary.

public BoltSpecHexHead getSpec() {
    return (BoltSpecHexHead) super.getSpec();
}

public void setSpec(BoltSpecHexHead spec) {
    super.setSpec(spec);
}

Actually, this is not DRY . If the property of the abstract class is in turn also abstract, and you want to avoid casting hell, then you'd better make it a parameterized type.

public abstract class BoltSpec {

    // ...

}

public abstract class Bolt<S extends BoltSpec> {

    private S spec;

    public S getSpec() {
        return spec;
    }

    public void setSpec(S spec) {
        this.spec = spec;
    }

}

public class BoltSpecHexHead extends BoltSpec {

    // ...

}

public class BoltHexHead extends Bolt<BoltSpecHexHead> {

    // ... (note: no getSpec()/setSpec() necessary!)

}

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM