Hi, it’s me again.
I’m in the process of updating our company custom plugins for openfire 4.3.2 (We previously ran stable on 4.1.6).
I have of course started migrating to maven, but that’s ok, and I am grateful for the amount of examples provided by the other plugins in this direction.
I am having a bit of a headache with jsp admin pages though.
From the logs it looks like they are being compiled correctly, and the menu items are added in Openfire Web Admin UI, however, if I click on any of them, not a single one works. They all go out as not found with a 404. There doesn’t seem to be anything in the logs either.
From my understanding, to get a jsp added to the admin UI we need to:
- Specify where it goes in the plugin.xml
- Specify pageId in the jsp
- Add jetty-jspc-maven-plugin in the pom plugins
- Add com.sun.jersey.Bundle to dependencies in pom.
Now, my experience is very limited with Maven, so it may be that I’m missing something.
I can provided anonimized poms and plugin files if needed.
Thanks in advance, any help welcome as I’m stumped as to why they’re not getting loaded.
Your best bet is to start with a working plugin; https://github.com/igniterealtime/openfire-xmldebugger-plugin is perhaps the simplest around, it only has one JSP page, but it does work.
There are a number of things to note;
pom.xml specifies the
maven-assembly-plugin to bundle the files up in to the required JAR format.
org.igniterealtime.openfire:plugins:4.3.0 as a parent. If you want the plugin to work on earlier versions as well, you may need to specify an older version of Jetty to compile your JSP pages (see the bookmarks plugin for how this can be done, but it does prevent you from using Java 8 syntax such as lambdas in your JSP pages). You’ll obviously also need to avoid using any features new to Openfire 4.3 to maintain backward compatibility, too.
- You must have a
src/web/WEB-INF/web.xml file for things to work. The XML Debugger plugin has the smallest possible one - it largely only exists as in indication that JSP compilation is required.
Thanks for the answer, I will try starting back from one of the working plugins as you said and try to eke out any differences in the pom or in the jsp structure.
I always had a bit of a hard time with getting the admin part of plugins to work, so it’s likely some small mistake carried over version by version and finally became incompatible with the newer versions of openfire.
Once I figure it out I’ll write here the solution, should anyone else stumble on the same path.
Sorry for the very late comeback, actually I found to my dismay that if I try to maven package xmldebugger or dbaccess plugins for example (Based on v.4.2.3 openfire codebase) neither produce working admin page links on our test server (Still running 4.2.3 because of this issue but that’s another story).
I think there must be something fundamentally wrong with what I am doing.
I’ll recap what I’m doing:
Platform Mac OS X 10.14.6
JDK 11 but compiling using IDE related JDK 1.8
IDE is IntelliJ CE latest version
using Build Project -> Openfire Plugin name compile / package.
The jar I get in the targets contains the compiled jsp files but they don’t get mapped once I upload them to the server. I can upload an example packaging of the xmldebbugger or other plugin for reference of course.
Thanks in advance,
Also, if relevant, I am now trying moving everything to 4.4.1 to see if it makes a change.
The JSPs apparently get added in…
Logical path in plugin is:
Plugin.xml specified item is:
<sidebar id="mobile-admin" name="Mobile Notifications">
<item id="mobile-admin-configuration" name="Mobile Notifications Configuration" description="pluginName Configuration parameters" url="configuration.jsp"/>
Clicking on the link in the Admin UI I get forwarded to:
http://serveraddress:9090/plugins/pluginName/configuration.jsp with a 404 error
Nothing gets logged in Jetty for these attempts, not even at Debug Level.
Has the name / path resolution changed?
Ok wait, really sorry, I hadn’t noticed the naming had changed for WEB-INF custom xml file from web-custom.xml to web.xml alone. I had followed the various steps but renaming the WEB-INF file had escaped me.
My bad. Routing seems to work again now.