> Steps to Reproduce:
> 1. create a bundle and install to group with standalone EAP server
> 2. deploy the bundle
> 3. remove the bundle
> 4. upload another bunle
> 5. try deploying bundle to the existing or new bundle group
> 
> Actual results:
> after step5. unable to select a resource group to deploy bundle to - even
> after create new 
> 
> Expected results:
> installing bundle to existing and/or new group works fine

We need more specific description here because some of the terms used are ambiguous. I'm confused what these replication steps are doing. For example:

Step 1. says "create a bundle and install to group" but then step 2 says "deploy the bundle".  What does "install to group" mean as opposed to "deploy the bundle" - installing to a group means deploying? Or do you mean using a "bundle group" in step 1? I dont know what you mean when you say "install to group" because that seems to mean the same as "deploy the bundle" - what kind of "group"?

Step 3 - When you say "remove" the bundle, I assume you mean you hit the "delete" button which undeployed. Or do you mean "revert" or do you mean "removing from the bundle group"?

Step 5 you say "deploying bundle to existing or new bundle group" - you don't deploy to bundle groups, you deploy to resource groups.

So - can you rewrite those replication steps with more explicit details so we know exactly what you do? What are the buttons you press, or the links you go to, and the words on the screen? Because things like "group" and "deploy" and "remove" can mean different things.

For the record, I just uploaded three bundles (v1, v2, and v3) and put them in the default, "unassigned" bundle group. I created a resource group with a single platform in it. I then deployed v1, then deployed v2 to that resource group. I then deleted the bundle v2 and then deployed v3 to the same resource group (I used the same bundle destination on all deployments). Things seemed to work.

Created attachment 933824 [details]
ClusterWebApp

Created attachment 933825 [details]
ClusterWebApp_1.2.2

based on what I see on the remote machine that is exhibiting this behavior, this code is the problem, in GetDestinationStep.groupSelectionChanged(Integer):

bundleServer.getResourceTypeBundleConfiguration(selectedGroupId.intValue(),
    new AsyncCallback<ResourceTypeBundleConfiguration>() {
        public void onSuccess(ResourceTypeBundleConfiguration result) {
            // populate the base location drop down with all the possible dest base directories
            LinkedHashMap<String, String> menuItems = null;
            if (result != null) {
                Set<BundleDestinationSpecification> destSpecs;
                destSpecs = result.getAcceptableBundleDestinationSpecifications(
                    wizard.getBundle().getBundleType().getName());

                if (destSpecs != null && destSpecs.size() > 0) {
                    String defaultSelectedItem = null;
                    menuItems = new LinkedHashMap<String, String>(destSpecs.size());
                    for (BundleDestinationSpecification spec : destSpecs) {
                        if (spec.getDescription() != null) {
                            menuItems.put(spec.getName(),
                                "<b>" + spec.getName() + "</b>: " + spec.getDescription());
                        } else {
                            menuItems.put(spec.getName(), spec.getName());
                        }
                        if (defaultSelectedItem == null) {
                            defaultSelectedItem = spec.getName();
                        }
                    }
                    destSpecItem.setValueMap(menuItems);
                    destSpecItem.setValue(defaultSelectedItem);
                   destination.setDestinationSpecificationName(defaultSelectedItem);
                }
            }
            ...

So either bundleServer.getResourceTypeBundleConfiguration returned null or result.getAcceptableBundleDestinationSpecifications returned null or was empty.

From the #Test page, in the Hibernate page, I execute this:

select rt.bundleConfiguration from ResourceType rt where rt.name = 'JBossAS7 Standalone Server'

This tells you the configuration ID of the bundle config. Take that ID and execute this:

select c.properties from Configuration c where c.id = '10715'

where 10715 is the config Id. You should see the config.

On my box, it gives me data. But on the remote test machine where the BZ is failing, I'm getting this error:

org.hibernate.hql.internal.ast.QuerySyntaxException: unexpected token: c near line 1, column 8 [select c.properties from org.rhq.core.domain.configuration.Configuration c where c.id = '10963']

I don't know why.

OK, Armine, don't need anything from you. I see it. Its easy to reproduce. No need to remove bundles or anything. 

1) Import an EAP instance (I used a 6.3 instance)
2) Create a compatible group with the one EAP instance in it
3) Upload one of the bundles attached to this BZ
4) Select bundle and elect to "deploy" it
5) In the Bundle Deploy Wizard, in the group drop down, select the group you created in step 2
6) *bug* notice there is no radio buttons to select for "base location"

I think there is something with hibernate here. This works on a master RHQ build, but not a JON build. So its the difference between alpha and GA versions of EAP 6.3 and their hibernate versions.

Whether the following is related or not I do not know, but its possible - find out what the bundle config is for the JBossAS7 Standalone resource type via the #Test page (Hibernate subpage):

select rt.bundleConfiguration from ResourceType rt where rt.name = 'JBossAS7 Standalone Server'

This tells you the configuration ID of the bundle config. Take that ID and execute this:

select c.properties from Configuration c where c.id = '#'

where # is the config Id. You should see the config. However, a parse error results: 

