Upgraded from 4.7.2 (x86, jdk8) to 4.8.0 (x64, jdk21)… Steps taken:
uninstalled jdk8
installed jdk21x64
stop OF service
installed OF4.8.0 but changed path to ‘program files (x86)’ so as to overwrite existing installation
OF4.8.0 came up just fine and all is working perfectly. Users, settings, groups, plugins… except for Presence Plugin. All calls that used to work just fine, now yield something like this…
java.lang.NoSuchMethodError: ‘boolean org.jivesoftware.openfire.user.UserManager.isRegisteredUser(java.lang.String)’ at org.jivesoftware.openfire.plugin.PresencePlugin.getPresence(PresencePlugin.java:229) at org.jivesoftware.openfire.plugin.presence.PresenceStatusServlet.doGet(PresenceStatusServlet.java:93) at javax.servlet.http.HttpServlet.service(HttpServlet.java:503) at javax.servlet.http.HttpServlet.service(HttpServlet.java:590) at org.jivesoftware.openfire.container.PluginServlet.handleServlet(PluginServlet.java:468) at org.jivesoftware.openfire.container.PluginServlet.service(PluginServlet.java:109) at javax.servlet.http.HttpServlet.service(HttpServlet.java:590) at org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1419) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:764) at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1665) at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:174) at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:292) at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77)
Wow, fast turnaround! That totally gets it back to working the way it used to.
One issue remains… which might have been a problem even before… Most user calls using text or image syntax work fine:
…but some users return “null”. If I change the type on those null guys to XML, this is the return (no ‘show’ or ‘status’, and brokenness in that block):
1
Again, most work fine whether pidgin or spark. Honestly I dont care too much about the block, but it would be nice if could be returned no matter what.
Again, most work fine whether pidgin or spark. Honestly I dont care too much about the block, but it would be nice if [status] could be returned no matter what.
Can you edit your last few posts to get the formatting right? When you use three backtick (`) characters in a row, then everything that follows will be shown as raw data (until you use another three backticks).
This correctly returns a valid image for all: /plugins/presence/status?jid=username@server.com
This works for most but sometimes returns a null even when the user is online and available: /plugins/presence/status?jid=username@server.com&type=text
When null is returned for text, this is typical of the xml for that user: /plugins/presence/status?jid=username@server.com&type=xml
Apart from the obvious bug (‘null’ should not be shown), there’s another oddity with the type=text variant: this shows the last known presence status, even if that is not the current status.
after some more tests, I see that for those ‘broken’ ones, if the person goes offline, then it does work consistently for all types. It only seems to become broken when those users go online, which leads me to believe that it might be client related, or rather some setting in the client? I will try some different clients and settings and see what I can find. Thanks for all your help!
Spark client works fine across the board. It’s a pidgin issue and just for a few of my user PC’s (unfortunately including my own). Some with Pidgin work fine, some don’t. I’m up to date so it’s going to take some more investo to determine the true cause.
Great! Additionally, I can provide some final insight after running more tests (in Pidgin).
It appears to be a Pidgin bug. For this particular issue, null is returned only when status is “Available” and MESSAGE is not entered (blank). If you are unavailable with or without a status message… or if you are “Available-and-have-status-message” going, then it properly returns a usable presence status every time.
I can’t say if this this affects every Pidgin install out there but it certainly affects mine (latest Pidgin build 2.14.12). I don’t have anything fancy with my installation, and very few plugins enabled. No weird saved statuses. This just seems to be how it works on mine.
The workaround is… make a custom message for the Available status and “Save and Use” it… then also in Preferences->Status/Idle, set “Use Status From last Exit at Startup”=YES. This makes your custom Message always in play for ‘Available’, after which, presence lookups will always return something other than null.
I look fwd to any fixes you eventually provide, but for now at least I have a workaround.