內容 |
|
I haven't encountered problems running JForum on Java 11. If there were any, that would certainly be a bug that would likely be fixed soon.
As to Jakarta 9, I have just done a quick test on Tomcat 10.1, and it seems to runs fine in Tomcat's webapps-javaee folder. Have you tried that? I'm not sure if other servlet containers have a similar facility.
As to the underlying question: eventually we'll certainly require newer Java and JakartaEE versions, but given that it seems to run fine as is, it's not a high priority right now.
|
|
|
You can try this jar file - it has the mail sending fixes.
|
|
|
Turns out that there were not one, but two bugs in the mail sending code - which must have been there for ages, without anyone ever noticing them. Kudos for triggering them!
|
|
|
My reading of the situation was pretty much completely wrong, including the use of the "Allow HTML" setting. The relevant setting that goes with "notifyText" is actually "Include the message contents within the notification email".
But that doesn't seem to have to do anything with the bug, which I suspect is caused by reusing the MimeMessage object. I need to look into avoiding that.
|
|
|
That doesn't look like the right fix, but don't worry - I already have a fix, and just need to test it. Patience
|
|
|
Yes, that's exactly what it is.
|
|
|
What I meant is: if at least one of them has HTML turned on, and at least one of them has it turned off.
Yes, that code section may well be the problem.
Config info is taken from the SystemGlobals.properties and jforum-custom.conf files. The DB table serves mainly as a backup of jforum-custom.conf.
|
|
|
I think this can happen if some of the users have "Allow HTML" turned on in their profile, and some users do not.
|
|
|
I'm not sure, as I don't use HTML emails, but I'll take a look.
|
|
|
In the file templates/default/user_profile.htm, replace registrationDay with registrationDate - that will use the format you selected. Note that in the topic view, the format will still use the short version "Jul 6, 2011", because there space is at a premium.
Attached is a new JForum jar file that has the fix for Oracle. If you replace the one you have with this one, it should work regardless of the cache setting. Let me know how it works out for you.
|
|
|
jdev1 wrote:I found reason of my problem it's "topic.cache.enabled" in SystemGlobal.properties. When it's "true" it uses selectAllByForum with MAX.integer as argument that's why it was 2147483647 as value.
That addresses the symptom, not the problem. If I provide you with a version that includes the fix I posted above, would you be willing to test that?
|
|
|
AN NPE sounds like some value is missing, so make sure all fields required for sending emails (basically, all fields above "Send a test email") have correct values in them.
|
|
|
jdev1 wrote:I looked at the history of sql queries in Oracle and saw that when executing the query Topic Model.selectAllByForumByLimit variables for the block "WHERE LINENUM >= ? AND LINENUM < ?" 0 and 2147483647 are passed.
The value 2147483647 interesting, that sounds suspiciously like "-1", as used in GenericTopicDAO.selectAllByForum, and should cause TopicModel.selectAllByForum to be used rather than TopicModel.selectAllByForumByLimit. That is an optimization which apparently was never fixed for the Oracle code.
I think this is what should be in OracleTopicDAO:
@Override public List<Topic> selectAllByForumByLimit (final int forumId, final int startFrom, final int count)
{
if (count < 0)
return super.selectAllByForumByLimit(forumId, startFrom, count);
else
return super.selectAllByForumByLimit(forumId, startFrom, startFrom + count);
}
|
|
|
No, it should be TopicModel.selectAllByForumByLimit in oracle.sql
I don't recall when selectAllByForum is executed, and when selectAllByForumByLimit, but only the latter one is overridden for Oracle.
|
|
|
|
|
|