org.hibernate.hql.internal.ast.QuerySyntaxException: unexpected token: c near line 1, column 8 [select c.properties from org.rhq.core.domain.configuration.Configuration c where c.id = '10559'
]
	at org.hibernate.hql.internal.ast.QuerySyntaxException.convert(QuerySyntaxException.java:54)
	at org.hibernate.hql.internal.ast.QuerySyntaxException.convert(QuerySyntaxException.java:47)
	at org.hibernate.hql.internal.ast.ErrorCounter.throwQueryException(ErrorCounter.java:79)
	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:278)
	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:182)
	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:138)
	at org.hibernate.engine.query.spi.HQLQueryPlan.(HQLQueryPlan.java:104)
	at org.hibernate.engine.query.spi.HQLQueryPlan.(HQLQueryPlan.java:79)
	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:168)
	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:222)
	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:200)
	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1703)

I found that GWT is for some reason sending a second event to the drop down callback where the event.getValue() == null and that causes the problem:

The class: org.rhq.coregui.client.bundle.deploy.GetDestinationStep

I propose this fix (notice "if (event.getValue() != null)" now wraps the body of the onChanged method):

            this.selector.addChangedHandler(new ChangedHandler() {
                @Override
                public void onChanged(ChangedEvent event) {
                    // if the user is typing in the name of the group, and is only partially
                    // done, the event value will be the String of the partial group name.
                    // If the selection is an actual group name, the event value will be
                    // an integer (the group ID) and that is our indication that the selection
                    // of an actual group has been made
                    if (event.getValue() != null) {
                        Integer selectedGroupId = null;
                        if (event.getValue() instanceof Integer) {
                            selectedGroupId = (Integer) event.getValue();
                        }
                        groupSelectionChanged(selectedGroupId);
                    }
                }
            });

I don't know why this only shows in JON builds. In order for me to property test, I'll need to a new JON build with this fix in it. But I will at least make sure this doesn't break RHQ.

with the "fix" in the previous comment, I now see bad behavior in RHQ build. Now, when I select a group, I get the radio buttons, but the text in the drop down field gets blanked out. Again, this happens in production mode, and dev mode, but if in dev mode WITH a breakpoint, then the works fine.

Hi John, just fyi, the issue described in comment #15 is/was visible before the fix (in er01.1)

(In reply to Armine Hovsepyan from comment #16)
> Hi John, just fyi, the issue described in comment #15 is/was visible before
> the fix (in er01.1)

The fix in comment #15 isn't anywhere right now except my local box. I was just saying, when I implement that fix on my box, and rebuild RHQ, I see other issues.

Yes, I see problems in er01.1 - that's where I've been doing most of my testing.

another interesting tidbit with that null-check fix in place:

the FIRST group I select will stay in the text field of the drop down.

But once I start selecting others, then the text field starts getting cleared out after the radio buttons are displayed.

(In reply to Armine Hovsepyan from comment #16)
> Hi John, just fyi, the issue described in comment #15 is/was visible before
> the fix (in er01.1)

OH! Armine - do you mean you see the behavior of the drop down text field get blanked out after selecting groups even in er01.1?

I'm seeing that even after backing out my "fix".

(In reply to John Mazzitelli from comment #19)
> (In reply to Armine Hovsepyan from comment #16)
> > Hi John, just fyi, the issue described in comment #15 is/was visible before
> > the fix (in er01.1)
> 
> OH! Armine - do you mean you see the behavior of the drop down text field
> get blanked out after selecting groups even in er01.1?
> 
> I'm seeing that even after backing out my "fix".

Yes, exactly. And it happens to me only when standalone server group (as destination group) is selected and never happend with domain server group or platform group.

changed title of BZ since this looks more general of a problem.

The problem is for some reason GWT is sending a new change event to the drop down selector widget with a new value of "null". I don't know why it wants to change the selection to null, but that causes all kinds of problems.

I think I fixed it. Committed to master.  Need someone to review and cherry pick to 3.3 branch.

commit 18aa52061a859787b7af997ffe2f145ab0c9a90b
Author: John Mazzitelli <mazz>
Date:   Thu Sep 4 13:13:24 2014 -0400

    BZ 1134486 - bundle deploy wizard group selection drop down is getting some odd events with a null value

Looks like a reasonable solution to eliminating the spurious events that result in null values.

Cherry-picked this to release/jon3.3.x

commit e3a4a32ffe1db6c608fa440651c6312e6d9b0c72
Author: John Mazzitelli <mazz>
Date:   Thu Sep 4 13:13:24 2014 -0400

    BZ 1134486 - bundle deploy wizard group selection drop down is getting some odd events with a null value. don't know why its  happening, but this fix codes around spurious events with new values being null

    (cherry picked from commit 18aa52061a859787b7af997ffe2f145ab0c9a90b)
    Signed-off-by: Mike Thompson <mithomps>

Moving to ON_QA as available for test with the following brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=385149

Created attachment 938501 [details]
bundle_group_standalone

haven't faced the issue in JON 3.3 ER03 - screen-shot of correct behaviour attached - moving to verified.