Not only are the tabs grey and empty, but you can't select them by
clicking on the title bars.

But if I open the Output Window manually from the Window menu, then
suddently these tabs can be selected and show contents.

So sounds like some problem in the window system to me.

I'll look into this.

I suspect the problem is that componentActivated() (an optimization hook that lets 
explorer/editor components get constructed but not initialized until shown) is never 
getting called.  If the component is opened normally, it will be.  What is jelly doing to get 
these components on the screen?  If it goes through the window system action, it should 
work fine;  if it is doing something else it might not.

it should be componentShowing() not componentActivated() as mentioned
in  Tim's comment

Jirka: is it possible that xtest calls the window system API outside
AWT event queue thread?

Okay, assorted test compilation problems are fixed for core & openide.  Regarding these 
tabs, two ways to set the selected tab:

someTabbedContainer.getSelectionModel().setSelectedIndex(i)
or faking a mouse event in the rectangle of a tab.  
This should generate a change event which will cause componentShowing() to be called on 
the component.


I've tried putting some logging and stack dumps into jemmy, the tab control and the 
winsys, to try to figure out what's going wrong, but I can't seem to find where the actual 
ide.log ends up.  The ide was started with
-userdir /space/nbsrc/xtest/instance/work/sys/ide
but this directory doesn't exist by the time the test suite finishes.

I don't think it something with jemmy/jellytools. Already when IDE is
started by XTest, the projects tab is grey. Tests starts later.
To see userdir after test finishes try:

cd ide/test
ant

Then ide\test\work\sys\ide directory is not removed.

Okay.  Is there *anything* that is different about how the IDE is started when tests are run 
than how it is started normally?  Any classpath differences, anything?  Anything different in 
the sequence of showing the main window?  

BTW Tim: now var/log/messages.log, not system/ide.log.

Classpath should be obvious from IDE log (XTest add something). Also
you can look at
xtest/plugins_src/ide/src/org/netbeans/xtest/plugin/ide/Main.java.

Well no surprise then; XTest's Main is probably wrong.
core/bootstrap/src/org/netbeans/Main.java for one thing is not run by
it at all, which I'm sure can cause it to behave differently from the
real IDE.

I am excluding the failing tests from commit validation for the moment
so others can work with the trunk without getting confused by this:

committed     Up-To-Date  1.7         ide/test/cfg-qa-functional.xml

IMHO XTest's ide-mode launcher needs to be completely rewritten as a
module which runs the tests, and placed in a separate dir (so that
netbeans.dirs can include it), and the IDE launched with the supported
nbexec launcher. Best would be to exclusively use the CLI facility to
communicate with the IDE, so that the IDE is launched in a completely
normal mode (just added inst dir containing the XTest hook module),
with a command-line param giving the name of the first test to run and
a classpath etc. for it (generally, all required info); subsequent
tests would be run by running the launcher again with similar args
(reusing the same running IDE; at the end of a test run the XTest
framework sends a special command to shut down the IDE.

BTW mount/unmountFileSystems are useless now. Repository.fileSystems
is not used any more.

TBD where the bug is; could be in core. But since it is not observed
in normal IDE usage, have to assume a bug in XTest may be triggering it.

> core/bootstrap/src/org/netbeans/Main.java for one thing is not run by
it at all

really?  I think XTest's Main is launched by org.netbeans.Main via
-Dnetbeans.mainclass=<XTest's Main>

Nonetheless here is some more info

1) I've removed -Dnetbeans.mainclass from
./xtest/plugins_src/ide/lib/ide_plugin_targets.xml which causes the
IDE to be run the usual way.  It works.  Projects tab comes up fine.

2) the var/log/message.log contains ZipExceptions thrown by
ModuleManager, that's because xtest passes non-existing dirs/jars to
it using -J-Dnetbeans.systemclassloader.patches

3) the IDE is launched w/
-J-Dtbag.classpath=.../ide/test/work/sys/tests/qa-functional/src;/h/ttran/work/...
Note semicolon (;) is used as separator even on Linux

> I think XTest's Main is launched by org.netbeans.Main via
> -Dnetbeans.mainclass=<XTest's Main>

OK, good if so... that leaves a number of other things in XTest's main
class which may or may not match the current impl in core (where I
know there were some changes recently but I don't know many details).
One area to look at: the code which checks for quiescence of EQ. Looks
probably harmless but I am not sure.

> 2) the var/log/message.log contains ZipExceptions thrown by
> ModuleManager, that's because xtest passes non-existing dirs/jars to
> it using -J-Dnetbeans.systemclassloader.patches

I fixed it. Directory ${xtest.testtype}/src was removed from
tbag.classpaths. It also means you cannot use
ATest.class.getResource() as ant/project tests did. I removed them
from xtest/instance/master-config.xml.

> 3) the IDE is launched w/
>
-J-Dtbag.classpath=.../ide/test/work/sys/tests/qa-functional/src;/h/ttran/work/...
> Note semicolon (;) is used as separator even on Linux

Fixed in MTestExecutor.

As Jesse pointed out the code which checks for quiescence of EQ in the
Main is guilty. But I don't know why. I thought it is independent on IDE.

Tim, if I remove code which waits for quiescence of EQ, IDE works
properly. But I don't want to throw away such a functionality because
it satisfies that IDE is initialized. We call
Toolkit.getDefaultToolkit().addAWTEventListener and that probably
clash with stuff in org.netbeans.core.windows.view.ui.TabbedHandler.
Could you look at it? I do not think XTest does something wrong.

