Hiya Ian.

Could you please clarify what further manifest properties are used by JON and what values are expect?  For example, how would you determine that this was a SOA version of run.jar rather than an EAP version?  Would the suffix be sufficient?

It would be better to nail all these in one go.

Thanks

Link: Added: This issue related SOA-465

Sure.

We currently only use Implementation-Version and Implementation-Title.

The value of Implementation-Version is tokenized on whitespace, and the first token becomes the Resource's version. For example, if the Implementation-Version was "4.3.0.GA_CP02 (build: SVNTag=JBPAPP_4_3_0_GA_CP02 date=200808051050)", the Resource version would get set to "4.3.0.GA_CP02". The Resource version is used in a couple places on the Agent side - for example, it is used to determine if the AS version is supported by JON (i.e. >= 3.2.3 and < 5.0.0), as well as to figure out the default configuration name and binding address. On the Server side, the Resource version is displayed in the Summary header when viewing the Resource. It is also used when figuring out which CPs from a subscribed patch channel apply to the Resource. Each CP entry in the patch feed lists one or more resourceType/version tuples that it applies to. JON lists a CP as being applicable to a Resource if that Resource's type/version matches one of the type/version tuples in the CP's feed entry. Given the way this matching is done, I think it would be safe to change the Implementation-Version for SOA 4.3 to "4.3.0.GA_SOA". Of course, once CPs are released for SOA 4.3, their feed entries should use this same version string. The key thing is that SOA 4.3 version contain the "SOA" substring somewhere in it to differentiate it from AS 4.3.0.GA and EAP 4.3.0.GA. AS, EAP, and SOA-P Resources all have the same resourceType in JON - "JBossAS Server", and since the CP matching algorithm uses resourceType and version to determine applicable patches, we need to make sure the version differentiates AS, SOA, and EAP.

As for Implementation-Title, we use that to figure out if the app server is AS, EAP, or SOA-P, i.e.:

    public static JBossProductType determineJBossProductType(Attributes attributes) {
        JBossProductType result = JBossProductType.AS;
        String implementationTitle = (attributes != null) ? attributes.getValue(Attributes.Name.IMPLEMENTATION_TITLE) : null;
        if (implementationTitle != null) {
            if (implementationTitle.equalsIgnoreCase("JBoss [EAP]")) {
                result = JBossProductType.EAP;
            } else if (implementationTitle.equalsIgnoreCase("JBoss [SOA]")) {
                result = JBossProductType.SOA;
            }
        }
        return result;
    }

We then use this knowledge to set the default name and description for the different product types, i.e.:

    AS("JBossAS", "JBoss Application Server", "default"), // the public offering
    EAP("JBossEAP", "JBoss Enterprise Application Platform", "production"), // the customer offering
    SOA("JBossSOA", "JBoss Enterprise SOA Platform", "production"); // the customer SOA platform

    public final String NAME;
    public final String DESCRIPTION;
    public final String DEFAULT_CONFIG_NAME;

    JBossProductType(String name, String description, String defaultConfigName) {
        this.NAME = name;
        this.DESCRIPTION = description;
        this.DEFAULT_CONFIG_NAME = defaultConfigName;
    }

Keep in mind that these are just defaults. The user can change the name or description of a Resource via the GUI.

Thanks Ian.

It looks like we may only have one outstanding issue in that case, differentiating between our two servers.

The configurations we have are

- standalone with a default configuration of 'default'
- embedded with a default configuration of 'production'

From what I can see from your last comment, you only (currently) cater for the embedded version and are not capable of handling the standalone version.  Is this correct?

If we are then to distinguish between standalone and embedded for the purpose of updating, does this mean that we must use different Implementation-Version strings?  Perhaps 4.3.0.GA_SOA and 4.3.0.GA_SOA_STANDALONE?

If I have understood your previous comments then this would appear to remove any clashes during the update process but, obviously, would not handle the different default configuration names.

Thanks again,
Kev

the JON team also need to make sure that there is no way that EAP patches can be applied to SOA embedded server and vice versa 
it may be possible to apply  an embedded patch to standalone BUT they would have to ensure only a subset of the files would be applied. I'm not sure this is possible with JON ie one patch but two different file lists, so it is probably better to make sure they are clearly identified as separate as well.

For those not familiar with the difference NB - the default configurations are different between the two

soa-4.2.0.GA.zip is the full appserver based on EAP with ESB Drools etc. also known as the embedded version
it has the following configs - all, production, default and minimal - the default config is production

standalone-soa-4.2.0.GA.zip is our "lightweight ESB server" it is a trim and slim version that is specifically for ESB use cases, not a full J2EE stack
it only has a default config which is why the default config differs between the two

Kev, Trev,

Yes, I am in agreement. SOA and SOA Standalone should definitely have different Implementation-Versions. This will allow different CPs to be released for the two products and allow the version to be used to distinguish which product the CP applies to.

Trev, thanks for the info on the default configs. We'll update JON to detect the default configs appropriately, though this won't make it into JON 2.1. If you guys want, we can also make the default Resource name and description for SOA Standalone to contain "SOA Standalone ..." to distinguish it from full SOA.

Thanks,
Ian

Can you make the default Resource name and description for SOA Standalone contain "SOA Standalone

Link: Added: This issue related JBNADM-3551

SOA-P piece of this task is done - remaining JON part is tracked here:  https://jira.jboss.org/jira/browse/JBNADM-3551