I only see some warnings in the error console and none of it seems to be critical.

@cvoronin: what are these errors in the Firefox console? Do they seem to be related to this issue?
If so, could you attach them to this issue?

I'm not 100% sure yet, but I believe the completion of JENKINS-4346 has solved this issue.

I always got the sense that the disappearing configuration screens had something to do with the connect-at-startup. I'm not familiar with Hudson's plugin architecture, but perhaps the jabber plugin's long initialization somehow made it miss the opportunity to make Hudson aware of its configuration forms?

I do not believe the JavaScript errors have to do with this error (I have not seen these myself). Further your observation in a comment upstream:

"I've heard from other users where this workaround fixed it permanently."

I do not believe is true – the fix would only last until Hudson's next startup.

I'll observe the behavior over the next few days and report back.

UPDATE Alas, I was wrong. Looks like I'll be having to remove the config file with each restart again.

What other plugins do you have installed? Maybe this a interplay with other plugins.
Also: did you have a look at the HTML source of the config page? Anything suspicious in it?
Maybe you could attach it here, too?

I am also getting this error.

From my perspective, it is definitely nothing to do with plugins as I disabled all of them. I also commented all of the jelly code in global.jelly to see if it is something to do with the view and the section header still doesn't even show up. Digging deeper into it, I narrowed it down to around the super.load() area called in JabberPublisherDescriptor.java. It's either when XStream is trying to unmarshall the XML file or when this command is called: JabberIMConnectionProvider.setDesc(this); The workaround works for me though (i.e. setting enabled = false in the config file) but it is not a solution as we want to push hudson to a prod environment

It's possible that an exception is being thrown somewhere and not being caught/logged so it makes it much more difficult to debug.

The funny thing is, I cannot replicate this issue on my local machine which is using glassfish v3 + java 6 on Ubuntu. However, our staging and prod environment is using glassfish v2.1 EE + java 6 on solaris 10 and it is occurring there so I don't know if this is a platform specific problem.

UPDATE: Nothing to do with XML unmarshalling in Xstream but definitely something within the call to JabberIMConnectionProvider.setDesc(this); I forced enabled = false before the call to "isEnabled()" in the JabberPublisherDescriptor constructor so it would instead call JabberIMConnectionProvider.setDesc(null) and the section reappears correctly. Of course when this is done, we would have to wait until the next retry attempt for the BOT to come online

UPDATE 2: Seems like something to do with the Authenticator. Commenting line 100 in IMConnectionProvider.java will fix the problem but then will not allow users to send certain commands to the bot:
//this.authentication = Hudson.getInstance().getSecurityRealm().getSecurityComponents().manager.authenticate(tmp);

UPDATE 3: Looks like the call to Hudson.getInstance().getSecurityRealm().getSecurityComponents().manager.authenticate(tmp); causes this issue for me (even when I don't assign it to the bean property). Since this goes into Acegisecurity, I will not dive any deeper since I have a decent workaround. If you secured hudson and are having this Jabber section disappearing issue, DO NOT enter anything in "Hudson Username" and "Hudson Password". Alternatively, you can delete the lines that contain <hudsonCiLogin> and <hudsonCiPassword> in hudson.plugins.jabber.im.transport.JabberPublisherDescriptor.xml. )Note that it is not good enough to clear the contents in the above two tags, you have to delete it since the plugin checks for null, not empty string)

Anyways, by not entering anything, it will not call the above statement to authenticate. I'm not sure what commands are missing for a non-authenticated user but the commands available to me are sufficient (i.e. running adhoc jobs and receiving notification for failed jobs are available). Again, this doesn't happen in all environments so there has to be some issue with the platform itself.

Great finding Derek!
I'll try to reproduce it this way.

Could someone please try the attached plugin snapshots to confirm that they fix the problem?

Code changed in hudson
User: : kutzi
Path:
trunk/hudson/plugins/instant-messaging/src/main/java/hudson/plugins/im/AuthenticationHolder.java
trunk/hudson/plugins/instant-messaging/src/main/java/hudson/plugins/im/IMConnectionProvider.java
trunk/hudson/plugins/instant-messaging/src/main/java/hudson/plugins/im/bot/Bot.java
trunk/hudson/plugins/ircbot/src/main/java/hudson/plugins/ircbot/v2/IRCConnection.java
trunk/hudson/plugins/ircbot/src/main/java/hudson/plugins/ircbot/v2/IRCConnectionProvider.java
trunk/hudson/plugins/jabber/src/main/java/hudson/plugins/jabber/im/transport/JabberIMConnection.java
trunk/hudson/plugins/jabber/src/main/java/hudson/plugins/jabber/im/transport/JabberIMConnectionProvider.java
http://jenkins-ci.org/commit/33296
Log:
JENKINS-5233 JENKINS-5978 Jabber/ircbot section wasn't showing up in global configuration page

fixed to my best knowledge in Jabber plugin v1.11.
Please reopen, if not

jabber plugin has been working reliably since this change.

I'm very pleased this issue is now fixed. Thank you!