Re. EQ quiescence test - still don't see anything obviously wrong. It
adds and removes itself as a Toolkit listener from a non-EQ thread,
which is probably safe. Some static methods are called as if they were
instance methods, but that is just poor style; harmless. Maybe it's
just that XTest is calling Toolkit.getDefaultToolkit too early in IDE
startup, before something critical has been initialized. Try just
delaying the EQ quiescence test for a few seconds.


Re. #2, test/${xtest.testtype}/src being removed from classpaths - it
should not have been there to begin with, as
build/test/${xtest.testtype}/classes is the correct classpath entry...
it does include resources as least when built by projectized.xml:

        <copy todir="${build.test.unit.classes.dir}">
            <fileset dir="${test.unit.src.dir}">
                <exclude name="**/*.java"/>
            </fileset>
        </copy>

If xtest-unit.xml does not do the equivalent then it is buggy.

Jirka writes (private mail):

"I reverted my commit to MTestExecutor because also other tests expect
golden file from sources on the classpath. So, your tests will work. I
need to fix it a different way."

Suggest that the executor again exclude this dir, and the compiler be
fixed to copy resources into the classes dir.

Delaying the EQ quiescence helps. But I am not sure this is a reliable
workaround.

I can't imagine what difference adding/removing an AWTEventListener can do - possibly it 
would affect the order in which things are added/removed; if your event listener consumes 
events, that would definitely affect things.  

The AWTEventListener in TabbedHandler is absolutely critical - it's the thing that causes 
different components to become activated on mouse clicks - there is no other reliable way 
to do this (trying to do it via focus events, etc. is what made the old window system have 
so many problems).  I've got a feeling the actual AWTEventListener is not the problem in 
and of itself.  It will synchronize on Toolkit.getDefaultToolkit(), but that should be all it 
needs to be safe from whatever thread.

Could you tell me exactly where the EQ quiesence code is, and exactly how to start 
NetBeans with it without running the entire suite or having it time out and get shut down?  
I need to see the code.

Possibly unrelated, terrifying code in core that could affect anything that touches the EQ 
(which btw, may be wrong - invokeAndWaiting it does not guarantee when it will run, 
which is what the comment says it's trying to do); if you're trying to do anything really 
funky with the event queue, you may not actually be getting the real event queue:

  protected void initializeMainWindow () {
    StartLog.logStart ("Main window initialization"); //NOI18N

    // #28536: make sure a JRE bug does not prevent the event queue from having
    // the right context class loader
    // and #35470: do it early, before any module-loaded AWT code might run
    // and #36820: even that isn't always early enough, so we need to push
    // a new EQ to enforce the context loader
    // XXX this is a hack!
    try {
        SwingUtilities.invokeAndWait(new Runnable() {
            public void run() {
                
Thread.currentThread().setContextClassLoader(getModuleSystem().getManager().getClassL
oader());
                Toolkit.getDefaultToolkit().getSystemEventQueue().push(new EventQueue());
            }
        });
    } catch (Exception e) {
        e.printStackTrace();
    }

(never mind about invokeAndWaiting not guaranteeing when it will run, somehow I had 
invokeLater in my head).

The code is in
xtest/plugins_src/ide/src/org/netbeans/xtest/plugin/ide/Main.java.
Look for initThread and QueueEmpty. If I add Thread.sleep(1500) before
initThread.start() it works. The difference is that the listener in
TabbedHandler is added before the listener in QueueEmpty. If it is in
reverse order it doesn't work.
To test it:
cd nb_all/ide/test
ant

what is the status of this bug?  It seems to me the trouble is xtest
is doing something untraditional.  Jiri S, you have to take the lead
on this.  Someone from core team then can assist you.  You're the only
one who understands how xtest works or should work.

I reassign this issue to xtest.  Please do the investigation, once
it's clear what needs to be done in core to make xtest work, reassign
it back.

Thanks

Suggestion:  Use System.identityHashCode() and make sure the event queue you're waiting 
for is really the same event queue the system is using the whole time.  I have a feeling it 
isn't.

BTW, another way to wait for even queue drainage (maybe):  An event that reposts itself 
when it runs, a minimum of N times, after which it continues reposting itself until the 
average time between invocations stabilizes.  Not sure if it wouldn't have some problems, 
but it might be interesting as a less invasive solution and one which will work no matter 
what foreign code does to the event queue.

The problem is JDK issue 4924516 (SHOWING_CHANGED event is not
propagated to all HierarchyListeners). It is fixed in 1.5.0. The
summary is that XTest does nothing illegal but IDE is relying on a
buggy feature of JDK. I added a workaround to XTest:

/cvs/xtest/plugins_src/ide/src/org/netbeans/xtest/plugin/ide/Main.java,v
 <--  Main.java
new revision: 1.11; previous revision: 1.10

Verified - JDK bug.

I've added a workaround for the JDK bug to TabbedContainer, so overrides addNotify(), 
and on JDK 1.4, will fake its own HierarchyEvent.  So this should work now.

Jirko, this:

>To test it:
>cd nb_all/ide/test
>ant

doesn't actually do anything, just exits after running no tests, so at the moment I can't 
actually reproduce the fix.  If it does work, please close;  if it doesn't, I don't know what 
else I can do.

It doesn't work. You can test it with TabbedHandler patch. Just apply
the patch and run IDE as usual (no XTest needed).

Created attachment 14681 [details]
TabbedHandler patch to reproduce the problem

It is not an XTest but JDK issue. It is fixed in JDK1.5.0. Workaround
in XTest works, workaround in TabbedContainer doesnt'. Signing as
wontfix because I can't do anything more.

Verified.