Hi,
the last version seems to be in http://www.igniterealtime.org/fisheye/browse/svn-org/messenger/trunk/src/java/or g/jivesoftware/database/ProfiledConnection.java?r=1113 and the current code relys on dbutil.jar which includes this and some other classes.On http://www.igniterealtime.org/fisheye/changelog/svn-org/ I can’t find a dbutil project. Any idea whether it is still in SVN?
LG
The .java files are included in the jar, as is done with most (all?) utility jars that Jive builds. Pretty handy
Hi Guus,
as long as I don’t want to edit the source code this may be pretty handy. At least for tinder.jar there is a (small) project in SVN.
I guess that we can delete “stringprep.jar” (another pretty Jive build) in Openfire trunk as now libidn is used.
LG
As long as there’s no particular bug in the library, I’d keep stuff as-is. The current setup has worked for us so far, and I’m not seeing a direct reason why we should change that now. If we’re going to need more modifications, than the odd bugfix that we do now, we can always consider moving this into a small sub-project. Is there any particular reason that you’re asking, or were you just wondering?
Let’s consider if the stringprep library is likely to be used by plugin developers directly. If so, removing the library might break stuff for them. Then again, keep using the library while Openfire is using libidn can cause problems in itself too. I’m not sure what would be best.
Hi Guus,
“Is there any particular reason that you’re asking, or were you just wondering?”
It was Findbugs with “Should ProfiledConnection$TimedCallableStatement be a static inner class?” I really wonder why Jive did make a library with a few files instead of leaving the code where it was. I’d like to remove this library and add the code to trunk again. Or do you think that someone else is using this library (SBS may use it but I wonder whether they use still this version)?
---- 2nd issue in one thread ---- I love to demonstrate bad practices ---- Don’t do this at home (; ----
“*If so, removing the *[stringprep] library might break stuff for them.” If we would add all plugins to Openfire trunk then one could simply check this. Of course there is still the need to distinguish between “supported” and “contributed” plugins. Maybe we can look at this when the new servers are ready.
LG